Rman duplicate: criando novo standby usando um active standby no ambiente em Cloud

Por Ronaldo dos Reis Olegario
Publicado em Setembro 2019

Revisado por Francisco Riccio




Sem sombra de dúvida o RMAN é uma mão na roda na vida do DBA Oracle. É um canivete Suíço com inúmeras funções. O RMAN pode ser utilizado para inúmeras funções que vão muito além do backup database, entre estas funções podemos destacar sua utilização como ferramenta de migração entre versões, Clone database, standby, backup de archives, backup incremental, backup incremental diferencial e ainda temos a possibilidade de abrir o database mesmo com a ausência de archives com a opção reset logs, Database point-in-time a lista de funcionalidades é gigante, impossível imaginar Oracle Database sem o utilitário RMAN.

Neste artigo vamos explorar o Duplicate database. O Duplicate database é um option do RMAN que tonar o Clone uma tarefa muito tranquila. O cenário que o artigo aborda é a criação de um novo ambiente que será utilizado como para desenvolvimento. Para a criar o novo ambiente vamos utilizar o Standby como servidor de backup, desta forma reduzimos o impacto do primário e temos uma liberdade maior quando a horários de backup. O Standby e o novo servidor de desenvolvimento estão na Oracle Cloud. Os SLAs e vlans dos ambientes são diferentes e nossos desafios são tempo de restore e conectividade entre os servidores, visto a segmentação de Vlans. Neste artigo não abordaremos os aspectos de deploy do ambiente nem configuração da Cloud. 




Validação do ambiente Standby


O primeiro passo é validar se o standby está sincronizado e aberto para leitura.  

Para validar se a instância está em modo de leitura executaremos a consulta conforme demonstrado na listagem 1.

Listagem 1: Validando estado da instância

SQL> conn / as sysdba
Connected.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY



Como podemos verificar na listagem 1, a instância está aberta para leitura. Vamos realizar a validação do sincronismo, conforme demonstrado na listagem 2.

Listagem 2: Validando sincronização do Standby

SQL> set linesize 100;
SQL> column name format a15;
SQL> column value format a15;
SQL> column time_computed format a20;
SQL> column datum_time format a20;
SQL> select name, value, time_computed, datum_time from v$dataguard_stats where 
name='apply lag';

NAME            VALUE           TIME_COMPUTED        DATUM_TIME
--------------- --------------- -------------------- --------------------
apply lag       +00 00:00:00    04/05/2019 14:02:25  04/05/2019 14:02:24

SQL> !date
Fri Apr  5 14:02:38 -03 2019

A listagem 2 demonstra que estamos 100% sincronizados com o primary.  Desta forma podemos seguir para os próximos passos com segurança que teremos dados atualizados.





Iniciando a instância Oracle no novo servidor


Para executar o duplicate precisamos iniciar uma instância do novo servidor. Para isso vamos precisa de um arquivo de inicialização mínimo, conforme demonstrado na listagem 3.

Listagem 3: Init.ora do novo servidor

*.compatible='12.1.0.2.0'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_create_online_log_dest_1='+DATA'
*.db_create_online_log_dest_2='+DATA'
*.db_file_name_convert='+DATAC1/DBSTD/','+DATA/DBDES/'
*.log_file_name_convert='+DATAC1/DBSTD/','+DATA/DBDES/','+RECOC1/DBSTD/','
+DATA/DBDES/','+DATAC1/DBSTD/','+DATA/DBDES/','+RECOC1/DBSTD/','+DATA/DBDES/'
*.db_files=4096
*.db_name='DBDES'
*.db_recovery_file_dest='+DATA'
*.db_recovery_file_dest_size=751619276800
*.db_unique_name='DBDES'
*.pga_aggregate_limit=0
*.pga_aggregate_target=4G
*.processes=4096
*.sga_max_size=12G
*.sga_target=10G



Para iniciar a instância basta acessar o SQLPlus e executar os passos listados na listagem 4.

Listagem 4: Startup da instância

sqlplus /nolog
conn / as sydba
startup nomount pfile='/home/oracle/init.ora';
ORACLE instance started.

Total System Global Area 1.2885E+10 bytes
Fixed Size                  3725224 bytes
Variable Size            3925870680 bytes
Database Buffers         8925478912 bytes
Redo Buffers               29827072 bytes

Neste caso o arquivo de inicialização está no home do usuário oracle. O caminho default do arquivo de inicialização é $ORACLE_HOME/dbs. Não utilizaremos o caminho default pois o duplicate vai criar um arquivo de inicialização no processo.





Conectividade entre os ambientes


Para que o rman consiga realizar o backup no standby precisaremos ajustar o arquivo TNSNAMES.ora. Vamos adicionar uma entrada no arquivo que será responsável pela conexão ao novo servidor.  

Listagem 5: Nova entrada de TNS no servidor Standby

DBDES =
        (DESCRIPTION=
                (ADDRESS=(PROTOCOL=tcp)(HOST=XXX.XXX.XXX.XXX)(PORT=1523))
            (CONNECT_DATA=
                (SERVICE_NAME=DBDES)
                (INSTANCE_NAME=DBDES)
            )
        )



Após adicionar a entrada vamos fazer um teste de conexão via tnsping.

Listagem 6: Testes de conectividade com desenvolvimento

tnsping DBDES

TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 08-APR-2019 19:36:44

Copyright (c) 1997, 2014, Oracle.  All rights reserved.

Used parameter files:
/u02/app/oracle/product/12.1.0/dbhome_3/network/admin/STSTD/sqlnet.ora


Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=10.210.8.122)(PORT=1523))
(CONNECT_DATA= (SERVICE_NAME=MLDEBS) (INSTANCE_NAME=DBDES)))
OK (0 msec)



Agora vamos adicionar a entrada no servidor standby no servidor de desenvolvimento

Listagem 7: Nova entrada de TNS no servidor Desenvolvimento

STSTD = 
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = XXX.XXX.XXX.XXX)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = STSTD)
      (FAILOVER_MODE =
        (TYPE = select)
        (METHOD = basic)
      )
    )
  )



Após adicionar a entrada vamos fazer um teste de conexão via tnsping e como o database está aberto podemos validar também com sqlplus.

Listagem 8: Teste conectividade com standby

tnsping STSTD

TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 08-APR-2019 19:43:18

Copyright (c) 1997, 2014, Oracle.  All rights reserved.

Used parameter files:
/db/MLDEBS/product/12.1.0/network/admin/DBDES/sqlnet_ifile.ora


Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = XXX.XXX.XXX.XXX)
(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = STSTD) (FAILOVER_MODE = 
(TYPE = select) (METHOD = basic))))
OK (0 msec)

sqlplus /nolog

SQL*Plus: Release 12.1.0.2.0 Production on Mon Apr 8 20:00:01 2019

Copyright (c) 1982, 2014, Oracle.  All rights reserved.
SQL> conn sys/welcome@STSTD/ as sysdba
Connected.
SQL> quit

Com dos testes de acesso realizados, concluímos esta etapa. O próximo passo é criar os scripts do Duplicate e partir para a execução.





Criando os script de duplicate


Após ter criado as entradas necessárias no TNS, testado as conexões agora precisamos trabalhar no script do duplicate. Devido ao tamanho do database separei o script em duas partes. A primeira parte é um shell demonstrado na listagem 9, este script é responsável por realizar a chamada do rman. A segunda parte é o script rman que executará o duplicate que é demonstrado na listagem 10.   

Listagem 9: Shell Script

#!/bin/bash
ORACLE_HOME=/db/DBDES/product/12.1.0
ORACLE_SID=DBDES
ORACLE_UNQNAME=$ORACLE_SID
OH=$ORACLE_HOME
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
export ORACLE_HOME ORACLE_SID
$ORACLE_HOME/bin/rman target sys/welcome@DBSTD auxiliary sys/welcome@DBDES 
cmdfile=/home/oracle/rman_duplicat_dbdes.rman log=/home/oracle/ rman_duplicat_dbdes.log



O script é basicamente um set de variáveis e a chamada do rman. O rman referencia o log e o script do duplicate. Com o log podemos acompanhar todos os steps da execução e em caso de problema é possível identificar o step exato da falha.

Listagem 10: rman script

run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;
allocate channel prmy5 type disk;
allocate auxiliary channel stby1 type disk;
allocate auxiliary channel stby2 type disk;
allocate auxiliary channel stby3 type disk;
allocate auxiliary channel stby4 type disk;
allocate auxiliary channel stby5 type disk;
DUPLICATE TARGET DATABASE TO DBDES
FROM ACTIVE DATABASE;
}

O próximo passo é executar o script e acompanhar o log visando identificar erros que impactam na conclusão do duplicate.





Validação do log do rman e do clone


Após o Duplicate ter concluído o processo vamos verificar o log gerado pelo Rmam e executar algumas querys no database para coletar informações do mesmo.
Para analisar o log vamos utilizar um grep no arquivo gerado buscando por ORA- e RMAN-. Com estes 2 filtros listamos todos os possíveis erros no log. Na listagem 11 é demostrado o uso do grep, devido a ausência de erros não foi possível captura o retorno dos comandos.

Listagem 11: Exemplo do grep

grep ORA- rman_duplicat_dbdes.rman
grep RMAN- rman_duplicat_dbdes.rman



A listagem 12 apresenta as linhas do final do log, podemos observar que o database foi aberto sem erro e estas disponível para uso.

Listagem 12: Parte final do log

contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script

database opened
Executing: alter database flashback on
Cannot remove created server parameter file
Finished Duplicate Db at 10-APR-19



Na listagem 13 demonstra o status do database após aberto como primário e habilitado para leitura e escrita.

Listagem 13: Database check

SQL> select open_mode ,protection_mode , database_role from v$database ;
OPEN_MODE PROTECTION_MODE DATABASE_ROLE
-------------------- -------------------- ----------------
READ WRITE MAXIMUM PERFORMANCE PRIMARY


SQL> select instance_name, host_name from v$instance;
INSTANCE_NAME
----------------
HOST_NAME
----------------------------------------------------------------
DBDES
XXXXXX.localhost




Conclusão


O duplicate facilita muito o processo de  clonagem de ambientes. Neste cenário devido ao tamanho do database e a janela de execução de backup no primário ultrapassar o horário com menos concorrência utilizar o standby para clonagem e backups é uma ótima alternativa.
A possibilidade de utilizar o standby para este tipo de operação ajuda muita na manutenção dos ambientes. O ambiente utilizado é um ambiente da Oracle Cloud, o processo de clonagem é o mesmo usado em ambientes on-premisse.  




Ronaldo dos reis Olegario, DBA Oracle/Sybase, SQLServer e Cloudera Administrator Senior, atuando a mais de 12 anos na área TI  é formado em Ciência da Computação pela PUC-RS, possui certificações de Oracle Professional 10g e 11g, Oracle Real Application Cluster 10G e Oracle Goldengate Certified Specialist.
rolegar@gmail.com - https://br.linkedin.com/in/ronaldoolegario

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.