Para melhor visualização, recomendo resolução de no mínimo 1024 x 768 e navegador Mozilla Firefox


segunda-feira, 1 de outubro de 2012

Criando um banco de dados standby com o RMAN e abordando o ACTIVE DATA GUARD e o SNAPSHOT STANDBY no Oracle 11g

Por Eduardo Legatti

Olá,


No artigo de Julho/2011 eu demonstrei na prática como clonar um banco de dados Oracle no mesmo servidor, através do comando DUPLICATE DATABASE do RMAN nas versões 10g e 11g. O foco principal do artigo não foi somente o de demonstrar os passos para realização da clonagem, mas também o de apresentar uma inovação na versão 11g com a cláusula ACTIVE DATABASE do comando duplicate do RMAN. Neste artigo irei demonstrar novamente uma clonagem utilizando o RMAN do Oracle 11g (11.2.0.3) de forma a criar um banco de dados standby físico (physical standby). A intenção é mostrar não apenas os passos para a criação de um banco de dados standby físico em outro servidor utilizando o RMAN com a cláusula "for standby", como também demonstrar alguns recursos do 11g como o ACTIVE DATA GUARD e o SNAPSHOT STANDBY. Para fazer uma breve introdução, o conceito por trás do Data Guard na qual um banco de dados standby está presente, nada mais é do que uma tecnologia de proteção contra desastres de um banco de dados Oracle. Nesta arquitetura temos um banco de dados primário (primary database) e um ou mais bancos de dados standby (standby database). Os bancos de dados estão conectados por uma rede que serve todas as transações à partir do banco de dados primário e depois as aplica ao banco de dados standby. Em essência, temos um banco de dados ativo e um banco de dados em recuperação constante. Portanto, o banco de dados standby físico é uma cópia bloco a bloco do banco de dados primário. Em relação aos modos de proteção dos dados, temos as seguintes opções:
  • No modo Maximum Performance (o padrão), as transações sofrem commit antes de suas informações de redo serem enviadas a um destino de banco de dados standby. Os commits no banco de dados primário ocorrem assim que as gravações nos arquivos de redo log online são concluídas.
  • No modo Maximum Availability, ao menos um destino de banco de dados standby deve ser gravado antes que uma transação sofra commit no banco de dados primário. Caso não seja possível, por causa algum tipo de falha, o banco de dados primário não sofrerá shutdown. Quando a falha é corrigida, os dados de redo que foram gerados à partir dela é transportado e aplicado no banco de dados standby.
  • No modo Maximum Protection, ao menos um destino de banco de dados standby deve ser gravado antes que uma transação sofra commit no banco de dados primário. Caso não seja possível, por causa de algum tipo de falha, o banco de dados primário sofrerá shutdown.
A arquitetura do Data Guard nos permite configurar os bancos dedos primário e standby com diferentes estruturas de diretórios para os arquivos de banco de dados, mas para facilitar o entendimento e a didática, irei assumir que os mesmos possuem estruturas de diretórios idênticos. No mais, segue abaixo a estrutura que utilizarei na criação do ambiente:


SERVER NAME ROLE     DB_NAME  DB_UNIQUE_NAME DATABASE FILES PATH          TNS SERVICE
----------- -------- -------- -------------- ---------------------------- -----------
linux1      PRIMARY  BD01     BD01           /u01/app/oracle/oradata/BD01 BD01_PRI
linux2      STANDBY  BD01     BD01_STBY      /u01/app/oracle/oradata/BD01 BD01_STBY

 
Bom, o primeiro passo é configurar o banco de dados primário. Vale a pena salientar que o banco de dados precisa estar obrigatoriamente operando no modo ARCHIVELOG e que a geração de redo forçada (force logging) esteja habilitada. Abaixo vocês verão que irei criar 4 grupos de arquivos de redo log standby no banco de dados primário. Estes arquivos são similares aos arquivos de redo log online, a única diferença é que os arquivos de redo log standby são usados para receber registros de redo provenientes do banco de dados primário quando utilizado como modo de transporte dos registros de redo o processo LGWR, independente dos modos de proteção (Maximum Protection/Performance/Availability). Embora os mesmos sejam utilizados somente enquanto o banco de dados está excutando em modo standby (standby role), a Oracle recomenda que criemos também arquivos de redo log standby no banco de dados primário de forma que uma eventual troca de roles (switchover, failover) entre os mesmos, aconteça de forma rápida e sem a necessidade de uma intervenção do DBA. Como regra e boa prática, é recomendável criarmos os arquivos de redo log standby do mesmo tamanho dos arquivos de redo log online (no meu caso 50 MB) e com um grupo a mais, ou seja, se meu banco de dados possui 3 grupos de redo log online (1, 2 e 3), então deverão ser criados 4 grupos de redo log standby (4, 5, 6 e 7). Vamos então para a prática.
========
PRIMARIO
========

[oracle@linux1 ~]$ export ORACLE_SID=BD01
[oracle@linux1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Seg Out 1 08:11:18 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup mount
Instância ORACLE iniciada.

Total System Global Area  943718400 bytes
Fixed Size                  2077264 bytes
Variable Size             490737072 bytes
Database Buffers          444596224 bytes
Redo Buffers                6307840 bytes
Banco de dados montado.

SQL> alter database archivelog;

Banco de dados alterado.

SQL> alter database open;

Banco de dados alterado.

SQL> alter database force logging;

Banco de dados alterado.

SQL> alter database add standby logfile 
  2  group 4 ('/u01/app/oracle/oradata/BD01/redo04.log') size 50M;

Banco de dados alterado.

SQL> alter database add standby logfile 
  2  group 5 ('/u01/app/oracle/oradata/BD01/redo05.log') size 50M;

Banco de dados alterado.

SQL> alter database add standby logfile 
  2  group 6 ('/u01/app/oracle/oradata/BD01/redo06.log') size 50M;

Banco de dados alterado.

SQL> alter database add standby logfile 
  2  group 7 ('/u01/app/oracle/oradata/BD01/redo07.log') size 50M;

Banco de dados alterado.

SQL> alter system set log_archive_config='dg_config=(BD01,BD01_STBY)';

Sistema alterado.

SQL> alter system set log_archive_dest_2='service=BD01_STBY lgwr async
  2  valid_for=(online_logfiles,primary_role) db_unique_name=BD01_STBY';

Sistema alterado.

SQL> alter system set fal_client='BD01_PRI';

Sistema alterado.

SQL> alter system set fal_server='BD01_STBY';

Sistema alterado.

SQL> alter system set log_archive_dest_state_2='ENABLE';

Sistema alterado.

SQL> alter system set standby_file_management=AUTO;

Sistema alterado.

Após realizar as configurações acima, irei copiar o arquivo de inicialização spfile e o arquivo de senhas para o servidor linux2 conforme demonstrado abaixo:
[oracle@linux1 ~]$ cd $ORACLE_HOME/dbs
[oracle@linux1 ~]$ scp orapwBD01 spfileBD01.ora oracle@linux2:$ORACLE_HOME/dbs
oracle@linux2's password: ********
orapwBD01                         100% 1536     1.5KB/s   00:00
spfileBD01.ora                    100% 3584     3.5KB/s   00:00

Neste momento já irei configurar nos servidores linux1 e linux2 as entradas TNS para os serviços de banco de dados primário e standby. Os mesmos deverão ser configurados no arquivo tnsnames.ora localizado em $ORACLE_HOME/network/admin
BD01_PRI =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = linux1)(PORT = 1521))
    )
    (CONNECT_DATA =
     (SERVICE_NAME = BD01)
    )
  )

BD01_STBY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = linux2)(PORT = 1521))
    )
    (CONNECT_DATA =
     (SERVICE_NAME = BD01)
    )
  )

Pronto. O banco de dados primário já está preparado para ser clonado. Com o software Oracle já instalado no servidor linux2, o próximo passo é criar as estruturas de diretórios necessários para o banco de dados standby e configurar os parâmetros necessários no arquivo de inicialização spfile. Como o banco de dados standby não será alvo de nenhuma política de backup, irei reduzir o tamanho da flash recovery area. Irei reduzir também os valores da SGA e PGA do banco de dados standby de forma a liberar recursos de memória para outros processos.
=======
STANDBY
=======

[oracle@linux2 ~]$ mkdir -p /u01/app/oracle/admin/BD01/adump
[oracle@linux2 ~]$ mkdir -p /u01/app/oracle/admin/BD01/dpdump
[oracle@linux2 ~]$ mkdir -p /u01/app/oracle/admin/BD01/pfile
[oracle@linux2 ~]$ mkdir -p /u01/app/oracle/oradata/BD01
[oracle@linux2 ~]$ export ORACLE_SID=BD01
[oracle@linux2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Seg Out 1 08:20:41 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup nomount
Instância ORACLE iniciada.

Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             104860532 bytes
Database Buffers          201326592 bytes
Redo Buffers                6328320 bytes

SQL> alter system set sga_target=300M scope=spfile;

Sistema alterado.

SQL> alter system set sga_max_size=300M scope=spfile;

Sistema alterado.

SQL> alter system set pga_aggregate_target=100M scope=spfile;

Sistema alterado.

SQL> alter system set db_recovery_file_dest_size=5G;

Sistema alterado.

SQL> alter system set db_unique_name='BD01_STBY'scope=spfile;

Sistema alterado.

SQL> alter system set log_archive_config='dg_config=(BD01,BD01_STBY)';

Sistema alterado.

SQL> alter system set log_archive_dest_2='service=BD01_PRI lgwr async 
  2  valid_for=(online_logfiles,primary_role) db_unique_name=BD01';

Sistema alterado.

SQL> alter system set fal_client='BD01_STBY';

Sistema alterado.

SQL> alter system set fal_server='BD01_PRI';

Sistema alterado.

SQL> alter system set log_archive_dest_state_2='ENABLE';

Sistema alterado.

SQL> startup nomount force;
Instância ORACLE iniciada.

Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             104860532 bytes
Database Buffers          201326592 bytes
Redo Buffers                6328320 bytes
Pronto. Por enquanto, a instância standby ficará no estado NOMOUNT para ser utilizado como instância auxiliar pelo RMAN no processo de clonagem que será realizado mais à frente. Abaixo irei configurar o listener no servidor linux2 adicionando uma entrada para o banco de dados BD01 de forma que o RMAN reconheça a mesma como instância auxiliar no processo de clonagem através do comando DUPLICATE TARGET DATABASE ... FROM ACTIVE DATABASE.
[oracle@linux2 ~]$ cd $ORACLE_HOME/network/admin
[oracle@linux2 ~]$ cat listener.ora

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = BD01)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
      (SID_NAME = BD01)
    )
  )

LISTENER =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = linux2.localdomain)(PORT = 1521))
  )

ADR_BASE_LISTENER = /u01/app/oracle


[oracle@linux2 admin]$ lsnrctl reload

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 01-OUT-2012 08:27:38

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Estabelecendo conexão com (HOST=linux2.localdomain)(PORT=1521)
O comando foi executado com êxito

[oracle@linux2 admin]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 01-OUT-2012 08:27:54

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Estabelecendo conexão com (HOST=linux2.localdomain)(PORT=1521)

STATUS do LISTENER
------------------
Apelido             LISTENER
Versão              TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Data Inicial        01-OUT-2012 08:27:28
Funcionamento       0 dias 0 hr. 0 min. 26 seg
Nível de Análise    off
Segurança           ON: Local OS Authentication
SNMP                OFF
Arq. Parâm. Listn.  /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Arq. Log Listener   /u01/app/oracle/diag/tnslsnr/linux2/listener/alert/log.xml
Resumo de Atendimento...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=linux2.localdomain)(PORT=1521)))
Resumo de Serviços...
O serviço "BD01" tem 1 instância(s).
  Instância "BD01", status UNKNOWN, tem 1 handler(s) para este serviço...
O serviço "BD01_STBY" tem 1 instância(s).
  Instância "BD01", status BLOCKED, tem 1 handler(s) para este serviço...
O comando foi executado com êxito

De volta ao servidor linux1, irei realizar a clonagem do banco de dados primário fazendo uso do RMAN com a opção "for standby" conforme demonstrado abaixo. Ao final, o mesmo será montado automaticamente.
========
PRIMARIO
========

[oracle@linux1 ~]$ rman target sys/manager@BD01_PRI auxiliary sys/manager@BD01_STBY

Gerenciador de Recuperação: Release 11.2.0.3.0 - Production on Seg Out 1 09:06:35 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

conectado ao banco de dados de destino: BD01 (DBID=3060188332)
conectado ao banco de dados auxiliar: BD01 (não montado)

RMAN> duplicate target database for standby
   2  from active database
   3  dorecover nofilenamecheck;
Iniciando Duplicate Db em 01/10/12
usar o arquivo de controle do banco de dados de destino em vez do catálogo de recuperação
canal alocado: ORA_AUX_DISK_1
canal ORA_AUX_DISK_1: SID=19 tipo de dispositivo=DISK

conteúdo do Script de Memória:
{
   backup as copy reuse
   targetfile  '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwBD01' auxiliary format
 '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwBD01'   ;
}
executando Script de Memória

Iniciando backup em 01/10/12
canal alocado: ORA_DISK_1
canal ORA_DISK_1: SID=38 tipo de dispositivo=DISK
Finalizado backup em 01/10/12

conteúdo do Script de Memória:
{
   backup as copy current controlfile for standby auxiliary format  '/u01/app/oracle/oradata/BD01/control01.ctl';
   restore clone controlfile to  '/u01/app/oracle/oradata/BD01/control02.ctl' from
 '/u01/app/oracle/oradata/BD01/control01.ctl';
   restore clone controlfile to  '/u01/app/oracle/oradata/BD01/control03.ctl' from
 '/u01/app/oracle/oradata/BD01/control01.ctl';
}
executando Script de Memória

Iniciando backup em 01/10/12
utilizando o canal ORA_DISK_1
canal ORA_DISK_1: iniciando cópia de arquivo de dados
copiando arquivo de controle stand-by
nome do arquivo de saída=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_BD01.f tag=TAG20121001T150647 RECID=2 STAMP=793897607
canal ORA_DISK_1: cópia de arquivo de dados concluída; tempo decorrido: 00:00:03
Finalizado backup em 01/10/12

Iniciando restore em 01/10/12
utilizando o canal ORA_AUX_DISK_1

canal ORA_AUX_DISK_1: cópia do arquivo de controle copiada
Finalizado restore em 01/10/12

Iniciando restore em 01/10/12
utilizando o canal ORA_AUX_DISK_1

canal ORA_AUX_DISK_1: cópia do arquivo de controle copiada
Finalizado restore em 01/10/12

conteúdo do Script de Memória:
{
   sql clone 'alter database mount standby database';
}
executando Script de Memória

instrução sql: alter database mount standby database

conteúdo do Script de Memória:
{
   set newname for tempfile  1 to
 "/u01/app/oracle/oradata/BD01/temp01.dbf";
   switch clone tempfile all;
   set newname for datafile  1 to
 "/u01/app/oracle/oradata/BD01/system01.dbf";
   set newname for datafile  2 to
 "/u01/app/oracle/oradata/BD01/sysaux01.dbf";
   set newname for datafile  3 to
 "/u01/app/oracle/oradata/BD01/undotbs01.dbf";
   set newname for datafile  4 to
 "/u01/app/oracle/oradata/BD01/users01.dbf";
   backup as copy reuse
   datafile  1 auxiliary format
 "/u01/app/oracle/oradata/BD01/system01.dbf"   datafile
 2 auxiliary format
 "/u01/app/oracle/oradata/BD01/sysaux01.dbf"   datafile
 3 auxiliary format
 "/u01/app/oracle/oradata/BD01/undotbs01.dbf"   datafile
 4 auxiliary format
 "/u01/app/oracle/oradata/BD01/users01.dbf"   ;
   sql 'alter system archive log current';
}
executando Script de Memória

executando comando: SET NEWNAME

arquivo temporário renomeado 1 para /u01/app/oracle/oradata/BD01/temp01.dbf no arquivo de controle

executando comando: SET NEWNAME

executando comando: SET NEWNAME

executando comando: SET NEWNAME

executando comando: SET NEWNAME

Iniciando backup em 01/10/12
utilizando o canal ORA_DISK_1
canal ORA_DISK_1: iniciando cópia de arquivo de dados
número do arquivo=00001 nome=/u01/app/oracle/oradata/BD01/system01.dbf do arquivo de dados de entrada
nome do arquivo de saída=/u01/app/oracle/oradata/BD01/system01.dbf tag=TAG20121001T150658
canal ORA_DISK_1: cópia de arquivo de dados concluída; tempo decorrido: 00:00:56
canal ORA_DISK_1: iniciando cópia de arquivo de dados
número do arquivo=00002 nome=/u01/app/oracle/oradata/BD01/sysaux01.dbf do arquivo de dados de entrada
nome do arquivo de saída=/u01/app/oracle/oradata/BD01/sysaux01.dbf tag=TAG20121001T150658
canal ORA_DISK_1: cópia de arquivo de dados concluída; tempo decorrido: 00:00:45
canal ORA_DISK_1: iniciando cópia de arquivo de dados
número do arquivo=00003 nome=/u01/app/oracle/oradata/BD01/undotbs01.dbf do arquivo de dados de entrada
nome do arquivo de saída=/u01/app/oracle/oradata/BD01/undotbs01.dbf tag=TAG20121001T150658
canal ORA_DISK_1: cópia de arquivo de dados concluída; tempo decorrido: 00:00:26
canal ORA_DISK_1: iniciando cópia de arquivo de dados
número do arquivo=00004 nome=/u01/app/oracle/oradata/BD01/users01.dbf do arquivo de dados de entrada
nome do arquivo de saída=/u01/app/oracle/oradata/BD01/users01.dbf tag=TAG20121001T150658
canal ORA_DISK_1: cópia de arquivo de dados concluída; tempo decorrido: 00:00:01
Finalizado backup em 01/10/12

instrução sql: alter system archive log current

conteúdo do Script de Memória:
{
   backup as copy reuse
   archivelog like  "/u01/app/oracle/fast_recovery_area/BD01/archivelog/2012_10_01/o1_mf_1_20_8548b2bp_.arc" auxiliary format
 "/u01/app/oracle/fast_recovery_area/BD01_STBY/archivelog/2012_10_01/o1_mf_1_20_%u_.arc"   ;
   catalog clone recovery area;
   switch clone datafile all;
}
executando Script de Memória

Iniciando backup em 01/10/12
utilizando o canal ORA_DISK_1
canal ORA_DISK_1: iniciando cópia de log arquivado
thread do log arquivado de entrada=1 sequência=20 RECID=5 STAMP=793897746
nome do arquivo de saída=/u01/app/oracle/fast_recovery_area/BD01_STBY/archivelog/2012_10_01/o1_mf_1_20_0bnl3qoj_.arc RECID=0 STAMP=0
canal ORA_DISK_1: cópia de log arquivado concluída, tempo decorrido: 00:00:01
Finalizado backup em 01/10/12

procurando todos os arquivos na área de recuperação

Lista de Arquivos Desconhecidos para o Banco de Dados
=====================================================
Nome do Arquivo: /u01/app/oracle/fast_recovery_area/BD01_STBY/archivelog/2012_10_01/o1_mf_1_20_0bnl3qoj_.arc
catalogando arquivos...
catalogação concluída

Lista de Arquivos Catalogados
=============================
Nome do Arquivo: /u01/app/oracle/fast_recovery_area/BD01_STBY/archivelog/2012_10_01/o1_mf_1_20_0bnl3qoj_.arc

arquivo de dados 1 alternado para a cópia do arquivo de dados
cópia do arquivo de dados de entrada RECID=2 STAMP=793897748 file name=/u01/app/oracle/oradata/BD01/system01.dbf
arquivo de dados 2 alternado para a cópia do arquivo de dados
cópia do arquivo de dados de entrada RECID=3 STAMP=793897748 file name=/u01/app/oracle/oradata/BD01/sysaux01.dbf
arquivo de dados 3 alternado para a cópia do arquivo de dados
cópia do arquivo de dados de entrada RECID=4 STAMP=793897748 file name=/u01/app/oracle/oradata/BD01/undotbs01.dbf
arquivo de dados 4 alternado para a cópia do arquivo de dados
cópia do arquivo de dados de entrada RECID=5 STAMP=793897748 file name=/u01/app/oracle/oradata/BD01/users01.dbf

conteúdo do Script de Memória:
{
   set until scn  220833;
   recover
   standby
   clone database
    delete archivelog
   ;
}
executando Script de Memória

executando comando: SET until clause

Iniciando recover em 01/10/12
utilizando o canal ORA_AUX_DISK_1

iniciar recuperação de mídia

o log arquivado para thread 1 com sequência 20 já está no disco como arquivo /u01/app/oracle/fast_recovery_area/BD01_STBY/archivelog/2012_10_01/o1_mf_1_20_0bnl3qoj_.arc
nome do arquivo de log arquivado=/u01/app/oracle/fast_recovery_area/BD01_STBY/archivelog/2012_10_01/o1_mf_1_20_0bnl3qoj_.arc thread=1 sequência=20
recuperação da mídia concluída, tempo decorrido: 00:00:02
Finalizado recover em 01/10/12
Finalizado Duplicate Db em 01/10/12

Após finalizado o processo de clonagem acima, irei ativar o banco de dados standby em modo de recuperação (real-time apply) de forma que o mesmo comece a receber e aplicar os registros de redo vindos do banco de dados primário, conforme demonstrado abaixo. Irei configurar também uma política de retenção dos archived redo logs provindas do banco de dados primário de forma a protegê-los de qualquer deleção realizada pela política de backup RMAN configurada no lado do banco de dados primário.
=======
STANDBY
=======

[oracle@linux2 ~]$ export ORACLE_SID=BD01
[oracle@linux2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Seg Out 1 09:12:24 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning option

SQL> alter database recover managed standby database
  2  using current logfile disconnect from session;

Banco de dados alterado.

[oracle@linux2 ~]$ rman target /

Gerenciador de Recuperação: Release 11.2.0.3.0 - Production on Seg Out 1 09:13:09 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

conectado ao banco de dados de destino: BD01 (DBID=3060188332, não aberto)

RMAN> configure archivelog deletion policy to applied on standby;

usar o arquivo de controle do banco de dados de destino em vez do catálogo
novos parâmetros de configuração RMAN:
configure archivelog deletion policy to applied on standby;
os novos parâmetros de configuração RMAN foram armazenados com sucesso

Com os bancos de dados primário e standby configurados e em pleno funcionamento, irei executar algumas queries em ambos os bancos de dados para verificar os seus status.
========
PRIMARIO
========

[oracle@linux1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Seg Out 1 09:14:47 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning option

SQL> select db_unique_name,protection_mode,protection_level,database_role
  2  from v$database;

DB_UNIQUE_NAME PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE
-------------- -------------------- -------------------- ----------------
BD01           MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE  PRIMARY

1 linha selecionada.

SQL> select process,status,sequence#,block# from v$managed_standby;

PROCESS   STATUS        SEQUENCE#     BLOCK#
--------- ------------ ---------- ----------
ARCH      OPENING              19          0
ARCH      CLOSING              21          1
ARCH      OPENING              18          0
ARCH      CLOSING              21          1
LNS       WRITING              22        984

Podemos verificar pelos resultados acima que por padrão o banco de dados standby foi configurado para a proteção MAXIMUM PERFORMANCE e que o processo de servidor LNS (Log Network Server) está atualmente escrevendo dados de redo da sequência 22. A leitura que eu faço da arquitetura do Data Guard neste caso é a seguinte: Os registros de redo transmitidos pelo processo LNS no banco de dados primário são recebidos pelo banco de dados standby por um outro processo chamado RFS (Remote File Server), como será visto mais à frente. O processo LNS lê os mesmos registros de redo provenientes do buffer de redo log na SGA e os transmite ao banco de dados standby através do Oracle NET Services. O processo RFS recebe os dados de redo no banco de dados standby e aplica os mesmos nos arquivos de redo log standby (standby redo log files). Neste momento, o processo MRP (Managed Recovery Process) obtém os dados dos arquivos de redo log standby e os aplica nos datafiles do banco de dados standby. Como eu configurei o real-time apply, os dados de redo recebidos, são aplicados imediatamente nos arquivos de banco de dados, sem a necessidade de aguardar que os arquivos de redo log standby sejam arquivados. A figura abaixo demonstra um pouco desta arquitetura.


Para ilustrar ainda um pouco mais sobre esse mecanismo, a imagem abaixo retirada da documentação oficial do Data Guard no site da Oracle, nos mostra com mais clareza os componentes envolvidos. Saliento novamente que, por padrão, os dados de redo não são aplicados no banco de dados standby até que o arquivo de redo log standby seja arquivado. Quando o recurso real-time apply é usado, os dados de redo são aplicados no banco de dados standby quando forem recebidos, reduzindo potencialmente o tempo necessário para se fazer uma operação de failover.
 
 

Abaixo irei verificar no banco de dados standby os status de recebimento e aplicação dos dados de redo vindos do banco de dados primário.
=======
STANDBY
=======

[oracle@linux2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Seg Out 1 09:14:58 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning option

SQL> select db_unique_name,protection_mode,protection_level,database_role
  2  from v$database;

DB_UNIQUE_NAME PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE
-------------- -------------------- -------------------- ----------------
BD01_STBY      MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE  PHYSICAL STANDBY

1 linha selecionada.

SQL> select process,status,sequence#,block# from v$managed_standby;

PROCESS   STATUS        SEQUENCE#     BLOCK#
--------- ------------ ---------- ----------
ARCH      CONNECTED             0          0
ARCH      CONNECTED             0          0
ARCH      CONNECTED             0          0
ARCH      CLOSING              21          1
RFS       IDLE                  0          0
RFS       IDLE                  0          0
RFS       IDLE                 22       1001
MRP0      APPLYING_LOG         22       1001

8 linhas selecionadas.

Acima podemos verificar que o processo RFS já terminou de escrever (neste momento) os dados de redo da sequência 22 nos arquivos de redo log standby e que o processo MRP já está aplicando os mesmos nos datafiles do banco de dados.


Sobre o ACTIVE DATA GUARD

 

Bom, com o banco de dados standby em pleno funcionamento, irei realizar um teste para demonstrar uma nova funcionalidade do Data Guard no Oracle 11g que se chama ACTIVE DATA GUARD. Nas versões anteriores ao Oracle 11g, um banco de dados standby físico pode ser aberto em modo somente leitura (read only). No entanto, a aplicação dos dados de redo provenientes do banco de dados primário será pausado, ou seja, os dados de redo continuarão sendo enviados para o banco de dados standby, mas o mesmos não serão aplicados nos arquivos de banco de dados até que o banco de dados standby seja colocado novamente no modo de recuperação. No Oracle 11g, podemos abrir o banco de dados standby em modo leitura e, mesmo assim, os dados de redo continuarão sendo aplicados no banco de dados standby, como veremos abaixo.
=======
STANDBY
=======

[oracle@linux2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Seg Out 1 09:38:30 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning option

SQL> alter database open read only;
alter database open read only
*
ERRO na linha 1:
ORA-10456: cannot open standby database; media recovery session may be in progress

Acima, eu quis demonstrar que não bastará apenas abrir o banco de dados em modo somente leitura. Será necessário cancelar o modo de recuperação, abrir o banco de dados em modo de somente leitura para, então, colocá-lo novamente em modo de recuperação.
SQL> alter database recover managed standby database cancel;

Banco de dados alterado.

SQL> alter database open read only;

Banco de dados alterado.

SQL> alter database recover managed standby database
  2  using current logfile disconnect from session;

Banco de dados alterado.

Com o banco de dados standby aberto como somente leitura, irei realizar algumas operações remotas no banco de dados primário e verificar se as alterações foram enviadas e aplicadas no banco de dados standby.
========
PRIMARIO
========

C:\>sqlplus system/manager@linux1/BD01

SQL*Plus: Release 11.2.0.3.0 - Production on Seg Out 1 09:41:27 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning option

SYSTEM@linux1/BD01> create user scott identified by tiger default tablespace users;

Usuário criado.

SYSTEM@linux1/BD01> grant connect,resource to scott;

Concessão bem-sucedida.

SYSTEM@linux1/BD01> create table scott.t1 (id number);

Tabela criada.

SYSTEM@linux1/BD01> insert into scott.t1 select level from dual connect by level <=10;

10 linhas criadas.

SYSTEM@linux1/BD01> commit;

Commit concluído.
Acima eu criei o usuário SCOTT e populei a tabela T1 com dez registros. Irei executar uma consulta remota no banco de dados standby de forma a verificar se os mesmos já se encontram presentes no mesmo.
C:\>sqlplus system/manager@linux2/BD01

SQL*Plus: Release 11.2.0.3.0 - Production on Seg Out 1 09:51:21 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning option

SYSTEM@linux2/BD01> select * from scott.t1;

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

10 linhas selecionadas.

Perfeito. Podemos ver acima que os registros de redo foram enviados e aplicados no banco de dados standby mesmo ele estando aberto como somente leitura.


Sobre o SNAPSHOT STANDBY

 

Bom, uma outra feature (característica) que foi lançada na versão 11g é o SNAPSHOT STANDBY. Quando alteramos o banco de dados de physical standby para snapshot standby, o mesmo se comporta como se tivéssemos temporariamente fazendo um failover e abrindo o mesmo no modo READ WRITE, ou seja, o mesmo estaria operando como um banco de dados primário. Neste caso, a aplicação dos dados de redo são pausadas até que o mesmo volte a ser um physical standby. Para isso, o Oracle faz uso da tecnologia Flashback Database e internamente cria um ponto de restauração garantido como poderemos ver abaixo:
=======
STANDBY
=======

[oracle@linux2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Seg Out 1 10:11:27 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup mount
Instância ORACLE iniciada.

Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             104860532 bytes
Database Buffers          201326592 bytes
Redo Buffers                6328320 bytes
Banco de dados montado.

SQL> alter database convert to snapshot standby;

Banco de dados alterado.

SQL> alter database open;

Banco de dados alterado.

SQL> select flashback_on FROM v$database;

FLASHBACK_ON
------------------
RESTORE POINT ONLY

Neste momento, o banco de dados standby está aberto no modo de leitura/escrita. Abaixo podemos ver uma parte do arquivo de alerta que mostra a criação do ponto de restauração.
Mon Oct 1 10:12:44 2012
ALTER DATABASE CONVERT TO SNAPSHOT STANDBY
Starting background process RVWR
Mon Oct 1 10:12:45 2012
RVWR started with pid=22, OS id=6660
Allocated 3981204 bytes in shared pool for flashback generation buffer
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_10/01/2012 10:12:44
krsv_proc_kill: Killing 3 processes (all RFS)
Begin: Standby Redo Logfile archival
Mon Oct 1 10:16:38 2012
ARC0: STARTING ARCH PROCESSES
Mon Oct 1 10:16:38 2012
ARC1 started with pid=19, OS id=6678
Mon Oct 1 10:16:38 2012
ARC2 started with pid=20, OS id=6680
ARC1: Archival started
ARC2: Archival started
ARC2: Becoming the heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
Mon Oct 1 10:16:38 2012
ARC3 started with pid=21, OS id=6682
Archived Log entry 5 added for thread 1 sequence 24 ID 0xb666f6ac dest 1:
Mon Oct 1 10:16:38 2012
End: Standby Redo Logfile archival
RESETLOGS after incomplete recovery UNTIL CHANGE 225380
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Resetting resetlogs activation ID 3060201132 (0xb666f6ac)
Online log /u01/app/oracle/fast_recovery_area/BD01_STBY/onlinelog/o1_mf_1_8548b8jr_.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/fast_recovery_area/BD01_STBY/onlinelog/o1_mf_2_8548b9xh_.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/fast_recovery_area/BD01_STBY/onlinelog/o1_mf_3_8548bbro_.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 225378
Mon Oct 1 10:16:38 2012
Setting recovery target incarnation to 2
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: ALTER DATABASE CONVERT TO SNAPSHOT STANDBY

Como teste, irei dropar o usuário SCOTT e então voltar o banco dados para physical standby de forma a verificar se o mesmo será novamente sincronizado com o banco de dados primário e se o usuário SCOTT será recuperado.
SQL> drop user scott cascade;

Usuário eliminado.

SQL> shutdown immediate;
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> startup mount;
Instância ORACLE iniciada.

Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             104860532 bytes
Database Buffers          201326592 bytes
Redo Buffers                6328320 bytes
Banco de dados montado.

SQL> alter database convert to physical standby;

Banco de dados alterado.

SQL> shutdown immediate;
ORA-01507: banco de dados não montado

Instância ORACLE desativada.

SQL> startup nomount;
Instância ORACLE iniciada.

Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             104860532 bytes
Database Buffers          201326592 bytes
Redo Buffers                6328320 bytes

SQL> alter database mount standby database;

Banco de dados alterado.

SQL> alter database recover managed standby database
  2  using current logfile disconnect from session;

Banco de dados alterado.

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------
NO

Abaixo podemos ver no arquivo de log de alerta que o Oracle realizou uma operação de Flashback Database para retornar o banco de dados enquanto ele ainda era um physical standby.
Mon Oct 1 10:31:18 2012
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (BD01)
krsv_proc_kill: Killing 3 processes (all RFS)
Flashback Restore Start
Flashback Restore Complete
Drop guaranteed restore point
Stopping background process RVWR
Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/BD01_STBY/flashback/o1_mf_854d1f21_.flb
Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/BD01_STBY/flashback/o1_mf_854d1j9p_.flb
Guaranteed restore point  dropped
Clearing standby activation ID 3060197238 (0xb666e776)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 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;
Shutting down archive processes
Archiving is disabled
Mon Oct 1 10:31:21 2012
ARCH shutting down
ARC3: Archival stopped
Mon Oct 1 10:31:21 2012
ARCH shutting down
ARC2: Archival stopped
Mon Oct 1 10:31:21 2012
ARCH shutting down
ARC1: Archival stopped
Mon Oct 1 10:31:21 2012
ARCH shutting down
ARC0: Archival stopped
Completed: alter database convert to physical standby

Após abrir novamente o banco de dados como somente leitura (como já demonstrado mais acima) poderemos verificar que o usuário SCOTT que foi dropado enquanto o banco de dados estava operando como SNAPSHOT DATABASE foi recuperado após a operação automática de Flashback Database.
C:\>sqlplus system/manager@linux2/BD01

SQL*Plus: Release 11.2.0.3.0 - Production on Seg Out 1 10:33:21 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning option

SYSTEM@linux2/BD01> select * from scott.t1;

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

10 linhas selecionadas.

Google+

18 comentários:

David Ricardo disse...

IMPECAVEL...Legatti, cada dia que passa melhoram os artigos postados por você, sou seu fã, gosto muito do seu trabalho junto á comunidade e principalmente de tudo que divulga aqui no seu portal. Parabéns mais uma vez. Grande abraço.

P.S: Apareça por SP.

Eduardo Legatti disse...

Olá David,

Obrigado pela visita. Como também sou um fã incondicional seu, aprecio demais os seus comentários!

Abraços,

Legatti

Neto Longhi disse...

Eduardo, sensacional esse artigo, meus parabéns, destrinchou o dataguard 11g perfeitamente. Virei fã também, estarei sempre por aqui agora. Abraço

Eduardo Legatti disse...

Olá Neto,

Obrigado pela visita e volte sempre! ;-)

Abraços

Legatti

Junior Mendes da Silva disse...

Parabéns Eduardo, sou iniciante com banco de dados Oracle e seus artigos são de excelente qualidade no assunto. Continue postando e nos ajudando com sua grande compreensão do assunto. Abraço.

Eduardo Legatti disse...

Olá Junior,

Obrigado pelo comentário e pela visita.

Bons estudos ;-)

Abraços

Legatti

Felipe Bartholo Favilla disse...

Fala Legatti! Como andam as coisas por BH?
Estou trabalhando com Oracle (quem diria) e seus artigos são excelentes. Gostei muito deste sobre o DataGuard. Ele me ajudou muito na implementação que realizei por aqui.

A gente se esbarra por ai...
Grande abraço!

Barth.

Eduardo Legatti disse...

Olá Barth,

Quanto tempo hein?? Você está devendo uma visita aqui em BH! ;-)

Muito bom saber que os artigos estão sendo úteis pra você!!

Abraços

Legatti

Lorran Alves disse...

Parabéns Eduardo pelo excelente artigo.

Só uma dúvida.

Para ativar o Snapshot o banco primário precisa está com o flashbackDatabase Habilitado?

Eduardo Legatti disse...

Olá Lorran,

Não é necessário. No caso do Snapshot, o próprio Oracle cria um ponto de restauração garantido chamado de "SNAPSHOT_STANDBY_REQUIRED". Consultando a view V$DATABASE, a coluna FLASHBACK_ON aparecerá a informação "RESTORE POINT ONLY".

Abraços

Legatti

James disse...

Ola Legatti, Tudo joia?

Estou com uma duvida, veja se pode me ajudar, meu ambiente é um exadata, tenho o banco primario que fica no host prd1, o ambiente standby fica no host stby1, estou fazer o duplicate a partir do standby no mesmo host stby1, os datafiles ficam em ASM, em diskgroups diferentes. porem ao finalizar o mesmo não convert os redo log file mesmo usando a clausa log_file_name_convert no pfile . Teria alguma dica ?

duplicate database for standby from active database nofilenamecheck dorecover

Eduardo Legatti disse...

Olá James,

Não estou com nenhum ambiente nesse momento para tentar te ajudar. Estou de férias!!

Veja se o link abaixo pode te ajudar.

http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmdupad.htm#BRADV441

Abraços

Legatti

Anônimo disse...

Mais um excelente post, Legatti.
Parabéns.

Lílian Barroso.

Eduardo Legatti disse...

Olá Lilian,

Obrigado pela visita ;-)

Abraços,

Legatti

Paulo Singaretti disse...

Parabéns pela dedicação! Excelente, me ajudou muito! estava com um problema na criação do real time apply, e seguindo do "zero" o passo a passo aqui encontrei o problema, valeu!

Eduardo Legatti disse...

Olá Paulo,

Obrigado pela visita :-)

Abraços,

Legatti

Atos disse...

Ola Eduardo.

Sou um novato em Oracle. Seu artigo artigo, ou melhor dizendo seus artigos são sempre uma grande ajuda e muito esclarecedores.
Obrigado por sua gentileza em disponibilizar e compartilhar conhecimento.

Parabéns.

Eduardo Legatti disse...

Olá Atos,

Obrigado pela visita e pelo comentário!!

Abraços,

Legatti

Postagens populares