Configurer la future base principale

Vous configurerez le futur service Oracle Exadata Database Service on Dedicated Infrastructure principal et configurerez Oracle Zero Downtime Migration pour préparer la migration de la base de données PeopleSoft vers OCI.

A propos des prérequis d'Oracle Zero Downtime Migration

Voici les prérequis Oracle Zero Downtime Migration (ZDM) les plus critiques pour une migration réussie :

  1. Serveur hôte ZDM

    Provisionnez un hôte dédié ou une machine virtuelle pour héberger l'installation ZDM, qui inclut une petite empreinte Oracle Clusterware, une base de données MySQL et l'application de patches et provisionnement de parc. La dernière image Oracle Linux 7 doit être installée sur ce serveur. Cette forme de machine virtuelle peut être petite, 2 coeurs avec 16 Go de RAM physique suffisent. Le serveur ZDM orchestre toutes les tâches de migration de base de données sur les systèmes source et cible.

  2. Connectivité réseau
    Le type de connectivité réseau dont vous disposez sur site vers les ressources sur OCI déterminera votre méthode de migration ZDM et vos options de transfert de données. Oracle Zero Downtime Migration permet différentes topologies de connectivité réseau, notamment des connexions directes via le VPN OCI FastConnect ou IPSec, l'utilisation de tunnels SSH, de serveurs proxy et d'hôtes de bastion.

    Remarques :

    Il est extrêmement important de comprendre comment vos systèmes sur site accéderont aux ressources OCI et si les ressources OCI doivent accéder à des systèmes sur site spécifiques, et si oui, par quel chemin réseau.
    Prenez les éléments suivants en considération :
    1. Le serveur hôte ZDM doit pouvoir accéder aux systèmes source et cible OCI sur site
    2. Pour les méthodes de migration en ligne utilisant Oracle Data Guard, les systèmes source et cible doivent pouvoir accéder les uns aux autres.
  3. Chiffrement transparent des données (TDE)

    OCI exige que toutes les bases de données soient cryptées. S'il n'est pas possible de crypter les données elles-mêmes avant le transfert de la base de données dans OCI, vous pouvez créer un portefeuille de fichier de clés TDE au niveau de la source et le processus de migration ZDM crypte les fichiers de données au niveau de la cible. Un portefeuille TDE est requis au niveau de la source pour les versions de base de données 12.2 et supérieures, mais vous pouvez utiliser cette méthode pour les versions de base de données antérieures.

    Pour connaître les étapes de définition du fichier de clés TDE, reportez-vous à Configuration du fichier de clés de cryptage transparent des données dans Déplacement vers Oracle Cloud à l'aide de Zero Downtime Migration.

  4. Base de données d'espace réservé
    Vous devez créer une base de données d'espace réservé sur Oracle Exadata Database Service on Dedicated Infrastructure cible avant de procéder à la migration avec Oracle Zero Downtime Migration. Le moniteur ZDM supprime les structures de données de la base de données de réserve dans le cadre du processus de migration, les structures de la base de données source étant restaurées à sa place. Ses métadonnées resteront en place. Utilisez la console OCI pour la créer, avec les contraintes suivantes :
    1. Le répertoire de base de base de données doit avoir la même version logicielle, la même version et le même niveau de patch que le répertoire principal.
    2. DB_NAME doit être identique à celui de la base de données principale.
    3. La valeur DB_UNIQUE_NAME peut être laissée vide ou spécifiée, mais elle doit être différente de la valeur principale.
    4. Le mot de passe SYS doit être identique à celui de la base principale, car nous utilisons Oracle Data Guard.
    5. Ne créez pas de base de données pluggable dans cette base de données Conteneur.
    6. Ne pas configurer de sauvegardes automatiques lors du provisionnement de cette base de données
  5. Accès SSH

    Oracle Zero Downtime Migration nécessite un accès SSH aux systèmes source et cible. Pour la cible, vous utiliserez l'utilisateur cloud opc et les clés SSH sans mot de passe. Pour une source sur site, vous utiliserez l'utilisateur root. Vous pouvez configurer des clés SSH sans mot de passe et les utiliser sans phrases de passe, ou vous pouvez utiliser l'utilisateur et le mot de passe root. Reportez-vous à Oracle Zero Downtime Migration pour configurer l'accès SSH et vérifier que le serveur hôte ZDM peut accéder aux systèmes source et cible.

Remarques :

Reportez-vous à Déplacement vers Oracle Cloud à l'aide de Zero Downtime Migration pour obtenir une description complète des prérequis pour Oracle Zero Downtime Migration.

Configuration d'Oracle Zero Downtime Migration pour Database Migration

Une fois les prérequis résolus et que vous avez installé Oracle Zero Downtime Migration, vous pouvez créer un fichier de réponses pour configurer la migration de base de données.

  1. Copiez le modèle de fichier de réponses trouvé dans $ZDM_HOME/rhp/zdm/template/zdm_template.rsp vers votre répertoire de travail sur le serveur hôte Oracle Zero Downtime Migration.
  2. Modifiez le fichier de réponses pour la migration de base de données.
    Plusieurs paramètres sont disponibles pour contrôler la migration.
    Par exemple, vous pouvez configurer la migration de façon à configurer Oracle Data Guard et Oracle Data Guard Broker, et à réduire les temps d'inactivité :
    Paramètre ZDM Value Commentaires
    TGT_DB_UNIQUE_NAME CDBHCM_iad1dx Spécifie la valeur db_unique_name de la base de données d'espace réservé.
    MIGRATION_METHOD ONLINE_PHYSICAL Méthode de migration utilisée par Oracle Zero Downtime Migration qui ne nécessite pas l'arrêt de la base de données principale.
    DATA_TRANSFER_MEDIUM OSS Oracle Zero Downtime Migration utilise le service OCI Object Storage pour préparer la sauvegarde de la base de données, puis la restaurer à partir de celle-ci. Vous pouvez utiliser d'autres méthodes de transfert, telles que DIRECT, qui peuvent utiliser RMAN RESTORE FROM SERVICE sans avoir à préparer la base de données dans le stockage d'objets. Pour DIRECT, d'autres paramètres Oracle Zero Downtime Migration sont requis, reportez-vous à la documentation Oracle Zero Downtime Migration.
    PLATFORM_TYPE ExaCS[1] Le système cible de la migration est Exadata Cloud Service.
    TGT_RETAIN_DB_UNIQUE_NAME TRUE (VRAI) Pour qu'Oracle Data Guard renvoie les journaux à la source, la base de données cible (TGT) DB_UNIQUE_NAME est conservée pendant le processus de migration.
    TGT_SKIP_DATAPATCH TRUE (VRAI) Ignorez l'exécution de datapatch sur la base de données cible.
    SHUTDOWN_SRC FALSE (FAUX) N'arrêtez pas la base de données source une fois la migration terminée.
    SRC_RMAN_CHANNELS 10 Oracle Recovery Manager (RMAN) alloue 10 canaux à la base de données source pour la sauvegarde parallèle de la base de données.
    TGT_RMAN_CHANNELS 10 Oracle RMAN allouera 10 canaux sur la base de données cible pour la restauration parallèle de la base de données.
    ZDM_USE_DG_BROKER TRUE (VRAI) Oracle Zero Downtime Migration configure Oracle Data Guard Broker dans le cadre du processus de migration.
    HOST https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/maacloud URL d'adresse de service OCI Object Storage. Requis pour le support de transfert de données OCI Object Storage.
    OPC_CONTAINER ZDM_Backup Nom de bucket OCI Object Storage. Requis pour le support de transfert de données OCI Object Storage.

    [1] La valeur acceptée pour PLATFORM_TYPE pour Oracle Exadata Database Service on Dedicated Infrastructure est ExaCS.

  3. Déterminez les paramètres et paramètres restants qui conviennent à votre scénario.
    Dans notre exemple, nous avons pu accepter les valeurs par défaut des paramètres restants. Pour plus d'informations, reportez-vous à la documentation Oracle Zero Downtime Migration.

Test de la configuration et du fichier de paramètres Oracle Zero Downtime Migration

Pour tester les étapes de préparation et le fichier de configuration, exécutez Oracle Zero Downtime Migration en mode d'évaluation.

L'option de ligne de commande -eval indique à Oracle Zero Downtime Migration d'effectuer des prévérifications uniquement pour toutes ses phases de processus de migration, puis de s'arrêter. Aucune modification n'est apportée aux systèmes. Les prévérifications Oracle Zero Downtime Migration sont effectuées sur les bases de données source et cible et, si DATA_TRANSFER_MEDIUM est défini sur OSS, sur OCI Object Storage.
  1. Exécutez les prévérifications du processus de migration.
    Exemple :
    $ZDM_HOME/bin/zdmcli migrate database \
     -sourcedb CDBHCM_sca6dp \
     -sourcenode scaqan10dv0505.example.com \
     -srcauth zdmauth \
     -srcarg1 user:opc \
     -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
     -srcarg3 sudo_location:/usr/bin/sudo \
     -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com \
     -backupuser <oci user name> \
     -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp \
     -tgtauth zdmauth \
     -tgtarg1 user:opc \
     -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
     -tgtarg3 sudo_location:/usr/bin/sudo \
     -eval

    Tous les travaux Oracle Zero Downtime Migration sont exécutés via un mécanisme de programmation de travaux et sont exécutés de manière asynchrone. Lorsqu'une commande Oracle Zero Downtime Migration est émise, vous recevez un ID de travail que vous pouvez utiliser pour vérifier le statut du travail.

  2. Vérifiez le statut de votre travail.
    Par exemple, exécutez la commande suivante pour interroger le statut du travail portant l'ID 5 :
    $ $ZDM_HOME/bin/zdmcli query job -jobid 5
    La sortie indique quelle tâche est en cours d'exécution, quelles tâches sont en attente et si les prévérifications ont réussi ou échoué. Lorsque vous interrogez le statut du travail, vous pouvez voir la progression jusqu'à ce que le travail ait exécuté toutes les tâches requises.
  3. Exécutez zdmcli avec -eval autant de fois que nécessaire pour que toutes les prévérifications réussissent.
    Si une tâche est marquée PRECHECK_FAILED, consultez le fichier journal "Résultat" pour connaître les erreurs et corrigez-les.
  4. Avant d'effectuer une migration réelle, assurez-vous que le mode d'évaluation renvoie PRECHECK_PASSED pour toutes les tâches de prévérification.
    Exemple :
    iad-zdm. ebsexadbprivate.ebscloudmaavcn.oraclevcn.com: Audit ID: 50
    Job ID: 5
    User: zdmuser
    Client: iad-zdm
    Job Type: "EVAL"
    Scheduled job command: "zdmcli migrate database -sourcedb CDBHCM_sca6dp -sourcenode scaqan10dv0505.mycompany.com -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3 sudo_location:/usr/bin/sudo -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com -backupuser <oci user name> -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3 sudo_location:/usr/bin/sudo -eval"
    Scheduled job execution start time: 2022-07-26T20:26:01Z. Equivalent local time: 2022-07-26 20:26:01
    Current status: SUCCEEDED
    Result file path: "/u01/app/zdmbase/chkbase/scheduled/job-5-2022-07-26-20:26:21.log"
    Metrics file path: "/u01/app/zdmbase/chkbase/scheduled/job-5-2022-07-26-20:26:21.json"
    Job execution start time: 2022-07-26 20:26:21
    Job execution end time: 2022-07-26 20:30:37
    Job execution elapsed time: 4 minutes 16 seconds
    ZDM_GET_SRC_INFO ........... PRECHECK_PASSED
    ZDM_GET_TGT_INFO ........... PRECHECK_PASSED
    ZDM_PRECHECKS_SRC .......... PRECHECK_PASSED
    ZDM_PRECHECKS_TGT .......... PRECHECK_PASSED
    ZDM_SETUP_SRC .............. PRECHECK_PASSED
    ZDM_SETUP_TGT .............. PRECHECK_PASSED
    ZDM_PREUSERACTIONS ......... PRECHECK_PASSED
    ZDM_PREUSERACTIONS_TGT ..... PRECHECK_PASSED
    ZDM_OBC_INST_SRC ........... PRECHECK_PASSED
    ZDM_OBC_INST_TGT ........... PRECHECK_PASSED
    ZDM_VALIDATE_SRC ........... PRECHECK_PASSED
    ZDM_VALIDATE_TGT ........... PRECHECK_PASSED
    ZDM_POSTUSERACTIONS ........ PRECHECK_PASSED
    ZDM_POSTUSERACTIONS_TGT .... PRECHECK_PASSED
    ZDM_CLEANUP_SRC ............ PRECHECK_PASSED
    ZDM_CLEANUP_TGT ............ PRECHECK_PASSED

Migration de la base de données PeopleSoft

Vous pouvez utiliser Oracle Zero Downtime Migration pour migrer la base de données. Par défaut, la base de données est migrée, puis basculée vers celle-ci.

Remarques :

Nous ne voulons PAS qu'Oracle Zero Downtime Migration effectue la permutation. Utilisez donc la clause -stopafter pour arrêter une fois la phase ZDM_CONFIGURE_DG_SRC terminée.

  1. Exécutez le processus de migration de base de données et indiquez -stopafter pour arrêter la migration.
    Exemple :
    $ZDM_HOME/bin/zdmcli migrate database \
     -sourcedb CDBHCM_sca6dp \
     -sourcenode scaqan10dv0505.mycompany.com \
     -srcauth zdmauth \
     -srcarg1 user:opc \
     -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
     -srcarg3 sudo_location:/usr/bin/sudo \
     -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com \
     -backupuser <oci user name> \
     -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp \
     -tgtauth zdmauth \
     -tgtarg1 user:opc \
     -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk \
     -tgtarg3 sudo_location:/usr/bin/sudo \
     -stopafter ZDM_CONFIGURE_DG_SRC

    La commande renvoie un ID de travail que vous pouvez utiliser pour vérifier le statut du travail.

  2. Vérifiez le statut de votre travail.
    Par exemple, exécutez la commande suivante pour interroger le statut du travail portant l'ID 6 :
    $ $ZDM_HOME/bin/zdmcli query job -jobid 6

    Voici un exemple de la sortie finale après avoir terminé la phase ZDM_CONFIGURE_DB_SRC.

    iad-zdm. ebsexadbprivate.ebscloudmaavcn.oraclevcn.com: Audit ID: 74
    Job ID: 6
    User: zdmuser
    Client: iad-zdm
    Job Type: "MIGRATE"
    Scheduled job command: "zdmcli migrate database -sourcedb CDBHCM_sca6dp -sourcenode scaqan10dv0505.mycompany.com -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3 sudo_location:/usr/bin/sudo -targetnode iadexadb-bw5wn1.ebsexadbprivate.ebscloudmaavcn.oraclevcn.com -backupuser <oci user name> -rsp /home/zdmuser/zdm_CDBHCM_migration.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3 sudo_location:/usr/bin/sudo -pauseafter ZDM_CONFIGURE_DG_SRC"
    Scheduled job execution start time: 2022-07-26T20:35:24Z. Equivalent local time: 2022-07-26 20:35:24
    Current status: PAUSED
    Current Phase: "ZDM_CONFIGURE_DG_SRC"
    Result file path: "/u01/app/zdmbase/chkbase/scheduled/job-6-2022-07-26-20:35:51.log"
    Metrics file path: "/u01/app/zdmbase/chkbase/scheduled/job-6-2022-07-26-20:35:51.json"
    Job execution start time: 2022-07-26 20:35:51
    Job execution end time: 2022-07-26 21:37:05
    Job execution elapsed time: 1 hours 1 minutes 14 seconds
    ZDM_GET_SRC_INFO ............... COMPLETED
    ZDM_GET_TGT_INFO ............... COMPLETED
    ZDM_PRECHECKS_SRC .............. COMPLETED
    ZDM_PRECHECKS_TGT .............. COMPLETED
    ZDM_SETUP_SRC .................. COMPLETED
    ZDM_SETUP_TGT .................. COMPLETED
    ZDM_PREUSERACTIONS ............. COMPLETED
    ZDM_PREUSERACTIONS_TGT ......... COMPLETED
    ZDM_OBC_INST_SRC ............... COMPLETED
    ZDM_OBC_INST_TGT ............... COMPLETED
    ZDM_VALIDATE_SRC ............... COMPLETED
    ZDM_VALIDATE_TGT ............... COMPLETED
    ZDM_BACKUP_FULL_SRC ............ COMPLETED
    ZDM_BACKUP_INCREMENTAL_SRC ..... COMPLETED
    ZDM_DISCOVER_SRC ............... COMPLETED
    ZDM_COPYFILES .................. COMPLETED
    ZDM_PREPARE_TGT ................ COMPLETED
    ZDM_SETUP_TDE_TGT .............. COMPLETED
    ZDM_CLONE_TGT .................. COMPLETED
    ZDM_FINALIZE_TGT ............... COMPLETED
    ZDM_CONFIGURE_DG_SRC ........... COMPLETED

Lorsque cette commande a terminé l'étape ZDM_CONFIGURE_DG_SRC, Oracle Zero Downtime Migration a copié la base de données source dans OCI, l'a configurée en tant que base de données de secours de la source, a configuré Data Guard Broker et a démarré redo apply. La nouvelle base de données de secours OCI est en cours de synchronisation avec la base de données principale source.

Oracle Zero Downtime Migration a également effectué les tâches suivantes :

  • Inscription de la base de données migrée dans Oracle Clusterware
  • Les métadonnées du plan de contrôle OCI ont été mises à jour avec les informations mises à jour, y compris les bases de données pluggables qui se trouvent dans la base de données de secours.
  • Cryptage des fichiers de données de la base de données de secours à l'aide du cryptage transparent des données (TDE), comme indiqué dans les prérequis Oracle Zero Downtime Migration.

    Remarques :

    La valeur WALLET_TYPE dans la vue V$ENCRYPTION_WALLET est définie sur AUTOLOGIN.

Définir des services de base de données basés sur des rôles pour une base principale future

Ajoutez les services de base de données basés sur les rôles que l'application PeopleSoft utilisera lorsque la base de données OCI remplit le rôle PRIMARY, à la fois pour les utilisateurs en ligne et pour l'ordonnanceur de traitements.

  • Ajoutez des services de base de données basés sur les rôles pour les utilisateurs en ligne et l'ordonnanceur de traitements.
    srvctl add service -db CDBHCM_iad1dx -pdb HR92U033 -service HR92U033_BATCH -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY,SNAPSHOT_STANDBY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3
    
    srvctl add service -db CDBHCM_iad1dx -pdb HR92U033 -service HR92U033_ONLINE -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY,SNAPSHOT_STANDBY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3