comment vérifier que la base de données est cohérente après une récupération incomplète

Vous pouvez restaurer une base de données à partir de la sauvegarde et appliquer de nombreuses archives pour la rendre cohérente. Maintenant, vous souhaitez vous assurer que les journaux de réinitialisation ouverts se déroulent correctement.
Voici comment vérifier que la base de données est cohérente après une récupération incomplète

La déclaration ci-dessous définit le format de date sur une forme étendue, car nous aurions besoin de cela plusieurs fois dans notre analyse

SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';

Vérification 1 :

Objectif :vérifier que les fichiers de données sont récupérés au moment prévu (PIT) et qu'ils sont cohérents (FUZZY=NO) récupéré) des fichiers de données en lisant les en-têtes des fichiers de données directement à partir des fichiers de données physiques :

SQL> sélectionnez fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) du groupe v$datafile_header par fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time;

• Vérifiez que le checkpoint_time / checkpoint_change# est conforme à votre intention UNTIL TIME/SCN. Si ce n'est pas le cas, récupérez davantage la base de données si vous disposez de davantage de journaux archivés.
• Si FUZZY=YES pour certains fichiers de données, cela signifie qu'une récupération supplémentaire est nécessaire. Si plus aucun journal archivé n'est disponible, identifiez ces fichiers de données et déterminez si nous pouvons les mettre hors ligne, car nous perdrons les données de ces fichiers de données. Si les fichiers de données appartiennent à l'espace table SYSTEM ou UNDO, nous pouvons / NE DEVONS PAS mettre ce fichier de données hors ligne sans une analyse appropriée. Veuillez consulter le support Oracle pour d'autres actions.

SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy='YES';

Parfois, si le nom de l'espace de table n'indique pas qu'il s'agit d'un espace de table UNDO, si nous voyons une valeur différente de zéro dans la colonne UNDO_OPT_CURRENT_CHANGE#, cela indique que le fichier de données contient des segments d'annulation.

Pour mettre un fichier de données hors ligne :

SQL> modifier le fichier de données de la base de données hors ligne;

Le contrôle 1 peut être considéré comme réussi lorsque :
+ Vérifié que tous les fichiers de données ont été récupérés jusqu'au moment prévu.
+ Fuzzy=NO pour SYSTEM, UNDO et tous les fichiers de données prévus. Pour les fichiers de données avec Fuzzy=YES, récupérez-les davantage ou mettez-les HORS LIGNE si aucun autre journal archivé n'est disponible.

Vérification 2 :

Objectif :Vérifier que les fichiers avec status=RECOVER ne sont pas HORS LIGNE par inadvertance

SQL> select status, enabled, count(*) from v$datafile group by status, enabled;STATUS  ENABLED      COUNT(*)------- ---------- --- -------SYSTEM   DISABLED            1EN LIGNE  READ WRITE          1114RECOVER DISABLED            2

Si les fichiers sont en statut RECOVER, vérifiez s'ils sont OFFLINE :

SQL> select file#, substr(name, 1, 50), status, error, recovery from v$datafile_header;

Si vous souhaitez que les données de ces fichiers soient accessibles, alors mettez-les EN LIGNE :

SQL> modifier le fichier de données de la base de données EN LIGNE ;

Si un fichier reste hors ligne au moment de OPEN RESETLOGS, le fichier de données ne peut pas être remis en ligne dans la même base de données OPENED.
Le contrôle 2 peut être considéré comme réussi lorsque :
a) Tous les fichiers de données prévus sont pas HORS LIGNE

Vérification 3 :

Objectif :vérification floue supplémentaire (vérification floue absolue)

Occasionnellement, il est possible de voir Fuzzy=NO et même checkpoint_change# pour tous les fichiers de données prévus; certains fichiers de données peuvent encore être flous et OPEN RESETLOGS renverra une erreur, par exemple

SQL> sélectionnez fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) du groupe v$datafile_header par fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time;FUZ STATUS  ERROR           REC CHECKPOINT_CHANGE#      CHECKPOINT_TIME   COUNT (*)--- ------- --------------- --- ------------------ - ------------------- ----------NON EN LIGNE                                5375858580 31-OCT-2011 23:10:14          7SQL> ALTER DATABASE OPEN RESETLOGS ;ORA -01194 :le fichier 14 a besoin de plus de récupération pour être cohérentORA-01110 :fichier de données 3 :'/u01/app/oracle/oradata/TEST/undotbs02.dbf' pré> 
SQL> select 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;
 

 Remarque :la colonne Min_PIT_SCN renverra la même valeur même pour plusieurs lignes, car nous y avons appliqué la fonction ANALYTICAL "MAX() OVER ()".
 

 La requête ci-dessus indique que la récupération doit être effectuée au moins JUSQU'AU SCN 5311524 pour rendre les fichiers de données cohérents et prêts à être OUVERTS. Puisque le checkpoint_change# est plus petit que Min_PIT_SCN, les fichiers de données demanderont plus de récupération.
 

 La vérification 3 peut être considérée comme réussie lorsque,
a) Aucune ligne n'est sélectionnée dans la requête ci-dessus (c'est-à-dire que Min_PIT_SCN est égal à 0 (zéro) pour tous les fichiers de données)
b) Min_PIT_SCN est renvoyé inférieur à Checkpoint_Change#
 

 Contrôle 4 :Archiver les journaux requis 
 

 Interrogez le fichier de contrôle pour trouver le dernier journal d'archivage requis pour la récupération. Disons que la sauvegarde s'est terminée le 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 ET NEXT_TIME ;
 

 Si la requête ci-dessus ne renvoie aucune ligne, il se peut que les informations soient dépassées par le fichier de contrôle - exécutez la requête suivante sur v$log_history.
 
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> sélectionnez un.THREAD#, un.SEQUENCE#, un.FIRST_TIME
à partir de V$ LOG_HISTORY a
où FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
FROM V$LOG_HISTORY b
WHERE b.FIRST_TIME 
Le numéro de séquence renvoyé par la requête ci-dessus est la séquence de journal en cours au moment de la fin de la sauvegarde - disons 530 thread 1.
 

 Pour une utilisation de récupération minimale :(Séquence# telle que renvoyée +1 )
 
RMAN> EXÉCUTER
{
DÉFINIR JUSQU'À SÉQUENCE 531 THREAD 1 ;
RÉCUPÉRER LA BASE DE DONNÉES ;
}
 

 S'il s'agit d'une implémentation RAC, utilisez ce SQL à la place pour interroger le fichier de contrôle :
 
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 ;
 

 Pour une récupération minimale, utilisez la séquence de journal et le thread qui a le NEXT_CHANGE# le plus bas renvoyé par la requête ci-dessus.
 

 Le contrôle 4 peut être considéré comme RÉUSSI lorsque :
 

 Tous les journaux d'archivage depuis le moment de la sauvegarde jusqu'à la fin de la sauvegarde sont disponibles pour une utilisation pendant la restauration
 

 Vérification 5 (Après avoir réussi OPEN RESETLOGS) : 
 

 Surveillez alert.log pour connaître l'heure des activités OPEN RESETLOGS. Vous pourriez voir des messages comme ci-dessous lors de la vérification du dictionnaire :
 

 Création du fichier OFFLINE 'MISSING00004' dans le fichier de contrôle
 

 si vous trouvez le fichier, essayez de le renommer. Sinon, nous pouvons déconnecter le fichier de données ou supprimer le tablespace associé :
 
SQL> select file#, status, enabled, substr(name, 1, 50) from v$datafile where name like '%MISSING%' ;FILE#    STATUS  ENABLED    SUBSTR(NAME,1,50)---- ---- ------- ---------- ----------------------------- ---------------------       4 HORS LIGNE DÉSACTIVÉ   //MISSING000       7 HORS LIGNE DÉSACTIVÉ   //MISSING000SQL> modifier le fichier de données de la base de données 4 en ligne; modifier le fichier de données de la base de données 4 en ligne*ERREUR à la ligne 1 : ORA-01157 :impossible d'identifier/verrouiller le fichier de données 4 : voir le fichier de trace DBWR>/dbs/MISSING00004'SQL> modifier le fichier de renommage de la base de données 'MISSING00004' en '//users01.dbf' ;Base de données modifiée.SQL> modifier le fichier de renommage de la base de données 'MISSING00007' en '//users02.dbf';Base de données modifiée.SQL> sélectionnez tablespace_name, status from dba_tablespaces where tablespace_name in (select tablespace_name from dba_data_files where file_id in (4, 7)) ;TABLESPACE_NAME                STATUS------------------ ---------- -- ---------USERS                          OFFLINESQL> ALTER TABLESPACE USERS ONLINE ;Tablespace modifié.
 

 J'espère que cela vous aidera à vérifier que la base de données est cohérente après une récupération incomplète. Merci de nous faire part de vos commentaires 
 

 Lit également 
comment trouver le numéro de séquence du journal d'archivage dans oracle
Commandes de sauvegarde RMAN
Commandes de sauvegarde de liste RMAN
Comment récupérer une base de données à l'aide de RMAN