Oracle Snapshot Standby, ein Feature der Data Guard-Software von Oracle, ermöglicht die temporäre Umwandlung einer physischen Standby-Datenbank in eine Snapshot-Standby-Datenbank für Lese- und Schreibvorgänge. Ideals für risikofreies Testen kann sie zurück in eine physische Standby-Datenbank umgewandelt werden, wobei alle Änderungen verworfen werden und die Anwendung von Redo-Daten wieder aufgenommen wird.
Updated by Emma on 2025/05/15
Die Data Guard-Funktion von Oracle 11g bringt uns nicht nur das bemerkenswerte Feature der Echtzeitabfrage durch Active Data Guard, sondern auch eine zusätzliche Freude namens Snapshot Standby-Datenbank-Funktionalität. Diese Funktionalität ermöglicht es, die Standby-Datenbank in einen „Read-Write“-Modus zu versetzen, um als Testumgebung zu dienen, wie zum Beispiel zur Simulation von Online-Bereitstellungen und anderen Aufgaben, die unpraktisch sein könnten, direkt auf der Produktions-Hauptdatenbank durchzuführen. Sobald die Aufgaben im Read-Write-Zustand abgeschlossen sind, ist es einfach, die Rolle der Snapshot-Standby-Datenbank wieder in ihre Standby-Datenbank-Rolle zurückzuwechseln und die Synchronisierung mit der Hauptdatenbank fortzusetzen. Während sich die Datenbank im Snapshot-Standby-Zustand befindet, kann sie die Logs der Hauptdatenbank empfangen, aber die Änderungen können nicht auf die Standby-Datenbank angewendet werden.
Wenn die Standby-Datenbank derzeit im Redo-Anwenden-Prozess beteiligt ist, muss dieser zunächst beendet werden.
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
Im Moment übernimmt die Standby-Datenbank die Rolle einer physischen Standby und funktioniert im MOUNTED-Modus.
Freundlicher Hinweis: Die Aktivierung der Snapshot-Standby-Datenbankfunktion erfordert nicht die Aktivierung der Flashback-Datenbankfunktion sowohl in der Primär- als auch in der Standby-Datenbank. Sie ist unabhängig davon, ob die Flashback-Datenbankfunktion aktiviert ist.
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
Stelle sicher, dass das Flashback-Feature in der primären Datenbank nicht aktiviert ist.
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
Stelle sicher, dass das Flashback-Feature auf der Standby-Datenbank nicht aktiviert ist.
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
Vor uns erstreckt sich eine völlig neue schreib-/lesefähige Datenbank.
Hauptdatenbank-Alertlog für 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
Warteschlange-Datenbank-Alert-Log für 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
Die entscheidende Zeile der Information lautet: „Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26.“ Dies zeigt den Zeitpunkt an, zu dem wir in einen Snapshot übergingen, was die nachfolgende Rückführung erleichtert.
Auch wenn die Hauptdatenbank die Protokolle wechselt, empfängt die Standby-Datenbank weiterhin die Protokolle, wenngleich ohne sie anzuwenden.
1) Log-Switch auf der primären Datenbank durchführen.
sys@ora11g> alter system switch logfile; System altered.
2) Der vom Hauptdatenbank aufgezeichnete Warnungsprotokollinhalt
Hauptdatenbank-Alertlog für 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
Warteschlangendatenbank-Alertlog für 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) Prüfen des Inhalts der Logdateien in den Archivverzeichnissen der primären und Standby-Datenbanken
(1) Archivierungsprotokolldateien der primären Datenbank:
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) Archiv-Logdateien der Standby-Datenbank:
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
Wie beobachtet, hat die Standby-Datenbank die Protokolldateien erfolgreich von der Hauptdatenbank empfangen.
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
SecoolerIn diesem Moment befindet sich die Standby-Datenbank in einem änderbaren und anpassbaren Zustand, was dem gewünschten „READ WRITE“-Modus entspricht.
Es ist entscheidend zu beachten, dass die Implementierung der Snapshot-Standby-Datenbank-Funktionalität grundsätzlich auf dem Prinzip der Flashback-Daten basiert. Daher sollte jede Aktion, die die Fähigkeit beeinträchtigen könnte, die Datenbank zurückzuführen, hier vermieden werden. Andernfalls wird die Snapshot-Standby-Datenbank nicht in ihren vorherigen Standby-Wiederherstellungsstatus zurückkehren können.
1) Starten Sie die Standby-Datenbank in den MOUNTED-Zustand neu.
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) Führen Sie einen Befehl aus, um die ursprüngliche Identität der physischen Standby-Datenbank wiederherzustellen.
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) Das Alarmprotokoll der Standby-Datenbank dokumentiert diesen Übergangsprozess detailliert.
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
Aus dem Alert-Log kann geschlossen werden, dass die verwendete Wiederherstellungsmethode die Flashback Database-Funktion nutzte. Dies bedeutet, dass selbst wenn die Standby-Datenbank nicht im Flashback-Datenbankmodus betrieben wurde, der Rollenwechsel der Standby-Datenbank immer noch mit der Flashback Database-Funktionalität durchgeführt werden kann.
4) Starten Sie die Sicherungsdatenbank im automatischen Wiederherstellungsprotokollmodus neu.
(1) An diesem Punkt befindet sich die Datenbank im NOMOUNTED-Zustand und muss neu gestartet werden.
Bitte beachten Sie, dass eine Neustart der Datenbank erforderlich ist, anstatt den ALTER-Befehl zu verwenden, andernfalls tritt folgende Fehlermeldung auf:
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) Indem man das Alarmprotokoll der Standby-Datenbank untersucht, kann der Wiederherstellungsprozess auf klare Weise beobachtet werden.
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) Überwachen Sie den Status der Protokollanwendung, indem Sie die dynamische Leistungsansicht V$ARCHIVED_LOG untersuchen.
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
Die Schlussfolgerung wurde bestätigt, da der Testbenutzer „OCMU“, der zuvor erstellt wurde, nicht existiert.
Oracle Snapshot Standby ist sehr nützlich für Testzwecke. Um Ihre Datenbankumgebung jedoch besser zu schützen, wird empfohlen, Ihre Oracle-Datenbank mit einer professionellen Backup- und Notfallwiederherstellungslösung zu sichern.
Vinchin Backup & Recovery bietet leistungsstarke Funktionen zum Schutz Ihrer Datenbanken in virtuellen Maschinen und physischen Servern, wobei der Vorgang sehr automatisch, flexibel und effizient ist. Es bietet den Schutz von mehreren Datenbanktypen wie Oracle DB, MySQL, SQL Server, Postgres Pro und MariaDB, unterstützt Datenbankkompression, zentrales Aufgabenmanagement, intelligente Sicherungsstrategien, Heißsicherung von Datenbanken sowie erweiterte Unterstützung für SQL Server/Oracle. Darüber hinaus bietet es auch eine leistungsstarke Schutzfunktion gegen Erpressersoftware (Ransomware)-Funktion und V2V-Migration über 10+ virtuelle Plattformen hinweg.
Vinchin Backup & Recovery wurde von Tausenden von Unternehmen ausgewählt, und Sie können dieses leistungsstarke System ebenfalls mit einem 60-tägigen Test mit voller Funktionsumfang beginnen! Außerdem kontaktieren Sie uns und teilen Sie uns Ihre Anforderungen mit, dann erhalten Sie eine Lösung, die auf Ihre IT-Umgebung zugeschnitten ist.
Die bemerkenswerte Funktion der „Snapshot-Standby-Datenbank“ ermöglicht es der Standby-Datenbank, temporär zu einer lese-schreibanwendbaren unabhängigen Datenbank zu werden. Dies erweitert die Einsatzmöglichkeiten der Standby-Datenbank erheblich. Durch die Nutzung dieser speziellen Funktionalität der Standby-Datenbank können Sie Probleme sicher testen und reproduzieren, die es in der Produktionsumgebung als „risikoreich“ anzusehen wäre, sie dort nachzubilden und zu reproduzieren. Sobald die Tests abgeschlossen sind, können Sie die Identität als physische Standby-Datenbank wiederherstellen und mit dem Log-Wiederherstellungsvorgang fortfahren.
Teilen auf:
