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

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

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:

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

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.

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.

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

[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.

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:

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:

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

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

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.

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)

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.

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

 

Passo8: Iniciar o Media Recovery Process (MRP)

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

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

4)   CONFIGURANDO O BROKER

 

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

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

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:

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

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:

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