RMAN

Roberto Sobrinho

30/08/2024

ORA-01196 OPEN RESETLOGS? Como Usar o _allow_resetlogs_corruption para Abertura Inconsistente

Ao tentar abrir o banco de dados no modo RESETLOGS, você pode se deparar com um erro crítico, como o abaixo, que indica que há Inconsistência no banco de dados:

Para lidar com essa situação, o Oracle oferece o parâmetro oculto _allow_resetlogs_corruption, que permite abrir o banco de dados mesmo quando existem Inconsistências nos datafiles. No entanto, é fundamental entender que esse procedimento traz riscos significativos: ele pode resultar em perda de dados, falhas adicionais e pode até mesmo não funcionar. Por isso, deve ser considerado apenas como última alternativa, quando todas as outras tentativas de recuperação falharam. Sempre que possível, consulte um DBA experiente antes de seguir com este método.

Passo 1: Verificando o Status dos Datafiles

Após restaurar o banco de dados, é fundamental verificar o status dos arquivos de dados, especialmente o checkpoint e se algum arquivo está marcado como “fuzzy”. A presença de arquivos “fuzzy” pode indicar que nem todos os dados foram devidamente gravados no disco, o que significa inconsistências no banco de dados.

SET LINESIZE 200
SET PAGESIZE 100
SET COLSEP ' | '
COLUMN status FORMAT A10 HEADING "Status"
COLUMN checkpoint_change FORMAT A15 HEADING "Checkpoint_Change"
COLUMN checkpoint_time FORMAT A25 HEADING "Checkpoint_Time"
COLUMN cnt FORMAT 99999 HEADING "CNT"
COLUMN fuzzy FORMAT A5 HEADING "Fuzzy"

select status,
       to_char(checkpoint_change#) checkpoint_change,
       to_char(checkpoint_time, 'dd-mon-yyyy hh24:mi:ss') as checkpoint_time,
       count(*) cnt,
       fuzzy
  from v$datafile_header
 group by status, checkpoint_change#, checkpoint_time, fuzzy
 order by status, checkpoint_change#, checkpoint_time;
 

Status     | Checkpoint_Chan | Checkpoint_Time           |    CNT | Fuzzy
---------- | --------------- | ------------------------- | ------ | -----
ONLINE     | 1471724         | 16-mar-2019 18:34:30      |      3 | NO
ONLINE     | 11818401        | 30-aug-2024 09:56:25      |      5 | YES
ONLINE     | 11818436        | 30-aug-2024 09:57:20      |      5 | YES

Neste exemplo, podemos observar que alguns arquivos de dados estão marcados como “fuzzy”, o que significa que há registros ainda não aplicados totalmente, e isso pode indicar a necessidade de uma recuperação completa antes de abrir o banco de dados.

Passo 2: Ajustando os REDO Logs

O próximo passo é ajustar os REDO logs para assegurar que o banco de dados possa ser aberto corretamente. Isso pode envolver a renomeação dos arquivos de dados para um novo local ou com nome diferente.

set echo off pages 0 feed off verify off trimspool on
spool /tmp/setnewnamedf.sql
SET LINESIZE 200
SET PAGESIZE 0
SET COLSEP '' 
SET HEADING OFF  
SET TERMOUT OFF 
SET TIMING OFF

SELECT 'alter database rename file ''' || a.member || ''' to ''' 
       || REGEXP_REPLACE(a.member, '([^/]+$)', 'new_\1') || ''';' 
FROM v$logfile a, v$log b
WHERE a.group# = b.group#
/

spool off;
set termout on
set echo on;

!cat /tmp/setnewnamedf.sql

Após o comando !cat /tmp/setnewnamedf.sql, serão exibidos os comandos gerados para renomear os arquivos de redo logs. Esses comandos devem ser revisados pelo DBA para garantir que estão corretos. Caso a saída gerada não esteja de acordo com a estrutura desejada, é essencial que o DBA faça os ajustes necessários antes de executar os comandos. Aqui está um exemplo de saída:

alter database rename file '/opt/oracle/oradata/XE/new_redo01.log' to '/opt/oracle/oradata/XE/new_redo01.log';
alter database rename file '/opt/oracle/oradata/XE/redo02.log' to '/opt/oracle/oradata/XE/new_new_redo02.log';
alter database rename file '/opt/oracle/oradata/XE/new_redo03.log' to '/opt/oracle/oradata/XE/new_redo03.log';

Isso ajusta o tempo de rollover para todos os usuários associados ao perfil.

Passo 3: Ajustar o INIT

Antes de continuar com a recuperação, é necessário ajustar o arquivo INIT.ORA ou os parâmetros no SPFILE. Aqui está o procedimento detalhado:

1. Parâmetros Antes das Modificações:

*.audit_file_dest='/opt/oracle/admin/XE/adump'
*.audit_trail='db'
*.compatible='18.0.0'
*.control_files='/opt/oracle/oradata/XE/control01.ctl','/opt/oracle/oradata/XE/control02.ctl'
*.control_management_pack_access='DIAGNOSTIC+TUNING'
*.db_block_size=8192
*.db_name='XE'
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=XEXDB)'
*.enable_pluggable_database=true
*.local_listener='LISTENER_XE'
*.nls_language='BRAZILIAN PORTUGUESE'
*.nls_territory='BRAZIL'
*.open_cursors=300
*.pga_aggregate_target=274m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_max_size=1287651328
*.sga_target=1287651328
*.undo_tablespace='UNDOTBS1'

2. Criar um PFILE a partir do SPFILE

create pfile='/tmp/ppfile.ora' from spfile;

Este comando cria um arquivo de parâmetros editável (PFILE) a partir do arquivo binário (SPFILE).

3. Editar o PFILE

Utilize um editor de texto, como o vi, para ajustar os parâmetros no arquivo criado:

vi /tmp/ppfile.ora

4. Parâmetros Após as Modificações:

*.audit_file_dest='/opt/oracle/admin/XE/adump'
*.audit_trail='db'
*.compatible='18.0.0'
*.control_files='/opt/oracle/oradata/XE/control01.ctl','/opt/oracle/oradata/XE/control02.ctl'
*.control_management_pack_access='DIAGNOSTIC+TUNING'
*.db_block_size=8192
*.db_name='XE'
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=XEXDB)'
*.enable_pluggable_database=true
*.local_listener='LISTENER_XE'
*.nls_language='BRAZILIAN PORTUGUESE'
*.nls_territory='BRAZIL'
*.open_cursors=300
*.pga_aggregate_target=274m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_max_size=1287651328
*.sga_target=1287651328
#*.undo_tablespace='UNDOTBS1'                     ## Parâmetro comentado
*._allow_resetlogs_corruption=true                ## Parâmetro adicionado
*._allow_error_simulation=TRUE                    ## Parâmetro adicionado
*.undo_management='MANUAL'                        ## Alterado para 'MANUAL'
*.db_recovery_file_dest='/opt/oracle/product/18c/dbhomeXE/dbs/arch' ## Destino configurado para espaço de recuperação
*.db_recovery_file_dest_size=100000G              ## Espaço de recuperação configurado como grande

5. Iniciar o Banco de Dados Usando o PFILE:

Após editar e salvar o PFILE, inicie o banco de dados no modo MOUNT utilizando o PFILE recém-editado:

shut abort;
startup mount pfile='/tmp/ppfile.ora';

Passo 4: Iniciar e Cancelar o Recover no sqlplus

sqlplus / as sysdba
recover database until cancel;
CANCEL;

Passo 5: Executar o OPEN RESETLOGS

alter database open resetlogs;

Neste momento, você está executando o passo mais crítico do processo. A abertura do banco de dados com RESETLOGS pode expor problemas graves, como o erro ORA-600, que pode ocorrer imediatamente após o comando ou durante a transição. Caso um erro ORA-600 ou outro problema semelhante ocorra, a recomendação é baixar imediatamente o banco de dados e tentar abrir novamente utilizando o SPFILE original. Em muitos casos, esse procedimento pode funcionar porque o Oracle já trocou o incarnation do banco de dados antes do erro, permitindo que ele continue a operação. Recomenda-se que o DBA acompanhe a execução desse comando em outra sessão, monitorando o alert.log com tail -f, para capturar qualquer erro no momento em que ocorrer.

Passo 6: Recriar a Tablespace TEMP

Em diversas situações, problemas relacionados à tablespace TEMP foram observados após a abertura do banco de dados utilizando o parâmetro _allow_resetlogs_corruption. Embora a recriação dessa tablespace seja um passo opcional, recomendo fortemente realizar essa ação para garantir a estabilidade e o correto funcionamento do banco de dados.

É importante destacar que as operações de drop e recriação da tablespace TEMP devem ser adaptadas às particularidades do ambiente em que o banco de dados está operando, como em ambientes Single Instance ou RAC (Real Application Clusters).

create temporary tablespace TEMP2 tempfile '/opt/oracle/oradata/XE/TEMP2_001.dbf' size 100M autoextend on;


alter database default temporary tablespace TEMP2;


drop tablespace TEMP including contents and datafiles;

Passo 7: Recriar a Tablespace UNDO

Durante a abertura do banco de dados utilizando o parâmetro _allow_resetlogs_corruption, há um risco significativo de que a tablespace UNDO seja corrompida ou se torne inadequada para o uso. Caso isso ocorra, é essencial recriar a tablespace UNDO para assegurar a integridade e o desempenho do banco de dados.

Assim como no caso da tablespace TEMP, os procedimentos de drop e recriação da tablespace UNDO devem ser ajustados conforme as particularidades do ambiente, seja ele Single Instance ou RAC.

create undo tablespace UNDOTBS_new1 datafile '/opt/oracle/oradata/XE/undotbs_new01.dbf' size 250M autoextend on;


alter system set undo_tablespace=UNDOTBS_new1;


drop tablespace UNDOTBS1 including contents and datafiles;

alter system set undo_tablespace=UNDOTBS_new1 scope=spfile sid='*';

Passo 7: Reiniciar o DB e Configurar o UNDO Tablespace

Após realizar todas as etapas anteriores, reinicie o banco de dados e configure o UNDO tablespace de forma persistente:

alter system set undo_tablespace=UNDOTBS_new1 scope=spfile sid='*';

shut immediate;

startup;

show parameter undo_tablespace

Passo 9: VALIDATE LOGICAL DATABASE

Após concluir todos os passos anteriores, é essencial garantir que o banco de dados esteja em boas condições lógicas. O Oracle RMAN oferece o comando VALIDATE CHECK LOGICAL DATABASE, que verifica a consistência lógica dos blocos de dados, ajudando a identificar qualquer corrupção que possa ter ocorrido durante o processo de recuperação, especialmente ao utilizar o parâmetro _allow_resetlogs_corruption.

rman target /

VALIDATE CHECK LOGICAL DATABASE;

Status: Indica o status da verificação para cada arquivo de dados.
Marked Corrupt: Informa o número de blocos marcados como corrompidos.
Empty Blocks: Mostra a quantidade de blocos vazios.
Blocks Examined: Quantidade de blocos examinados durante a validação.
High SCN: O maior SCN (System Change Number) encontrado no arquivo de dados.

Esse passo é indispensável para assegurar que o banco de dados esteja em ordem após o processo de recuperação. Ele vai além de simplesmente verificar se os blocos de dados são legíveis; ele também confirma que tudo dentro do banco de dados, como índices, tabelas e relações, está correto e sem erros. A execução dessa validação garante a integridade do banco de dados, especialmente após o uso de métodos mais avançados e arriscados, como o _allow_resetlogs_corruption.

O uso do parâmetro _allow_resetlogs_corruption deve ser encarado como uma última alternativa e realizado com extrema cautela. Embora esse procedimento possa permitir a abertura do banco de dados em situações críticas, ele traz consigo riscos significativos, incluindo a possibilidade de corrupção de dados. Além disso, o uso de parâmetros ocultos, como o _allow_resetlogs_corruption, não é recomendado sem o suporte direto da Oracle, pois esses parâmetros podem introduzir comportamentos inesperados e comprometer a integridade do banco de dados.

Recomenda-se que essa abordagem seja utilizada apenas quando todas as outras tentativas de recuperação falharam, e que o DBA esteja plenamente ciente dos riscos envolvidos. Seja cauteloso e responsável ao utilizar esse recurso. Sempre que possível, envolva o suporte da Oracle para orientar e validar o uso desses parâmetros, garantindo que as decisões tomadas sejam as mais seguras possíveis para o ambiente de produção.

⚡🧨 #20240830 #DBASobrinho #GuinaNãoTinhaDó #BóBó #CaceteDeAgulha #PedreiroFaltou #PrimeiroGoogle #EmCasa #BocaFechadaNãoEntraMosca #FazM 🧨⚡

Compartilhe

Pesquisar

Roberto Sobrinho

Sou Roberto Fernandes Sobrinho, também conhecido como Sobrinho DBA , pós graduado em “Architecture and Database Administration”, entusiasta, dedicado e com 20 anos de experiência com Oracle Database e suas diversas distribuições e variações.