1. Provisionner et déployer une solution à disponibilité maximale pour PeopleSoft sur Oracle Cloud
  2. Configurer pour le service de migration de bases de données
  3. Configurer la future base de données secondaire

Configurer la future base de données secondaire

Après avoir établi la première base de secours physique dans Oracle Cloud Infrastructure (OCI), vous en créerez une seconde dans une autre région. Cette deuxième base de données est la base de données de votre environnement de récupération après sinistre en nuage.

La fonctionnalité de base de données de secours en cascade d'Oracle Data Guard, où la deuxième base de données de secours reçoit redo de la première base de données de secours, et non directement de la base principale sur place, réduit le trafic réseau du site hôte sur place. Il déterminera également la route de propagation redo principale.

Pour le moment, certaines contraintes nous empêchent d'utiliser les outils OCI pour établir et gérer entièrement notre future base de données de reprise après sinistre. Le service en nuage d'association d'Oracle Data Guard ne peut pas enregistrer actuellement une relation de base de données de secours existante et ne pourra pas gérer la configuration de la base de données de secours. Par conséquent, par exemple, Oracle Managed Disaster Recovery Cloud Service ne peut pas être utilisé.

Comme les deux bases de données de secours sont établies avec une base de données fictive basée sur OCI, le plan de contrôle OCI peut gérer l'application de correctifs et d'autres activités de cycle de vie pour chacune d'entre elles.

Créer une base de données de paramètres fictifs

Utilisez la console OCI pour créer une nouvelle base de données de paramètre fictif dans une autre région (recommandée) ou dans un autre domaine de disponibilité dans la même région.

Suivez les étapes ci-dessous. NE supprimez PAS la base de données de paramètre fictif à l'aide d'outils tels qu'OCI ou dbaascli.
  1. Sélectionnez Exadata dans Oracle Public Cloud. Sélectionnez le service Oracle Exadata Database Service on Dedicated Infrastructure sur lequel vous voulez déployer la base de données.

    Suivez ces contraintes :

    • Le répertoire de base de données doit avoir la même version de logiciel, la même version et le même niveau de correctif que la source.
    • La valeur DB_NAME doit être identique à celle de la base principale et de la première base de secours.
    • DB_UNIQUE_NAME peut être vide ou spécifié, mais doit être différent de la base principale sur place et de la première base de secours physique.
    • Ne configurez pas de sauvegardes automatiques lors du provisionnement de cette base de données.
    • Ne spécifiez pas de nom de base de données enfichable lors du provisionnement de cette base de données.
  2. Saisissez les données de configuration de secours en cascade.
    1. Connectez-vous en tant qu'utilisateur du système d'exploitation oracle sur l'un des noeuds de base de données hébergeant la base de données fictive qui vient d'être créée.
    2. Approvisionnez l'environnement pour cette base de données.
    3. Exécutez la commande suivante à l'aide de DB_UNIQUE_NAME :
    $ srvctl config database -db DB_UNIQUE_NAME
    Enregistrez ces données de configuration, vous les utiliserez dans plusieurs étapes ci-dessous.
  3. Arrêtez la base de données des paramètres fictifs.
    $ srvctl stop database -db cascade standby placeholder database -stopoption immediate
  4. Connectez-vous en tant qu'utilisateur grid OS. À l'aide de la commande asmcmd, videz les fichiers dans les répertoires sous +DATAC1/DB_UNIQUE_NAME :
    1. DATAFILE
    2. ONLINELOG
    3. Tout PDB GUID/DATAFILE
    4. Tous les fichiers de contrôle sous +DATAC1/DB_UNIQUE_NAME/CONTROLFILE
    5. Fichier de mots de passe spécifié dans les données de configuration saisies à l'étape 1
  5. Sous +RECOC1/DB_UNIQUE_NAME, supprimez les fichiers des répertoires ARCHIVELOG, AUTOBACKUP et FLASHBACKLOG.
  6. Ne pas supprimer spfile.

Se préparer pour la restauration de la base de données

Configurez le nouveau répertoire de base Oracle en vue de la restauration de la base de données.

  • Ajustez le fichier tnsnames.ora dans chaque environnement pour être conscient de chacune des autres bases de données. Vérifiez les communications entre les environnements.
  • Copiez le fichier de mots de passe de la première base de données de secours.
  • Copiez le portefeuille Chiffrement transparent des données (TDE) de la première base de données de secours.
  • Ajustez les paramètres de la base de données de secours en cascade.

Configurer TNS pour la base de secours en cascade

Ajustez le fichier tnsnames.ora dans chaque environnement pour être conscient de chacune des autres bases de données. Vérifiez les communications entre les environnements.

Data Guard Broker doit pouvoir communiquer avec chaque base de données de la configuration, quelle que soit l'instance à laquelle il est connecté. Oracle Zero Downtime Migration a effectué cette configuration pour la relation de secours initiale. Vous devez ajouter la base de données de secours en cascade dans la configuration :
  • Ajoutez la chaîne de connexion TNS pour la base de données de secours en cascade aux fichiers tnsnames.ora utilisés par toutes les instances Oracle Real Application Clusters (Oracle RAC) des bases de données principale sur place et de première base de secours
  • Ajoutez les chaînes de connexion TNS pour la base principale sur place et les premières bases de données de secours OCI aux fichiers tnsnames.ora utilisés par toutes les instances Oracle RAC de la base de données de secours en cascade.
Ces entrées TNS doivent chacune utiliser des adresses SCAN IP, et non le nom SCAN. Voici un exemple d'entrée TNS conforme créée par Oracle Zero Downtime Migration pour notre première base de données de secours : 
CDBHCM_iad1dx =
          (DESCRIPTION =
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  1>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  2>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  3>)) (PORT = 1521))
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = CDBHCM_iad1dx)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
              (UR=A)
             )
          )

Vous devez vous connecter à chaque serveur de base de données en tant qu'utilisateur du système d'exploitation oracle, sourcez votre environnement, puis accédez au répertoire $TNS_ADMIN.

  1. Pour chaque instance Oracle RAC de la base principale sur place et de la première base de données de secours OCI, modifiez le fichier tnsnames.ora et ajoutez la chaîne de connexion TNS de la base de données de secours en cascade.
  2. Pour chaque instance Oracle RAC de la base de données de secours en cascade OCI, modifiez le fichier tnsnames.ora et ajoutez des chaînes de connexion TNS pour la base principale sur place et la première base de données de secours OCI.
  3. Testez que vous pouvez effectuer une commande ping sur la première base de données de secours à partir de la base de données de secours en cascade, à l'aide de l'utilitaire tnsping avec l'alias de chaîne de connexion ajouté.
    $ tnsping CDBHCM_iad1dx
    Cela devrait retourner OK avec un temps de latence en millisecondes. Si OK n'est pas retourné, vérifiez les erreurs et corrigez-les en conséquence.
  4. Testez la connexion de chacun des serveurs de base de données qui hébergeront la base de données de secours en cascade vers la première base de données de secours (CDBHCM_iad1dx) à l'aide de SQL*Plus. Vous aurez besoin du mot de passe SYS pour l'instance principale.
    $ sqlplus sys/<password>@CDBHCM_iad1dx as sysdba
    Corrigez les erreurs et répétez-les jusqu'à ce que vous puissiez vous connecter.

Copier le fichier de mots de passe

Copiez le fichier de mots de passe de la première base de données de secours.

  1. Connectez-vous à l'un des serveurs hébergeant votre première base de données de secours (CDBHCM_iad1dx) en tant qu'utilisateur oracle OS.
  2. Utilisez srvctl pour déterminer où se trouve le fichier de mots de passe de cette base de données, puis copiez-le dans le répertoire /tmp.
    Pour déterminer l'emplacement racine du portefeuille, exécutez la commande suivante en tant que sysdba :
    $ srvctl config database -db first standby db name
  3. Recherchez la ligne qui indique "Fichier de mot de passe :" et enregistrez son emplacement (chemin d'accès à Oracle Automatic Storage Management (Oracle ASM)).
  4. Devenez l'utilisateur du système d'exploitation de grille et utilisez la commande asmcmd pour copier le fichier de mots de passe dans le répertoire /tmp :
    $ asmcmd -p
asmcmd> cd +DATAC1/path from step 3
asmcmd> cp <password file name> /tmp/password file name
  5. Transférez le fichier de mots de passe à un emplacement temporaire sur l'un des serveurs de base de données de secours en cascade à l'aide de scp ou par quelque moyen que ce soit que vous utilisiez pour transférer des fichiers dans OCI.
  6. Connectez-vous au serveur de base de données de secours en cascade sur lequel le fichier de mots de passe a été placé, en tant qu'utilisateur du système d'exploitation grid. Copiez le fichier de mots de passe dans Oracle ASM, à l'aide de l'emplacement spécifié dans les données de configuration de secours en cascade ci-dessus.
    $ asmcmd -p --privilege sysdba
asmcmd> pwcopy –dbuniquename cascade standby db unique name /tmp/password-file-name +ASM Diskgroup/path/password-file-name -f
    Par exemple,
    asmcmd> pwcopy –dbuniquename CDBHCM_phx5s   /tmp/password file name +DATAC1/CDBHCM_phx5s/PASSWORD/orapwCDBHCM_phx5s -f
  7. Assurez-vous que toutes les chaînes de connexion TNS sont configurées correctement en validant que chaque base de données peut se connecter à toutes les autres bases de données. La correction des erreurs de connexion pour les tentatives de connexion suivantes échoue.
    1. À partir de la base de données sur place (principale) :
      $ sqlplus sys/password@first standby db as sysdba
$ sqlplus sys/password@cascade standby db as sysdba
    2. À partir de la première base de secours physique :
      $ sqlplus sys/password@on-prem primary as sysdba
$ sqlplus sys/password@cascade standby db as sysdba
    3. A partir de la base de secours physique en cascade :
      $ sqlplus sys/password@on-prem primary as sysdba
$ sqlplus sys/password@first standby db as sysdba
    Ne pas continuer tant que toutes les tentatives de connexion n'ont pas réussi.

Copier le portefeuille TDE

Copiez le portefeuille Chiffrement transparent des données (TDE) à partir de la première base de données de secours. On Oracle Exadata Database Service on Dedicated Infrastructure, the location that cloud tooling uses to store the TDE wallets is on Oracle Advanced Cluster File System (Oracle ACFS), which all database servers in the cluster share.
  1. Connectez-vous à l'un des serveurs hébergeant votre première base de données de secours (CDBHCM_iad1dx) en tant qu'utilisateur du système d'exploitation oracle et accédez au répertoire racine du portefeuille.
    Pour déterminer l'emplacement racine du portefeuille, exécutez la commande suivante en tant que sysdba :
    $ sqlplus / as sysdba
SQL> show wallet_root
$ cd wallet root location from “show wallet_root” above
  2. Allez à l'emplacement racine du portefeuille et compressez le répertoire tde.
    Le répertoire tde se trouve sous le répertoire indiqué à l'étape 1, qui est généralement /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root. 
    $ zip -r CDBHDM_tde_wallet.zip  tde
  3. Transférez ce fichier ZIP vers l'un des serveurs de base de données qui hébergera la base de données en cascade (CDBHCM_phx5s) vers un emplacement temporaire (par exemple, /tmp).
    Utilisez scp ou par quelque moyen que ce soit pour transférer des fichiers dans OCI.
  4. Connectez-vous aux serveurs de base de données qui hébergeront la base de données en cascade (CDBHCM_phx5s) et sur laquelle le fichier zip a été placé, en tant qu'utilisateur du système d'exploitation oracle et accédez au répertoire racine du portefeuille.

    L'emplacement doit être le même que précédemment, car DB_NAME est le même (CDBHCM). 

    $ cd /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root
  5. Déplacez le répertoire TDE existant vers un autre nom.
    $ mv tde tde_date
  6. Déplacez le fichier ZIP contenant le portefeuille TDE (CDBHDM_tde_wallet.zip) créé à l'étape 2 vers le chemin suivant :/var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root.
    Remplacez DB_NAME par le nom de votre base de données.
  7. Décompressez le fichier CDBHDM_tde_wallet.zip.
    $ unzip CDBHDM_tde_wallet.zip

Cela crée un nouveau sous-répertoire tde avec les fichiers de portefeuille de la première base de données de secours physique.

Ajuster les paramètres de base de données pour la base de secours en cascade

Finaliser la configuration de la base de données de secours en cascade.

  1. Connectez-vous à l'un des serveurs hébergeant la première base de données de secours (CDBHCM_iad1dx) en tant qu'utilisateur oracle OS et sourcez l'environnement. 
    $ . ./CDBHCM.env
  2. Créez un fichier pfile à partir de la première base de secours à utiliser comme référence pour ajuster les paramètres de la base de secours en cascade.
    $ cd $ORACLE_HOME/dbs
$ sqlplus / as sysdba
SQL> create pfile=’tmp_CDBHCM_iad1dx_init.ora’ from spfile;
  3. Connectez-vous à l'un des serveurs de base de données qui hébergera la base de données de secours en cascade (CDBHCM_phx5s) et sourcez l'environnement :
    $ . ./CDBHCM.env
  4. Démarrez NOMOUNT sur une instance.
    $ sqlplus / as sysdba
SQL> startup nomount
  5. Apportez les ajustements suivants aux paramètres de base de données pour la base de données en cascade, en référençant la liste des paramètres de base de données de l'étape 2 ci-dessus :
    SQL> alter system set control_files=’’ sid=’*’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 1>’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 2>’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance N>’ scope=spfile;
SQL> alter system set sga_target=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
SQL> alter system set log_buffer=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
  6. Ajustez les paramètres propres à PeopleSoft.
    SQL> alter system set “_gby_hash_aggregation_enabled”=false sid=’*’ scope=spfile;
SQL> alter system set “_ignore_desc_in_index”=true sid=’*’ scope=spfile;
SQL> alter system set “_unnest_subquery”=true sid=’*’ scope=spfile;
SQL> alter system set nls_length_semantics='CHAR' sid=’*’ scope=spfile;

    Note :

    Ne modifiez pas les paramètres suivants :
    • DB_NAME
    • DB_UNIQUE_NAME
    • WALLET_ROOT
  7. Arrêtez et redémarrez NOMOUNT sur l'instance pour mettre en oeuvre les modifications.
    $ sqlplus / as sysdba
SQL> shutdown immediate
SQL> startup nomount

Restaurer la base de données vers la base de secours en cascade

Restaurez la base de données sur l'empreinte de secours en cascade de la première base de secours physique. Utilisez la commande RESTORE FROM SERVICE d'Oracle Recovery Manager (RMAN) pour restaurer le fichier de contrôle et les fichiers de données.

  1. Si l'instance de la base de secours en cascade n'est pas démarrée, démarrez-la dans NOMOUNT :
    $ sqlplus / as sysdba 
$ SQL> startup nomount
  2. Utilisez RMAN pour restaurer le fichier de contrôle et les fichiers de données de la première base de données de secours vers la base de données de secours en cascade.

    Note :

    Il peut être nécessaire d'ajuster le nombre de canaux RMAN pour un disque de type périphérique afin de ne pas saturer le réseau. Si une modification est requise, faites-le avant d'exécuter la commande "restaurer la base de données à partir du service". Vous pouvez le faire avec la commande suivante, en remplaçant N selon le cas : 
    RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM N; 
    $ rman target / nocatalog
RMAN> restore standby controlfile from service ‘first standby db name’;
RMAN> alter database mount;
RMAN> restore database from service ‘first standby db name’ section size 8G;
RMAN> shutdown immediate;
RMAN> exit
  3. Redémarrez toutes les instances et montez la base de données de secours en cascade à l'aide de srvctl.
    $ srvctl start database -db cascade standby db unique name -startoption mount
  4. Créez et effacez tous les fichiers journaux en ligne et de secours à l'aide du script suivant.
    $ sqlplus “/ as sysdba”
SQL> set pagesize 0 feedback off linesize 120 trimspool on
SQL> spool /tmp/clearlogs.sql
SQL> select distinct 'alter database clear logfile group '||group#||';' from v$logfile;
SQL> spool off
  5. Inspectez le script clearlogs.sql généré avant de l'exécuter. L'instance de base de données va alors créer et effacer les fichiers journaux en ligne et de secours pour tous les threads. Exécutez ensuite le script.
    SQL> @/tmp/clearlogs.sql

Configurer Data Guard Broker pour la base de secours en cascade

Vous avez déjà configuré Data Guard Broker entre la base principale sur place et la première base de données de secours OCI par Oracle Zero Downtime Migration. Vous allez maintenant ajouter la base de données de secours en cascade à la configuration.

La base de données de secours en cascade et les bases de données sur place ne communiquent pas directement entre elles. Si nécessaire, redo est expédié au moyen de la première base de données de secours sur place :

  • Lorsque la base de données sur place est principale, redo est envoyé de la base principale sur place à la première base de données de secours ou par celle-ci, puis à la base de données de secours en cascade :
    • Principal sur place vers la première base de données de secours OCI
    • Première base de données de secours OCI vers la base de données de secours en cascade OCI
  • Lorsque la première base de données de secours joue le rôle de base principale, redo est envoyée directement de cette base de données aux bases de données sur place et en cascade :
    • OCI principale à la base de données de secours sur place
    • OCI principal vers la base de données de secours en cascade OCI
  • Si la base de données de secours en cascade devient la base principale dans cette configuration, les données de journalisation sont envoyées de cette base de données vers ou via la première base de données de secours OCI, puis vers la base de données sur place :
    • Première base de données de secours OCI vers la base de données de secours sur place
    • OCI en cascade de la base principale vers la première base de secours OCI
  1. Configurez Data Guard Broker sur le serveur de base de données hébergeant la base de données de secours en cascade. Connectez-vous à l'un des serveurs de base de données hébergeant la base de données de secours en cascade en tant qu'utilisateur du système d'exploitation oracle et sourcez l'environnement. 
    $ sqlplus / as sysdba
SQL> alter system set dg_broker_config_file1=’+DTAC1/cascade standby db/DG/dr1 cascade standby db.dat’ sid=’*’ scope=both;
SQL> alter system set dg_broker_config_file2=’+RECOC1/cascade standby db/DG/dr2 cascade standby db.dat’ sid=’*’ scope=both;
SQL> alter system set dg_broker_start=TRUE sid=’*’ scope=both;
  2. Connectez-vous à la base de données principale ou à la première base de secours physique, puis sourcez l'environnement. Ajoutez la nouvelle base de données de secours en cascade à la configuration Data Guard Broker existante.
    $ dgmgrl 
DGMGRL>  connect sys/password
DGMGRL> show configuration
DGMGRL> add database 'cascade standby db’
 as connect identifier is cascade standby db;
  3. Ajoutez redo routes.
    DGMGRL> edit database on-premises db set property redoroutes='(LOCAL : first standby db ASYNC)';
DGMGRL> edit database first standby db set property redoroutes='(LOCAL : on-premises db ASYNC, cascade standby db ASYNC)(on-premises db : cascade standby db ASYNC)(cascade standby db : on-premises db ASYNC)';
DGMGRL> edit database cascade standby db set property redoroutes='(LOCAL : first standby db ASYNC)';
  4. Activez la nouvelle base de données de secours en cascade.
    DGMGRL> enable database cascade standby db;
  5. Une fois la base de données en cascade activée, elle commence à recevoir redo généré par la base de données principale sur place au moyen de la première base de secours. À partir de Data Guard Broker, affichez la configuration :
    DGMGRL> show configuration lag
Configuration - zdm_psfthcm_dg
  Protection Mode: MaxPerformance
  Members:
  CDBHCM_sca6dp  - Primary database
    CDBHCM_iad1dx - Physical standby database 
                      Transport Lag:      0 seconds (computed 0 seconds ago)
                      Apply Lag:          0 seconds (computed 1 second ago)
      CDBHCM_phx5s - Physical standby database (receiving current redo)
                        Transport Lag:      1 second (computed 1 second ago)
                        Apply Lag:          2 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 47 seconds ago)

Définir les services de base de données basés sur les rôles pour la base de secours future

Ajoutez des services de base de données basés sur des rôles que l'application PeopleSoft utilisera lorsque la base de données secondaire OCI remplit le rôle PRIMARY.

  1. Sert à ajouter des services de base de données fondés sur des rôles pour le Répartiteur de traitements.
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_BATCH -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3
  2. Ajoutez des services de base de données basés sur les rôles pour les utilisateurs en ligne. 
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_ONLINE -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3