Cette page a été traduite par l'API Cloud Translation.

Valider le déploiement de Data Guard

Une fois que vous avez configuré l'agent Data Guard, vous devez vérifier que le rétablissement a été copié à partir de la base de données principale et appliqué à la base de données de secours. La procédure suivante peut être utilisée pour vérifier l'état de Data Guard depuis les bases de données principale et de secours.

Les exemples suivants sont utilisés tout au long de ce guide:

Nom de base de données unique	Noms d'hôtes du serveur	Noms d'instance RAC	Rôle
`DBDG_SITE1`	`site1db1`, `site1db2`	`DBDG_SITE11`, `DBDG_SITE12`	Principal
`DBDG_SITE2`	`site2db1`, `site2db2`	`DBDG_SITE21`, `DBDG_SITE22`	Instance de secours

Valider le déploiement de Data Guard

Connectez-vous au premier serveur de solution Bare Metal qui héberge la base de données principale, puis définissez la variable d'environnement ORACLE_SID afin de pouvoir vous connecter à la base de données principale:
```
source oraenv <<< "DBDG_SITE11"
```
Démarrez SQL*Plus, puis déterminez le numéro de séquence le plus récent pour les journaux de rétablissement archivés:
```
sqlplus / as sysdba
```
```
SELECT THREAD#, max(SEQUENCE#) "Last Primary Seq Archived"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;
```
La sortie suivante a un numéro de séquence maximal de 40 pour le thread 1 et un numéro de séquence maximal de 33 pour le thread 2:
```
   THREAD# Last Primary Seq Archived
---------- -------------------------
         1                        40
         2                        33
```
Enregistrez les résultats à comparer à la base de données de secours. Les numéros de séquence sur la base de données de secours sont censés correspondre à la base de données principale.
Connectez-vous au premier serveur de solution Bare Metal qui héberge la base de données de secours, puis définissez la variable d'environnement ORACLE_SID afin de pouvoir vous connecter à la base de données de secours:
```
source oraenv <<< "DBDG_SITE21"
```

Démarrez SQL*Plus, puis vérifiez que le dernier numéro de séquence reçu et appliqué aux journaux de rétablissement archivés correspond au dernier numéro de séquence sur la base de données principale:

sqlplus / as sysdba

SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Received"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;

SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Applied"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# AND VAL.APPLIED IN ('YES','IN-MEMORY') GROUP BY
THREAD# ORDER BY 1;

Le résultat suivant comporte des numéros de séquence correspondant à la requête précédente exécutée sur la base de données de secours:

   THREAD# Last Standby Seq Received
---------- -------------------------
         1                        40
         2                        33

   THREAD# Last Standby Seq Applied
---------- ------------------------
         1                       40
         2                       33

Vérifiez que l'état du processus de récupération géré est APPLYING_LOG:
```
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE '%MRP%';
```
L'exemple suivant présente un processus de récupération géré unique nommé MRP0 avec l'état APPLYING_LOG:
```
PROCESS   STATUS
--------- ------------
MRP0      APPLYING_LOG
```

Vérifiez l'absence de transport ou appliquez un délai sur la base de données de secours:

COLUMN NAME FORMAT a20
COLUMN VALUE FORMAT a30
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag%';

Le résultat suivant ne montre aucun temps de latence sur la base de données de secours:

NAME                 VALUE
-------------------- ------------------------------
transport lag        +00 00:00:00
apply lag            +00 00:00:00

En cas de décalage, consultez la documentation de dépannage d'Oracle Data Guard.

Commutation de base de données à l'aide de l'agent Data Guard

Une commutation est une inversion de rôle dans laquelle la base de données principale devient une base de données de secours, et inversement. Au cours du processus de commutation, les clients de base de données sont déconnectés de la base de données principale. Selon la manière dont votre application se connecte à la base de données, une commutation peut perturber le trafic de l'application. Oracle propose des options permettant de maintenir la continuité des applications lors des transitions de rôles. Vous pouvez tester votre préparation à la reprise après sinistre en effectuant une commutation de base de données avec les instructions suivantes:

Connectez-vous au serveur de solution Bare Metal qui héberge la base de données principale.
Lancez l'interface de ligne de commande Data Guard et connectez-vous à la base de données de secours:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Lorsque vous êtes invité à entrer un mot de passe, saisissez votre mot de passe de connexion à distance SYS pour la base de données.
Vérifiez que la base de données est prête pour une commutation.
```
VALIDATE DATABASE DBDG_SITE2;
```
Si l'opération réussit, la base de données est prête à être à la commutation.
Si l'opération réussit, exécutez la commande de commutation suivante :
```
SWITCHOVER TO DBDG_SITE2;
```
Si la commande aboutit, vous recevrez un message indiquant que DBDG_SITE2 est la nouvelle base de données principale dans la configuration.
Exécutez la commande suivante pour vérifier que les rôles de la base de données sont échangés:
```
SHOW CONFIGURATION;
```
Exécutez la commande suivante pour revenir à la configuration d'origine:
```
SWITCHOVER TO DBDG_SITE1;
```

Basculement de base de données à l'aide de l'agent Data Guard

Un basculement est une transition de rôle dans laquelle l'une des bases de données de secours est transférée vers le rôle principal en raison d'une panne complète du site. Le rétablissement de la base de données n'est pas envoyé à la base de données de secours tant que la base de données de secours n'a pas été rétablie.

Effectuer le basculement

Connectez-vous au premier serveur de solution Bare Metal qui héberge la base de données de secours.
Connectez-vous à l'interface de ligne de commande Data Guard, puis basculez la base de données principale vers la base de données de secours:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Lorsque vous êtes invité à entrer un mot de passe, saisissez votre mot de passe de connexion à distance SYS pour la base de données.
Initiez le basculement comme suit :
```
FAILOVER TO DBDG_SITE2
```
Exécutez show configuration; pour vérifier que DBDG_SITE2 est désormais la base de données principale et que DBDG_SITE1 doit être rétabli.

Réactiver la base de données principale

Vous ne pouvez rétablir la base de données principale après un basculement que si flashback database est activé. Pour rétablir la base de données principale défaillante, procédez comme suit:

Connectez-vous au premier serveur de solution Bare Metal qui héberge la base de données principale.
Connectez-vous à l'interface de ligne de commande Data Guard, puis à la base de données principale, puis rétablir la base de données ayant échoué:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Lorsque vous êtes invité à entrer un mot de passe, saisissez votre mot de passe de connexion à distance SYS pour la base de données.
Rétablissez la base de données:
```
REINSTATE DATABASE DBDG_SITE1;
EXIT;
```

Étapes suivantes

Ensuite, configurez un observateur Data Guard sur Compute Engine.