Une base de données de secours physique s'appuie sur l'application continue des journaux d'archivage d'une base de données principale pour être synchronisée avec elle. Dans les versions d'Oracle Database antérieures à 10g, en cas de journal d'archivage manquant ou corrompu, vous deviez reconstruire la base de données de secours à partir de zéro. À partir de 10g, vous pouvez utiliser une sauvegarde incrémentielle à partir de SCN et récupérer la veille en utilisant la même chose pour compenser les journaux d'archive manquants. Dans ce document, nous verrons comment récupérer la base de données de secours à partir d'un journal d'archive manquant
Voici donc les étapes à suivre pour récupérer la base de données de secours à partir d'un journal d'archivage manquant
Étape 1 :
Sur la base de données de secours, vérifiez le SCN actuel
sqlplus "/ as sysdba" SQL>set numwidth 30; SQL>select current_scn from v$database; CURRENT_SCN ----------- 6746747647647
Étape 2 :
Sur la base de données principale, créez la sauvegarde incrémentielle nécessaire à partir du SCN ci-dessus
rman target /
RMAN> {
allocate channel c1 type disk;
BACKUP INCREMENTAL FROM SCN 6746747647647 DATABASE
FORMAT /tmp/inc_standby_%U';
} Nous pouvons utiliser des travailleurs parallèles pour accélérer la création de la sauvegarde si la base de données a généré beaucoup de modifications
run
{allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
allocate channel d5 type disk;
allocate channel d6 type disk;
allocate channel d7 type disk;
allocate channel d8 type disk;
allocate channel d9 type disk;
allocate channel d10 type disk;
BACKUP INCREMENTAL FROM SCN 6746747647647 DATABASE
FORMAT /tmp/inc_standby_%U';
}
Étape 3 :
Annuler la récupération gérée sur la base de données de secours
sqlplus "/ as sysdba" SQL>alter database recover managed standby database cancel; Media recovery complete.
Étape 4 :
- scp les fichiers de sauvegarde sur le serveur de secours vers le dossier /tmp.
- Cataloguer les fichiers de sauvegarde incrémentielle dans la base de données de secours
rman target / RMAN> CATALOG START WITH '/tmp/'; searching for all files that match the pattern /tmp/ List of Files Unknown to the Database =====================================…… Do you really want to catalog the above files (enter YES or NO)? YES cataloging files… cataloging done
Étape 5 :
Appliquer la sauvegarde incrémentielle à la base de données de secours
rman target / RMAN>RECOVER DATABASE NOREDO;
Étape 6 :
Remettez la base de données de secours en mode de récupération gérée.
sqlplus "/ as sysdba" SQL>recover managed standby database disconnect; Media recovery complete.
Dans alert.log, vous remarquerez que la base de données de secours recherche toujours les anciens fichiers journaux
FAL[client]: Failed to request gap sequence GAP - thread 1 sequence ….
C'est parce que le fichier de contrôle n'a pas été mis à jour. Par conséquent, le fichier de contrôle de secours doit être recréé
Étape 7 :
Sur le primaire, créez un nouveau fichier de contrôle de secours
sqlplus "/ as sysdba" SQL> alter database create standby controlfile as ‘/tmp/standby01.ctl’; System altered.
Étape 8 :
Capturez les informations du fichier de données dans la base de données STANDBY.
Le fichier de contrôle de secours devra être actualisé à partir de la sauvegarde effectuée à l'étape 7. Étant donné que les noms des fichiers de données sont probablement différents de ceux du fichier principal, enregistrez les noms de vos fichiers de données de secours pour référence après la restauration du fichier de contrôle à partir de la sauvegarde principale. Exécutez la requête ci-dessous dans la base de données de secours et enregistrez les résultats pour une utilisation ultérieure.
spool standby_datafile_names.txt
set pagesize 1000;
set lines 200
col name format a60
select file#, name from v$datafile order by file# ;
spool off
Étape 9 :
Copiez le fichier de contrôle de secours sur le site de secours. Arrêtez la base de données de secours et remplacez les fichiers de contrôle de secours et redémarrez la base de données de secours en mode de récupération gérée à l'aide de la commande ci-dessous
RMAN> SHUTDOWN IMMEDIATE ; RMAN> STARTUP NOMOUNT; RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/standby01.ctl';
Étape 10 :
Monter le standby
RMAN> ALTER DATABASE MOUNT;
Étape 11 :
Cette étape est nécessaire si l'emplacement des fichiers de données est différent en veille et en primaire
Si le primaire et le standby ont des noms de structure et de fichier de données identiques, cette étape peut être ignorée.
Oracle recommande de vérifier l'incarnation principale et de secours avant de terminer cette étape.
example:
RMAN> list incarnation;
Puisque nous avons restauré le fichier de contrôle à partir de PRIMARY, les noms d'emplacement des fichiers de données dans ce fichier de contrôle STANDBY restauré seront les mêmes que ceux de la base de données PRIMARY. Si la structure de répertoires est différente entre les bases de données de secours et principales ou si vous utilisez des noms de fichiers gérés Oracle OMF, il ne sera pas en mesure d'identifier les fichiers de secours. Nous pouvons donc cataloguer les fichiers de données STANDBY avec RMAN pour exécuter l'opération de renommage.
Effectuez l'étape ci-dessous dans STANDBY pour chaque groupe de disques (ou répertoire) où résident les fichiers de données de secours.
RMAN> CATALOG START WITH '+DATA/STBY/datafile/';
Si des fichiers de données ont été ajoutés au SCN principal APRÈS le SCN de sauvegarde (dans notre exemple, scn 6746747647647), ces fichiers de données ne seront pas automatiquement créés sur le serveur de secours, quel que soit le paramètre standby_file_management défini. Les fichiers de données ajoutés devront être restaurés sur le serveur de secours. Pour déterminer si des fichiers ont été ajoutés au principal depuis le SCN en veille actuel
SQL>SELECT FILE#, NAME FROM V$DATAFILE WHERE CREATION_CHANGE# > 6746747647647
S'il renvoie des lignes, nous devons restaurer ces fichiers du primaire au standby
RMAN> backup datafile <missing-1>,<missing-2> ,<missing-3> , format '/tmp/ForStandby_%U' tag 'FORSTANDBY';
Copiez-les en veille, puis cataloguez-les et restaurez-les
CATALOG START WITH '/tmp/ForStandby';
run
{
set newname for datafile X to '+DISKGROUP';
set newname for datafile Y to '+DISKGROUP';
set newname for datafile Z to '+DISKGROUP';
etc.
restore datafile x,y,z,….;
} Maintenant, nous pouvons passer de la base de données à copier
RMAN> SWITCH DATABASE TO COPY;
Si la requête ci-dessus retourne avec 0 0 lignes
RMAN> SWITCH DATABASE TO COPY;
Étape 11
En VEILLE base de données, effacez tous les groupes de journaux de rétablissement en attente :
SQL> sélectionnez GROUP# dans v$logfile où TYPE='STANDBY' regroupez par GROUP# ;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1 ;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2 ;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3 ;
Étape 12
Vous pouvez maintenant démarrer le MRP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
J'espère que vous aimez ces étapes détaillées sur la façon de récupérer une base de données de secours à partir d'un journal d'archivage manquant. Veuillez fournir les commentaires. Il peut y avoir une erreur.
Lit également
Non ASM vers ASM
comment trouver le numéro de séquence du journal d'archivage dans oracle
comment vérifier les erreurs du journal d'alerte dans oracle
Commandes de sauvegarde RMAN
Commandes de sauvegarde de liste RMAN
/>Étapes à suivre pour restaurer une base de données de secours physique à l'aide de la sauvegarde incrémentielle RMAN. (Doc ID 836986.1)
