


Gostaria de visitar um site de país da Oracle mais perto de si?
Visite Oracle.com Brasil Não obrigado, prefiro ficar aqui

Para outro país/região, aceda a esta página

Desempenho e Disponibilidade de Banco de dados

Configure Data Guard Physical

Setup usando Data Broker no
Oracle Database 19c
Por André Luiz Dutra Ontalba
Publicado em Junho 2019

Revisado por Francisco Riccio

Ambientes

 Necessário ter dois servidores (VMs ou físicos) com um sistema operacional e Oracle instalado. Meu
ambiente eu usei Oracle Linux 7.6 e Oracle Database 19c.
 O servidor primário (duts-dg1) tem uma instância em execução.
 O servidor em standby (duts-dg2) somente a instalação dos binários.
 Sem nenhum bloqueio a comunicação entre as máquinas sobre o listener.

Setup do banco de dados primário

Logging
Verifique se o banco de dados primário está no modo ARCHIVELOG.

 Copy
 SELECT log_mode FROM v$database;

LOG_MODE
------------
NOARCHIVELOG

SQL>

Se estiver em NOARCHIVELOG mode, altere para o modo ARCHIVELOG.

 Copy

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

Habilite o log FORCE LOGGING.

 Copy

ALTER DATABASE FORCE LOGGING;

-- Make sure at least one logfile is present.

ALTER SYSTEM SWITCH LOGFILE;

Crie os standby redo logs no database primário (em caso de switchovers). O standby redo logs deve ser o
mesmo tamanho que os redo logs e deve haver um grupo extra por thread. No meu caso, os seguintes
standby redo logs deve ser criado em ambos os servidores.

 Copy

-- If Oracle Managed Files (OMF) is not used.

ALTER DATABASE ADD STANDBY LOGFILE ('/u01/data/duts/std_redo01.log') SIZE 100M
ALTER DATABASE ADD STANDBY LOGFILE ('/u01/data/duts/std_redo02.log') SIZE 100M
ALTER DATABASE ADD STANDBY LOGFILE ('/u01/data/duts/std_redo03.log') SIZE 100M
ALTER DATABASE ADD STANDBY LOGFILE ('/u01/data/duts/std_redo04.log') SIZE 100M

-- If Oracle Managed Files (OMF) is used.

ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;
ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;
ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;
ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;

Se voce que usar a feature flashback database, ative no servidor primário agora, e ele será ativo no
standby também. Eu sempre uso em meus ambientes.
 Copy
 ALTER DATABASE FLASHBACK ON;

m class="sml">sl
Verifique a configuração dos parâmetros DB_UNIQUE_NAME e DB_NAME . Nesse caso, eles são definidos
como "duts" no banco de dados primário.

 Copy

SQL> show parameter db_name

NAME TYPE VALUE

------------------------------------ ----------- -----------------------------
db_name string duts

SQL> show parameter db_unique_name

NAME TYPE VALUE

------------------------------------ ----------- -----------------------------
db_unique_name string duts

SQL>

O DB_NAME do standby database será o mesmo que o da primário, mas deve ser diferente o valor do
DB_UNIQUE_NAME. Para este exemplo, o banco de dados standby terá o valor "duts_stby".

Verifique se o parâmetro STANDBY_FILE_MANAGEMENT está definido.

 Copy

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Service Setup

As entradas para os bancos de dados primário e em standby são necessárias no

"$ORACLE_HOME/network/admin/tnsnames.ora" em ambos servidores.

Você pode criá-los usando o utilitário de configuração de rede (netca) ou manualmente.

As seguintes entradas foram usadas durante esta configuração. Observe o uso do SID, em vez do
SERVICE_NAME nas entradas. Isto é importante quando o broker for se conectar a os bancos de dados
quando eles estão em shutdown, porque os serviços não estarão ativos.

 Copy

duts =
(DESCRIPTION =
 (ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))
)
(CONNECT_DATA =
(SID = duts)
)
)

duts_stby =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))
)
(CONNECT_DATA =
(SID = duts)
)
)

O arquivo "$ORACLE_HOME/network/admin/listener.ora" no servidor primário contém a seguinte

configuração.

 Copy

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = duts_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/19.0.0/db_1)
(SID_NAME = duts)
)
)

ADR_BASE_LISTENER = /u01/app/oracle

O arquivo "$ORACLE_HOME/network/admin/listener.ora" no servidor standby contém a seguinte

configuração.

Uma vez que o broker será necessário se conectar ao banco de dados quando estiver em shutdown. Não
podemos confiar no registro automático com o listener, Portanto, uma a entrada explícita para o banco de
dados.

 Copy
 LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = duts_stby_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/19.0.0/db_1)
(SID_NAME = duts)
)
)

ADR_BASE_LISTENER = /u01/app/oracle

Uma vez que o listener.ora estiver ok, reinicie o listener em ambos os servers.

 Copy

lsnrctl stop
lsnrctl start

Configuração do Servidor Standby

Preparando o Duplicate
Crie um arquivo de parâmetros "/tmp/initduts_stby.ora" para o standby database com os seguintes
conteúdos.

 Copy

*.db_name='duts'

Crie os diretórios necessários no servidor standby

 Copy

mkdir -p /u02/data/duts/pdbseed
mkdir -p /u02/data/duts/pdb1
mkdir -p /u02/app/oracle/fast_recovery_area/duts
mkdir -p /u02/app/oracle/admin/duts/adump
Criar um arquivo de senha, com a mesma senha do SYS usado no banco de dados primário.

 Copy

$ orapwd file=/u01/app/oracle/product/19.0.0/db_1/dbs/orapwduts password=oracl

Criando o Standby usando o DUPLICATE

Inicie a instancia auxiliar no servidor standby com o arquivo de parâmetros gerados.

 Copy

$ export ORACLE_SID=duts
$ sqlplus / as sysdba

SQL> STARTUP NOMOUNT PFILE='/tmp/initduts_stby.ora';

Conecte-se ao RMAN, especificando a string completa para o TARGET e AUXILIARY. Não tente usar a
autenticação do sistema operacional.

 Copy

$ rman TARGET sys/oracle@duts AUXILIARY sys/oracle@duts_stby

Agora emita o seguinte comando DUPLICATE.

 Copy

DUPLICATE TARGET DATABASE

FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET db_unique_name='duts_stby' COMMENT 'Is standby 19c'
NOFILENAMECHECK;

Se você precisar converter locais de arquivos, ou alterar quaisquer parâmetros de inicialização, você pode
fazer isso durante a duplicate usando o comando Set.

 Copy

DUPLICATE TARGET DATABASE

FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
 SET db_unique_name='duts_stby' COMMENT 'Is standby 19c'
SET db_file_name_convert='/u01/data/duts/','/u02/data/duts/'
SET log_file_name_convert='/u01/data/duts/','/u02/data/duts/'
SET job_queue_processes='0'
NOFILENAMECHECK;

Uma breve explicação das cláusulas individuais é mostrada abaixo.

 FOR STANDBY: Isto informa que o comando DUPLICATE deve ser utilizado para um standby, por isso
não vai forçar uma troca do DBID.

 FROM ACTIVE DATABASE: O DUPLICATE será criado diretamente a partir dos DataFiles de origem, sem
nehum backup adicional.

 DORECOVER: O DUPLICATE incluirá a etapa de recuperação, trazendo o standby até o ponto atual no
tempo.
 SPFILE: Nos permite redefinir valores no SPFile quando ele é copiado do servidor de origem.
 NOFILENAMECHECK: Locais de arquivo de destino não são verificados.

Uma vez que o DUPLICATE está completo, podemos começar a usar o broker.

Ativando Broker

Neste ponto, temos o banco de dados primário e o standby database, então agora precisamos começar a
usar o Data Guard Broker para gerenciá-los. Faça a conexão em ambos databases (primário e standby) e
emitir o seguinte comando.

 Copy

ALTER SYSTEM SET dg_broker_start=true;

No servidor primário, emita o seguinte comando para registrar o servidor primário com o Broker.

 Copy

$ dgmgrl sys/oracle@duts
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue May 11 14:39:33 2019
Version 19.2.0.0.0

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

Welcome to DGMGRL, type "help" for information.

Connected as SYSDBA.
DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS duts CONNECT IDE
Configuration "dg_config" created with primary database "duts"
DGMGRL>

Agora adicione o banco de dados standby.

 Copy
 DGMGRL> ADD DATABASE duts_stby AS CONNECT IDENTIFIER IS duts_stby MAINTAINED A
Database "duts_stby" added
DGMGRL>

Agora vamos ativar a nova configuração.

 Copy

DGMGRL> ENABLE CONFIGURATION;

Enabled.
DGMGRL>

Os comandos a seguir mostram como verificar a configuração e o status dos bancos de dados do Broker.

 Copy

DGMGRL> SHOW CONFIGURATION;

Configuration - dg_config

Protection Mode: MaxPerformance

Members:
duts - Primary database
duts_stby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 26 seconds ago)

DGMGRL> SHOW DATABASE duts;

Database - duts

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

Database Status:
SUCCESS

DGMGRL> SHOW DATABASE duts_stby;

Database - duts_stby

Role: PHYSICAL STANDBY

Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
 Average Apply Rate: 5.00 KByte/s
Real Time Query: OFF
Instance(s):
duts

Database Status:
SUCCESS

DGMGRL>

Database Switchover

Um banco de dados pode estar em um dos dois modos mutuamente exclusivos (Primário ou standby).
Essas funções podem ser alteradas em tempo de execução sem perda de dados ou reset dos redo logs.
Este processo é conhecido como um Switchover e podem ser executadas usando os seguintes comandos.
Conecte-se ao banco de dados primário (duts) e faça o switchover para o banco de dados standby
(duts_stby).

 Copy

$ dgmgrl sys/oracle@duts
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue May 11 14:55:33 2019
Version 19.2.0.0.0

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

Welcome to DGMGRL, type "help" for information.

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

Vamos mudar de volta para o primário original. Conecte-se ao novo primário (duts_stby) e faça o
switchover para o novo banco de dados standby (duts).

 Copy

$ dgmgrl sys/oracle@duts_stby
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue May 11 14:57:20 2019
Version 19.2.0.0.0
 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

Welcome to DGMGRL, type "help" for information.

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

Database Failover

Se o banco de dados primário não estiver disponível, o banco de dados standby poderá ser ativado como
um banco de dados primário usando as instruções a seguir. Conecte-se ao banco de dados standby
(duts_stby) e ao failover.

 Copy

$ dgmgrl sys/oracle@duts_stby
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue May 11 15:00:20 2019
Version 19.2.0.0.0

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

Welcome to DGMGRL, type "help" for information.

Connected as SYSDBA.
DGMGRL> FAILOVER TO duts_stby;
Performing failover NOW, please wait...
Failover succeeded, new primary is "duts_stby"
DGMGRL>

Uma vez que o banco de dados standby é agora o banco de dados primário, deve ser feito um backup
imediatamente do mesmo.

O banco de dados primário original agora pode ser configurado como um standby. Se o flashback
database foi habilitado no banco de dados primário, então isso pode ser feito relativamente facil com o
seguinte comando.

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

 Copy

Se flashback database não estiver ativado, você terá que recriar manualmente d

 Copy

# 1) Cleanup the old instance.

sqlplus / as sysdba <<eof shutdown="" immediate;="" exit;="" eof="" rm="" -rf=
</eof>

Flashback Database

Ele já foi mencionado na seção anterior, mas vale a pena chamar sua atenção para Flashback Database
mais uma vez. Embora um switchover/switchback é seguro para ambos o banco de dados primário e
standby, a failover transforma o banco de dados primário inútil para converter para um banco de dados
em standby. Se flashback database não estiver ativo, o banco de dados primário original deve ser desfeito
e recriado como um banco de dados em standby.

qUma alternativa é habilitar flashback database no banco de dados primário (e o standby se desejado)
assim, no caso de um failover, o primário pode ser feito um flashed back para o um ponto antes do failover
e rapidamente convertido em um banco de dados standby, como mostrado acima.

Criação de application service

Para facilitar a administração de conexões de cliente, e para tornar as operações SWITCHOVER mais
transparentes para os clientes, é recomendável criar serviços no banco de dados.

Exemplo, definição de serviço « DUTSS » :

 Copy
 begin DBMS_SERVICE.CREATE_SERVICE ( service_name => 'DUTSS',
network_name => ' DUTSS ',
failover_method => 'BASIC',
failover_type => 'SELECT',
failover_retries => 180,
failover_delay => 1);
end;
/

Neste caso, há 180 tentativas e um delay de 1 segundo(Então, basicamente 3 minutos antes do switching).
Isto deve ser adaptado dependendo de suas necessidades e exigências.

Este é o serviço que devem ser usados pelo client.

Criando trigger de Startup

Para gerenciar o início automático dos serviços, em especial no caso de uma transição de função, a
seguinte TRIGGER deve ser criado (exemplo para o serviço DUTS). A trigger deve ser criado no SYS:

 Copy

Connect SYS as SYSDBA

CREATE OR REPLACE TRIGGER manage_app_services

AFTER STARTUP
ON DATABASE
DECLARE
role VARCHAR (30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;

IF role = 'PRIMARY'
THEN
DBMS_SERVICE.START_SERVICE ('DUTSS');
END IF;
END;
/

Em seguida, reiniciamos o banco de dados primário para verificar se o serviço foi iniciado:

 Copy

sqlplus / as sysdba
shutdown immediate ;
startup

Conexões de cliente
Para fazer as transições de função (como resultado de um SWITCHOVER ou FAILOVER) transparente para
os usuários do banco de dados a connection string precisa ser configurado com um failover connection
string.

Isso pode ser configurado no TNSNAMES.ORA, configurando dois endereços ou duas descrições para o
mesmo alias. Exemplo de um alias definido para DUTS:

 Copy

DUTS =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))
)
(CONNECT_DATA = (SERVICE_NAME = DUTSS))
)

Com esse método, os clientes tentarão primeiro se conectar ao primeiro endereço (correspondente ao
servidor primário). Se estiver operacional, a conexão é estabelecida com esta base.

Se este primeiro endereço não responde (servidor primário indisponível ou serviços parados), em seguida,
o cliente tenta se conectar ao segundo endereço (apontando para o servidor standby). Se estiver
operacional (que será o caso apenas depois de um SWITCHOVER ou um FAILOVER), em seguida, o cliente
se conectará à base de emergência de forma transparente e automática.

André Luiz Dutra Ontalba , é um Oracle ACE member, formado em Ciências da Computação, é
especialista em Banco de Dados Oracle com sólidos conhecimentos em Engineered Systems, Performance
& Tuning, RAC, Oracle Cloud e Oracle ERP's System; Trabalha com Oracle há 17 anos, certificado OCP
Oracle 11/12g/Cloud e conta com mais de 27 outras certificações em produtos da Oracle. Atualmente
trabalha como Senior Database Architect na Sogeti Luxembourg uma empresa da Capgemini Group. André
é fundador do Grupo de Usuários Oracle de Luxemburgo (LUXOUG). Articulista para o OTN, GPO (Grupo
de Usuários Oracle Brasil) e LUXOUG. Twitter @aontalba / blog www.dbadutra.com/p>

Recursos para Por que a Saiba mais Novidades Entre em

Oracle Contato
Carreiras O que é Oracle
Desenvolvedores Relatórios de computação em CloudWorld Vendas: 0800-891-
Analistas nuvem? Oracle Arm 4433
Investidores
O que é CRM? Processors
Parceiros Gartner MQ para Como podemos
ERP Cloud O que é Docker? Oracle e Premier ajudar?
Startups League
Responsabilidade O que é Inscreva-se para
Estudantes e Corporativa Kubernetes? Oracle Red Bull receber e-mails
Educadores Racing
Diversidade e O que é Python? Eventos
Inclusão
 Práticas de O que é SaaS? Plataforma de Notícias
Segurança Experiência do
Blogs
Funcionário
Oracle Support
Rewards

© 2022 Mapa Termos de Cookie Opções Carreiras

Oracle do Site Uso e Preferences de

País/Região
Privacidade Anúncios