Oracle Snapshot Standby, une fonctionnalité du logiciel Oracle Data Guard, permet la conversion temporaire d'une base de données secondaire physique en une base de données secondaire instantanée pour des opérations en lecture-écriture. Parfaite pour des tests sans risque, elle peut être rétablie en une base de données secondaire physique, en supprimant toutes les modifications et en reprenant l'application des données redo.
Updated by Eleonore on 2025/05/15
Le Data Guard d'Oracle 11g nous offre non seulement la fonction remarquable de requête en temps réel grâce à Active Data Guard, mais aussi une autre commodité appelée la fonctionnalité Snapshot Standby database. Cette fonctionnalité permet de placer la base de données secondaire en mode « lecture-écriture », servant d'environnement pour des tests qui peuvent être inconvenants à effectuer directement sur la base de données primaire de production, comme simuler des déploiements en ligne et d'autres tâches. Une fois les tâches terminées en mode lecture-écriture, il est aisé de ramener le rôle de la base de données snapshot standby à son rôle de base de données secondaire, reprenant ainsi la synchronisation avec la base de données principale. Lorsque celle-ci est en état de base de données snapshot standby, elle peut recevoir les journaux de la base de données primaire, mais les modifications ne peuvent pas être appliquées à la base de données secondaire.
Si la base de données secondaire est actuellement engagée dans la procédure Redo Apply, il est nécessaire de l'arrêter en premier lieu.
sys@ora11gdg> alter database recover managed standby database cancel; Database altered.
sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE PHYSICAL STANDBY MOUNTED
À ce stade, la base de données en veille assume le rôle de base de données physique en veille et fonctionne en mode MONTÉ.
Rappel amical : L'activation de la fonctionnalité de base de données d'attente instantanée (Snapshot Standby) ne nécessite pas l'activation de la fonctionnalité Flashback Database sur les bases de données principale et secondaire. Elle est indépendante de l'état d'activation de la fonctionnalité flashback database.
sys@ora11gdg> show parameter db_recovery_file_dest NAME TYPE VALUE db_recovery_file_dest string /u01/app/oracle/flash_recovery_area db_recovery_file_dest_size big integer 3852M
Confirmez que la fonction de flashback n'est pas activée sur la base de données principale.
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
Confirmez que la fonction de flashback n'est pas activée sur la base de données secondaire.
sys@ora11gdg> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
sys@ora11gdg> alter database convert to snapshot standby; Database altered. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE SNAPSHOT STANDBY MOUNTED
sys@ora11gdg> alter database open; Database altered. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE SNAPSHOT STANDBY READ WRITE
Une toute nouvelle base de données en mode lecture-écriture s'ouvre devant nous.
Journal d'alerte de la base de données principale pour Oracle 11g :
Mon Mar 19 18:46:28 2012 LNS: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135) LNS: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact Error 3135 for archive log file 2 to 'ora11gdg' Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact LNS: Failed to archive log 2 thread 1 sequence 50 (3135) Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact
Journal d'alerte de la base de données en veille pour Oracle 11g :
Mon Mar 19 18:46:26 2012 alter database convert to snapshot standby Starting background process RVWR Mon Mar 19 18:46:26 2012 RVWR started with pid=26, OS id=8824 Allocated 3981204 bytes in shared pool for flashback generation buffer Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26 krsv_proc_kill: Killing 3 processes (all RFS) Begin: Standby Redo Logfile archival End: Standby Redo Logfile archival RESETLOGS after complete recovery through change 1472476 Resetting resetlogs activation ID 4174194338 (0xf8cd26a2) Online log /u01/app/oracle/oradata/ora11gdg/redo01.log: Thread 1 Group 1 was previously cleared Online log /u01/app/oracle/oradata/ora11gdg/redo02.log: Thread 1 Group 2 was previously cleared Online log /u01/app/oracle/oradata/ora11gdg/redo03.log: Thread 1 Group 3 was previously cleared Standby became primary SCN: 1472474 Mon Mar 19 18:46:29 2012 Setting recovery target incarnation to 5 CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby Completed: alter database convert to snapshot standby
La ligne d'information cruciale indique : « Point de restauration garanti créé SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26. » Cela marque le moment où nous sommes passés en mode instantané, facilitant ainsi la réversion ultérieure.
Même lorsque la base de données principale commute les journaux, la base de données secondaire continue de recevoir les journaux, bien qu'elle ne les applique pas.
1) Commutateur de journal sur la base de données principale.
sys@ora11g> alter system switch logfile; System altered.
2) Le contenu du journal d'alerte enregistré par la base de données principale
Journal d'alerte de la base de données principale pour Oracle 11g :
Mon Mar 19 18:52:00 2012 Thread 1 cannot allocate new log, sequence 52 Private strand flush not complete Current log# 3 seq# 51 mem# 0: /u01/app/oracle/oradata/ora11g/redo03.log Mon Mar 19 18:52:00 2012 ARC3: Standby redo logfile selected for thread 1 sequence 50 for destination LOG_ARCHIVE_DEST_2 Thread 1 advanced to log sequence 52 (LGWR switch) Current log# 1 seq# 52 mem# 0: /u01/app/oracle/oradata/ora11g/redo01.log Mon Mar 19 18:52:03 2012 Archived Log entry 91 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1: Mon Mar 19 18:52:03 2012 LNS: Standby redo logfile selected for thread 1 sequence 51 for destination LOG_ARCHIVE_DEST_2 LNS: Standby redo logfile selected for thread 1 sequence 52 for destination LOG_ARCHIVE_DEST_2
Journal d'alerte de la base de données en attente pour Oracle 11g :
Mon Mar 19 18:52:00 2012 RFS[5]: Assigned to RFS process 9174 RFS[5]: Identified database type as 'snapshot standby': Client is ARCH pid 27296 Mon Mar 19 18:52:00 2012 RFS[6]: Assigned to RFS process 9176 RFS[6]: Identified database type as 'snapshot standby': Client is ARCH pid 27300 RFS[6]: Selected log 4 for thread 1 sequence 50 dbid -120744030 branch 778023141 Mon Mar 19 18:52:00 2012 Archived Log entry 47 added for thread 1 sequence 50 ID 0xf8cd26a2 dest 1: Mon Mar 19 18:52:03 2012 RFS[7]: Assigned to RFS process 9180 RFS[7]: Identified database type as 'snapshot standby': Client is LGWR ASYNC pid 27302 RFS[7]: Selected log 4 for thread 1 sequence 51 dbid -120744030 branch 778023141 Mon Mar 19 18:52:04 2012 Archived Log entry 48 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1: RFS[7]: Selected log 4 for thread 1 sequence 52 dbid -120744030 branch 778023141
3) Examiner le contenu des fichiers journaux dans les répertoires d'archive des bases de données principale et secondaire
(1) Fichiers journaux d'archivage de la base de données principale :
ora11g@secdb /home/oracle/arch/ora11g$ ls -ltr total 879M ...omitted... -rw-r----- 1 oracle oinstall 1.1M Mar 19 18:51 1_50_778023141.arc -rw-r----- 1 oracle oinstall 363K Mar 19 18:52 1_51_778023141.arc
(2) Fichiers journaux d'archivage de la base de données en attente :
ora11g@secdb /home/oracle/arch/ora11gdg$ ls -ltr total 847M ...omitted... -rw-r----- 1 oracle oinstall 1.1M Mar 19 18:52 1_50_778023141.arc -rw-r----- 1 oracle oinstall 363K Mar 19 18:52 1_51_778023141.arc
Comme observé, la base de données en attente a réussi à recevoir les fichiers journaux envoyés par la base de données principale.
sys@ora11gdg> create user ocmu identified by ocmu;
User created.
secooler@ora11gdg> grant dba to ocmu;
Grant succeeded.
secooler@ora11gdg> conn ocmu/ocmu
Connected.
ocmu@ora11gdg> create table t (x varchar2(8));
Table created.
ocmu@ora11gdg> insert into t values ('Secooler');
1 row created.
ocmu@ora11gdg> commit;
Commit complete.
ocmu@ora11gdg> select * from t;
X
SecoolerÀ cet instant, la base de données secondaire est dans un état modifiable et ajustable, ce qui correspond au mode « READ WRITE » souhaité.
Il est crucial de noter que la mise en œuvre de la fonctionnalité de base de données Snapshot Standby repose fondamentalement sur le principe des données flashback. Par conséquent, toute action susceptible de nuire à la capacité de retourner la base de données en arrière doit être évitée ici. Sinon, la base de données Snapshot Standby ne pourra pas revenir à son état précédent de récupération en attente.
1) Redémarrer la base de données secondaire dans l'état MOUNTED.
ocmu@ora11gdg> conn / as sysdba Connected. sys@ora11gdg> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. sys@ora11gdg> startup mount ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1336232 bytes Variable Size 268438616 bytes Database Buffers 37748736 bytes Redo Buffers 6336512 bytes Database mounted. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE SNAPSHOT STANDBY MOUNTED
2) Exécutez une commande pour restaurer l'identité d'origine de la base de données de standby physique.
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) Le journal d'alerte de la base de données secondaire documente soigneusement ce processus de transition.
Mon Mar 19 19:30:24 2012 alter database convert to physical standby ALTER DATABASE CONVERT TO PHYSICAL STANDBY (ora11gdg) Flashback Restore Start Flashback Restore Complete Stopping background process RVWR Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg3n2jc_.flb Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg52yst_.flb Guaranteed restore point dropped Clearing standby activation ID 4174523254 (0xf8d22b76) The primary database controlfile was created using the 'MAXLOGFILES 30' clause. There is space for up to 27 standby redo logfiles Use the following SQL commands on the standby database to create standby redo logfiles that match the primary database: ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800; Completed: alter database convert to physical standby
À partir du journal d'alerte, il peut être déduit que la méthode de récupération a utilisé la fonctionnalité Flashback Database. Cela signifie que même si la base de données secondaire n'était pas en mode flashback, la transition de rôle de la base de données secondaire peut tout de même être réalisée en utilisant la fonctionnalité Flashback Database.
4) Redémarrez la base de données de secours en mode de journal de récupération automatique.
(1) À ce stade, la base de données est dans un état NON MONTÉE et doit être redémarrée.
Veuillez noter qu'il nécessite un redémarrage de la base de données au lieu d'utiliser la commande ALTER, sinon le message d'erreur suivant sera rencontré :
sys@ora11gdg> alter database mount; alter database mount l ERROR at line 1: ORA-00750: database has been previously mounted and dismounted sys@ora11gdg> shutdown immediate; ORA-01507: database not mounted ORACLE instance shut down. sys@ora11gdg> startup mount; ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1336232 bytes Variable Size 268438616 bytes Database Buffers 37748736 bytes Redo Buffers 6336512 bytes Database mounted. sys@ora11gdg> alter database recover managed standby database disconnect; Database altered.
(2) En examinant le journal d'alerte de la base de données secondaire, le processus de récupération peut être observé de manière claire.
Mon Mar 19 19:43:48 2012 Managed Standby Recovery not using Real Time Apply Parallel Media Recovery started with 4 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Clearing online redo logfile 1 /u01/app/oracle/oradata/ora11gdg/redo01.log Clearing online log 1 of thread 1 sequence number 1 Completed: alter database recover managed standby database disconnect Clearing online redo logfile 1 complete Clearing online redo logfile 2 /u01/app/oracle/oradata/ora11gdg/redo02.log Clearing online log 2 of thread 1 sequence number 2 Clearing online redo logfile 2 complete Media Recovery Log /home/oracle/arch/ora11gdg/1_49_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_50_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_51_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_52_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_53_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_54_778023141.arc Media Recovery Waiting for thread 1 sequence 55
(3) Surveillez l'état de l'application de journal en inspectant la vue de performances dynamique V$ARCHIVED_LOG.
sys@ora11gdg> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#; SEQUENCE# FIRST_TIME NEXT_TIME APPLIED ...omitted... 49 20120319 18:32:32 20120319 18:38:03 YES 50 20120319 18:38:03 20120319 18:51:00 YES 51 20120319 18:51:00 20120319 18:52:03 YES 52 20120319 18:52:03 20120319 19:09:57 YES 53 20120319 19:09:57 20120319 19:10:15 YES 54 20120319 19:10:15 20120319 19:10:25 YES 52 rows selected.
sys@ora11gdg> alter database recover managed standby database cancel; Database altered. sys@ora11gdg> alter database open read only; Database altered. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE PHYSICAL STANDBY READ ONLY sys@ora11gdg> select username from dba_users where username = 'OCMU'; no rows selected
La conclusion a été confirmée car l'utilisateur de test « OCMU » créé précédemment n'existe pas.
Oracle Snapshot Standby est très utile à des fins de test. Cependant, pour protéger encore davantage votre environnement de base de données, il est recommandé de sauvegarder votre base de données Oracle avec une solution de sauvegarde et de reprise après sinistre professionnelle.
Vinchin Backup & Recovery offre des fonctionnalités puissantes pour protéger vos bases de données dans les machines virtuelles et les serveurs physiques, de manière très automatique, flexible et efficace. Il fournit une protection multi-type des bases de données de Oracle DB, MySQL, SQL Server, Postgres Pro et MariaDB, avec prise en charge de la compression des bases de données, gestion centralisée des tâches, stratégies de sauvegarde intelligentes, sauvegarde de base de données en ligne et support avancé pour SQL Server/Oracle. De plus, il prend également en charge le puissant fonction de protection contre le ransomware et la migration V2V entre plus de 10 plates-formes virtuelles.
Vinchin Backup & Recovery a été sélectionné par des milliers d'entreprises et vous aussi pouvez commencer à utiliser ce puissant système avec un essai de 60 jours avec toutes les fonctionnalités ! De plus, contactez-nous et faites-nous part de vos besoins, et vous recevrez une solution adaptée à votre environnement informatique.
Le trait remarquable de la “base de données en mode instantané d'attente” permet à la base de données d'attente de devenir temporairement une base de données indépendante en lecture-écriture. Cela élargit considérablement les possibilités d'utilisation de la base de données d'attente. En exploitant cette fonctionnalité spéciale de la base de données d'attente, vous pouvez tester et reproduire en toute sécurité des problèmes qui pourraient être « risqués » à simuler et reproduire dans l'environnement de production. Une fois les tests terminés, vous pouvez restaurer son identité en tant que base de données physique d'attente et continuer avec la récupération des journaux.
Partager sur:
