1. Déployer une topologie de récupération après sinistre multinuage à l'aide du service Oracle Database pour Azure
  2. Déployer la topologie

Déployer la topologie

La clause "from service" de RMAN vous permet de restaurer et de récupérer les fichiers de base de données principale dans une base de secours sur le réseau. Vous pouvez utiliser cette fonctionnalité pour instancier une base de données de secours au lieu de la commande RMAN DUPLICATE DATABASE et est plus intuitive et moins sujette aux erreurs, ce qui permet de gagner du temps.

Note :

Cliquez sur Copier pour enregistrer l'exemple de commande dans le presse-papiers et le coller dans votre ligne de commande. Veillez à remplacer toute valeur variables par des valeurs propres à votre mise en oeuvre.

Créer la base de secours à l'aide de RMAN

Utilisez Oracle Recovery Manager (RMAN) pour créer la base de secours à partir de la base principale active. Vous pouvez également effectuer une restauration à partir d'une sauvegarde de la base de données principale.

  1. Connectez-vous à la base de données et démarrez-la en mode NOMOUNT.
    $ rman target / 
    startup nomount;
  2. Restaurez le fichier de contrôle de secours à partir du service principal. Dans cet exemple, DBUKS_898_LHR est la base de données principale :
    restore standby controlfile from service 'DBUKS_898_LHR';
    La sortie doit ressembler à ceci : 
    Starting restore at 04-JUL-23 
using target database control file instead of recovery catalog 
allocated channel: ORA_DISK_1 
channel ORA_DISK_1: SID=28 device type=DISK 
channel ORA_DISK_1: starting datafile backup set restore 
channel ORA_DISK_1: using network backup set from service DBUKS_898_LHR 
channel ORA_DISK_1: restoring control file 
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04 
output file name=+RECO/DBUKS_R2J_AMS/CONTROLFILE/current.256.1139953721 
Finished restore at 04-JUL-23
  3. Montez la base de données : 
    alter database mount;
    La sortie doit ressembler à ceci : 
    released channel: 
ORA_DISK_1 Statement processed
  4. En tant qu'utilisateur racine de l'instance OCI, modifiez les autorisations du répertoire Oracle pour l'ouvrir (chmod 777). 
    cd /opt/ 
    ls -ltra
    Voici ce que vous devriez voir :
    drwxr-xr-x 10 root root 4096 Jun 20 03:52 oracle
    L'entrée :
    [root@ldbuksdr]# chmod 777 oracle/ 
    ls -ltra
    Voici ce que vous devriez voir :
    drwxrwxrwx 10 root root 4096 Jun 20 03:52 oracle
  5. Restaurez la base de données à partir de la base principale (DBUKS_898_LHR) : 
    restore database from service ' DBUKS_898_LHR ';
    La sortie doit ressembler à ceci : 
    Starting restore at 04-JUL-23 
using target database control file instead of recovery catalog 
allocated channel: ORA_SBT_TAPE_1 
channel ORA_SBT_TAPE_1: SID=162 device type=SBT_TAPE 
channel ORA_SBT_TAPE_1: Oracle Database Backup Service Library VER=19.0.0.1 allocated 
channel: ORA_DISK_1 channel ORA_DISK_1: SID=28 device type=DISK 
channel ORA_SBT_TAPE_1: starting datafile backup set restore 
channel ORA_SBT_TAPE_1: using network backup set from service DBUKS_898_LHR 
channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set 
channel ORA_SBT_TAPE_1: restoring datafile 00001 to +DATA/DBUKS_898_LHR/DATAFILE/system.261.1139943103 
channel ORA_DISK_1: starting datafile backup set restore 
channel ORA_DISK_1: using network backup set from service DBUKS_898_LHR 
channel ORA_DISK_1: specifying datafile(s) to restore from backup set 
channel ORA_DISK_1: restoring datafile 00003 to +DATA/DBUKS_898_LHR/DATAFILE/sysaux.268.1139943085 
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:38 
channel ORA_SBT_TAPE_1: starting datafile backup set restore 
channel ORA_SBT_TAPE_1: using network backup set from service DBUKS_898_LHR 
channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set 
channel ORA_SBT_TAPE_1: restoring datafile 00004 to +DATA/DBUKS_898_LHR/DATAFILE/undotbs1.260.1139943133 
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:04 
channel ORA_SBT_TAPE_1: starting datafile backup set restore 
channel ORA_SBT_TAPE_1: using network backup set from service DBUKS_898_LHR 
channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set 
channel ORA_SBT_TAPE_1: restoring datafile 00005 to +DATA/DBUKS_898_LHR/F9D6EA8CCAA09630E0530905F40A5107/DATAFILE/system.264.1139942759 
channel ORA_DISK_1: restore complete, elapsed time: 00:00:49 
channel ORA_DISK_1: starting datafile backup set restore 
channel ORA_DISK_1: using network backup set from service DBUKS_898_LHR 
channel ORA_DISK_1: specifying datafile(s) to restore from backup set 
channel ORA_DISK_1: restoring datafile 00006 to +DATA/DBUKS_898_LHR/F9D6EA8CCAA09630E0530905F40A5107/DATAFILE/sysaux.265.1139942759 
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:25 channel ORA_SBT_TAPE_1: starting datafile backup set restore 
channel ORA_SBT_TAPE_1: using network backup set from service DBUKS_898_LHR 
channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set 
channel ORA_SBT_TAPE_1: restoring datafile 00007 to +DATA/DBUKS_898_LHR/F9D6EA8CCAA09630E0530905F40A5107/DATAFILE/undotbs1.266.1139942759 
channel ORA_DISK_1: restore complete, elapsed time: 00:00:18 
channel ORA_DISK_1: starting datafile backup set restore 
channel ORA_DISK_1: using network backup set from service DBUKS_898_LHR 
channel ORA_DISK_1: specifying datafile(s) to restore from backup set 
channel ORA_DISK_1: restoring datafile 00008 to +DATA/DBUKS_898_LHR/FE812140C0716067E053F6005A0AEB32/DATAFILE/system.273.1139943583 
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:04 
channel ORA_SBT_TAPE_1: starting datafile backup set restore 
channel ORA_SBT_TAPE_1: using network backup set from service DBUKS_898_LHR 
channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set 
channel ORA_SBT_TAPE_1: restoring datafile 00009 to +DATA/DBUKS_898_LHR/FE812140C0716067E053F6005A0AEB32/DATAFILE/sysaux.271.1139943599 
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:16 
channel ORA_SBT_TAPE_1: starting datafile backup set restore 
channel ORA_SBT_TAPE_1: using network backup set from service DBUKS_898_LHR 
channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set 
channel ORA_SBT_TAPE_1: restoring datafile 00010 to +DATA/DBUKS_898_LHR/FE812140C0716067E053F6005A0AEB32/DATAFILE/undotbs1.270.1139943611 
channel ORA_DISK_1: restore complete, elapsed time: 00:00:20 channel ORA_DISK_1: starting datafile backup set restore 
channel ORA_DISK_1: using network backup set from service DBUKS_898_LHR 
channel ORA_DISK_1: specifying datafile(s) to restore from backup set 
channel ORA_DISK_1: restoring datafile 00011 to +DATA/DBUKS_898_LHR/DATAFILE/users.269.1139943873 channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:02 
channel ORA_SBT_TAPE_1: starting datafile backup set restore 
channel ORA_SBT_TAPE_1: using network backup set from service DBUKS_898_LHR channel ORA_SBT_TAPE_1: specifying datafile(s) to restore from backup set 
channel ORA_SBT_TAPE_1: restoring datafile 00012 to +DATA/DBUKS_898_LHR/FE812140C0716067E053F6005A0AEB32/DATAFILE/users.274.1139943875 
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:02 
Finished restore at 04-JUL-23
    exit ;

Valider la base de données de secours

Vous devez ensuite valider la base de données de secours.

  1. Consultez le nom et le rôle de la base de données. À partir de l'invite SQL>, entrez : 
     select FORCE_LOGGING, FLASHBACK_ON, OPEN_MODE, DATABASE_ROLE, DATAGUARD_BROKER, PROTECTION_MODE from v$database ;

    La réponse suivante doit s'afficher :

    FORCE_LOGGING         FLASHBACK_ON       OPEN_MODE       DATABASE_ROLE       DATAGUARD_BROKER        PROTECTION_MODE 
-------------------- ------------------ --------------- ------------------- ------------------------ ---------------------------- 
YES                  NO                  MOUNTED        PHYSICAL STANDBY       DISABLED              MAXIMUM PERFORMANCE
  2. Consultez le traitement d'archivage, le numéro de fil de statut et le numéro de séquence de la base de données :
    select sysdate,process,status,thread#,sequence#,block# from v$managed_standby where status!='IDLE';

    La réponse suivante doit s'afficher :

    04-JUL-23    ARCH    CONNECTED    0    0    0 
04-JUL-23    DGRD    ALLOCATED    0    0    0 
04-JUL-23    DGRD    ALLOCATED    0    0    0 
04-JUL-23    ARCH    CONNECTED    0    0    0 
04-JUL-23    ARCH    CONNECTED    0    0    0 
04-JUL-23    ARCH    CONNECTED    0    0    0

    Ensuite, entrez :

    select distinct process from gv$managed_standby;

    La réponse suivante doit s'afficher :

    PROCESS 
--------- 
ARCH 
DGRD

Ajouter des fichiers journaux de secours aux bases de données principale et de secours

Les fichiers de journalisation de secours sont utilisés sur une base de données de secours pour recevoir les données de journalisation de la base principale. Les enregistrements écrits dans les fichiers de journalisation en ligne de la base principale sont transférés vers la base de secours et sont écrits dans les fichiers de journalisation de secours en même temps, ce qui réduit la probabilité de perte de données sur la base de secours. La journalisation de secours est obligatoire pour une application en temps réel.
Utilisez l'invite de commande SQL> pour les étapes suivantes.
  1. Tout d'abord, ajoutez les fichiers journaux de secours à la base principale.
    1. Entrez : 
      select group#, type, member from v$logfile;

      Vous verrez une réponse similaire à celle-ci :

      GROUP#      TYPE    MEMBER 
---------- ------- --------------------------------------------------------- 
3          ONLINE  +RECO/DBUKS_898_LHR/ONLINELOG/group_3.259.1139942665 
2          ONLINE  +RECO/DBUKS_898_LHR/ONLINELOG/group_2.258.1139942665 
1          ONLINE  +RECO/DBUKS_898_LHR/ONLINELOG/group_1.257.1139942665
    2. Entrez : 
      select bytes, group# from v$log;
      Vous verrez une réponse similaire à celle-ci :
      1073741824 1 
1073741824 3 
1073741824 2
    3. Entrez cette série de commandes :
      SQL> alter database add standby logfile thread 1 group 5 ('+RECO') size 1073741824;
      alter database add standby logfile thread 1 group 6 ('+RECO') size 1073741824; 
      alter database add standby logfile thread 1 group 7 ('+RECO') size 1073741824;
      La réponse de chacun devrait être : 
      Database altered
    4. Entrez : 
      select group#, type, member from v$logfile;
      Vous verrez une réponse similaire à celle-ci : 
      GROUP#      TYPE      MEMBER 
---------- -------   ------------------------------------------------------- 
3          ONLINE    +RECO/DBUKS_898_LHR/ONLINELOG/group_3.259.1139942665 
2          ONLINE    +RECO/DBUKS_898_LHR/ONLINELOG/group_2.258.1139942665 
1          ONLINE    +RECO/DBUKS_898_LHR/ONLINELOG/group_1.257.1139942665 
4          STANDBY   +RECO/DBUKS_898_LHR/ONLINELOG/group_4.432.1141789993 
5          STANDBY   +RECO/DBUKS_898_LHR/ONLINELOG/group_5.431.1141790001 
6          STANDBY   +RECO/DBUKS_898_LHR/ONLINELOG/group_6.430.1141790011 
7          STANDBY   +RECO/DBUKS_898_LHR/ONLINELOG/group_7.430.1141790017
    5. Archivez la liste des journaux : 
      archive log list
  2. A présent, ajoutez les fichiers de journalisation de secours à la base de données de secours.
    1. Entrez :
      select group#, type, member from v$logfile;
      Vous verrez une réponse similaire à celle-ci : 
      GROUP#      TYPE    MEMBER 
---------- ------- ------------------------------------------------------ 
3          ONLINE  +RECO/DBUKS_R2J_AMS/ONLINELOG/group_3.489.1141280529 
2          ONLINE  +RECO/DBUKS_R2J_AMS/ONLINELOG/group_2.488.1141280519 
1          ONLINE  +RECO/DBUKS_R2J_AMS/ONLINELOG/group_1.487.1141280511
    2. Entrez : 
      select bytes, group# from v$log;
      Vous verrez une réponse similaire à celle-ci :
      1073741824 1 
1073741824 3 
1073741824 2
    3. Entrez cette série de commandes :
      alter database add standby logfile thread 1 group 4 ('+RECO') size 1073741824;
      alter database add standby logfile thread 1 group 5 ('+RECO') size 1073741824; 
      alter database add standby logfile thread 1 group 6 ('+RECO') size 1073741824; 
      alter database add standby logfile thread 1 group 7 ('+RECO') size 1073741824;
      La réponse pour chaque commande doit être : 
      Database altered
    4. Entrez : 
      select group#, type, member from v$logfile;
      Vous verrez une réponse similaire à celle-ci : 
      GROUP#      TYPE      MEMBER 
---------- -------   ------------------------------------------------------ 
3          ONLINE    +RECO/DBUKS_898_LHR/ONLINELOG/group_3.489.1141280529 
2          ONLINE    +RECO/DBUKS_898_LHR/ONLINELOG/group_2.488.1141280519 
1          ONLINE    +RECO/DBUKS_898_LHR/ONLINELOG/group_1.487.1141280511 
4          STANDBY   +DATA/DBUKS_R2J_AMS/ONLINELOG/group_4.294.1141283919 
5          STANDBY   +DATA/DBUKS_R2J_AMS/ONLINELOG/group_5.295.1141283929 
6          STANDBY   +DATA/DBUKS_R2J_AMS/ONLINELOG/group_6.296.1141283937 
7          STANDBY   +DATA/DBUKS_R2J_AMS/ONLINELOG/group_7.296.1141283938
  3. Supprimez les fichiers journaux avec le nom unique de la base de données principale. Sur les trois fichiers journaux, l'un des fichiers sera le journal courant et, par conséquent, vous ne pourrez pas le supprimer pour le moment; ce fichier sera supprimé et recréé plus tard.
    1. Entrez : 
      alter database drop logfile group 1;
      Vous verrez une réponse similaire à celle-ci : 
      alter database drop logfile group 1 
* 
ERROR at line 1: 
ORA-01623: log 1 is current log for instance dbuks (thread 1) - cannot drop 
ORA-00312: online log 1 thread 1: '+RECO/DBUKS_898_LHR/ONLINELOG/group_1.257.1139942665'
    2. Entrez :
      alter database drop logfile group 2; 
      alter database drop logfile group 3;
      La réponse de chacun devrait être : 
      Database altered
  4. Recréez les fichiers journaux en entrant les commandes suivantes : 
    alter database add logfile thread 1 group 2 ('+RECO') size 1073741824;
    alter database add logfile thread 1 group 3 ('+RECO') size 1073741824;
    La réponse de chacun devrait être :
    Database altered.

Configurer Oracle Data Guard Broker

Maintenant, configurez Oracle Data Guard Broker, enregistrez la base de données de secours et synchronisez les bases de données principale et de secours. Configurez Oracle Data Guard Broker en activant le paramètre dg_broker_config_file sur les bases de données principale et de secours. Pour Oracle Automatic Storage Management (Oracle ASM), placez les fichiers de configuration du broker sur des groupes de disques distincts. Pour Oracle Real Application Clusters (Oracle RAC), les fichiers de configuration du broker doivent se trouver dans le stockage partagé.
  1. Vérifiez la valeur dg_broker_start pour la base de données principale et la base de secours. Assurez-vous qu'elle est réglée à Vrai; à la ligne de commande SQL, entrez :
    show parameter dg_broker_start;
    La sortie doit ressembler à ceci : 
    NAME                                  TYPE         VALUE 
------------------------------------ ----------- ------------------------------ 
dg_broker_start                       boolean      TRUE
    Si dg_broker_start est réglé à FALSE, réglez le paramètre à TRUE avant de passer aux étapes suivantes; entrez :
    alter system set dg_broker_start=true; 
    select pname from v$process where pname like 'DMON%';
    La sortie doit ressembler à ceci : 
    PNAME 
----- 
DMON
  2. Vérifiez les fichiers Oracle Data Guard pour la base principale :
    show parameter dg_broker_config_file1;
    show parameter dg_broker_config_file2;
    Si vous disposez d'Oracle RAC ou d'Oracle ASM, vous pouvez modifier l'emplacement du fichier de configuration, par exemple : 
    alter system set dg_broker_config_file1=broker_config_file_location; 
    alter system set dg_broker_config_file2=broker_config_file_location;
  3. Enregistrez les bases de données principale et de secours :
    Utilisez l'interface de ligne de commande d'Oracle Data Guard (DGMGRL) pour enregistrer la base principale et pour ajouter le profil de la base de secours à la configuration du broker :
    1. Connectez-vous à l'hôte principal en tant que sys.
      dgmgrl sys/password@net_service_name_for_primary
    2. Créez une configuration qui utilise le nom de la base de données principale. 
      CREATE CONFIGURATION configuration_name AS PRIMARY DATABASE IS primary_database_name CONNECT IDENTIFIER IS primary_database_name;
      La sortie doit ressembler à ceci : 
      CREATE CONFIGURATION dbuks_898_lhr_dbuks_r2j_ams AS PRIMARY DATABASE IS dbuks_898_lhr CONNECT IDENTIFIER IS dbuks_898_lhr;
    3. Ajoutez la base de données de secours. 
      ADD DATABASE standby unique database name AS CONNECT IDENTIFIER IS standby unique database name MAINTAINED AS PHYSICAL;
      Par exemple :
      ADD DATABASE dbuks_r2j_ams AS CONNECT IDENTIFIER IS dbuks_r2j_ams MAINTAINED AS PHYSICAL;
      La sortie doit ressembler à ceci : 
      Database "dbuks_r2j_ams" added
  4. Activez la configuration : 
    enable configuration;
  5. Affichez la configuration :
    1. Entrez :
      show configuration;

      Note :

      Si vous recevez un AVERTISSEMENT indiquant que le décalage d'application n'a pas pu être déterminé, connectez-vous à la base de données principale au moyen de sqlplus et effectuez quelques changements de journal.
      La sortie doit ressembler à ceci : 
      Configuration - dbuks_898_lhr_dbuks_r2j_ams 
Protection Mode: MaxPerformance 
Members: 
dbuks_898_lhr - Primary database 
dbuks_r2j_ams - Physical standby database 
Fast-Start Failover: Disabled 
Configuration Status: 
SUCCESS (status updated 36 seconds ago)
    2. Affichez la configuration de la base de données principale (dans cet exemple, dbuks_898_lhr) : 
      show database dbuks_898_lhr
      Une réponse semblable à la suivante s'affiche : 
      Database - dbuks_898_lhr 
Role: PRIMARY 
Intended State: TRANSPORT-ON 
Instance(s): 
dbuks 
Database Status: 
SUCCESS
    3. Affichez la configuration de la base de données de secours (dans cet exemple, dbuks_r2j_ams) :
      show database dbuks_r2j_ams
      Une réponse semblable à la suivante s'affiche : 
      Database - dbuks_r2j_ams 
Role: PHYSICAL STANDBY 
Intended State: APPLY-ON 
Transport Lag: 0 seconds (computed 1 second ago) 
Apply Lag: 0 seconds (computed 0 seconds ago) 
Average Apply Rate: 59.00 KByte/s 
Real Time Query: ON 
Instance(s): 
dbuks 
Database Status: 
SUCCESS

Confirmer la réplication

La base de secours doit maintenant commencer à appliquer les informations de journalisation reçues de la base principale.

Utilisez l'invite de commande SQL> pour les étapes suivantes.
  1. Vérifiez le traitement PBM :
    1. Entrez : 
      select sysdate, process, status, thread#, sequence#, block# 
from v$managed_standby 
where status!='IDLE';
      La sortie doit ressembler à ceci :
      SYSDATE    PROCESS     STATUS         THREAD#      SEQUENCE#    BLOCK# 
---------  ---------  ------------   ----------   ----------   ---------- 
10-JUL-23  DGRD       ALLOCATED          0            0            0 
10-JUL-23  ARCH       CONNECTED          0            0            0 
10-JUL-23  DGRD       ALLOCATED          0            0            0 
10-JUL-23  ARCH       CONNECTED          0            0            0 
10-JUL-23  ARCH       CONNECTED          0            0            0 
10-JUL-23  ARCH       CONNECTED          0            0            0 
10-JUL-23  RFS        RECEIVING          1           417          2413 
10-JUL-23  MRP0       APPLYING_LOG       1           417          2412
    2. Affichez les processus Data Guard. 
      select distinct process from gv$managed_standby;
      La sortie doit ressembler à ceci :
      PROCESS 
--------- 
DGRD 
RFS 
MRP0 
ARCH
    3. La base de données de secours a maintenant commencé à appliquer les fichiers de journalisation. Effectuez des changements de journal sur la base principale et confirmez à nouveau sur la base de secours :
      select sysdate, process, status, thread#, sequence#, block#from v$managed_standbywhere status!='IDLE';
      La sortie doit ressembler à ceci :
      SYSDATE      PROCESS    STATUS          THREAD#     SEQUENCE#     BLOCK#
---------   ---------   ------------   ----------   ----------   ----------
04-JUL-23   DGRD        ALLOCATED           0           0           0
04-JUL-23   ARCH        CONNECTED           0           0           0
04-JUL-23   DGRD        ALLOCATED           0           0           0
04-JUL-23   ARCH        CLOSING             1          253          1
04-JUL-23   ARCH        CONNECTED           0           0           0
04-JUL-23   ARCH        CLOSING             1          252          1
04-JUL-23   MRP0        APPLYING_LOG        1          254          17
04-JUL-23   RFS         RECEIVING           1          254          18
    4. Archiver la liste des journaux dans la base de données principale :
      archive log list
      La sortie doit ressembler à ceci :
      Database log mode Archive Mode 
Automatic archival Enabled 
Archive destination USE_DB_RECOVERY_FILE_DEST 
Oldest online log sequence 415 
Next log sequence to archive 417 
Current log sequence 417
      Ensuite, entrez :
      alter system switch logfile;
      Vous devriez recevoir cette réponse : 
      System altered.
      Entrez : 
       /
      Voici ce que vous devriez voir :
      System altered.
      Archivez maintenant la liste des journaux : 
      archive log list
      Vous devriez recevoir cette réponse : 
      Database log mode Archive Mode 
Automatic archival Enabled 
Archive destination USE_DB_RECOVERY_FILE_DEST 
Oldest online log sequence 417 
Next log sequence to archive 419 
Current log sequence 419
    5. Archivez la liste des journaux dans la base de données de secours; entrez :
      select sysdate, process, status, thread#, sequence#, block# 
from v$managed_standby 
where status!='IDLE';

      Vous devriez recevoir cette réponse : 

      SYSDATE      PROCESS     STATUS        THREAD#      SEQUENCE#      BLOCK#
---------    ---------  ------------ ----------    ----------     ----------
10-JUL-23    DGRD       ALLOCATED         0             0             0
10-JUL-23    ARCH      CONNECTED          0             0             0
10-JUL-23    DGRD      ALLOCATED          0             0             0
10-JUL-23    ARCH      CLOSING            1            418            1
10-JUL-23    ARCH      CONNECTED          0             0             0
10-JUL-23    ARCH      CLOSING            1            417          2048
10-JUL-23    RFS       RECEIVING          1            419           59
10-JUL-23    MRP0      APPLYING_LOG       1            419           58
  2. Activez Flashback sur la base de secours :
    1. Entrez : 
      ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel; 
SQL> alter database flashback on;
      Après chaque commande, vous devriez voir :
      Database altered
    2. Vérifiez que le flashback de la base de données est activé (on). 
      select flashback_on from v$database;
      La sortie doit ressembler à ceci : 
      FLASHBACK_ON 
------------------ 
YES
    3. Ensuite, entrez :
      recover managed standby database using current logfile disconnect from session;
      Voici ce que vous devriez voir : 
      Media recovery complete.
  3. Affichez les détails de la base de données :
    select FORCE_LOGGING, FLASHBACK_ON, OPEN_MODE, DATABASE_ROLE, DATAGUARD_BROKER, PROTECTION_MODE from v$database ;
    La sortie doit ressembler à ceci :
    FORCE_LOGGING   FLASHBACK_ON   OPEN_MODE   DATABASE_ROLE     DATAGUARD_BROKER   PROTECTION_MODE 
---------------------------------------------------------- --------------- ----- ----------------------- ----------------------------- 
YES             YES            MOUNTED     PHYSICAL STANDBY  ENABLED          MAXIMUM PERFORMANCE
  4. Utilisez l'utilitaire Server Control (srvctl) pour arrêter la base de données de secours : 
    srvctl stop database -d db_unique_name
    La sortie doit ressembler à ceci : 
    srvctl stop database -d dbuks_r2j_ams
  5. Utilisez l'utilitaire Server Control pour démarrer la base de secours : 
    srvctl start database -d db_unique_name
    La sortie doit ressembler à ceci : 
    srvctl start database -d dbuks_r2j_ams
  6. Affichez les détails de la base de données :
    select FORCE_LOGGING, FLASHBACK_ON, OPEN_MODE, DATABASE_ROLE, DATAGUARD_BROKER, PROTECTION_MODE from v$database ;
    La sortie doit ressembler à ceci :
     FORCE_LOGGING   FLASHBACK_ON   OPEN_MODE               DATABASE_ROLE      DATAGUARD_BROKER     PROTECTION_MODE 
-----------------------------------------------------------------------   -------------------- ----------------------- 
YES             YES             READ ONLY WITH APPLY   PHYSICAL STANDBY   ENABLED               MAXIMUM PERFORMANCE
  7. Vous pouvez maintenant ajouter d'autres commutateurs de fichier de journalisation à partir de la base principale et vous assurer que les informations de journalisation sont appliquées à la base de secours.
  8. Recréez le fichier journal en attente, qui existe avec le nom unique principal. Entrez les commandes suivantes :
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel; 
    alter database drop logfile group 1;
    alter database add standby logfile thread 1 group 1 ('+RECO') size 1073741824;
    Après chaque commande, vous devriez voir : 
    Database altered.
    Enfin, entrez :
    recover managed standby database using current logfile disconnect from session;
    Voici ce que vous devriez voir : 
    Media recovery complete.