Remarques :

• Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction à Oracle Cloud Infrastructure Free Tier.
• Il utilise des exemples de valeurs pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. Lorsque vous terminez votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

Implémenter Oracle Zero Downtime Migration 21.5 Cloud Native Disaster Recovery Automation

Introduction

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

Diagramme d'architecture

Etapes du workflow Oracle Zero Downtime Migration

1. Lancez la migration de base de données.
2. Effectuez une restauration à partir du service.
3. Instanciez la base de données de secours sur la base principale cible.
4. Synchronisez la base de données principale et la base de données de secours sur la base de données principale cible.
5. Effectuez la restauration à partir du service.
6. Instanciez la base de données de secours sur la base de données de secours cible.
7. Synchroniser les bases de données de secours source et cible.
8. Surveiller la préparation aux permutations.
9. Effectuez la permutation et la transition de rôle.
10. Configurez la configuration principale cible et restaurez la configuration Cloud Broker.
    1. Oracle Zero Downtime Migration restaure la configuration du broker cloud entre la base de données principale de la cible cloud et la base de données de secours de la cible cloud.
    2. Oracle Zero Downtime Migration configure la base de données principale cible pour qu'elle envoie les fichiers de journalisation à la base de données de secours cible.
11. Effectuez des vérifications après validation.
12. Finaliser le processus de migration.

Remarque : Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Cloud@Customer, Exadata sur site et Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure prennent en charge ce workflow.

Prérequis

• Provisionnez la base de données principale cible et la base de données de secours cible avant de commencer 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, vous pouvez le faire à l'aide des 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 Oracle Data Guard (DGMGRL), qui est un outil de l'interface de ligne de commande du broker 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, système de base de données de machine virtuelle (ZDLRA n'est pas pris en charge).

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

Tâche 1 : tâches de pré-migration

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

1. Installez le logiciel sur le système source. Le build zdmcli affiche la version des fichiers binaires. Pour plus d'informations, reportez-vous à la section Install the Software on the Source System.

   

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

   

   Inventaire des bases de données et des serveurs :

   Nom	Value
   Nom et version de la base de données	Db0403 & 19c
   Nom d'hôte source (onpremise)	source de base de données
   Nom d'hôte "principal cible" OCI	ociserverprimary
   Nom d'affichage de la console "principale cible" OCI	OCI_FUTURE_PRIMARY
   Nom d'hôte de la base de données de secours cible OCI	ociserverstandby
   Nom d'affichage de la console de secours cible OCI	OCI_FUTURE_STANDBY
   Nom de PDB	Db0403_Pdb1
   &Version du nom du serveur ZDM	atelier & 21.5

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

   

   

3. La journalisation forcée et le mode d'archivage 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'utilisateur zdmuser pour la source et également cibler les serveurs de secours principal et cible 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 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. Le fichier /etc/hosts du futur serveur principal OCI a été mis à jour avec les entrées affichées dans l'image suivante.

   

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

   

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

   

Tâche 2 : évaluer le travail Oracle Zero Downtime Migration

Vérifiez la commande de préparation 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 l'évaluation des prévérifications et de la préparation 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 le travail de migration final

Le statut du travail EVAL est Succès à 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

L'indicateur pauseafter a été ajouté à la commande de migration pour mettre en pause la migration après la phase ZDM_CONFIGURE_DG_TGT. Le travail s'est terminé avec succès jusqu'à la phase ZDM_CONFIGURE_DG_TGT et a été mis 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 ~]$

Le travail de migration a été mis en pause avant l'étape de permutation. Les bases de données principale et de secours futures OCI passent en mode de secours physique et Oracle Data Guard Broker est configuré par le travail 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 du travail de migration

Commençons la permutation en reprenant le travail Oracle Zero Downtime Migration et le travail 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 du travail et celui-ci est désormais marqué comme réussi.

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 (maintenant il s'agit de l'OCI principal en cours) 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 principale au rôle de base de données de secours physique.

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

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

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

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

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

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

Liens connexes

• Notes sur la version de Zero Downtime Migration

• Annonce d'Oracle Zero Downtime Migration 21.5

• Oracle Zero Downtime Migration 21.5

Remerciements

• Auteur - Sivakrishna Burle (Ingénieur Cloud senior, Oracle North America Cloud Services - NACIE)

Ressources de formation supplémentaires

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

Pour obtenir la documentation produit, consultez le site Oracle Help Center.

---

Informations relatives au titre et au copyright

Implement Oracle Zero Downtime Migration 21.5 Cloud Native Disaster Recovery Automation

G32263-01

Copyright ©2025, Oracle and/or its affiliates.