como verificar se o banco de dados é consistente após a recuperação incompleta

Você pode restaurar um banco de dados do backup e aplicar muitos arquivos para torná-lo consistente. Agora, você gostaria de garantir que os registros de redefinições abertos funcionem bem.
Veja como verificar se o banco de dados é consistente após uma recuperação incompleta

A declaração abaixo define o formato de data para o formato estendido, pois exigiríamos isso muitas vezes em nossa análise

SQL> altera o conjunto de sessões nls_date_format='DD-MON-AAAA HH24:MI:SS';

Verificação 1:

Objetivo:Verificar se os arquivos de dados são recuperados no ponto no tempo pretendido (PIT) e estão consistentes (FUZZY=NO)
Consulte o status atual e o PIT (P-oint I-n T-ime até o qual os arquivos de dados foram recuperado) de arquivos de dados lendo os cabeçalhos dos arquivos de dados diretamente dos arquivos de dados físicos:

SQL> selecione fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) do grupo v$datafile_header por fuzzy, status, error, recover, checkpoint_change#, checkpoint_time;

Verifique se checkpoint_time / checkpoint_change# está de acordo com a sua intenção ATÉ TIME/SCN. Caso contrário, recupere o banco de dados ainda mais se tiver mais logs arquivados disponíveis.
Se FUZZY=YES para alguns arquivos de dados, significa que mais recuperação é necessária. Se não houver mais logs arquivados disponíveis, identifique esses arquivos de dados e determine se podemos colocá-los offline porque perderemos os dados nesses arquivos de dados. Se os arquivos de dados pertencerem ao tablespace SYSTEM ou UNDO, não podemos/devemos colocar esse arquivo de dados offline sem a devida análise. Consulte o Suporte da Oracle para mais ações.

SQL> selecione file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# de v$datafile_header onde fuzzy='YES';

Ocasionalmente, se o nome do tablespace não indicar que é um tablespace UNDO, se virmos um valor diferente de zero na coluna UNDO_OPT_CURRENT_CHANGE#, isso indica que o arquivo de dados contém segmentos de undo.

Para colocar um arquivo de dados offline:

SQL> altera o arquivo de dados do banco de dados offline;

Verificação 1 pode ser considerada Aprovada quando:
+ Verificado que todos os arquivos de dados foram recuperados até o ponto no tempo pretendido.
+ Fuzzy=NO para SYSTEM, UNDO e todos os arquivos de dados pretendidos. Para arquivos de dados com Fuzzy=YES, recupere-os ainda mais ou coloque-os OFFLINE se não houver mais logs arquivados disponíveis.

Verificação 2:

Objetivo:Verificar se os arquivos com status=RECOVER não estão OFFLINE involuntariamente

SQL> seleciona status, habilitado, contagem(*) de v$datafile group by status, enabled;STATUS  ENABLED      COUNT(*)----------- ---------- --- -------SISTEMA  DESATIVADO            1ONLINE  LER ESCREVER          1114RECUPERAR DESATIVADO            2

Se os arquivos estiverem no status RECOVER, verifique se estão OFFLINE:

SQL> selecione arquivo#, substr(nome, 1, 50), status, erro, recupere de v$datafile_header;

Se você deseja que os dados desses arquivos sejam acessíveis, coloque-os ONLINE:

SQL> altera o arquivo de dados do banco de dados ONLINE;

Se um arquivo permanecer offline no momento de OPEN RESETLOGS, o arquivo de dados não poderá ser colocado novamente online no mesmo banco de dados OPENED.
A verificação 2 pode ser considerada Aprovada quando:
a) Todos os arquivos de dados pretendidos são não OFFLINE

Verificação 3:

Objetivo:Verificação Fuzzy Adicional (Verificação Fuzzy Absoluta)

Ocasionalmente, é possível ver Fuzzy=NO e o mesmo checkpoint_change# para todos os arquivos de dados pretendidos; ainda alguns dos arquivos de dados podem estar confusos e OPEN RESETLOGS retornará erro, por exemplo.

SQL> selecione fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) do grupo v$datafile_header por fuzzy, status, error, recover, checkpoint_change#, checkpoint_time;FUZ STATUS  ERROR           REC CHECKPOINT_CHANGE#      CHECKPOINT_TIME   COUNT (*)--- ------- --------------- --- ------------------ - ------------------- ----------NO  ONLINE                                 5375858580 31-OUT-2011 23:10:14          7SQL> ALTER DATABASE OPEN RESETLOGS;ORA -01194:o arquivo 14 precisa de mais recuperação para ser consistenteORA-01110:data file 3:'/u01/app/oracle/oradata/TEST/undotbs02.dbf'Portanto, devemos realizar uma verificação fuzzy adicional conhecida como Absolute Fuzzy Check: SQL> selecione hxfil file#, substr(hxfnm, 1, 50) name, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over() Min_PIT_SCN from x$kcvfh where fhafs!=0;
 
 Nota:A coluna Min_PIT_SCN retornará o mesmo valor mesmo para várias linhas, pois aplicamos a função ANALYTICAL “MAX() OVER ()” nela. 
 
 A consulta acima indica que a recuperação deve ser realizada pelo menos ATÉ SCN 5311524 para tornar os arquivos de dados consistentes e prontos para ABRIR. Como checkpoint_change# é menor que Min_PIT_SCN, os arquivos de dados solicitarão mais recuperação. 
 
 A verificação 3 pode ser considerada Aprovada quando,
a) Nenhuma linha selecionada da consulta acima (ou seja, Min_PIT_SCN é 0 (Zero) para todos os arquivos de dados)
b) Min_PIT_SCN é retornado menor que Checkpoint_Change# 
 
 Verificação 4:arquivar registros obrigatórios 
 
 Consulte o controlfile para localizar o archivelog mais recente necessário para a recuperação. Digamos que o backup foi concluído em 31-AUG-2011 23:20:14:
 SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG
WHERE '31 -AUG-11 23:20:14' ENTRE FIRST_TIME E NEXT_TIME;
 
 Se a consulta acima não retornar nenhuma linha, pode ser que as informações tenham ultrapassado o arquivo de controle – execute a consulta a seguir em v$log_history. 
 SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> selecione a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
de V$ LOG_HISTORY a
onde FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
FROM V$LOG_HISTORY b
WHERE b.FIRST_TIME 
O sequence# retornado pela consulta acima é a sequência de log atual no momento em que o backup terminou - digamos 530 thread 1.
 
 Para uso mínimo de recuperação:(Sequence# conforme retornado +1 ) 
 RMAN> RUN
{
SET ATÉ A SEQUÊNCIA 531 THREAD 1;
RECOVER DATABASE;
}
 
 Se esta for uma implementação RAC, use este SQL para consultar o arquivo de controle:
 SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' BETWEEN FIRST_TIME AND NEXT_TIME;
 
 Para recuperação mínima, use a sequência de log e o encadeamento que possui o NEXT_CHANGE# mais baixo retornado pela consulta acima. 
 
 A verificação 4 pode ser considerada APROVADA quando:
 
 Todos os archives desde o momento do backup até o final do backup estão disponíveis para uso durante a recuperação 
 
 Verificação 5 (Após OPEN RESETLOGS bem-sucedidos): 
 
 Monitore o alert.log para o horário das atividades OPEN RESETLOGS. Você pode ver algumas mensagens como abaixo durante a verificação do dicionário:
 
 Criando o arquivo OFFLINE 'MISSING00004' no controlfile 
 
 se você encontrar o arquivo, tente renomeá-los. Caso contrário, podemos desligar o arquivo de dados ou descartar o tablespace associado:
 SQL> selecione file#, status, enabled, substr(name, 1, 50) from v$datafile where name like '%MISSING%';FILE#    STATUS  ENABLED    SUBSTR(NAME,1,50)---- ---- ------- ---------- ----------------------------- ---------------------       4 OFFLINE DISABLED   //MISSING000       7 OFFLINE DISABLED   //MISSING000SQL> alter database datafile 4 online;alter database datafile 4 online*ERRO na linha 1:ORA-01157:impossível identificar/bloquear arquivo de dados 4 - veja arquivo de rastreamento DBWRORA-01111:nome do arquivo de dados 4 é desconhecido - renomeie para corrigir o arquivoORA-01110:arquivo de dados 4:'//dbs/MISSING00004'SQL> altera banco de dados renomear arquivo 'MISSING00004' para '//users01.dbf';Banco de dados alterado.SQL> altera banco de dados renomear arquivo 'MISSING00007' para '//users02.dbf';Banco de dados alterado.SQL> selecione tablespace_name, status de dba_tablespaces where tablespace_name in (selecione tablespace_name de dba_data_files onde file_id in (4, 7));TABLESPACE_NAME               STATUS------------------ ---------- -- ---------USERS                          OFFLINESQL> ALTER TABLESPACE USERS ONLINE;Tablespace alterado.
 
 Espero que isso ajude em como verificar se o banco de dados é consistente após a recuperação incompleta. Por favor, forneça o feedback 
 
 Também lê 
como encontrar o número de sequência do log do arquivo no oracle
Comandos de backup do RMAN
Comandos de backup da lista do RMAN
Como recuperar o banco de dados usando o RMAN