12c

Fale pessoal. Andei brincando um pouco com o Oracle 12c últimamente, afinal, temos que nos manter sempre atualizados, senão o mercado dá uma rasteira em nós, ou usando uma gíria paraense, nós “levamos o farelo’. Fiz este pequeno tutorial de como configurar um ambiente de Dataguard usando o Oracle 12c EE. Todos os testes foram feitos no VirtualBox (host Debian 7 e guest OEL6.3). Espero que seja útil para vocês assim como foi útil para mim. Dúvidas/sugestões/críticas são bem-vindas.

 

1)   Informações iniciais

Versão SO: Oracle Enterprise Linux 6.3 – 64 bits

Versão do Clusterware: 12.1.0.1 – 64 bits (software owner: grid)

Versão RDBMS: 12.1.0.1 – 64 bits (software owner: oracle)

SID primário: CDBPROD (DB_NAME: CDBPROD | DB_UNIQUE_NAME: CDBPROD) – 192.168.0.123

SID standby: CDBPROD (DB_NAME: CDBPROD | DB_UNIQUE_NAME: PROD_DR) – 192.168.0.124

 

2)   Configurações no lado primário

 

Passo1: Habilitar o FORCE LOGGING

SQL> ALTER DATABASE FORCE LOGGING;

 

Passo2: Copiar o password file do primário para o Standby

scp orapwcdbprod oracle@192.168.0.124:/u01/app/oracle/product/12.1.0/db_home1/dbs

 

Passo3: Adicionar uma entrada estática no Listener para a base de dados primária. Editar esse arquivo com o usuário grid. Após sua edição, recarregar o listener. Ex:

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = cdbprod)

(ORACLE_HOME = /u01/app/12.1.0/product/db_1)

(SID_NAME = cdbprod)

)

(SID_DESC =

(GLOBAL_DBNAME = cdbprod_DGMGRL) ### uso do broker ###

(ORACLE_HOME = /u01/app/12.1.0/product/db_1)

(SID_NAME = cdbprod)

)

)

Passo4: Adicionar uma entrada referente ao Standby no tnsnames.ora

PROD_DR =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = vm-ora12-stdb.localdomain)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = prod_dr)

)

Passo5: Criar os Standby REDO Logs. Criar G + 1 Standby REDO Logs, onde G indica o total de REDO Log Groups. Por exemplo, caso existam 4 REDO Log Groups, deve-se criar 5 Standby REDO Log Groups.

alter database add standby logfile group 4 ‘+DGPROD1’ size 100M;

alter database add standby logfile group 5 ‘+DGPROD1’ size 100M;

alter database add standby logfile group 6 ‘+DGPROD1’ size 100M;

alter database add standby logfile group 7 ‘+DGPROD1’ size 100M;

 

Passo6: Criar um PFILE baseado no SPFILE do primário, e copia-lo para o Standby. Esse PFILE será posteriormente editado no Standby, adequando seus parâmetros, para que finalmente, a base de dados Standby seja montada.

SQL> create pfile ‘/u01/app/oracle/12.1.0/product/db_1/dbs/pfile_standby.ora’ from spfile;

scp pfile_standby.ora oracle@192.168.0.124:/u01/app/oracle/product/12.1.0/db_home1/dbs

 

Passo7: Criar um STANDBY Control File e copia-lo para seu destino final, no Standby

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/u01/app/12.1.0/product/db_1/dbs/control01.ctl’;

scp control01.ctl oracle@192.168.0.124:/u01/app/oracle/product/12.1.0/db_home1/dbs

[LADO STANDBY] Após o termino da cópia do Standby controlfile para o Standby, deve-se copiar esse controlfile para dentro do ASM, via RMAN.

 

Passo8:[EXECUTAR APENAS APÓS O RESTORE] Após a conclusão do RESTORE do Standby, é necessário alterar alguns parâmetros no primário, relacionados às configurações do Standby. Após realizar essas alterações, reiniciar a base de dados primária.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG=’DG_CONFIG=(CDBPROD,PROD_DR)’ SCOPE=SPFILE;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=’SERVICE=PROD_DR ASYNC NOAFFIRM REOPEN=15 VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD_DR’ SCOPE=SPFILE’;

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=’AUTO’ SCOPE=SPFILE;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=’ENABLE’ SCOPE=SPFILE;

SQL> ALTER SYSTEM SET FAL_SERVER=’PROD_DR’ SCOPE=SPFILE;

SQL> ALTER SYSTEM SET FAL_CLIENT=’CDBPROD’ SCOPE=SPFILE;

 

OBS1: Caso se use o Broker para gerenciar o Dataguard, não será necessário setar o parâmetro LOG_ARCHIVE_DEST_2, pois isso será automaticamente feito pelo Broker durante a sua configuração. Caso se defina esse parâmetro, no momento de criar a configuração do Broker, o erro ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added será lançado.

 


3)   Configurações no lado Standby

 

Passo1:Criar as estruturas de diretórios necessárias, como o AUDIT_FILE_DEST:

cd $ORACLE_BASE

mkdir –p admin/prod_dr/adump

 

Passo2: Adicionar uma entrada estática no Listener para a base de dados Standby. Editar esse arquivo com o usuário grid. Após sua edição, recarregar o listener. Ex:

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = prod_dr)

(ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)

(SID_NAME = cdbprod)

)

(SID_DESC =

(GLOBAL_DBNAME = prod_dr_DGMGRL) ### uso do broker ###

(ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)

(SID_NAME = cdbprod)

)

)

 

Passo3:Adicionar 2 entradas no tnsnames.ora, uma apontando para a base Primária e outra para a base Standby

# standby

PROD_DR =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = vm-ora12-stdb.localdomain)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = prod_dr)

)

 

# primário

CDBPROD =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = vm-ora12.localdomain)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = cdbprod)

)

 

Passo4:Editar o PFILE copiado do primário, adequando seus parâmetros para o Standby. Os parâmetros alterados foram os seguintes:

*.audit_file_dest=’novo_caminho_arquivos_auditoria’

*.control_files=’caminho_standby_controlfile’

*.db_name=’cdbprod’

*.db_unique_name=’prod_dr’

*.log_archive_dest_2=’service=cdbprod async noaffirm reopen=15 valid_for(all_logfiles,primary_role) db_unique_name=cdbprod’

*.standby_file_management=’AUTO’

*.log_archive_dest_state_1=’ENABLE’

*.log_archive_dest_state_2=’ENABLE’

*.db_file_name_convert=(‘+DGPROD1’,’+DGDATA’)

*.log_file_name_convert=(‘+DGPROD1’,’+DGDATA’,’+DGFRA’,’+DGDATA’)

*. log_archive_config=’DG_CONFIG=(CDBPROD,PROD_DR)’

*.fal_server=’CDBPROD’

 

OBS1: Caso se use o Broker para gerenciar o Dataguard, não será necessário setar o parâmetro LOG_ARCHIVE_DEST_2, pois isso será automaticamente feito pelo Broker durante a sua configuração. Caso se defina esse parâmetro, no momento de criar a configuração do Broker, o erro ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added será lançado.

NOTA1: O parâmetro DB_UNIQUE_NAME será diferente entre o primário e o Standby, e o parâmetro DB_NAME será o mesmo para ambos.

NOTA2: O parâmetro STANDBY_ARCHIVE_DEST está depreciado.

 

Passo5:Iniciar a base Standby em NOMOUNT, usando o PFILE previamente editado. Depois alterar o estado da base de dados para MOUNT.

export ORACLE_SID=cdbprod

sqlplus / as sysdba

SQL> startup nomount pfile=’/u01/app/oracle/product/12.1.0/db_home1/dbs/pfile_standby.ora’;

SQL> ALTER DATABASE MOUNT;

Passo6:Iniciar o RESTORE da base de dados primária. O RESTORE será feito usando a nova feature do 12c, que é o restore via service_name (entrada tnsnames.ora)

rman target /

RMAN> RESTORE DATABASE FROM SERVICE CDBPROD USING COMPRESSED BACKUPSET;

 

Passo7: Criar os Standby REDO Logs. Criar G + 1 Standby REDO Logs, onde G indica o total de REDO Log Groups. Por exemplo, caso existam 4 REDO Log Groups, deve-se criar 5 Standby REDO Log Groups.

alter database add standby logfile group 4 ‘+DGDATA’ size 100M;

alter database add standby logfile group 5 ‘+DGDATA’ size 100M;

alter database add standby logfile group 6 ‘+DGDATA’ size 100M;

alter database add standby logfile group 7 ‘+DGDATA’ size 100M;

 

OBS1: O RESTORE via service_name já criou os Standby redo log files.

 

Passo8: Iniciar o Media Recovery Process (MRP)

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

 

Passo9:Criar um SPFILE e o armazenar em um diskgroup:

SQL> create spfile=’+DGDATA/PROD_DR/SPFILE/spfilecdbprod.ora’ from pfile=’u01/app/oracle/product/12.1.0/db_home1/dbs/pfile_standby.ora’;

 

### criar um arquivo “init<SID>.ora” dentro de ORACLE_HOME/dbs

vi initcdbprod.ora

 

### inserir o seguinte no arquivo initcdbprod.ora

spfile=’ +DGDATA/PROD_DR/SPFILE/spfilecdbprod.ora’

 

### testar

SQL> shutdown immediate;

SQL> startup mount;

 

Passo10: Adicionar a base de dados Standby ao Clusterware. Executar o comando abaixo como usuário “oracle”:

srvctl add database –d prod_dr –n cdbprod –r physical_standby –s mount –o /u01/app/oracle/product/12.1.0/db_home1 –p +DGDATA/PROD_DR/SPFILE/spfilecdbprod.ora

 

### desligar o standby e ligar novamente para que o clusterware seja atualizado

shutdown immediate;

startup mount;

 


4)   Configurando o Broker

 

Passo1: Alterar o parâmetro DG_BROKER_START, no standby e no primário:

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

 

Passo2:No primário, acessar a ferramenta DGMGRL e criar a configuração:

dgmgrl

DGMGRL> connect sys/senha

DGMGRL> create configuration cfg_cdbprod as primary database is cdbprod connect identifier is ‘cdbprod’;

DGMGRL> add database ‘prod_dr’ as connect identifier is ‘prod_dr’ maintained as physical;

DGMGRL> enable configuration;

 

### validar

DGMGRL> show configuration;

 

 

5)   Realizando um switchover

Um Switchover significa inverter os papeis em um ambiente de alta disponibilidade e Disaster Recovery configurado com o Dataguard. Nessa ação, o primário se tornará o novo Standby e o Standby atual se tornará o novo primário.

 

Passo1:Conectado no primário (via Broker), obter o nome da base de dados Standby:

DGMGRL> show configuration;

 

Passo2:Conectado no primário (via Broker), executar o Switchover, apontando para o standby, que se tornará o novo primário:

DGMGRL> switchover to prod_dr;

 

 

6)   Realizando um failover

Quando um failover é necessário, isso indica que o servidor primário foi perdido devido a alguma falha de hardware, de software ou um desastre no site principal. Com algum Standby sobrevivente, é possível retomar as atividades em com um curto período de downtime apenas.

 

Passo1:Conectado no Standby (via Broker), obter o nome da base de dados Standby:

DGMGRL> show configuration;

 

Passo2:Conectado no Standby sobrevivente (via Broker), executar o Failover, apontando para o standby, que se tornará o novo primário:

DGMGRL> failover to prod_dr;