Oracle Snapshot Standby, funkcja oprogramowania Oracle Data Guard, pozwala tymczasowo przekształcić fizyczną bazę danych w trybie standby na bazę Snapshot Standby, umożliwiając operacje odczytu i zapisu. Idealne do bezpiecznego testowania, może zostać przywrócone do pierwotnego stanu fizycznej bazy standby, odrzucając wszystkie zmiany i wznawiając stosowanie danych redo.
Updated by Maciej Kowalczyk on 2026/02/26
Funkcja Data Guard w Oracle 11g oferuje nam nie tylko wyjątkową możliwość wykonywania zapytań w czasie rzeczywistym dzięki Active Data Guard, ale także dodatkową przyjemność znaną jako funkcja bazy danych Snapshot Standby. Funkcja ta umożliwia przejście bazy danych w tryb „read-write” (czyli odczyt i zapis), służąc jako środowisko testowe do zadań, które trudno byłoby wykonać bezpośrednio na produkcyjnej bazie danych, jak np. symulacja wdrożeń online i inne operacje. Po wykonaniu zadań w trybie read-write, można łatwo przywrócić rolę bazy danych Snapshot Standby do trybu bazy danych standby, kontynuując synchronizację z główną bazą danych. W stanie Snapshot Standby baza danych może odbierać dzienniki z głównej bazy danych, jednak zmiany te nie mogą zostać zastosowane w bazie danych standby.
Jeśli baza danych w trybie standby aktualnie wykonuje procedurę Redo Apply, konieczne jest jej najpierw zakończenie.
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
W tej chwili baza danych rezerwowa pełni rolę fizycznej bazy rezerwowej i działa w trybie MOUNTED.
Przypomnienie: Włączenie funkcji bazy danych Snapshot Standby nie wymaga aktywowania funkcji Flashback Database w głównej bazie danych i bazie standby. Jest niezależne od tego, czy funkcja Flashback Database jest włączona.
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
Potwierdź, że funkcja „flashback” jest wyłączona w głównej bazie danych.
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
Potwierdź, że funkcja flashback nie jest włączona w bazie danych w trybie oczekiwania.
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
Nowa baza danych z możliwością odczytu i zapisu pojawia się przed nami.
Dziennik alertów bazy danych głównej dla 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
Dziennik alertów bazy danych standby dla 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
Kluczowa linia informacji brzmi: "Utworzono gwarantowany punkt przywracania SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26." Oznacza to moment, w którym przekształciliśmy się w migawkę, ułatwiając późniejsze przywrócenie.
Nawet wtedy, gdy baza danych podstawowa zmienia dzienniki, baza danych w trybie oczekiwania nadal odbiera dzienniki, choć nie stosuje ich.
1) Włącz dziennik na bazie danych podstawowej.
sys@ora11g> alter system switch logfile; System altered.
2) Zawartość dziennika alertów zarejestrowana przez bazę danych podstawową
Dziennik alertów podstawowej bazy danych dla 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
Dziennik alertów bazy danych w trybie standby dla 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) Sprawdzanie zawartości plików dziennika w katalogach archiwum baz danych głównych i zapasowych
(1) Pliki dziennika archiwum bazy danych podstawowej:
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) Pliki dziennika archiwum bazy danych w trybie czuwania:
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
Zgodnie z obserwacjami, baza danych w trybie oczekiwania pomyślnie odebrała pliki dziennika wysłane z głównej bazy danych.
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
SecoolerW tej chwili baza danych standby znajduje się w stanie, w którym można ją modyfikować i dostosowywać, co odpowiada pożądanemu trybowi „READ WRITE” .
Ważne jest, aby zauważyć, że implementacja funkcji bazy danych Snapshot Standby opiera się w dużej mierze na zasadzie przywracania danych (flashback). Dlatego należy unikać wszelkich działań, które mogłyby utrudnić przywracanie bazy danych. W przeciwnym wypadku baza danych Snapshot Standby nie będzie mogła powrócić do swojego poprzedniego stanu odzyskiwania rezerwowego.
1) Uruchom ponownie bazę danych w stanie 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) Uruchom polecenie przywracające oryginalną tożsamość bazy danych w trybie fizycznego standby.
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) Dziennik alertów bazy danych w trybie gotowości dokładnie odnotowuje ten proces przejścia.
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
Z dziennika alertów można wywnioskować, że użyto mechanizmu Flashback Database. Oznacza to, że nawet jeśli baza danych w trybie odtwarzania nie była uruchomiona z opcją Flashback Database, to przechodzenie na rolę bazy danych w trybie odtwarzania można mimo to zrealizować przy użyciu funkcji Flashback Database.
4) Uruchom ponownie bazę danych w trybie automatycznego odzyskiwania dziennika.
(1) W tym momencie baza danych jest w stanie NOMOUNTED i musi zostać ponownie uruchomiona.
Proszę zauważyć, że wymaga to ponownego uruchomienia bazy danych zamiast używania polecenia ALTER, w przeciwnym razie pojawi się następujący komunikat błędu:
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) Poprzez analizę dziennika alertów bazy danych w trybie standby, proces odzyskiwania może być obserwowany w przejrzysty sposób.
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) Monitoruj stan aplikacji dziennika, sprawdzając dynamiczną widok wydajności 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
Podsumowanie zostało potwierdzone – użytkownik testowy „OCMU” utworzony wcześniej nie istnieje.
Oracle Snapshot Standby jest bardzo przydatny do celów testowych. Jednak aby dodatkowo zabezpieczyć swoje środowisko bazodanowe, zaleca się tworzenie kopii zapasowych bazy danych Oracle za pomocą profesjonalnego rozwiązania do tworzenia kopii zapasowych i odzyskiwania po awarii.
Vinchin Backup & Recovery oferta potężne funkcje umożliwiające ochronę baz danych zarówno w maszynach wirtualnych, jak i na serwerach fizycznych, działając w sposób automatyczny, elastyczny i wydajny. Zapewnia ochronę wielu typów baz danych, w tym Oracle DB, MySQL, SQL Server, Postgres Pro i MariaDB, wspiera kompresję baz danych, centralne zarządzanie zadaniami, inteligentne strategie tworzenia kopii zapasowych, tworzenie kopii zapasowych gorących baz danych oraz zaawansowane wsparcie dla SQL Server/Oracle. Ponadto oferuje również zaawansowaną funkcję ochrony przed ransomware oraz migracji V2V między ponad 10 platformami wirtualnymi.
Vinchin Backup & Recovery został wybrany przez tysiące firm, a Ty również możesz zacząć korzystać z tego potężnego systemu w ramach 60-dniowej wersji próbnej z pełnymi funkcjami! Skontaktuj się z nami kontaktuj się z nami i zostaw swoje wymagania, otrzymasz wtedy rozwiązanie dostosowane do Twojego środowiska IT.
Niezwykła funkcja „Bazy danych w trybie Snapshot Standby” umożliwia tymczasowe przekształcenie bazy danych w trybie standby w niezależną bazę danych z dostępem do odczytu i zapisu. To znacznie rozszerza możliwości wykorzystania bazy danych w trybie standby. Korzystając z tej szczególnej funkcji, można bezpiecznie testować oraz odtwarzać problemy, które mogłyby być „ryzykowne” do symulacji i odtworzenia w środowisku produkcyjnym. Po zakoczeniu testów można przywrócić bazie danych status fizycznej bazy danych standby i kontynuować odzyskiwanie dziennika transakcji.
Udostępnij na:
