Configurando RedoRoutes no Data Guard Broker

No meu artigo “Cascateamento de redo em uma configuração Data Guard” demonstrei como funciona o cascateamento de redo, onde um banco standby da configuração Data Guard fica responsável por replicar o redo recebido do primário para os outros bancos standby da configuração. Neste artigo irei demonstrar como criar a configuração no Data Guard Broker para este cenário de cascateamento de redo.

Relembrando os bancos

No meu artigo anterior, nossa configuração Data Guard era composta por:

• saopaulo1: é o banco primário;
• saopaulo2: é o cascading standby e replica o redo do banco primário saopaulo1 para os bancos bahia e ceara;
• bahia e ceara: são os destinos terminais, que receberão o redo do cascading standby;
• Todos os bancos, exceto “saopaulo1”, são standbys físicos;

Criando a configuração no Data Guard Broker

Inicialmente, em todos os bancos da configuração Data Guard, habilitamos o Data Guard Broker:

ALTER SYSTEM SET DG_BROKER_START=TRUE;

Quando habilitado, este parâmetro irá inicializar dois processos de background:

• DMON: é o processo responsável por monitorar e manter a configuração do Data Guard Broker, atualizando os arquivos de configuração do broker;
• INSV (Data Guard Broker Instance Slave Process): em um ambiente RAC, faz a comunicação do Data Guard Broker entre as instâncias;

A partir do Oracle Database 12c Release 1 (12.1), para que todos os bancos possam ser adicionados a uma configuração do broker, quaisquer parâmetros LOG_ARCHIVE_DEST_n que tenham o atributo SERVICE definido, mas não o atributo NOREGISTER, devem ser limpos:

ALTER SYSTEM SET log_archive_dest_n='' SCOPE=BOTH SID='*';

Com o broker habilitado, iniciamos o utilitário DGMGRL no host do nosso banco primário:

dgmgrl sys/senha

Agora criamos a configuração chamada “cascading”, apontando o banco saopaulo1 como primário:

CREATE CONFIGURATION cascading AS PRIMARY DATABASE IS saopaulo1 CONNECT IDENTIFIER IS saopaulo1;

Em seguida, adicionamos os standbys da configuração, saopaulo2, ceara e bahia:

ADD DATABASE saopaulo2 AS CONNECT IDENTIFIER IS saopaulo2 MAINTAINED AS PHYSICAL;

ADD DATABASE ceara AS CONNECT IDENTIFIER IS ceara MAINTAINED AS PHYSICAL;

ADD DATABASE bahia AS CONNECT IDENTIFIER IS bahia MAINTAINED AS PHYSICAL;

Caso a configuração do broker seja habilitada neste momento, o comportamento do transporte de redo seguirá o padrão, no qual o banco de dados primário envia seu redo para todos os destinos de transporte de redo possíveis na configuração. Como nossa configuração Data Guard usa de cascateamento de redo, podemos sobrescrever este comportamento com a propriedade “RedoRoutes”.

Inicialmente vamos configurar o banco primário, saopaulo1, para que faça o envio de redo para o banco saopaulo2, de maneira assíncrona:

EDIT DATABASE 'SAOPAULO1' SET PROPERTY 'RedoRoutes' = '(LOCAL : SAOPAULO2 ASYNC)';

Neste caso usamos ‘LOCAL’ para dizer ao broker que o redo que será enviado para o standby saopaulo2 vem do banco que estamos editando a propriedade.

Em seguida, configuramos o banco saopaulo2, nosso cascading standby, responsável por propagar o redo do banco primário saopaulo1 para os standbys bahia e ceara de maneira assíncrona:

EDIT DATABASE 'SAOPAULO2' SET PROPERTY 'RedoRoutes' = '(SAOPAULO1 : BAHIA ASYNC, CEARA ASYNC)';

Com estas configurações feitas, podemos habilitar a configuração do broker:

ENABLE CONFIGURATION;

Podemos ver a configuração de RedoRoutes com o comando:

VALIDATE DATABASE VERBOSE saopaulo2;

Verificando a configuração, com o comando SHOW CONFIGURATION temos:

Conclusão

A utilização de configurações de Data Guard Broker facilita muito o gerenciamento de um Data Guard, tornando a execução de processos como switchover e failover mais simples. Em configurações como o cascateamento de redo precisamos dominar as propriedades do broker a fim de configurá-lo da maneira correta, para que a administração seja facilitada.

Espero que este artigo tenha apresentado conceitos que venham a ser úteis no seu dia-a-dia!