Páginas

27 de fev. de 2014

Implementando um Data Guard com Standby Físico


Olá pessoal,

     No artigo de hoje vou apresentar um roteiro simples de implantação de um ambiente Data Guard com 1 BD Primário e 1 BD Standby Físico, no Oracle 11G, com o modo de proteção Máxima Performance. Se você é leigo no assunto, sugiro que leia primeiro o artigo Conceitos básicos do Oracle Data Guard.

     Por se tratar um assunto bastante complexo e cheio de detalhes, acho muito difícil compreender todos os conceitos e recursos que o Data Guard possui, em 1 ou mais artigos de um blog, portanto, se você quer entender melhor o que iremos fazer em cada passo do roteiro abaixo, sugiro que você participe de um treinamento em Data Guard (eu, por exemplo, participei em um treinamento em 2012) ou que você estude, sem economizar tempo, as documentações e livros que podem ser encontradas nas referências ao final do artigo.

     De um modo geral, o que você precisa entender é que, o melhor método para criar o standby físico, é fazer um duplicate database via rman, configurando-se no destino os parâmetros que devem ser convertidos, como por exemplo, os nomes dos datafiles e controlfiles. Para criar o BD standby físico, é necessário apenas copiar o password file do BD primário, criar na máquina destino um arquivo pfile com um valor para o parâmetro db_name, e iniciar a instância do standby. Para mais detalhes, siga o roteiro abaixo, adaptando os valores em cinza, de acordo com os seus requisitos e necessidade:
  
PASSO-A-PASSO PARA IMPLANTAR UM DATA GUARD C/ 1 STANDBY FÍSICO
  
1- Configurações prévias do BD primário:
  
    a) O BD deve estar configurado para gerar archive logs. Se não estiver, leia o artigo
Configurando Bancos de Dados para gerar Archive Logs.
 
    b) Force a geração de redo logs em todas as operações do BD. Essa configuração é essencial para que os BDs Primário e Standby sejam cópias idênticas:
         SQL> ALTER DATABASE FORCE LOGGING;

    c) Crie diretórios p/ armazenar os Standby Redo Logs (SRLs). Recomenda-se que a quantidade de grupos de standby logs seja igual ao total de grupos de redo logs + 1.  SRLs são necessários no modo de proteção Máxima Performance somente quando a replicação de dados for realizada através do processo LGWR (e não através do processo ARCHn), que será o nosso caso.

    d) Crie os grupos de redo logs standy by, como no exemplo do comando abaixo:
         SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 (
                   '/u01/logfile5/pmry/prmy_stdby_logfile_g5_m1.rdo', 
                   '/u01/logfile5/pmry/prmy_stdby_logfile_g5_m2.rdo', 
) SIZE 500M;
         Obs.: O tamanho do standby log deve ser igual ao tamanho dos redo log files.
  
  
2- Parâmetros necessários p/ o BD primário replicar dados p/ o BD standby:
   
    a) Configure o parâmetro log_archive_config indicando os nomes dos bds (primário e standby), como no exemplo abaixo:
         SQL> alter system set log_archive_config='dg_config=(pmrystby)' scope=both;
    b) Habilite e configure o 2º destino de archive logs apontando para o bd standby:
         SQL> alter system set log_archive_dest_state_2='ENABLE' scope=both;
         SQL> alter system set log_archive_dest_2='service=stby lgwr async valid_for=(online_logfile,primary_role) db_unique_name=stby' scope=both;
    c) Configure o servidor para resolver gaps, quando necessário (será utilizado somente quando o BD estiver no papel de standby):
         SQL> alter system set fal_server='stby' scope=both;
    d) Configure o gerenciamento de arquivos automático (será utilizado somente quando o BD estiver no papel de standby). Essa configuração é necessária para que a inclusão, alteração ou deleção de tablespaces/datafiles seja replicada para este BD quando ele estiver no papel de Standby :
         SQL> alter system set standby_file_management=AUTO scope=both;
    e) Configure proteção contra corrompimento de dados. Esta configuração evita que corrompimentos no BD Primário sejam replicados para o BD Standby:
         SQL> alter system set DB_ULTRA_SAFE=DATA_AND_INDEX scope=spfile;
    f) Habilite e configure Flashback Database. Esta configuração é necessária para permitir que você transforme o Standby Físico em Snapshot Standby, quando houver necessidade, além de permitir outros benefícios, como por exemplo, transformar o BD Primário em Standby após um Failover:

                 SQL> alter system set db_recovery_file_dest_size=5G scope=both;
     SQL> alter system set db_recovery_file_dest='/u01/fra/pmry' scope=both;
         SQL> shutdown immediate;
         SQL> startup mount exclusive;
         SQL> alter database flashback on;
         SQL> alter database open;
    g) Verifique/configure o log buffer p/ ter no mínimo 8 MB;

    h) Certifique-se de que a SGA esteja configurada c/ ASMM p/ melhor gerenciamento de memória.

    i) Configure 4 ou mais processos arquivadores (necessário para o broker que vamos instalar em um próximo artigo): 
         SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES =4 SCOPE=BOTH;

3- Criando o BD standby físico:

    a) Configure apelidos no tnsnames das máquinas do BD primário e standby para ambos possam se conectar bidirecionalmente;

    b) Copie o password file do BD primário para a máquina do BD standby, renomeando-o apropriadamente;
    c) Crie na máquina do BD standby, diretórios correspondentes aos diretórios de todos os arquivos do BD primário, se o BD não for utilizar armazenamento ASM. Exemplos:
         $> mkdir /oradados/stby
         $> mkdir /oraindices/stby
         $> mkdir /oralog/stby
         $> mkdir /oractfl/stby
         $> mkdir /oraarc/stby
         $> mkdir /orafra/stby
    
    d) Configure e inicie o listener da máquina do BD Standby;
    e) Inicie o BD Standby em modo nomount com um arquivo de parâmetros contendo somente o nome do BD (Ex.: db_name=stby);
    f) Configure a variável de ambiente ORACLE_SID com o nome do BD Primário e entre no RMAN a partir da máquina do BD Primário, conectando-se também no futuro BD Standby, como um BD auxiliar:
         $> export ORACLE_SID=pmry         
         SQL> rman target sys/xxxxxx auxiliary sys/xxxxxx@stby

    g) Crie o BD Standby usando o comando DUPLICATE ACTIVE DATABASE no RMAN. Não é necessário ter backup prévio do BD de produção:
         RMAN> DUPLICATE TARGET DATABASE for standby FROM ACTIVE DATABASE 
    dorecover NOFILENAMECHECK NORESUME 
   DB_FILE_NAME_CONVERT '/oradados/pmry' ,  '/oradados/stby', 
                                                        'pmry'                   ,  'stby'
    log_file_name_convert   'pmry' , 'stby'   
    CONTROL_FILES         '/oractfl/pmry' ,  '/oractfl/stby'
    SPFILE
    parameter_value_convert     'pmry'        ,   'stby'                               
    SET LOG_FILE_NAME_CONVERT   'pmry'  ,   'stby'  
    set DB_FILE_NAME_CONVERT    '/oradados/pmry' ,  '/oradados/stby', 
                                                                  'pmry'                   ,  'stby'
    set db_unique_name = 'stby'
    set fal_server='pmry'
    set standby_file_management='AUTO'
    set log_archive_config = 'dg_config=(pmry,stby)'
    set log_archive_format = 'stby_%r%t%s.arc'
    set log_archive_dest_1 = 'LOCATION=/oraarc/stby'
  set log_archive_dest_2 = 'service=pmry lgwr async valid_for=(online_logfile,primary_role)           
                                             db_unique_name=pmry'
    set db_recovery_file_dest_size = '5G'
    set db_recovery_file_dest = '/orafra/stby'
    set AUDIT_FILE_DEST = '/ora00/app/oracle/product/diag/rdbms/stby/stby/trace'
    set DB_ULTRA_SAFE=DATA_AND_INDEX  
    SET SGA_MAX_SIZE = '24G
    SET SGA_TARGET = '24G'
    SET pga_aggregate_target = '4G';

    h) Se o comando acima foi executado com sucesso, saia do RMAN, entre no SQL Plus e inicie a recuperação de logs no BD Standby:
         SQL> shutdown immediate;
         SQL> startup mount;

    i) Habilite FLASHBACK DATABASE no Standby:
         SQL> alter database flashback on;

    j) Inicie o modo de recuperação no Standby:
         SQL> alter database recover managed standby database using current logfile disconnect;

    l) Verifique se a replicação de redo logs está funcionando perfeitamente, executando a consulta abaixo nos 2 BDs:
         SQL> select process, status, sequence#, block# from v$managed_standby;

      Obs.: No BD Primário você deverá ver o processo LNS escrevendo no log atual. No standby você deverá ver 1 ou mais processos RFS e o processo MRPn aplicando o log (APPLYING_LOG) de mesmo número que você viu o LNS escrevendo no BD Primário.


   Depois de implantar o Standby, recomendo configurar o Data Guard Broker, pois esse componente extra oferece vários benefícios, tais como: administrar o ambiente Data Guard via Enterprise Manager e instalar um mecanismo de restauração automática em casos de Failover. Para mais informações, sugiro a leitura do artigo Configurando o Data Broker no Data Guard.

   Por hoje é só! Qualquer dúvida, é só deixar um comentário, que eu responderei em seguida!


Referências:
   - Quick Guide to configuring Oracle 11gR2 Data Guard Physical Standby
  - Livro Oracle Dataguard 11g Handbook, Editora Oracle Press, Autores: Larry Carpenter, Charles Kim, Sonya Carothers, Michael Smith, Joe Meeks, Bill Burke, Joydip Kundu, Nitin Vengurlekar.
   - Treinamento oficial da Oracle: Oracle Database 11g: Data Guard Administration
   - Oracle® Data Guard Concepts and Administration11g Release 2 (11.2) 

9 comentários:

  1. vai me ajudar a fazer replicação no meu banco de dados aqui . Obrigado bom artigo, ja esta no meu favoritos.

    ResponderExcluir
    Respostas
    1. Que bom que o artigo vai ser útil! Qq dúvida é só deixar um comentário aqui!

      []s

      Excluir
  2. Parabéns pelo artigo. Alguma previsão para o documento sobre Data Broker?

    ResponderExcluir
    Respostas
    1. Fabricio, já era para eu ter publicado. Na verdade eu esqueci deste compromisso e fui publicando outros artigos. Até o final do ano publicarei, ok?

      Excluir
    2. Fabricio, o artigo sobre o Data Broker já foi publicado: http://www.fabioprado.net/2016/05/configurando-o-data-broker-no-data-guard.html.
      []s

      Excluir
  3. Existe algum problema de performance, caso a máquina do standby seja muito inferior a de produção? Posso trabalhar com Linux na maquina de produção de Windows na de Standby?

    ResponderExcluir
    Respostas
    1. Normalmente a máquina do standby é inferior, isso é normal, é o meu caso nos ambientes que administro, e acredito que isso só cause problemas quando a replicação é síncrona. Quanto ao SO, teoricamente não há problemas, mas é recomendado que ambos tenham a mesma versão de SO. Eu particularmente não recomendo usar SO diferentes, principalmente em ambientes críticos, pois bugs existem, são diferente em SOs diferentes, e dessa forma fica mais difícil tratá-los.

      Excluir
  4. Muito bom, porém no RMAN seria interessante explicar linha a linha do que se trata, alguns parâmetros não são muito óbvios.

    ResponderExcluir