Oracle Snapshot Standby, una funzione del software Oracle Data Guard, consente la conversione temporanea di un database standby fisico in un snapshot standby per operazioni di lettura/scrittura. Ideale per il testing senza rischi, può essere riportato allo stato di standby fisico, eliminando tutte le modifiche e riprendendo l'applicazione dei dati redo.
Updated by Sofia on 2025/05/15
La funzionalità Data Guard di Oracle 11g ci offre non solo la straordinaria possibilità di eseguire query in tempo reale grazie ad Active Data Guard, ma anche un'altra caratteristica piacevole nota come funzionalità Snapshot Standby database. Questa funzionalità consente di impostare il database di standby in modalità "read-write", fornendo un ambiente per test utili che potrebbero essere scomodi da effettuare direttamente sul database primario di produzione, come simulare distribuzioni online ed altre attività. Una volta completate le attività in modalità read-write, è semplice ripristinare il ruolo del database snapshot standby al suo ruolo di standby, riavviando la sincronizzazione con il database primario. Durante lo stato di database snapshot standby, esso può ricevere i log dal database primario, ma le modifiche non possono essere applicate al database standby.
Se il database di standby è attualmente coinvolto nel procedimento Redo Apply, è necessario interromperlo prima.
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
In questo momento, il database di standby assume il ruolo di standby fisico e opera in modalità MOUNTED.
Promemoria: L'attivazione della funzionalità del database Snapshot Standby non richiede l'attivazione della funzionalità Flashback Database sui database primario e di standby. È indipendente dal fatto che la funzionalità del database flashback sia attivata o no.
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
Conferma che la funzione di flashback non sia abilitata sul database principale.
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
Conferma che la funzione di flashback non sia abilitata nel database di standby.
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
Un nuovo database in modalità lettura/scrittura si presenta davanti a noi.
Log degli avvisi del database primario per 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
Log degli avvisi del database di standby per 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 riga di informazione cruciale afferma: "Punto di ripristino garantito creato SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26." Ciò indica il momento in cui siamo stati trasformati in uno snapshot, facilitando la successiva reversibilità.
Anche quando il database primario cambia i log, il database di standby continua a ricevere i log, sebbene senza applicarli.
1) Switch del log sul database primario.
sys@ora11g> alter system switch logfile; System altered.
2）Il contenuto del registro di avviso registrato dal database principale
Log degli avvisi del database primario per 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
File di log di avviso della database di standby per 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) Esaminare il contenuto dei file di registro nelle directory di archivio dei database principale e di standby
(1) File di registro di archivio del database 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) File di registro di archiviazione del database di backup:
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
Come osservato, il database di standby ha ricevuto con successo i file di log inviati dal database 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
SecoolerIn questo momento, il database di standby si trova in uno stato modificabile e regolabile, che corrisponde alla modalità desiderata “READ WRITE”.
È fondamentale notare che l'implementazione della funzionalità del database Snapshot Standby è basata in modo essenziale sul principio dei dati di flashback. Pertanto, qualsiasi azione che potrebbe ostacolare la capacità di effettuare il flashback del database dovrebbe essere evitata. Altrimenti, il database Snapshot Standby non sarà in grado di tornare allo stato precedente di recupero in standby.
1) Riavviare il database di standby nello stato 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) Esegui un comando per ripristinare l'identità originale del database di standby fisico.
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) Il registro di avviso del database di standby documenta con precisione questo processo di transizione.
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
Dal registro delle notifiche si può dedurre che il metodo di ripristino abbia utilizzato la funzionalità Flashback Database. Ciò significa che anche se il database di standby non era in modalità flashback, la transizione del ruolo del database di standby può comunque essere eseguita utilizzando la funzionalità Flashback Database.
4) Riavviare il database di standby in modalità di registrazione di recupero automatico.
(1) A questo punto, il database si trova nello stato NOMOUNTED e deve essere riavviato.
Si prega di notare che richiede il riavvio del database invece di utilizzare il comando ALTER, altrimenti verrà visualizzato il seguente messaggio di errore:
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) Esaminando il registro di avviso del database di standby, è possibile osservare il processo di ripristino in maniera chiara.
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) Monitora lo stato dell'applicazione di registrazione ispezionando la vista delle prestazioni dinamiche 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 conclusione è stata confermata in quanto l'utente di test "OCMU" precedentemente creato non esiste.
Oracle Snapshot Standby è molto utile a scopo di testing. Tuttavia, per proteggere ulteriormente il tuo ambiente database, si consiglia di eseguire il backup del tuo database Oracle con una soluzione di backup e ripristino d'emergenza professionale.
Vinchin Backup & Recovery fornisce funzionalità potenti per proteggere i tuoi database sia nelle macchine virtuali che nei server fisici, è abbastanza automatico, flessibile ed efficiente. Offre la protezione multi-tipo di database di Oracle DB, MySQL, SQL Server, Postgres Pro e MariaDB, supportando la compressione del database, la gestione centralizzata dei processi, strategie di backup intelligenti, backup di database in esecuzione e un avanzato supporto per SQL Server/Oracle. Inoltre, fornisce anche una funzionalità potente di protezione contro il ransomware e migrazione V2V tra più di 10 piattaforme virtuali.
Vinchin Backup & Recovery è stato selezionato da migliaia di aziende e anche tu puoi iniziare ad utilizzare questo potente sistema con un trial pienamente funzionale di 60 giorni! Inoltre, contattaci e comunicaci le tue esigenze, e riceverai una soluzione adatta al tuo ambiente IT.
Il notevole vantaggio del “Database in Modalità Snapshot Standby” permette al database standby di diventare temporaneamente un database indipendente in modalità lettura/scrittura. Ciò amplia enormemente le possibilità di utilizzo del database standby. Sfruttando questa funzionalità speciale del database standby, è possibile testare e riprodurre in sicurezza problemi che potrebbero essere "rischiosi" da simulare e riprodurre nell'ambiente di produzione. Una volta completati i test, è possibile ripristinare il ruolo di database fisico standby e procedere con il recupero dei log.
Condividi su:
