Note :

• Ce tutoriel nécessite l'accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, voir Démarrer avec le niveau gratuit d'Oracle Cloud Infrastructure.
• Il utilise des exemples de valeurs pour les données d'identification, la location et les compartiments d'Oracle Cloud Infrastructure. À la fin de votre laboratoire, remplacez ces valeurs par celles qui sont propres à votre environnement en nuage.

Mettre en œuvre Oracle Zero Downtime Migration 21.5 Cloud Native Disaster Recovery Automation

Présentation

Dans une migration typique, Oracle Zero Downtime Migration migre une base de données source vers une seule base de données cible (un seul point de défaillance). Désormais, dans la version 21.5, vous pouvez également créer une stratégie de récupération après sinistre pendant la post-migration afin de pouvoir répondre à un événement ayant une incidence négative sur vos activités commerciales et effectuer une récupération à partir de celui-ci. Deux bases de données cibles sont instanciées lors de la migration (base de données principale cible et base de secours cible), où les deux peuvent se trouver dans différentes régions (pour réduire les impacts des catastrophes naturelles). Au cours de la post-migration, la configuration du courtier Oracle Data Guard est restaurée dans les deux bases de données cibles pour permettre les opérations natives en nuage telles que la permutation et le basculement (dans la console Oracle Database Cloud Service). Pour plus d'informations, voir Création d'une stratégie de reprise après sinistre native Oracle Cloud.

Diagramme d'architecture

Étapes du flux de travail d'Oracle Zero Downtime Migration

1. Lancez la migration de la base de données.
2. Effectuer une restauration à partir du service.
3. Instancier la base de données de secours sur la base principale cible.
4. Synchroniser la base principale et la base de secours sur la base principale cible.
5. Effectuer une restauration à partir du service.
6. Instancier la base de données de secours sur la base de données de secours cible.
7. Synchroniser les bases de secours source et cible.
8. Surveiller la disponibilité de la permutation.
9. Effectuer la permutation et la transition de rôle.
10. Configurer la configuration principale cible et restaurer le courtier en nuage.
    1. Oracle Zero Downtime Migration restaure la configuration du courtier en nuage entre la base de données principale cible et la base de données de secours cible.
    2. Oracle Zero Downtime Migration configure la base principale cible pour qu'elle envoie les fichiers de journalisation à la base de secours cible.
11. Effectuer des vérifications après validation.
12. Finaliser le processus de migration.

Note : Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Cloud@Customer, Exadata sur place et Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure prennent en charge ce flux de travail.

Préalables

• Provisionnez la base de données principale cible et la base de secours cible avant de lancer le processus de migration. Ces environnements sont supposés être configurés à l'aide d'Oracle Data Guard Broker.

  • Lorsque Exadata Cloud Service (ExaCS)/Oracle Exadata Database Service on Cloud@Customer est utilisé pour platform_type, cela peut être fait à l'aide d'associations Oracle Data Guard (dans la console Oracle Database Cloud Service).
  • Pour le système de base de données de machine virtuelle platform_type, la configuration peut être effectuée (manuellement) à l'aide de l'interface de ligne de commande d'Oracle Data Guard (DGMGRL), qui est un outil d'interface de ligne de commande du courtier Oracle Data Guard.

• Méthodes de migration prises en charge : Seules les migrations en ligne sont prises en charge (où Oracle Data Guard est utilisé).

• Méthodes de transfert de données prises en charge : OCI Object Storage, Zero Data Loss Recovery Appliance (ZDLRA), Direct.

• Type de plate-forme pris en charge : ExaCS, Oracle Exadata Database Service on Cloud@Customer, Virtual Machine Database System (ZDLRA n'est pas pris en charge).

• Générez une paire de clés publique/privée et ajoutez les clés publiques aux 3 serveurs (source, cible principale, cible de secours). Copiez le fichier de clé privée sur l'hôte du service Oracle Zero Downtime Migration à un emplacement accessible. Ce fichier sera utilisé lors de la migration pour la connexion.

Tâche 1 : Tâches avant migration

Les étapes suivantes expliquent les tâches préalables à effectuer avant la migration réelle.

1. Installez le logiciel sur le système source. zdmcli build affiche la version des binaires. Pour plus d'informations, voir Installer le logiciel sur le système source.

   

2. Comme indiqué dans les préalables, la configuration de la récupération après sinistre a été configurée entre les machines de système de base de données de machine virtuelle de secours principale et cible OCI, comme illustré dans l'image suivante.

   

   Inventaire des bases de données et des serveurs :

   Nom	Valeur
   Nom et version de la base de données	Db0403 & 19c
   Nom d'hôte source (sur place)	source de données
   Nom d'hôte "principal cible" OCI	ociserverprimaire
   Nom d'affichage de la console "Principale cible" OCI	OCI_FUTURE_PRIMARY
   Nom d'hôte de la "base de secours cible" OCI	ociserverstandby
   Nom d'affichage de la console "Base de secours cible" OCI	OCI_FUTURE_STANDBY
   Nom de la base de données enfichable	Db0403_Pdb1
   &Version du nom de serveur ZDM	Atelier & 21.5

   Les images suivantes présentent les détails de la base de données principale cible OCI et des systèmes de base de données de secours cible.

   

   

3. La journalisation forcée et le mode de journalisation archivée de la base de données source sont activés et peuvent être vérifiés à l'aide de la commande suivante.

   select force_logging ,log_mode from v$database;
   FORCE_LOGGING  LOG_MODE
   --------------------------------------- ------------
   YES  ARCHIVELOG
   

4. Exécutez la commande tnsping pour tester le port 1521 activé entre les serveurs principaux source et cible et inversement pour l'expédition des journaux.

5. Le serveur Oracle Zero Downtime Migration doit pouvoir utiliser SSH en tant qu'zdmuser pour approvisionner et également cibler les serveurs de secours principaux et cibles en tant qu'utilisateur OPC. Ici, l'utilisateur du système d'exploitation du serveur source est également OPC utilisé dans cette migration avec le nom d'utilisateur OPC du système d'exploitation cible.

   

6. Le fichier /etc/hosts du serveur source a été mis à jour avec les informations sur la base de données principale et la base de données de secours cible.

   

7. Fichier /etc/hosts du serveur principal futur OCI mis à jour avec les entrées affichées dans l'image suivante.

   

8. Fichier /etc/hosts du serveur de secours futur OCI mis à jour avec les entrées affichées dans l'image suivante.

   

9. Fichier /etc/hosts du serveur hôte du service Oracle Zero Downtime Migration mis à jour avec les entrées affichées dans l'image suivante.

   

Tâche 2 : Évaluer la tâche Oracle Zero Downtime Migration

Vérifiez la commande de disponibilité d'Oracle Zero Downtime Migration à l'aide de la commande d'indicateur -eval. -eval ne lance pas la migration réelle, elle sera utilisée pour évaluer les vérifications préalables et la disponibilité des environnements.

Exécutez la commande suivante :

/u01/app/zdmhome/bin/zdmcli migrate database -rsp /home/zdmuser/physical_online.rsp -sourcedb DB0403_sourcedb -sourcenode databasesource -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/priv.key -srcarg3 sudo_location:/usr/bin/sudo -targetnode ociserverprimary -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/priv.key -tgtarg3 sudo_location:/usr/bin/sudo -targethome /u01/app/oracle/product/19.0.0.0/dbhome_1 -eval

Sortie :

Les paramètres du fichier de réponses seront utilisés pour la migration finale.

Tâche 3 : Instancier la tâche de migration finale

Le statut de la tâche EVAL est Réussite à partir de la tâche 2 et la commande suivante est utilisée pour démarrer la migration.

/u01/app/zdmhome/bin/zdmcli migrate database -rsp /home/zdmuser/physical_online.rsp -sourcedb DB0403_sourcedb -sourcenode databasesource -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/priv.key -srcarg3 sudo_location:/usr/bin/sudo -targetnode ociserverprimary -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/priv.key -tgtarg3 sudo_location:/usr/bin/sudo -targethome /u01/app/oracle/product/19.0.0.0/dbhome_1 -pauseafter ZDM_CONFIGURE_DG_TGT

Ajout de l'indicateur pauseafter à la commande de migration pour mettre la migration en pause après la phase ZDM_CONFIGURE_DG_TGT. La tâche s'est terminée avec succès jusqu'à la phase ZDM_CONFIGURE_DG_TGT et a été mise en pause comme prévu.

Résultats de la migration :

[zdmuser@workshop ~]$ zdmcli query job -jobid 13
workshop.pgvcnpublic1.pgvcn.oraclevcn.com: Audit ID: 115
Job ID: 13
User: zdmuser
Client: workshop
Job Type: "MIGRATE"
Scheduled job command: "zdmcli migrate database -rsp /home/zdmuser/physical_online.rsp -sourcedb DB0403_sourcedb -sourcenode databasesource -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/priv.key -srcarg3 sudo_location:/usr/bin/sudo -targetnode ociserverprimary -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/priv.key -tgtarg3 sudo_location:/usr/bin/sudo -targethome /u01/app/oracle/product/19.0.0.0/dbhome_1"
Scheduled job execution start time: 2025-04-03T18:23:49Z. Equivalent local time: 2025-04-03 18:23:49
Current status: PAUSED
Current Phase: "ZDM_CONFIGURE_DG_TGT"
Result file path: "/u01/app/zdmbase/chkbase/scheduled/job-13-2025-04-03-18:23:55.log"
Metrics file path: "/u01/app/zdmbase/chkbase/scheduled/job-13-2025-04-03-18:23:55.json"
Job execution start time: 2025-04-03 18:23:55
Job execution end time: 2025-04-03 19:35:48
Job execution elapsed time: 41 minutes 7 seconds
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_GET_STBY_INFO ............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_PRECHECKS_STBY ............ COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_SETUP_STBY ................ COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_PREUSERACTIONS_STBY ....... COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_VALIDATE_STBY ............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_RESTORE_TGT ............... COMPLETED
ZDM_RECOVER_TGT ............... COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_COPYFILES_TGT_STBY ........ COMPLETED
ZDM_PREPARE_STBY .............. COMPLETED
ZDM_SETUP_TDE_STBY ............ COMPLETED
ZDM_RESTORE_TGT_STBY .......... COMPLETED
ZDM_RECOVER_TGT_STBY .......... COMPLETED
ZDM_FINALIZE_STBY ............. COMPLETED
ZDM_CONFIGURE_DG_TGT .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ PENDING
ZDM_SWITCHOVER_TGT ............ PENDING
ZDM_POST_DATABASE_OPEN_TGT .... PENDING
ZDM_DATAPATCH_TGT ............. PENDING
ZDM_POST_MIGRATE_TGT_STBY ..... PENDING
ZDM_POST_MIGRATE_TGT .......... PENDING
ZDM_POSTUSERACTIONS ........... PENDING
ZDM_POSTUSERACTIONS_TGT ....... PENDING
ZDM_POSTUSERACTIONS_STBY ...... PENDING
ZDM_CLEANUP_SRC ............... PENDING
ZDM_CLEANUP_TGT ............... PENDING
ZDM_CLEANUP_STBY .............. PENDING

Pause After Phase: "ZDM_CONFIGURE_DG_TGT" <<<<<<<<<<<<<<<< job paused after this Phase.
[zdmuser@workshop ~]$

La tâche de migration a été mise en pause avant l'étape de permutation. Les futures bases de données de secours principales et futures OCI sont passées en mode de secours physique et Oracle Data Guard Broker est configuré par la tâche Oracle Zero Downtime Migration avec les trois bases de données de la configuration et toutes sont synchronisées.

Tâche 4 : Démarrer la phase de permutation des tâches de migration

Commençons la permutation en reprenant la tâche Oracle Zero Downtime Migration et la tâche 3, qui est 13.

[zdmuser@workshop ~]$ zdmcli resume job -jobid 13

workshop.pgvcnpublic1.pgvcn.oraclevcn.com: Audit ID: 117

La commande zdmcli query job -jobid 13 indique le statut de la tâche et celle-ci est marquée comme réussie maintenant.

Sortie :

[zdmuser@workshop ~]$ zdmcli query job -jobid 13
workshop.pgvcnpublic1.pgvcn.oraclevcn.com: Audit ID: 121
Job ID: 13
User: zdmuser
Client: workshop
Job Type: "MIGRATE"
Scheduled job command: "zdmcli migrate database -rsp /home/zdmuser/physical_online.rsp -sourcedb DB0403_sourcedb -sourcenode databasesource -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/priv.key -srcarg3 sudo_location:/usr/bin/sudo -targetnode ociserverprimary -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/priv.key -tgtarg3 sudo_location:/usr/bin/sudo -targethome /u01/app/oracle/product/19.0.0.0/dbhome_1"
Scheduled job execution start time: 2025-04-03T18:23:49Z. Equivalent local time: 2025-04-03 18:23:49

Current status: SUCCEEDED <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Result file path: "/u01/app/zdmbase/chkbase/scheduled/job-13-2025-04-03-18:23:55.log"
Metrics file path: "/u01/app/zdmbase/chkbase/scheduled/job-13-2025-04-03-18:23:55.json"
Job execution start time: 2025-04-03 18:23:55
Job execution end time: 2025-04-04 06:03:04
Job execution elapsed time: 56 minutes 15 seconds
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_GET_STBY_INFO ............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_PRECHECKS_STBY ............ COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_SETUP_STBY ................ COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_PREUSERACTIONS_STBY ....... COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_VALIDATE_STBY ............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_RESTORE_TGT ............... COMPLETED
ZDM_RECOVER_TGT ............... COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_COPYFILES_TGT_STBY ........ COMPLETED
ZDM_PREPARE_STBY .............. COMPLETED
ZDM_SETUP_TDE_STBY ............ COMPLETED
ZDM_RESTORE_TGT_STBY .......... COMPLETED
ZDM_RECOVER_TGT_STBY .......... COMPLETED
ZDM_FINALIZE_STBY ............. COMPLETED
ZDM_CONFIGURE_DG_TGT .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_POST_MIGRATE_TGT_STBY ..... COMPLETED
ZDM_POST_MIGRATE_TGT .......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_POSTUSERACTIONS_STBY ...... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED
ZDM_CLEANUP_STBY .............. COMPLETED
[zdmuser@workshop ~]$

La commande DGMGRL est exécutée à partir de l'OCI principal cible (il s'agit maintenant de l'OCI principal courant) lors de la permutation de base de données. La base de données de secours cible OCI est toujours en mode De secours comme prévu et la source est passée du rôle de base de données de secours principale au rôle de base de données de secours physique.

Bien que la base de données de secours sur place ne s'affiche pas dans la configuration du courtier, elle continue de recevoir les fichiers de journalisation de la base de données principale OCI vers la base de données sur place source et peut être vérifiée à l'aide des commutateurs de journaux ou de la valeur log_archive_dest_3.

Tâche 5 : Supprimer la base de données source de la configuration

Supprimez définitivement la synchronisation sur place et effectuez la permutation native à partir de la console OCI.

Lancez la tâche de permutation à partir de la console pour tester la permutation à la console.

	Principal OCI	Base de données de secours OCI
Avant la permutation	DB0403_primary_oci	DB0403_69p_iad
Après la permutation	DB0403_69p_iad	DB0403_primary_oci

L'image suivante présente la sortie DGMGRL une fois la permutation terminée.

Liens connexes

• Notes de version pour la migration sans temps d'arrêt

• Présentation d'Oracle Zero Downtime Migration 21.5

• Oracle Zero Downtime Migration 21.5

Remerciements

• Auteur - Sivakrishna Burle (ingénieur en nuage principal, services infonuagiques Oracle pour l'Amérique du Nord - NACIE)

Autres ressources d'apprentissage

Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation sur le produit, visitez Oracle Help Center.

---

Informations sur le titre et les droits d'auteur

Implement Oracle Zero Downtime Migration 21.5 Cloud Native Disaster Recovery Automation

G32262-01

Copyright ©2025, Oracle and/or its affiliates.