MANUAL ORACLE DATA GUARD 11G/12c

POLO-IT - ADERLAN OLIVEIRA

AMBIENTE:

SISTEMA OPERACIONAL: ORACLE ENTERPRISE LINUX 6.7

SGBD: ORACLE DATABASE 11GR2 11.2.0.4

SALVADOR, 28 DE MARÇO DE 2016

1 - CHECKLIST BÁSICO INCIAL
Como todo projeto, a criação de um ambiente Data Guard traz a quase certeza do sucesso quando
iniciado com checklist de validações. Estas validações prévias estão a seguir. Nem todas são pré-
requisitos, mas todas proverão vantagem ao cliente.
Faça os seguintes questionamentos - se necessário e possível, corrija ou adote a solução:
QUESTIONAMENTO MANDATÓRIO? AÇÃO
Os servidores possuem as NÃO. Se não, recomende ao
mesmas características de cliente que adeque,
hardware? partindo do suposto que
os componentes de um
ambiente DG devem
estar sempre aptos a
assumirem as roles
PRIMARY ou STANDY.
O banco PRIMARY está em SIM SE NÃO estiver, ative
modo archive? imediatamente,
configurando além da
máscara e
LOG_ARCHIVE_DESTE_1,
o ARCHIVE_LAG_TARGET
= 600
O banco está em modo NÃO Se não estiver, Ative –
FLASHBACK? justificativa e instrução
no item
As máquinas se enxergam SIM SE NÃO, configure o DNS
pela rede? Resolver os ou o /etc/hosts.
respectivos nomes e os
nomes alheios?
O PRIMARY está em modo SIM Se não estiver, ative. Veja
FORCE LOGING? item

2 – CONFIGURAR COMUNICAÇÃO ENTRE HOSTS – RESOLUÇÃO DOS HOSTNAMES

As preparações dos servidores não demandam muito esforço técnico, mas precisam ser feitos e
validados com cuidado.
Para este tutorial, partiremos do suposto que os binários estão instalados em ambos os servidores
e que no primeiro, o banco será um banco de produção já ativo. Também assumiremos como
verdade que o ambiente está será configurado em SO Oracle Linux 6.7.
2.1 - Edite do /etc/hosts
É imprescindível que as máquinas se ‘enxerguem’ via rede. Sendo assim, editaremos o /etc/hosts
informando em ambos tanto seu próprio nome quanto do host que abrigará o segundo banco.
Documente através de comentário na entrada. Abaixo, no exemplo, o que chamamos de fal
server é o servidor remoto. Faça o comentário da mesma forma no ambiente secundário, pois
quando este assumir a role PRIMARY, saberemos quem é seu AUXILIARY.
Ressaltando que se o cliente tiver um DNS confiável, esta etapa pode ser desconsiderada.
2.2 Teste via ping no hostname e via ssh.

3 - RELAÇÃO DE CONFIANÇA CRUZADA

A relação de confiança não é um pré-requisito para Data Guard, mas recomendamos que seja
feito para auxiliar em atividades que demandem a troca de arquivos, como por exemplo quando
o AUXILIARY necessitar ser refeito por motivo de failover e tivermos que copiar peças de backup.
3.1 - Gere chave com usuário oracle:
$ ssh-keygen -t rsa -f ~/.ssh/id_rsa
3.2 - Inserir no host secundário
$ cat ~/.ssh/id_rsa.pub | ssh oracle@192.168.0.5 'cat - >> ~/.ssh/authorized_keys'
3.3 - Teste acessando via ssh ou transferindo arquivo ao outro host e confirme se pede senha.

4 - ATIVAÇÃO DO MODO ARCHIVE NO PRIMARY.

4.1 - Configure o local onde os archives serão salvos:

alter system set log_archive_dest_1='LOCATION=/u03/archive/database1';

4.2 - Edite a máscara dos archives para .arc:

alter system set log_archive_format='%t_%s_%r.arc' scope = spfile;

4.3 – Altere o parâmetro LAG_ARCHIVE_TARGET para 600 (força o arquivamento de 10/10

minutos).
Alter system set archive_lag_target=600;
3 – ATIVAR O MODO FLASHBACK NO PRIMARY
A ativação do flashback não é mandatório, mas além de uma excelente prática que
permitirá retornar o banco a estados antigos sem necessidade de restore, a ativação do
modo flashback viabilizará o uso do ACTIVE DATAGUARD. Há o contra-argumento de que
haverá perda de desempenho, mas também devemos considerar que um cliente que tem
recurso financeiro para adquirir uma licença Enterprise + Data Guard, provavelmente terá
uma boa ou excelente infraestrutura de discos, o que viabilizará esta ativação de modo a
não haver impacto em seu ambiente produtivo.
3.1 - Ative e configure o tamanho e diretório da FRA:
SQL> alter system set db_recovery_file_dest_size=10g;

SQL> alter system set db_recovery_file_dest='/u03/backup/';

3.2 - Ative o modo flashback

alter database flashback on;

4 – ATIVAÇÃO DO MODO FORCE LOGGING.

SQL> alter database force logging;

5 - PREPARAÇÃO DO AMBIENTE QUE ABRIGARÁ O STANDBY

Antes da criação do banco/instância que abriga, precisaremos determinar a arquitetura do
ambiente. No cenário hipotético, nosso ambiente de produção inicial (PRIMARY) tem os seguintes
parâmetros:
INSTANCE_NAME = PROD

DB_UNIQUE_NAME = DATABASE1

DB_NAME = DATABASE

Esta fuga do cotidiano é proposital, para que o conceito de Data Guard se torne mais claro. Para
ter sucesso na configuração do ambiente, é preciso entender os conceitos de cada um destes
parâmetros e como deve/pode ser tratado no ambiente DG.
INSTANCE_NAME = O nome da instância. Em dataguard, CADA membro PODERÁ ter sua instância
DIFERENTE.
DB_UNIQUE_NAME = Nome único do banco. Em dataguard, CADA membro DEVERÁ ter sua
DB_UNIQUE_NAME DIFERENTE
DB_NAME = Nome Global do banco de dados. Em dataguard, TODOS os membros DEVERÃO o
mesmo DB_NAME.
Sendo assim, adotaremos a seguinte estrutura de ambiente:
MEMBRO: PRIMARY STANDBY
HOSTNAME: vm-lnx-lab04 vm-lnx-lab05
IP: 192.168.168.184 192.168.168.185
INSTANCE_NAME: PROD PROD
DB_UNIQUE_NAME: DATABASE1 DATABASE2
DB_NAME: DATABASE DATABASE
DIRETÓRIO DE DATA FILES /u02/oradata/DATABASE1/ /u02/oradata/DATABASE2/
Tendo definido nossa estrutura, no segundo servidor, crie uma instância e banco já com os
parâmetros descritos na coluna 2. Ele será descartado, mas a recomendação da criação é para
que haja uma validação prévia do ambiente.

6 - PREPARAÇÃO O ORANET
O transporte de informação de forma bilateral do ambiente Data Guard funciona totalmente
suportado pelo ORANET. Um dos segredos tanto da restauração do backup quanto no
funcionamento impecável está na configuração correta e validada do ORANET. Tome por verdade
e lembre: A comunicação deve ser uma mão via dupla, tendo que funcionar tanto PRIMARY ->
AUXILIARY quanto AUXILIARY – PRIMARY.
6.1 CRIAÇÃO DE LISTENER EXPLÍCITO
A criação do listener explícito, futuramente permitirá a configuração e utilização de Data Guard
Broker – Esta é uma excelente ferramenta, que permite além de administrar todo o ambiente
DG, repara-lo e configura-lo, removendo ou adicionando novos membros ou alterando a
característica do mesmo. Entendemos que o ambiente deverá ser preparado para qualquer nova
configuração, evitando indisponibilidades caso futuramente estas opções sejam assumidas pelo
cliente. Da mesma forma, evitaremos questionamentos desnecessários.
https://docs.oracle.com/cd/B28359_01/server.111/b28295/concepts.htm
6.1.1 - Para isso, edite os arquivos $ORACLE_HOME/network/admin/listener.ora em ambos os nós–
caso não existam, crio-os.
Adicione o seguinte bloco, adaptando-o às características do ambiente:
LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = vm-lnx-lab05)(PORT = 1521))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = DATABASE2)

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

(SID_NAME = PROD)

(SID_DESC =

(GLOBAL_DBNAME = DATABASE1)

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

(SID_NAME = PROD)

)
)

Note que o listener explicita ambos os membros.

6.1.2 – Pare os listeners de cada membro e inicio-os, verificando o serviço provido por cada um:
Lsnrctl stop
Lsnrctl start
lsnrctl status
lsnrctl services

Lembre que o SMON (se versão =< 11G) ou LREG (12c) demoram para registrar as instâncias.
Aguarde um pouco ou entre em cada instância e:
SQL> alter system register;

6.2 – EDIÇÃO DO TNSNAMES.ORA

6.2.1 – Edite o tnsnames.ora
Insira no tnsnames.ora de ambos os servidores o mesmo bloco. Note que a referência é cruzada
e que o aliás deverá ser informado como db_unique_name de ambos, pois é este parâmetro que
proverá o service nos respectivos listeners e que também será usado nos parâmetros do
ambiente.
DATABASE1 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = vm-lnx-lab04)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = DATABASE1)

(UR=A)

DATABASE2 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = vm-lnx-lab05)(PORT = 1521))

(CONNECT_DATA =
 (SERVER = DEDICATED)

(SERVICE_NAME = DATABASE2)

(UR=A)

6.2.2 - Teste a conexão a partir de cada host de forma cruzada:

Utlize o Sql Plus e o tnsping para validar a confiugração.

7 – GERAÇÃO DE BACKUP MATRIZ.

7.1 - NO PRIMARY, crie um arquivo para geração de backup utilizando bloco abaixo.
Para isso, edite no bloco do RMAN as seguintes configurações:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3; (Escolher a quantidade de canais)
CONFIGURE COMPRESSION ALGORITHM 'HIGH'; (BASIC, LOW, MEDIUM OU HIGH).
run
{

configure channel device type disk maxpiecesize 5G format '$DEST/backupset/%d_full_%U.bak';

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;

backup current controlfile for standby format '$DEST/backupset/control_dataguard_%d_%U.bkp';

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '$DEST/controlfile/%F';

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

sql "alter system switch logfile";

backup AS COMPRESSED BACKUPSET database include current controlfile tag 'full backup com controlfile';

sql "alter system switch logfile";

Caso já haja um backup e não seja possível atualizar este por alguma razão, gerar standby
controlfile através do banco de produção:
SQL> alter database create standby controlfile as '/u03/backup/fisico/controlfile/control01.ctl'
LEMBRE: Se é dataguard, é enterprise, e se é enterprise, pode se usar parallelism e compressão
avançada no backup RMAN
Para isso, deve inserir ou editar no bloco do RMAN:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3; (Escolher a quantidade de canais)
CONFIGURE COMPRESSION ALGORITHM 'HIGH'; (BASIC, LOW, MEDIUM OU HIGH).
7.2 – Transfira o backup para partição semelhante no servidor que abrigará o STANDBY.

8 – CRIAÇÃO DO STANDBY.

Com sucesso da primeira etapa da preparação de ambos os ambientes, partiremos agora para a
criação do dataguard. Assim como a criação de um standby comum, o Data Guard precisa ser
feito através do RMAN ou de qualquer técnica de restauração física, como restore a frio, por
exemplo. No entanto, como este documento tem como objetivo servir de guia adaptado para os
ambientes de produção monitorados pela Polo-iT, abordaremos as duas técnicas mais viáveis,
sendo RMAN HOT BACKUP/RESTORE e RMAN DUPLICATE. Nesta versão do manual, iniciaremos
com o RMAN DUPLICATE
8.1 – Desligue através de shutdown abort o banco STANDBY:
SQL> Shut abort

8.2 – Limpe os dados da instância e banco criado para validação e teste.

Remova os arquivos orapwd e spfile/init e controlfiles do diretório $ORACLE_HOME/dbs banco
que foi criado anteriormente. Desta forma, criaremos um ambiente fidedigno ao ambiente de
produção caso este tenha parâmetros específicos. Além disso, também configuraremos a
memória da mesma forma, evitando problemas de desempenho em caso de SWITCHOVER ou
FAILOVER.
8.3 – No PRIMARY, crie um pfile pelo spfile
SQL> Create pfile from spfile

8.4 – NO PRIMARY, se não houver, crie um arquivo de senha:

$ orapwd file=orapwPROD password=senha_sys

8.4 – Copie os arquivos de configuração e senha:

Copie do PRIMARY do diretório $ORACLE_HOME/dbs para o mesmo diretório no STANDBY o pfile
e o arquivo de senha gerados anteriormente.
8.5 – Parametrize a nova instância
No STANDBY, edite o init renomeando-o, alterando os parâmetros de forma a se adequarem ao
ambiente corrente, tal como diretório de DIAGNOSTIC_DEST, LOG_ARCHIVE_DEST,
CONTROL_FILES, entre outros.
****!atenção! – edite o db_unique_name para o novo nome.****
*.db_unique_name='DATABASE2'
8.6 – Inicie a instância em NOMOUNT.
SQL> startup nomount;
8.7 – Crie um spfile e reinicie em nomount.
SQL> create spfile from pfile;

SQL> shut immediate;

SQL> startup nomount;

Nota: Outros parâmetros poderiam ser alterados já aqui, mas por segurança e também como
forma de validação, alteraremos posteriormente via SPFILE.
8.8 – Defina o local de armazenamento dos datafiles no PRIMARY e no STANDBY.
NO PRIMARY:
alter system set log_file_name_convert='/u02/oradata/DATABASE2/','/u02/oradata/DATABASE1/' scope = spfile;

alter system set db_file_name_convert='/u02/oradata/DATABASE2/','/u02/oradata/DATABASE1/' scope = spfile;

Não são dinâmicos, reinicie a instância.

NO STANDBY:
alter system set log_file_name_convert='/u02/oradata/DATABASE1/','/u02/oradata/DATABASE2/' scope = spfile;

alter system set db_file_name_convert='/u02/oradata/DATABASE1/','/u02/oradata/DATABASE2/' scope = spfile;

Não são dinâmicos, reinicie a instância EM NOMOUNT

Estes parâmetros não são pré-requisitos, mas sua configuração permitirá a restauração sem
preocupação com set new name ára data files e temp files (db_file_name_convert) e para redo logs
(log_file_name_convert). Além disso, na criação de datafiles/redologs futuros, os mesmos já serão
redirecionados para a partição que definirmos. No primeiro parâmetro, estamos ‘dizendo’ ao
banco: “O que for criado em /u02/oradata/DATABASE2/ do meu host remoto, redirecione para
/u02/oradata/DATABASE1/”. Veja abaixo um exemplo onde criamos um datafile no PRIMARY
para a tablespace USERS e observe o comportamento no STANDBY em um ambiente já
configurado e validado.

Dicas importantes sobre o convert:

Caso seja feito para um ambiente com diretórios similares, pode-se

CRIAÇÃO NO PRODUÇÃO:

LOG DO STANDBY
Este parâmetro aceita diversos diretórios como argumento (vide documentação).
https://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams048.htm#REFRN10038

8.9 - Ative a criação automática de datafiles

Tanto no PRIMARY quanto no STANDBY:
SQL> alter system set standby_file_management=auto;

Este parâmetro é dinâmico. Com esta configuração, não precisamos nos preocupar em criar
manualmente os datafiles no standby quando criados no PRIMARY.

9 – DUPLICAÇÃO DO BANCO

9.1 - Através do PRIMARY, conecte tanto no PRIMARY quanto no STANDBY

$ rman target / AUXILIARY=sys/oracle@DATABASE2

Onde:
Target / é nossa conexão local (PRIMARY).
$ rman AUXILIARY=sys/oracle@DATABASE2 é nossa conexão com o standby.
!ATENÇÃO! – Aqui, recomendo ver o nome do banco – o RMAN retornará em database e auxiliary
o valor de db_name. No exemplo acima, conectamos apenas para exemplo, mas o status na linha
deverá ser not mounted. Caso contrário, estará conectado em um
banco de produção ou possivelmente não deixou o STANDBY no mount.
9.2 – Duplique o banco
DUPLICATE TARGET DATABAE FOR STANDBY DORECOVER;

Nota: Tanto a conexão quanto o comando podem ser postos em um sh. Assim, poderá ser
executado em nohup.
Ainda sobre o DUPLICATE, caso os ambientes sejam fiéis, poderá ser restaurado da seguinte
forma: DUPLICATE TARGET DATABAE FOR STANDBY DORECOVER NOFILENAMECHECK;
O parâmetro NOFILENAMECHECK ignora a conversão ou verificação do path.
9.3 – Valide o log de restore.

10 – PARAMETRIZAÇÃO FINAL

10.1 - Defina os membros compositores do DG

Após o sucesso do recover, altere o parâmetro log_archive_config conforme abaixo, informando
as entradas no tnsnames.ora que identifica ambos. Use exatamente o mesmo valor tanto no
PRIMARY quanto no STANDBY.
SQL> alter system set log_archive_config='DG_CONFIG=(DATABASE1,DATABASE2)';

10.2 – Configure os novos destinos de de archive no PRIMARY e no STANDBY.

ALTERE O LOG_ARCHIVE_DEST_1 E LOG_ARCHIVE_DEST_2 tanto no PRIMARY quanto no
STANDBY, fazendo referência inversa

NO PRIMARY:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u03/archive/database1/
valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DATABASE1';

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=DATABASE2 ASYNC VALID_FOR=

(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DATABASE2';

NO STANDY:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u03/archive/database2/
valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DATABASE2';

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=DATABASE1 ASYNC VALID_FOR=

(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DATABASE21';

10.3 – Defina as roles atuais

Informe a ambos as ROLES atuais, definindo o segundo host como fal_server e a sim próprio como
fal_client.
NO PRIMARY:
alter system set fal_client=DATABASE1;

alter system set fal_server=DATABASE2;

NO STANDY:
alter system set fal_client=DATABASE2;

alter system set fal_server=DATABASE1;

Este parâmetro em conjunto com os log_archive_dest_n definem a arquitetura do Data Guard,

por exemplo, quando houver standby cascade em arquitetura vertiral ou horizontal.
10.4 - Habilite a geração/envio de archives
No PRIMARY e no STANDBY.
log_archive_dest_state_1='ENABLE';

log_archive_dest_state_2='ENABLE';

10.5 – Monte o banco STANDBY e inicie o recover

Como o banco estará em mount por conta do RMAN DUPLICATE que o põe assim
automaticamente, desligue-o.
SQL> shut immediate;
SQL> startup nomount;

SQL> alter database mount standby database;

SQL> alter database recover managed standby database using current logfile disconnect;
10.6 – Adicione standby redo logs
No PRIMARY adicione standby redo logs. Para saber a quantidade necessária, consulte a
quantidade de grupos do banco PRIMARY e adicione mais um a conta. Sobre o tamanho, deverão
ser iguais.
Supondo que o banco de produção tenha 3 grupos de redo de 50Mb:

SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 50M;

11 – ATIVAÇÃO DO MODO FLASHBACK NO STANDBY

Se a recomendação de ativação do modo flashback no ambiente foi acatada, ative nesta etapa
no banco STANDBY (caso não esteja).
11.1 - Pare a recuperação automática
SQL> alter database recover managed standby database cancel;

11.2 - Ative e configure o tamanho e diretório da FRA

SQL> alter system set db_recovery_file_dest_size=10g;

SQL> alter system set db_recovery_file_dest='/u03/backup/';

11.3 - Ative o modo flashback

SQL> alter database flashback on;

11.4 - Retome a aplicação automática

SQL> alter database recover managed standby database disconnect from session;

9 - SWITCHOVER / SWITCHBACK – VALIDAÇÃO DO AMBIENTE.

Mediante o sucesso da criação do ambiente, devemos agora fazer o teste de switchover /
switchback. Este teste é indispensável, tendo em vista que em cenários de FAILOVER / FAILBACK
temos que ter certeza e segurança que funcionará.
Todos os passos a seguir deverão ser executados mediante acompanhamento dos respectivos
alert logs do PRIMARY e do STANDBY:
9.1 – SWITCHOVER
9.1.2 - No PRIMARY e no STANDBY, verifique o status para troca das roles:
SQL> select switchover_status from v$database; --Esperado TO STANDBY OU ACTIVE SESSION para o primary e NOT
ALLOWED no standby:
9.1.3 – No PRIMARY, habilite-o a assumir a role STANDBY e verifique novamente o status em
AMBOS.
***ATENÇÃO**** Esta execução derrubará o banco PRODUÇÃO.
EM AMBOS:

SQL> SELECT I.INSTANCE_NAME, D.NAME, P.VALUE FROM V$INSTANCE I, V$DATABASE D, v$parameter P WHERE
P.name='db_unique_name';

SQL> select switchover_status from v$database; --Esperado banco off para produção e SESSIONS ACTIVE para STANDBY

NO ATUAL PRIMARY:

SQL> alter database commit to switchover to physical standby with session shutdown;

9.1.4 – MONTE O PRIMARY como STANDBY DATABASE e, novamente, check os status de ambos.

NO ATUAL PRIMARY:

SQL> startup nomount

NO ATUAL PRIMARY:

SQL> alter database mount standby database

EM AMBOS:

SQL> SELECT I.INSTANCE_NAME, D.NAME, P.VALUE FROM V$INSTANCE I, V$DATABASE D, v$parameter P WHERE
P.name=’db_unique_name;

SQL> select switchover_status from v$database; -- RECOVERY NEEDED para produção e SESSIONS ACTIVE para
STANDBY

9.1.4 – Permita a mudança de role do STANDBY para PRIMARY, abra o banco inicie o recover no
antigo PRIMARY
NO STANDBY:
SELECT I.INSTANCE_NAME, D.NAME, P.VALUE FROM V$INSTANCE I, V$DATABASE D, v$parameter P WHERE
P.name='db_unique_name'

SQL> alter database commit to switchover to primary with session shutdown;

SQL> alter database open;

NO ANTIGO PRIMAY

SQL> alter database recover managed standby database disconnect from session;

-- No oracle 11 ou < usar:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

9.1.4 – Confirme as roles em ambos e teste o switch.

EM AMBOS:
SQL> select database_role from v$database; --Esperado PHYSICAL STANDBY no antigo PRIMARY
e PRIMARY no antigo STANDBY
No atual PRIMARY, faça o switch de logs e acompanhe ambos os alerts. Mensagem esperada no
STANDBY:

NO PRIMARY:

9.2 – SWITCHBACK
É comum que um ambiente possa fazer switchover e não consiga executar o switchback
– Estes erros normalmente estão relacionados a configuração do ORANET ou parâmetros
errados. Para evitar que haja um erro fatal em um possível evento de
FAILOVER/FAILBACK, refaça a operação acima, desta vez retornando o servidor original a
ROLE de PRIMARY.

10 – Configuração do serviço e do oranet.

Infelizmente o oracle não oferece uma opção para switchover e switchback no que diz respeito
ao tnsnames.ora, mas apenas para casos de failover e failback. A diferença é que no caso do
failover, o cliente não encontrará o stream referente ao serviço do oracle e por isso o bloco
padrão de tns funciona, mas caso se faça um switchover, haverá erro porque o primeiro
tratamento não é entendido como um timeout. Veja abaixo um bloco funcional de failover:

ORCLT =

(DESCRIPTION_LIST =

(FAILOVER = ON)

(LOAD_BALANCE = OFF)

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.100.9.111)(PORT = 1521))

(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)

(CONNECT_DATA = (SERVICE_NAME =orcl.santacasaba.local)(SERVER = DEDICATED))

(DESCRIPTION =

(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.100.9.110)(PORT = 1521))

(CONNECT_DATA = (SERVICE_NAME = orcldg.santacasaba.local)(SERVER = DEDICATED))

)
No caso acima, a conexão só irá mudar para o host alternativo caso o acesso ao primário esteja completamente
inviável.

Uma solução para resolvermos esse problema é a configuração de um serviço que só será iniciado através de uma
trigger de startup e caso o banco atual seja o primary:

Criação do serviço:

exec dbms_service.create_service('svc_orcl','svc_orcl');

Criação da trigger que irá verificar a role atual e iniciar o serviço (o defer/enable do log_archive_dest é opcional):

create or replace trigger poloit_ativa_service_dg after startup on database

declare

v_role varchar(30);

begin

select database_role into v_role from v$database;

if (v_role = 'PRIMARY') then

dbms_service.start_service('svc_orcl');

end if;

execute immediate 'alter system set log_archive_dest_state_2=defer';

execute immediate 'alter system set log_archive_dest_state_2=enable';

end;

Entrada para o tnsnames.ora que conectará independentemente do tipo de switch (se failover ou switchover):
ORCL =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.100.9.111)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.100.9.110)(PORT = 1521)))

(CONNECT_DATA =

(SERVICE_NAME = svc_orcl)))

11 – ACTIVE DATA GUARD

Partindo do pressuposto de que o ambiente está pronto e replicando, para se ativar o active dataguard, execute no banco standby:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

ALTER DATABASE OPEN;

SELECT OPEN MODO FROM V$DATABASE;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
 O QUE VEM A SEGUIR:

- Troubleshooting de erros comuns;

- Desfazendo o data guard;

- Ações imediatas para restabelecimento;

- Cascade standby (vertical e horizontal);

- Controle de archives;

- Modos de proteção e suas respectivas intervenções peculiares;

- Data Guard + RAC.