Oracle Data Guard Broker Configuration

Agora que já entendemos o básico sobre o funcionamento do Oracle Data Guard Broker, vejamos como criar uma configuração inicial e habilitar o Broker na nossa configuração do Data Guard.

Para habilitar o broker, devemos cumprir alguns pré-requisitos. O primeiro é que os databases da configuração do Data Guard usem um spfile. Isso é necessário pois o broker irá alterar os parâmetros do database relacionado ao Data Guard e assim conciliar os os atributos entre os parâmetros do banco e o arquivo de configuração do broker.

O segundo pré-requisito é relacionado ao Oracle NET, nesse caso tanto o tnsnames.ora e o listener.ora.

Com respeito ao tnsnames.ora, já utilizamos ele mesmo sem o broker. Mas com o broker devemos estar atentos na configuração do destino. O detalhe necessário é que precisamos configurar ele com o SID e não com o service_name. É necessário utilizar o SID nessa configuração pois o Broker terá que se comunicar com o banco mesmo quando ele estiver down, ou seja, nesse momento não existe o service_name.

CDB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.15.51)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = cdb1)
    )
  )

CDBSTB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.15.49)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = cdb1)
    )
  )

O outro pré-requisito é relacionado ao listener.ora. Deve-se configurar um serviço estático para que ele se registre no listener local. Isso também é necessário para que o observer, explicado no post anterior, reinicie a instância como parte de restabelecimento do antigo primary database depois de um fast-start failover. Esse serviço estático só é necessário se não estiver usando o Oracle Restart ou o Oracle Clusterware. No caso de uma single instance sem o Oracle Restart.

Por padrão, esse serviço estático é configurado da seguinte maneira: db_unique_name_DGMGRL.db_domain. Pode-se alterar esse padrão se desejado, utilizando o parâmetro StaticConnectIdentifier.

Veja como ficaria no primary:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = terciocosta1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (SID_NAME=cdb1)
      (GLOBAL_DBNAME=cdb1_DGMGRL)
      (ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1)
      (ENVS="TNS_ADMIN=/u01/app/oracle/product/19.0.0/dbhome_1/network/admin")
    )
  )

E agora no meu standby:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = terciocosta1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (SID_NAME=cdb1)
      (GLOBAL_DBNAME=cdbstb_DGMGRL)
      (ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1)
      (ENVS="TNS_ADMIN=/u01/app/oracle/product/19.0.0/dbhome_1/network/admin")
    )
  )

Pode executar um start e stop no listener ou apenas um reload, para carregar as novas configurações do listener.ora.

Depois de cumprir os pré-requisitos, vamos agora habilitar o broker. Isso é feito alterando o valor do parâmetro DG_BROKER_START para TRUE, em ambos os bancos:

SQL> ALTER SYSTEM SET DG_BROKER_START = TRUE;

System altered.

Agora, já temos os dois arquivos de configuração criados. O local padrão é na $ORACLE_HOME/dbs. Você pode verificar eles consultado o parâmetro DG_BROKER_CONFIG_FILEn.

Uma observação a se fazer, é quando algum dos seus bancos é um RAC. Nesse caso, o arquivo de configuração do broker deve ser compartilhado entre as instâncias, fazemos isso com a ajuda do parâmetro DG_BROKER_CONFIG_FILEn. Deve-se criar esse arquivo em um cluster file system ou no ASM.

Lembrando, que para alterar esse parâmetro o DG_BROKER_START deve estar FALSE. E para mover esses arquivos temos algumas opções. Caso ele esteja no file system do sistema operacional, faça o move via sistema operacional mesmo. Caso o novo ou o antigo local esteja no ASM, utilize a procedure DBMS_FILE_TRANSFER.COPY_FILE. Após alterar, inicie novamente o broker altere o parâmetro DG_BROKER_START novamente para TRUE.

Com o parâmetro DG_BROKER_START em TRUE, o processo DMON é iniciado. A arquitetura com esse processo a mais é demonstrado na imagem abaixo:

Agora, vamos utilizar o DGMGRL para criar a configuração e registrar os databases.

$ dgmgrl sys/oracle
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Feb 1 12:00:14 2021
Version 19.10.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "cdb1"
Connected as SYSDBA.
DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS cdb1 CONNECT IDENTIFIER IS cdb1;
Configuration "dg_config" created with primary database "cdb1"
DGMGRL> ADD DATABASE cdbstb AS CONNECT IDENTIFIER IS cdbstb MAINTAINED AS PHYSICAL;
Database "cdbstb" added
DGMGRL> ENABLE CONFIGURATION;
Enabled.
DGMGRL> SHOW CONFIGURATION;

Configuration - dg_config

  Protection Mode: MaxPerformance
  Members:
  cdb1   - Primary database
    cdbstb - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 27 seconds ago)

DGMGRL> SHOW DATABASE CDB1;

Database - cdb1

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    cdb1

Database Status:
SUCCESS

DGMGRL> SHOW DATABASE CDBSTB;

Database - cdbstb

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 0 seconds ago)
  Average Apply Rate: 5.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    cdb1

Database Status:
SUCCESS

Pronto. Bem simples, nada de ficar alteando parâmetros de LOG_ARCHIVE_DEST_n. Apenas criamos a configuração do broker informando quem seria o primary database e qual seria o seu identifier. Adicionei um standby na configuração de uma maneira bem similar. Habilitei e exibi o resultado da configuração.

Bem, com certeza muitos devem ter achado um método bem simples. Mas, como alteramos o método de transporte de redo? Simples, alterando o parâmetro LogXptMode:

DGMGRL> SHOW DATABASE cdbstb LogXptMode;
  LogXptMode = 'ASYNC'
DGMGRL> EDIT DATABASE cdbstb SET PROPERTY LogXptMode='SYNC';
Property "logxptmode" updated
DGMGRL> SHOW DATABASE cdb1 LogXptMode;
  LogXptMode = 'SYNC'

No exemplo acima não configuramos AFFRIM ou NOAFFIRM. No caso de SYNC sempre vai ser AFFIRM e FASTSYNC sempre vai ser NOAFFIRM.

E para alterar o modo de proteção:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.

Um outro método de alterar a configuração relacionada ao redo transport é através do RedoRoutes. Um exemplo seria a configuração em que existe um FARSYNC, onde podemos configurar da seguinte maneira:

DGMGRL> EDIT DATABASE cdb1 SET PROPERTY RedoRoutes = '(LOCAL : fs1 SYNC)';
DGMGRL> EDIT DATABASE fs1 SET PROPERTY RedoRoutes = '(cdb1 : cdbstb ASYNC)';
DGMGRL> SHOW CONFIGURATION;
 
Configuration - dg_config
 
  Protection Mode: MaxAvailability
  Members:
  cdb1 - Primary database
    fs1 - Physical standby database
      cdbstb - Physical standby database (receiving current redo)
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS

Acima configuramos o RedoRoutes para enviar o redo para o FarSync de maneira síncrona. O FarSync por sua vez envia para o standby de maneira assíncrona, habilitando o real time cascading. Se não desejar o real time é só omitir o ASYNC.

Mas, e como eu faço para adicionar o destino alternativo no caso da falha do FarSync por exemplo? Da seguinte maneira:

DGMGRL> EDIT DATABASE cd1 SET PROPERTY 'RedoRoutes' = '(LOCAL : ( fs1 ASYNC PRIORITY=1, cdbstb ASYNC PRIORITY=2 ))';

Agora, para finalizar o post, vejamos como é realizar um switchover.

DGMGRL> SWITCHOVER TO cdbstb;
Performing switchover NOW, please wait...
Operation requires a connection to database "cdbstb"
Connecting ...
Connected to "cdbstb"
Connected as SYSDBA.
New primary database "cdbstb" is opening...
Operation requires start up of instance "cdb1" on database "cdb1"
Starting instance "cdb1"...
Connected to an idle instance.
ORACLE instance started.
Connected to "cdb1"
Database mounted.
Connected to "cdb1"
Switchover succeeded, new primary is "cdbstb"
DGMGRL> switchover to cdb1;
Performing switchover NOW, please wait...
Operation requires a connection to database "cdb1"
Connecting ...
Connected to "cdb1"
Connected as SYSDBA.
New primary database "cdb1" is opening...
Operation requires start up of instance "cdb1" on database "cdbstb"
Starting instance "cdb1"...
Connected to an idle instance.
ORACLE instance started.
Connected to "cdbstb"
Database mounted.
Database opened.
Connected to "cdbstb"
Switchover succeeded, new primary is "cdb1"

Acima fiz um switchover para o standby físico e depois retornei para o primary novamente. Tudo com um único comando ele cuida de todas as etapas relacionadas ao switchover. Isso também acontece com um failover:

DGMGRL> failover to cdbstb;
Performing failover NOW, please wait...
Failover succeeded, new primary is "cdbstb"

Algo muito bom com o broker, é que é muito fácil recuperar um failed primary quando ele esta com o flashback ativo. Podemos recuperar ele e assim ele passará a ser um standby físico na nossa configuração.

DGMGRL> REINSTATE DATABASE cdb1;
Reinstating database "cdb1", please wait...
Operation requires shut down of instance "cdb1" on database "cdb1"
Shutting down instance "cdb1"...
Connected to "cdb1"
ORACLE instance shut down.
Operation requires start up of instance "cdb1" on database "cdb1"
Starting instance "cdb1"...
Connected to an idle instance.
ORACLE instance started.
Connected to "cdb1"
Database mounted.
Connected to "cdb1"
Continuing to reinstate database "cdb1" ...
Reinstatement of database "cdb1" succeeded

Meu nome é Tércio Costa, sou formado em Ciências da Computação pela UFPB, tenho a certificação OCP 2019, Oracle SQL Expert e OCP 12c PL/SQL entre outras certificações de OCI, mantendo um blog reconhecido pela OTN(oraclepress.wordpress.com), no qual também publico artigos técnicos no portal OTN, no portal http://www.profissionaloracle.com.br/gpo e na revista SQL Magazine. Além de tudo isto sou um Oracle ACE por estar sempre contribuindo para a comunidade com um bom nível de expertise.

Marcado com: , , , , , , , , ,
Publicado em broker, Data Guard, High Availability

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.

Esse Blog é reconhecido pela
Sou um
Certificações
Sou articulista

Clique para seguir este blog e receber notificações via email de novos posts.

Tércio Costa

Tércio Costa

Meu nome é Tércio Costa, sou formado em Ciências da Computação pela UFPB, tenho a certificação OCP 2019, Oracle SQL Expert e OCP 12c PL/SQL entre outras certificações de OCI, mantendo um blog reconhecido pela OTN(oraclepress.wordpress.com), no qual também publico artigos técnicos no portal OTN, no portal http://www.profissionaloracle.com.br/gpo e na revista SQL Magazine. Além de tudo isto sou um Oracle ACE por estar sempre contribuindo para a comunidade com um bom nível de expertise.

Links Pessoais

Serviços verificados

Visualizar Perfil Completo →

Total de Visualizações da Página
  • 238.425 Visualizações
%d blogueiros gostam disto: