Dans l'onglet Ressources SnapCenter > vue base de données, cliquez sur le nom de la base de données pour ouvrir la sauvegarde de la base de données.

Sélectionnez la copie de sauvegarde de la base de données et le point dans le temps souhaité pour la restauration. Marquez également le numéro SCN correspondant au point dans le temps. La restauration ponctuelle peut être effectuée à l'aide de l'heure ou du SCN.

Mettez en surbrillance l'instantané du volume du journal et cliquez sur le bouton Monter pour monter le volume.

Sélectionnez l'instance EC2 principale pour monter le volume du journal.

Vérifiez que le travail de montage s'est terminé correctement. Vérifiez également sur l'hôte de l'instance EC2 pour voir le volume du journal monté et le chemin du point de montage.

Copiez les journaux d'archivage du volume du journal monté dans le répertoire du journal d'archivage en cours.

[ec2-user@ip-10-0-0-151 ~]$ cp /var/opt/snapcenter/sco/backup_mount/ip-10-0-0-151_03-25-2022_11.15.01.1503_1/ORCL/1/db/ORCL_A/arch/*.arc /ora_nfs_log/db/ORCL_A/arch/

Revenez à l'onglet ressource SnapCenter > page de sauvegarde de la base de données, mettez en surbrillance la copie Snapshot de données, puis cliquez sur le bouton Restaurer pour lancer le flux de travail de restauration de la base de données.

Vérifiez tous les fichiers de données et modifiez l'état de la base de données si nécessaire pour la restauration et la restauration, puis cliquez sur Next.

Choisissez une étendue de récupération à l'aide de SCN ou de Time. Plutôt que de copier les journaux d'archive montés dans le répertoire de journaux actuel comme indiqué à l'étape 6, le chemin du journal d'archivage monté peut être répertorié dans « spécifier des emplacements de fichiers journaux d'archive externes » pour la restauration.

Spécifiez un prescripteur facultatif à exécuter si nécessaire.

Spécifiez un script de post-script facultatif à exécuter si nécessaire. Vérifiez la base de données ouverte après la récupération.

Indiquez un serveur SMTP et une adresse e-mail si une notification de travail est nécessaire.

Restaurez le récapitulatif du travail. Cliquez sur Terminer pour lancer la tâche de restauration.

Valider la restauration à partir de SnapCenter.

Valider la restauration à partir de l'hôte de l'instance EC2.

Pour démonter le volume du journal de restauration, inversez les étapes de l'étape 4.

Effectuer une sauvegarde instantanée complète de la base de données primaire à partir de SnapCenter en utilisant le groupe de ressources de sauvegarde complet.

Dans l'onglet ressource SnapCenter > vue base de données, ouvrez la page gestion des sauvegardes de la base de données principale à partir de laquelle la réplique doit être créée.

Montez le snapshot du volume de journal effectué à l'étape 4 sur l'hôte de l'instance EC2 de secours.

Mettez en surbrillance la copie snapshot à cloner pour la réplique, puis cliquez sur le bouton Cloner pour lancer la procédure de clonage.

Modifiez le nom de la copie du réplica afin qu'il soit différent du nom de la base de données principale. Cliquez sur Suivant.

Remplacez l'hôte clone par l'hôte EC2 de secours, acceptez la dénomination par défaut et cliquez sur Next (Suivant).

Modifiez vos paramètres Oracle Home pour qu'ils correspondent à ceux configurés pour l'hôte du serveur Oracle cible, puis cliquez sur Next (Suivant).

Spécifiez un point de récupération à l'aide du temps ou du SCN et du chemin du journal d'archivage monté.

Si nécessaire, envoyez les paramètres de messagerie SMTP.

Clonez le récapitulatif des tâches, puis cliquez sur Terminer pour lancer la tâche de clonage.

Validez le clone de réplica en consultant le journal des travaux de clonage.

Désactivez le mode de journal d'archivage Oracle. Connectez-vous à l'instance EC2 en tant qu'utilisateur oracle et exécutez la commande suivante :

sqlplus / as sysdba

shutdown immediate;

startup mount;

alter database noarchivelog;

alter database open;

Pour effectuer une simulation de basculement, exécutez une sauvegarde de snapshot de journal pour vider les dernières transactions du site de secours, comme indiqué dans la section Prise d'un instantané du journal d'archivage. Dans le cas d'un basculement déclenché par une défaillance réelle, les dernières données récupérables sont répliquées vers le site de secours avec la dernière sauvegarde planifiée du volume des journaux.

Faire un break de SnapMirror entre le cluster principal et le cluster FSX de secours.

Montez les volumes de base de données de secours répliqués sur l'hôte d'instance EC2 de secours.

Rééditez le binaire Oracle si le binaire Oracle répliqué est utilisé pour la restauration Oracle.

Restaurez la base de données Oracle de secours vers le dernier journal d'archivage disponible.

Ouvrez la base de données Oracle de secours pour l'accès des applications et des utilisateurs.

Dans le cas d'une panne réelle du site primaire, la base de données Oracle de secours joue désormais le rôle de nouveau site principal et les volumes de base de données peuvent être utilisés pour reconstruire le site primaire en panne comme un nouveau site de secours avec la méthode SnapMirror inverse.

Pour une simulation d'échec du site primaire pour le test ou la validation, arrêtez la base de données Oracle de secours après avoir terminé les exercices de test. Démontez ensuite les volumes de base de données de secours de l'hôte de l'instance EC2 de secours et synchronisez la réplication du site primaire vers le site de secours.