O recurso Oracle Snapshot Standby, do software Data Guard da Oracle, permite a conversão temporária de um banco de dados standby físico em um snapshot standby para operações de leitura e gravação. Ideal para testes sem riscos, ele pode ser revertido para um standby físico, descartando todas as alterações e retomando a aplicação dos dados redo.
Updated by Ana on 2025/05/15
A Data Guard do Oracle 11g não só nos traz o notável recurso de consulta em tempo real por meio do Active Data Guard, mas também uma funcionalidade adicional chamada Snapshot Standby database. Essa funcionalidade permite que o banco de dados standby seja colocado em modo “leitura-escrita”, servindo como um ambiente para fins de teste que podem ser inconvenientes de realizar diretamente no banco de dados principal de produção, como simular implantações online e outras tarefas. Uma vez concluídas as tarefas no estado de leitura-escrita, é fácil reverter o papel do banco de dados Snapshot Standby para seu papel original de banco de dados standby, retomando a sincronização com o banco de dados principal. Enquanto estiver no estado de banco de dados Snapshot Standby, ele pode receber os logs do banco de dados principal, mas as alterações não podem ser aplicadas ao banco de dados standby.
Se o banco de dados standby estiver atualmente envolvido no procedimento de Aplicação de Redo, é necessário encerrá-lo primeiro.
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
Neste momento, o banco de dados em standby assume o papel de um standby físico e opera no modo MOUNTED.
Lembrete amigável: Habilitar a funcionalidade do banco de dados Snapshot Standby não requer habilitar o recurso Flashback Database tanto no banco de dados principal quanto no banco de dados de standby. Ele é independente de whether o recurso de banco de dados flashback está habilitado.
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
Confirme que o recurso de flashbak não está habilitado no banco de dados principal.
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
Confirme que o recurso de flashback não está habilitado no banco de dados de 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
Uma nova base de dados de leitura e gravação se abre diante de nós.
Log de alerta do banco de dados principal para 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 de alerta do banco de dados em modo standby para 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
A linha crucial de informações afirma: "Ponto de restauração garantido criado SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26." Isso indica o momento em que nos transformamos em um instantâneo, facilitando a subsequente reversão.
Mesmo quando o banco de dados principal alterna os logs, o banco de dados standby continua a receber os logs, embora sem aplicá-los.
1) Troca de log no banco de dados principal.
sys@ora11g> alter system switch logfile; System altered.
2）O conteúdo do registro de alerta gravado pelo banco de dados principal
Log de alerta do banco de dados principal para 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
Log de alerta do banco de dados em modo standby para 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) Examinando o conteúdo dos arquivos de log nos diretórios de arquivos da base de dados principal e de standby
(1) Arquivos de logs do banco de dados principal:
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) Arquivos de log de backup do banco de dados em standby:
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
Como observado, o banco de dados de standby recebeu com sucesso os arquivos de log enviados do banco de dados principal.
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
SecoolerNeste momento, o banco de dados de espera está em um estado modificável e ajustável, que corresponde ao modo desejado “LEITURA ESCRITA”.
É crucial observar que a implementação da funcionalidade de banco de dados Snapshot Standby baseia-se fundamentalmente no princípio de dados de flashback. Portanto, qualquer ação que possa obstaculizar a capacidade de realizar o flashback do banco de dados deve ser evitada aqui. Caso contrário, o banco de dados Snapshot Standby não será capaz de retornar ao seu estado anterior de recuperação standby.
1) Reinicie o banco de dados standby para o estado 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) Execute um comando para restaurar a identidade original do banco de dados standby físico.
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) O registro de alerta do banco de dados em standby documenta meticulosamente este processo de transição.
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
A partir do registro de alerta, pode-se inferir que o método de recuperação utilizou o recurso Flashback Database. Isso significa que, mesmo que o banco de dados de standby não estivesse sendo executado no modo de banco de dados flashback, a transição de função do banco de dados de standby ainda pode ser realizada usando a funcionalidade Flashback Database.
4) Reinicie o banco de dados de standby no modo de registro de recuperação automática.
(1) Neste ponto, o banco de dados está no estado NOMOUNTED e precisa ser reiniciado.
Observe que é necessário reiniciar o banco de dados em vez de usar o comando ALTER, caso contrário, a seguinte mensagem de erro será encontrada:
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) Ao examinar o log de alerta do banco de dados de standby, o processo de recuperação pode ser observado de maneira clara.
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) Monitore o status do aplicativo de logs inspecionando a visão de desempenho dinâmico 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
A conclusão foi confirmada, pois o usuário de teste “OCMU” que foi criado anteriormente não existe.
O Oracle Snapshot Standby é muito útil para fins de teste. No entanto, para proteger ainda mais seu ambiente de banco de dados, é recomendável fazer backup do seu banco de dados Oracle com uma solução profissional de backup e recuperação de desastres.
Vinchin Backup & Recovery fornece funcionalidade poderosa para proteger seus bancos de dados em máquinas virtuais e servidores físicos, sendo bastante automático, flexível e eficiente. Ele oferece proteção para múltiplos tipos de banco de dados, incluindo Oracle DB, MySQL, SQL Server, Postgres Pro e MariaDB, com suporte para compressão de banco de dados, gerenciamento centralizado de tarefas, estratégias inteligentes de backup, backup de banco de dados quente e suporte avançado ao SQL Server/Oracle. Além disso, também oferece um recurso poderoso de proteção contra ransomware e migração V2V em mais de 10 plataformas virtuais.
Vinchin Backup & Recovery foi selecionado por milhares de empresas e você também pode começar a usar este poderoso sistema com uma versão de trial de 60 dias com todos os recursos! Além disso, entre em contato conosco e relate suas necessidades, e então você receberá uma solução de acordo com o seu ambiente de TI.
O recurso notável do “Banco de Dados em Modo Snapshot Standby” permite que o banco de dados standby se torne temporariamente um banco de dados independente com leitura e gravação. Isso amplia muito as possibilidades de uso do banco de dados standby. Ao aproveitar essa funcionalidade especial do banco de dados standby, você pode testar e reproduzir com segurança problemas que poderiam ser "arriscados" de simular e reproduzir no ambiente de produção. Uma vez concluídos os testes, você pode restaurar sua identidade como um banco de dados standby físico e continuar com a recuperação de logs.
Compartilhar em:
