Treinamento Data Guard

Oracle Data Guard – Implementação & Manutenção
Introdução

Visão Geral
 Este workshop destina-se a profissionais que
buscam aprender e/ou aprimorar seus
conhecimentos com o Oracle Data Guard.
 É desejável que se tenha o mínimo de conhecimento
da arquitetura de banco de dados Oracle, nas
versões 11g ou 12c.
 O objetivo do workshop é mostrar as principais
funcionalidades do processo de Data Guard, bem
como o processo de implementação, administração
e manutenção.
2

Objetivos do Treinamento
 Neste workshop você vai aprender:
 Criar um ambiente de replicação com o Data Guard.
 Físico.
 Lógico.
 Snapshot Standby
 Gerenciar o Data Guard.
 Executar operações de teste (switchover).
 Executar operações em desastres (failover).
 Recuperar cenários de desastres (failback).
 Otimizar o gerenciamento com o Data Guard Broker.
3

Agenda
4
 O Data Guard.
 Data Guard Físico.
 Data Guard Broker (overview).
 DGMGRL (configuração).
 Data Guard Físico (via OEM).
 Data Guard Lógico.
 Modos de Proteção.
 Monitoramento.
 Otimização.
 Data Guard & Flashback.
 Role Trasictions.
 Fast Start Failover.
 Snapshot Database.
 Active Data Guard.
 Backup & Restore.
 Conectividade dos clientes.

Instrutor
 Douglas Paiva de Sousa
 Oracle Instructor – Oradata Cons. e Treinamentos
 Oracle WDP Instructor – KaSolution
 Oracle WDP Instructor – Grupo Impacta
 http://douglasdba.wordpress.com
 http://douglasdba.profissionaloracle.com.br
 http://www.oradata.com.br/blog
http://br.linkedin.com/in/dpsdba/ @oradatact
5
/oradata

Data Guard
Overview

Neste Capítulo
 Neste capítulo você vai aprender:
 Arquitetura básica do Data Guard.
 Diferenças entre o Data Guard físico, lógico e snapshot
 Benefícios de se implementar o Data Guard.
7

Tipos de Data Guard
 Data Guard Físico (Physical Standby Database)
 Cópia exata de um database (bloco a bloco).
 Sincronizado através dos archived redologs vindos do
banco de dados primário.
 Pode ser usado para relatórios em paralelo com o
ambiente de produção.
 Data Guard Lógico (Logical Standby Database)
 Compartilha as mesmas definições de schema.
 Sincronizado através dos comandos SQL que são
executados no ambiente primário.
 Pode ser usado em paralelo com a produção para
relatórios e upgrades.
9

Tipos de Data Guard
 Snapshot Standby Database.
 Banco dados standby completamente “alterável”.
 Criado através da conversão de um Data Guard Físico.
 Atualizações locais são descartadas, quando o banco
de dados volta a ser um standby físico.
10

Tipos de Serviços
 Data Guard oferece três tipos de serviços:
 Redo transport services
 Apply Services
 Redo Apply
 SQL Apply
 Role management services.
11

Troca de Papeis
(role trasitions)
O Data Guard suporta dois tipos de “role transitions”:
 Switchover:
 “O primeiro vira segundo e o segundo vira primeiro”.
 Para manutenções planejadas (exemplo SO, hardware).
 Failover:
 Usada em caso de desastres (emergências).
 Situações não planejadas.
 Zero ou mínima parda de dados (depende da opção
escolhida).
 Pode ser executada automaticamente (com o fast-start-
failover).
12

Ferramentas de Administração
 Administração de um Data Guard pode ser feita:
 Com Data Guard Broker:
 DGMGRL (linha de comando).
 Enterprise Manager Grid/Cloud Control.
 Comandos SQL (direto no banco de dados).
 Sem o Data Guard Broker:
 Comandos SQL (direto no banco de dados).
14

Arquitetura (overview)
15
Primary
database
transactions
Online
redo
logs
ARC0
RFS
MRP or
LSP
Archived redo
logs
ARC0
Standby
database
Reports
Standby
redo logs
Archived redo
logs
Oraclenet
LNSn
(Real-time
apply)
LGWR
Redo
buffer
Gap resolution

Data Guard Físico
16
Produção Standby

Data Guard Lógico
17
Redo transport
Transform redo
information into
SQL
SQL Apply
Reports
Produção Standby

Resolvendo Gaps
18
Produção
Online
redo
logs
ARC0
RFS
MRP or
LSP
ARC0
Standby
Reports
Standby
redo logs Backup
Oraclenet
LNSn
(Real-time
apply)
LGWR
Redo
buffer
ARCH ping
Redo to
resolve gap

Métodos de Proteção
 No Data Guard você vai precisar escolher o melhor
método de proteção de seus dados, baseando-se
em um de três pilares “custo”, “disponibilidade” e
“performance”:
 Máxima Proteção.
 Máxima Disponibilidade.
 Máxima Performance.
19

SO, Hardware e Software
 No Data Guard é recomendável que o servidor
primário seja igual ao servidor secundário, mas
caso não seja possível, alguns componentes pode
ser diferentes, como:
 Arquitetura de CPU.
 Sistema Operacional.
 Binários do sistema operacional (32-bit ou 64-bit).
 Binários do banco de dados (32-bit ou 64-bit).
20

SO, Hardware e Software
 O que deve ser igual:
 O mesmo release do Oracle Database Enterprise
Edition deve ser instalado nos dois servidores.
 Se em algum servidor você usar ASM ou OMF, o mesmo
deve ser feito no outro servidor.
21

Benefícios de Data Guard
 Com o Data Guard você ganha:
 Continuidade no negócio em caso de desastres.
 Proteção contra perda e corrupção de dados.
 Elimina a replicação “ativo-passivo”.
 Configuração flexível de acordo com as necessidades
do negócio, seja proteção ou recuperação.
 Gerenciamento centralizado.
22

Resumo
 Neste capítulo foi abordado:
 Arquitetura básica do Data Guard.
 Diferenças entre o Data Guard físico, lógico e snapshot
 Benefícios de se implementar o Data Guard.
23

Data Guard
Físico

Neste Capítulo
 Configurar o servidor primário juntamente com a
camada de redes (Oracle Net Services) para suportar
a criação do servidor standby e o processo de “role
trasiction”.
 Criar a instancia de banco de dados no servidor
standby utilizando o RMAN.
25

Processo de criação
Para criar um Standby Database Físico:
 Prepare o servidor primário.
 Defina os parâmetros no servidor Standby.
 Configure a camada de redes (listener e tnsnames).
 Inicialize a instancia standby.
 No RMAN execute DUPLICATE TARGET DATABASE...
 Inicialize o processo de transporte e aplicação dos arquivos
de redo log.
26

Servidor Primário
Pré-requisitos do servidor primário:
 Habilitar o “FORCE LOGGING” na instancia.
 Criar um arquivo de senhas (se necessário).
 Criar os standby redo logs.
 Definir os parâmetros do SPFILE.
 Colocar a instancia no modo ARCHIVELOG.
27
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG
SQL> ALTER DATABASE OPEN

Servidor Primário
Modo FORCE LOGGING:
 Recomendado para garantir a consistência dos dados.
 Força a geração de redo log, até mesmo para operações
NOLOGGING.
 Não “loga” tablespace temporária e seus segmentos.
 É recomendado tanto para standby físico quanto logico.
 Para habilitar execute o comando:
28
SQL> ALTER DATABASE FORCE LOGGING

Servidor Primário
Standby Redo logs:
29
Redo log servidor primário
RFS ARC0
Standby
redo logs
Archived
redo logs
MRP/LSP
STANDBY
DATABASE

Servidor Primário
Standby Redo logs:
 Criando os standby redo logs com o SQL*Plus:
30
SQL> ALTER DATABASE ADD STANDBY LOGFILE
2 '/u01/app/oracle/oradata/orcl/srl01.log'
3 SIZE 50M;
Database altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE
2 '/u01/app/oracle/oradata/orcl/srl02.log'
3 SIZE 50M;
Database altered.

Servidor Primário
Standby Redo logs (consultando os metadados):
31
SQL> SELECT group#, type, member FROM v$logfile
2 WHERE type = 'STANDBY';
GROUP# TYPE MEMBER
------ ------- ------------------------------------------
4 STANDBY /u01/app/oracle/oradata/pc00prmy/srl01.log
SQL> SELECT group#, dbid, thread#, sequence#, status
2 FROM v$standby_log;
GROUP# DBID THREAD# SEQUENCE# STATUS
---------- ---------- ---------- ---------- ----------
4 UNASSIGNED 0 0 UNASSIGNED

Servidor Primário
Parâmetros de inicialização SPFILE:
32
Parâmetro Descrição
LOG_ARCHIVE_CONFIG Recebe o db_unique_name dos bancos
de dados envolvidos no Data Guard.
LOG_ARCHIVE_DEST_n Controla o serviço de transporte dos
redo logs.
LOG_ARCHIVE_DEST_STATE_n Especifica o estado do destino dos
redo logs.
ARCHIVE_LAG_TARGEET Força um switch de log após um
determinado período (em segundos).
LOG_ARCHIVE_TRACE Controla o output dos processos de
archive.

Servidor Primário
Parâmetro LOG_ARCHIVE_CONFIG:
 Neste parâmetro, informe o atributo DG_CONFIG
mais o DB_UNIQUE_NAME do servidor primário e
os demais DB_UNIQUE_NAME do servidor(es)
standby.
33
SQL> ALTER SYSTEM SET
LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIM,STBY)'

Servidor Primário
Parâmetro LOG_ARCHIVE_DEST_n
 Use este parâmetro para:
 Archivelogs local (se não estiver usando a FRA).
 Incluir ao menos um destes atributos:
 LOCATION: Especifique um caminho válido.
 SERVICE: Aliás de TNSNAMES que referencie um standby
database.
 Inclua um LOG_ARCHIVE_DEST_STATE_n para cada um dos
LOG_ARCHIVE_DEST_n.
34
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=
‘SERVICE=STBY
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=STBY’;
SQL> LOG_ARCHIVE_DEST_STATE_1=ENABLE;

Servidor Primário
Role Base Destinations:
35
log_archive_dest_1 =
'service=STBY async
valid_for=
(online_logfile,
primary_role)
db_unique_name=STBY'
SERVIDOR
PRIMÁRIO
SERVIDOR
STANDBY
log_archive_dest_1 =
'service=PRIM async
valid_for=
(online_logfile,
primary_role)
db_unique_name=PRIM'

Servidor Primário
Parâmetro VALID_FOR (Combinações):
36
Combinação Primário Standby
Físico
Standby
Lógico
ONLINE_LOGFILE, PRIMARY_ROLE Valid Ignored Ignored
ONLINE_LOGFILE, STANDBY_ROLE Ignored Ignored Valid
ONLINE_LOGFILE, ALL_ROLES Valid Ignored Valid
STANDBY_LOGFILE,STANDBY_ROLE Ignored Valid Valid
STANDBY_LOGFILE, ALL_ROLES Ignored Valid Valid
ALL_LOGFILES, PRIMARY_ROLE Valid Ignored Ignored
ALL_LOGFILES, STANDBY_ROLE Ignored Valid Valid
ALL_LOGFILES, ALL_ROLES Valid Valid Valid

Servidor Primário
Definindo o modo de transporte dos redo logs:
 No parâmetro LOG_ARCHIVE_DEST_n use:
 SYNC ou ASYNC
 Indica se as operações de rede serão executadas de maneira
síncrona ou assíncrona pelo LGWR (default ASYNC).
 AFFIRM ou NOARFFIRM
 Garante que o arquivo de redo log, foi escrito com sucesso
no disco do servidor standby.
 NOAFFIRM é o padrão quando ASYNC está em uso e
AFFIRM é o padrão quando SYNC está em uso.
37

Servidor Primário
Parâmetros de Storage:
 Use estes parâmetros apenas quando as estruturas de
discos entre os servidores primário e standby forem
distintas.
38
Parâmetro Descrição
DB_FILE_NAME_CONVERT Converte a localização dos datafiles.
LOG_FILE_NAME_CONVERT Converte a localização dos arquivos de
redo log.
STANDBY_FILE_MANAGEMENT Controla automaticamente o
gerenciamento de arquivos entre os
servidores.

Servidor Primário
DB_FILE_NAME_CONVERT
 Deve ser definido quando os servidores possuem
estruturas de storage diferenciadas para os datafiles.
 Múltiplos pares podem ser adicionados ao mesmo
parâmetro.
 Usado somente em standby databases físicos.
 Pode ser usado também no comando DUPLICATE do rman.
39
SQL> ALTER SYSTEM SET DB_FILE_NAME_CONVERT =
(‘/disk1/oradata/prod/’, ‘/disco1/oradata/stby/’,
‘/disk2/oradata/prod/’, ‘/disco2/oradata/stby/’);

Servidor Primário
LOG_FILE_NAME_CONVERT
 Deve ser definido quando os servidores possuem
estruturas de storage diferenciadas para os arquivos de
redo log.
 Múltiplos pares podem ser adicionados ao mesmo
parâmetro.
 Usado somente em standby databases físicos.
 Pode ser usado também no comando DUPLICATE do rman.
40
SQL> ALTER SYSTEM SET LOG_FILE_NAME_CONVERT =
(‘/disk1/oradata/logs/’, ‘/disco1/oradata/logs/’);

Servidor Primário
STANDBY_FILE_MANAGEMENT
 Usado para manter a consistência dos datafiles nos
processos de manutenção do banco de dados primário
(adição, remoção, movimentação e etc...).
 Recebe dois possíveis valores:
 MANUAL: O que o DBA fizer no servidor primário deve
ser feito no servidor standby.
 AUTO: O que for feito no servidor primário será
automaticamente replicado para o servidor standby.
41
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT = AUTO;

Servidor Primário
Exemplo Completo:
42
DB_NAME=PRIM
DB_UNIQUE_NAME=PRIM
LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIM,STBY)'
CONTROL_FILES='/u01/app/oracle/oradata/PRIM/control1.ctl',
'/u01/app/oracle/oradata/PRIM/control2.ctl'
LOG_ARCHIVE_DEST_1=
'SERVICE=STBY
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=STBY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

Servidor Primário
Arquivo “tnsnames.ora”:
43
PRIM =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)
(HOST = ordt-srv1.oradata.com)
(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = PRIM.oradata.com)
)
)

Servidor Primário
Arquivo “listener.ora”:
Deve ter uma entrada estática.
44
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = PRIM.oradata.com)
(ORACLE_HOME = /u01/app/oracle/product/12.1.0/db_1)
(SID_NAME = PRIM)
)
)

Servidor Primário
Arquivo de senha:
 Copie o arquivo de senha do servidor primário
para o servidor standby.
 O arquivo de senha (no servidor primário) se
encontra no diretório $ORACLE_HOME/dbs.
 No servidor standby renomeie o arquivo para:
“orapw<SID>”
45

Servidor Standby
Crie um arquivo de parâmetros só com o DB_NAME.
 Este arquivo será usado somente no inicio do
processo de replicação, após isso será gerado um
novo arquivo com todos os parâmetros necessários.
46
$ cd $ORACLE_HOME/dbs
$ cat pfile.ora > DB_NAME=STBY

Servidor Standby
Crie os diretórios para os arquivos de auditoria:
Para armazenar os datafiles, crie os diretórios em
“$ORACLE_BASE/oradata”:
47
[oracle@ordt-srv2 ~]$ cd /u01/app/oracle/admin
[oracle@ordt-srv2 admin]$ ls
PRIM
[oracle@ordt-srv2 admin]$ mkdir STBY
[oracle@ordt-srv2 admin]$ cd STBY
[oracle@ordt-srv2 STBY]$ mkdir adump
[oracle@ordt-srv2 oradata]$ mkdir STBY
[oracle@ordt-srv2 oradata]$ ls
PRIM STBY

Servidor Standby
Inicie a instancia (no servidor standby) em modo
NOMOUNT, a partir do pfile.ora criado outrora.
48
SQL> startup nomount pfile=$HOME/dbs/pfile.ora
ORACLE instance started.
Total System Global Area 150667264 bytes
Fixed Size 1298472 bytes
Variable Size 92278744 bytes
Database Buffers 50331648 bytes
Redo Buffers 6758400 bytes

Servidor Standby
Parâmetros FAL_CLIENT e FAL_SERVER:
 Fetch Archive Log (FAL):
 Mecanismo responsável por resolver possíveis gaps de
archivelogs entre os servidores.
 Usado apenas para standby databases físicos.
 Processo inicializado apenas quando necessários, após
desliga-se automaticamente.
 FAL_CLIENT: Servidor primário (o serviço)
 FAL_SERVER: Servidor standby (o servidor)
49
FAL_CLIENT = ‘PRIM’
FAL_SERVER = ‘STBY’

Script para replicação
Exemplo (via RMAN)50
run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate auxiliary channel stby type disk;
duplicate target database for standby from active database
spfile
parameter_value_convert 'PRIM', 'STBY'
set db_unique_name='STBY'
set db_file_name_convert='/disk1/df/','/disco1/df/'
set log_file_name_convert='/disk1/log/','/disco1/log/'
set control_files='/u01/app/oracle/oradata/stby.ctl'
set log_archive_max_processes='5'
set fal_client='STBY'
set fal_server='PRIM'
set standby_file_management='AUTO'
set log_archive_config='dg_config=(PRIM,STBY)'
set log_archive_dest_1='service=STBY ASYNC
valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=PRIM';
}

Executando a replicação
Para iniciar o processo de replicação:
 Entre no rman e conecte-se na instancia de
produção (como “target”) e na instancia standby
(como “auxiliary”).
 Execute o script criado anteriormente.
51
RMAN> connect target sys/oracle
RMAN> connect auxiliary sys/oracle@STBY
RMAN> @create_standby

Real-Time Apply
52
RFS
Standby
redo log
files
MRP
ARC0
Servidor
Primário
Servidor
Standby
Archived
redo log
files

Iniciando o processo
de replicação online
Para iniciar o processo de replicação online (pós
replicação inicial):
 Entre no SQL*Plus (como SYSDBA) e execute:
53
$ sqlplus / as sysdba
SQL> ALTER DATABASE
2 RECOVER MANAGED STANDBY DATABASE
3 USING CURRENT LOGFILE
4 DISCONNECT FROM SESSION;

Resumo
 Habilitar o FORCE LOGGING.
 Criar os standby redo logs.
 Definir os parâmetros de inicialização no servidor
primário e standby.
 Configurar a conexão entre os servidores.
 Criar um standby físico com o comando DUPLICATE do
rman.
 Inicializar o serviço de transporte e aplicação dos redo
logs.
54

Data Guard
Broker

Neste Capítulo
 Arquitetura.
 Conceitos.
 Benefícios.
 Configurações.
 Usar o DGMGRL para gerenciar seu ambiente.
56

Características
 O Data Guard Broker:
 Framework de gerenciamento distribuído.
 Automatiza e centraliza a criação, manutenção e
monitoramento dos ambientes com Data Guard.
 Todas as operações de gerenciamento, podem ser
feitas localmente ou remotamente, com interfaces de
fácil utilização:
 Oracle Enterprise Manager Grid/Cloud Control
 DGMGRL (linha de comando)
57

Componentes
 O Data Guard Broker (Componentes):
 No lado do cliente:
 Oracle Enterprise Manager Grid/Cloud Control.
 DGMGRL (linha de comando)
 Do lado do servidor:
 DMON (processo de background).
 Arquivos de configuração.
58

Configurações
A configuração mais apropriada para se ter um Data
Guard, é ter seus servidores (primários e standby) em
localizações geográficas distintas.
59
SP
MG
ES
RJ

Modelo de Gerenciamento
60
Standby A
Produção
Data Guard
Broker
Standby B
Standby C
Standby D

Data Guard Monitor DMON
 Processo DMON
 Processo de background no lado do servidor.
 Presente em todas as instancias do ambiente.
 Criado quando usuário inicializa o “Broker”.
 Executa requisições e monitoramento dos recursos.
 Atualiza arquivos de configuração.
 Cria um arquivo de trace drc<SID>.
 Modifica parâmetros de inicialização durante
processes de “role transactions”.
62

Benefícios
 Melhora a alta disponibilidade, proteção de dados,
capacidades de recuperação de desastres, herdando
as características do Data Guard automatizando as
tarefas de configuração e monitoramento.
 Automaticamente promove um servidor standby em um
servidor primário em caso de desastres.
 Fácil configuração de bancos de dados standby
adicionais.
 Gerenciamento fácil e centralizado.
 Comunicação entre os servidores, envolvidos no Data
Guard através do protocolo Oracle Net.
63

Comparações
64
Com DG Broker Sem DG Broker
Geral Gerenciamento
centralizado
Instancias gerenciadas
individualmente.
Criação de um Standby DB Pode se utilizar wizards do
OEM 12c
Manualmente editando
vários arquivos.
Configuração e
Gerenciamento
Unificado através de
interface única.
Setup individual de cada
componente em seu
respectivo servidor.
Monitoramento Monitoramento continuo.
Status e reports automáticos
Integrados com o OEM 12c
Monitoramento individual
nas “v$” de cada servidor
envolvido na configuração.
Controle Role transactions com um
único comando.
Vários comando e
sequencia coordenada nos
servidores envolvidos na
configuração.

Interfaces
 Linha de comando:
 Inicializado com o comando dgmgrl em qualquer
computador que tenha um client Oracle instalado.
 Permite o gerenciamento e controle das configurações
do Data Guard com scripts personalizados.
 Oracle Enterprise Manager 11g Grid Control/12c
Cloud Control:
 Fornece diversos wizards para as atividades de
gerenciamento e configuração do Data Guard.
65

Exemplo: Linha de comando
66
DGMGRL> connect sys/oracle_4U@PRIM
Connected.
DGMGRL> show configuration verbose
Configuration
Name: DGConfig1
Enabled: YES
Protection Mode: MaxAvailability
Databases:
PRIM - Primary database
STBY - Physical standby database
Fast-Start Failover: DISABLED
Current status for "DGConfig1":
SUCCESS

Vantagens de OEM
 Gerenciamento e configuração através de
ferramentas gráficas (mais simples e produtivas).
 Automatiza e simplifica operações complexas na
hora de criar/gerenciar standby databases através
de wizards.
 Executa todas as configurações de rede necessárias
para os processos de “role transaction” e transporte
dos arquivos de redo log.
 Checagem das operações dos serviços de
transporte de redo log, para garantir que estejam
com os parâmetros corretos.
69

Resumo
 Arquitetura.
 Conceitos.
 Benefícios.
 Configurações.
 Usar o DGMGRL para gerenciar seu ambiente.
 Linha de comando.
 OEM 12c.
70

Criando o
Data Guard
Broker

Neste Capítulo
 Criar as configurações do Data Guard Broker.
 Gerenciar o seu ambiente com o Data Guard Broker.
72

Pré Requisitos
 Versão Enterprise.
 Single Instance ou Oracle RAC.
 Valor do parâmetro COMPATIBLE: 10.2.0.1ou mais
(produção e standby).
 Arquivos de configuração de rede (tnsnames e
listener) precisam existir e serem configurados em
ambos servidores.
 Atributo GLOBAL_DATABASE_NAME (no listener)
deve ter seu valor concatenado com a string
“_DGMGRL.seu_dominio”
73

Pré Requisitos
 Parâmetro DG_BROKER_START deve estar como
TRUE.
 Banco de dados primário deve estar em modo
archivelog.
 Todos os bancos de dados devem estar em modo
MOUNT ou OPEN.
 DG_BROKER_CONFIG_FILEn: Deve ser configurado
em caso de ambientes com Oracle RAC.
74

Pré Requisitos: SPFILE
 É obrigatório o uso do SPFILE.
 Usando o SPFILE, você consegue garantir que as
configurações entre os servidores mantenham-se
consistentes.
 Com o Data Guard Broker, você pode usar o
Enterprise Manager ou o DGMGRL para atualizar
parâmetros no SPFILE.
75

Data Guard Monitor
Arquivos de configuração:
 Os arquivos de configurações são:
 Criados automaticamente com um nome e caminho default
quando o Data Guard Broker é iniciado.
 Gerenciados automaticamente pelo processo DMON.
 Os arquivos de configurações são criados e gerenciados em
dois locais distintos em cada um dos sites.
 dr1<db_unique_name>.dat
 dr2<db_unique_name>.dat
 Localização default:
 Unix: $ORACLE_HOME/dbs
 Windows: $ORACLE_HOME/database
 Use DG_BROKER_CONFIG_FILEn para sobrescrever a
localização default dos arquivos em ambientes Oracle RAC.
76

Arquivos de log
 Os arquivos de log do Data Guard Broker, contém
as informações escritas pelo processo DMON.
 Há um arquivo de log para cada banco de dados
envolvido na configuração do Data Guard Broker.
 Os arquivos de log, são criados no mesmo diretório
que o alert.log da instancia de banco de dados
com o nome drc<$ORACLE_SID>.log
77

Criando o Data Guard Broker
 Entre no DGMGRL e conecte-se na instancia
primária:
 Defina as configurações, incluindo um profile para
a instancia primária.
 Adicione os bancos de dados standby para às
configurações.
 Habilite as configurações, incluindo os bancos de
dados.
78

Criando o Data Guard Broker
79
$ dgmgrl
DGMGRL> connect sys/oracle_4U@PRIM
DGMGRL> CREATE CONFIGURATION 'DGConfig1' AS
> PRIMARY DATABASE IS PRIM
> CONNECT IDENTIFIER IS PRIM;
Configuration "DGConfig1" created with primary
database "PRIM"
DGMGRL>
DGMGRL> ADD DATABASE STBY AS CONNECT IDENTIFIER IS
STBY;
Database "STBY" added
DGMGRL>

Habilitando a Configuração
80
DGMGRL> ENABLE CONFIGURATION;
Enabled.
DGMGRL> SHOW CONFIGURATION
Configuration
Name: DGConfig1
Enabled: YES
Protection Mode: MaxPerformance
Databases:
SUCCESS

Editando a Configuração
 Para alterar algum propriedade:
 Para alterar o estado de standby database:
 Para alterar o estado de um banco de dados
primário:
81
DGMGRL> EDIT DATABASE PRIM SET PROPERTY
> LogXptMode='SYNC';
DGMGRL> EDIT DATABASE PRIM SET STATE='APPLY-OFF';
DGMGRL> EDIT DATABASE PRIM SET STATE='TRANSPORT-
OFF';

Serviços de Transport de Redo
 Especifique as propriedades abaixo para
gerenciar o serviço de transporte dos arquivos de
redo log.
 DGConnectIdentifier
 LogXptMode
 LogShipping
82

Identificador de Conexão
 DGConnectIdentifier:
 Especifica o identificador de conexão usado pelo Data Guard
Broker para conectar-se ao banco de dados.
 É definido quando um banco de dados é adicionado a
configuração do Data Guard Broker, ou quando um valor é
especificado na clausula CONECT IDENTIFIER CLAUSE
(opcional), ou extraído do atributo SERVICE do parametro
LOG_ARCHIVE_DEST_n.
 Usado nos parametros FAL_CLIENT e FAL_SERVER
 Alterando o DGConnectIdentifier, automaticamente altera-se
os valores de SERVICE, FAL_CLIENT e FAL_SERVER.
83

Redo Transport (LogXptMode)
 O serviço de transporte dos arquivos de redo log deve
ser escolhido em conjunto com um modo de proteção.
 LogXptMode é usado para definir o serviço de transporte
dos arquivos de redo log.
 ASYNC
 Definie ASYNC e NOAFFIRM nos atributos do parâmetro
LOG_ARCHIVE_DEST_n.
 Obrigatório para o modo de máxima performance.
 SYNC
 Definie SYNC e AFFIRM nos atributos do parâmetro
LOG_ARCHIVE_DEST_n.
 Obrigatório para os modos de máxima proteção e máxima
disponibilidade
84

Redo Transport (LogShipping)
 LogShipping
 Controla se os archivelogs foram enviados ao servidor standby
de destino.
 Aplicável apenas quando o estado do banco de dados
primário está como TRANSPORT-ON.
87

Gerenciamento da Configuração
 Desabilitando o gerenciamento do Data Guard Broker:
 Desabilitando o gerenciamento de um standby database
específico:
 Removendo um banco de dados:
 Removendo a configuração:
88
DGMGRL> DISABLE CONFIGURATION;
DGMGRL> DISABLE DATABASE ‘STBY’;
DGMGRL> REMOVE DATABASE ‘STBY’;
DGMGRL> REMOVE CONFIGURATION;

Resumo
 Criar as configurações do Data Guard Broker.
 Gerenciar o seu ambiente com o Data Guard Broker.
89

Data Guard
Lógico

Neste Capítulo
 Determinar quando criar um Data Guard Lógico.
 Criar um Data Guard Lógico.
 Gerenciamento do SQL-Apply.
91

Benefícios
 Uso eficiente dos recursos:
 Standby aberto, ativo, independente da produção.
 Índices e materialized views podem ser criados para
melhora da performance.
 Reduz o workload da instancia de produção:
 Relatórios.
 Consultas massivas.
 Cálculos e etc.
92

Benefícios
 Proteção de dados:
 Corrupção na instancia primaria não são propagadas.
 DRP (Disater Recovery Plan):
 Switchover e Failover.
 Minimiza downtimes planejados e não planejados.
 Pode ser usado para upgrad do banco de dados e
aplicação de patchs.
93

Preparação
 Antes da criação de um Data Guard lógico:
 Veja os data types não suportados.
 Tenha ciência dos comandos DDLs não suportados.
 Garantir a unicidade (PK) dos registros.
 Banco de dados primário deve estar em modo
archivelog.
96

Objetos não suportados
Data Guard lógico, automaticamente exclui objetos
não suportados quando aplica o conteúdo dos redo
logs no banco de dados standby.
 Objetos não suportados:
 Tabelas e sequences do usuário SYS.
 Tabelas com compressão.
 Tabelas usadas em materialized views.
 Global temporary tables.
 Tabelas com data types não suportados (continua...)
97

Data types não suportados
O serviço Log-Apply exclui automaticamente tabelas
com data types não suportados, quando está
aplicando o conteúdo dos arquivos de redo log.
 Data types não suportados:
 BFILE, ROWID e UROWID.
 Data types definidos pelo usuário.
 Data types multimídia (Spatial, Imagem, Oracle Text).
 Collectios (VARRAYS e nested-tables).
 LOBs
 XMLType como objeto relacional.
 BINARY XML
98

Tenho tabelas não suportadas?
Para saber se seu banco de dados primário possui
tabelas não suportadas no processo de Data Guard
lógico, execute o select:
99
SQL> SELECT * FROM dba_logstdby_unsupported_table
2 ORDER BY owner;
OWNER TABLE_NAME
------------------------------ ------------------------------
IX AQ$_STREAMS_QUEUE_TABLE_T
IX AQ$_STREAMS_QUEUE_TABLE_H
…
OE CUSTOMERS
OE WAREHOUSES
PM PRINT_MEDIA
PM ONLINE_MEDIA
SH DIMENSION_EXCEPTIONS
20 rows selected.

Tenho data types não suportados?
Para saber se seu banco de dados primário possui
tabelas com data types não suportadas no processo
de Data Guard lógico, execute o select:
100
SQL> SELECT table_name, column_name, attributes, data_type
2 FROM dba_logstdby_unsupported WHERE owner = 'OE';
TABLE_NAME COLUMN_NAME ATTRIBUTES DATA_TYPE
-------------- -------------------- ------------ ----------
CUSTOMERS CUST_ADDRESS OBJECT
CUSTOMERS PHONE_NUMBERS VARRAY
CUSTOMERS CUST_GEO_LOCATION OBJECT
WAREHOUSES WH_GEO_LOCATION OBJECT
PURCHASEORDER SYS_NC_ROWINFO$ Object Table OPAQUE
CATEGORIES_TAB CATEGORY_NAME Object Table VARCHAR2
CATEGORIES_TAB CATEGORY_DESCRIPTION Object Table VARCHAR2
CATEGORIES_TAB CATEGORY_ID Object Table NUMBER
CATEGORIES_TAB PARENT_CATEGORY_ID Object Table NUMBER
9 rows selected.

Comandos proibidos no standby
101
ALTER DATABASE
ALTER SESSION
ALTER MATERIALIZED VIEW
ALTER MATERIALIZED VIEW LOG
ALTER SYSTEM
CREATE CONTROL FILE
CREATE DATABASE
CREATE DATABASE LINK
CREATE PFILE FROM SPFILE
CREATE SCHEMA AUTHORIZATION
CREATE MATERIALIZED VIEW
CREATE MATERIALIZED VIEW LOG
CREATE SPFILE FROM PFILE
DROP DATABASE LINK
DROP MATERIALIZED VIEW
DROP MATERIALIZED VIEW LOG
 EXPLAIN
 LOCK TABLE
 SET CONSTRAINTS
 SET ROLE
 SET TRANSACTION

Unicidade de registros (PK)
Para saber se você tem tabelas sem PK (primary key
– chave primária) definidas, você pode consultar a
view DBA_LOGSTDBY_NOT_UNIQUE:
102
SQL> SELECT * FROM dba_logstdby_not_unique;
OWNER TABLE_NAME BAD_COLUMN
------ -------------------------- ----------
HR EMP_HIST N
SCOTT BONUS N
SCOTT SALGRADE N
SH SUPPLEMENTARY_DEMOGRAPHICS N
SH COSTS N
SH SALES

RELY Constraint
Você pode adicionar uma RELY constraint para
identificar as linhas como únicas dentro de uma
tabela.
103
SQL> ALTER TABLE hr.employees
2 ADD PRIMARY KEY (employee_id, last_name)
3 RELY DISABLE;

Criando o Data Guard Lógico
Para criar um Data Guard Lógico:
1. Crie um standby físico.
2. Pare o processe de redo-apply.
3. Prepare a instancia primaria para fazer parte de
um ambiente com standby logico.
4. Crie um processo de LogMiner.
5. Faça a transição para o standby lógico.
6. Abra o standby lógico.
7. Verifique se tudo está executando OK.
104

Criando o standby físico:
 Crie um standby database físico (capitulo 02).
 Garanta que seu standby database físico seja o
seu servidor primário.
105

Pare o processo de redo-apply no standby database:
 Pelo SQL*Plus:
 Ou pelo Data Guard Broker (caso esteja usando):
106
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
2 DATABASE CANCEL;
DGMGRL> EDIT DATABASE 'STBY' set state='apply-
off';
Succeeded.

Prepare o banco de dados primário para participar
de um ambiente com standby database lógico:
 Acerte o parâmetro LOG_ARCHIVE_DEST_n de
acordo com um ambiente de Data Guard lógico:
 Defina o valor do parâmetro UNDO_RETENTION
para 3600.
107
LOG_ARCHIVE_DEST_2=
'LOCATION=<directory>
VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE)
DB_UNIQUE_NAME=STBY'
LOG_ARCHIVE_DEST_STATE_2=enable

Habilitando o LogMiner
 Habilite o processo do LogMiner, para que as
entradas nos arquivos de redo log sejam
interpretadas no servidor standby.
 Automaticamente o processo supplemental logging
é habilitado.
 Execute este processo no servidor primário.
108
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

Transição DG Físico / Lógico
 Para converter o então Data Guard físico para o
modelo lógico, execute o comando:
 Execute um shutdown e inicialize a instancia em
modo MOUNT.
 Ajuste o valor dos parâmetros LOG_ARCHIVE_DEST
109
SQL> ALTER DATABASE RECOVER TO
2 LOGICAL STANDBY db_name;

Abrindo o DG Lógico
 Abra a instancia standby com a opção RESETLOGS.
 Inicie o processo de aplicação do conteúdo vindo
do ambiente primário (produção).
110
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER DATABASE START LOGICAL
STANDBY APPLY IMMEDIATE;

Adicionando ao Data Guard Broker
 Para adicionar seu standby database lógico à
configuração do Data Guar Broker, use o DGMGRL:
111
DGMGRL> ADD DATABASE 'STBY' AS
> CONNECT IDENTIFIER IS STBY;
Database "STBY" added
DGMGRL>

Monitorando
 Para checar se seu processo está executando 100%
corretamente execute o select:
 Para “forçar” o envio de informações do primário
para o standby:
 Consulte a view DBA_LOGSTDBY_LOG para
verificar se os redo logs estão sendo registrados.
112
SQL> SELECT sequence#, first_time, next_time,
2 dict_begin, dict_end
3 FROM dba_logstdby_log ORDER BY sequence#;
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

Monitorando
 Verificando se os redo logs estão sendo aplicados:
 Para ver as atividades em progresso:
 Para ver o andamento de todos os processos:
113
SQL> SELECT name, value FROM v$logstdby_stats
2 WHERE name = 'coordinator state';
SQL> SELECT sid, serial#, spid, type, high_scn
2 FROM v$logstdby_process;
SQL> SELECT applied_scn, latest_scn
2 FROM v$logstdby_progress;

Protegendo o Standby
 Como o standby logico está completamente
“aberto” para os usuários, uma boa ideia é
protege-lo, para isso use o comando:
 ALTER DATABASE GUARD ALL|STANDBY|NONE
 ALL: Impede qualquer modificação no standby database.
 STANDBY: Impede alteração em dados do standby só.
 NONE: Segurança normal (default).
 Consulte a coluna GUARD_STATUS da V$DATABASE.
 Com o uso do DG Broker, automaticamente usa-se ALL.
 Configuração aplicável para todos usuários exceto
SYS.
114

Auto-Delete Redo Logs
115
DBMS_LOGSTDBY.APPLY_SET

Auto-Delete Redo Logs
 Parâmetro LOG_AUTO_DEL_RETENTION_TARGET:
 Numero de minutos que o processo de SQL-Apply vai
reter as informações, após aplica-las no standby.
 Aplicável somente quando LOG_AUTO_DELETE está
definido como TRUE e os archives não estão sendo
gerados na fast recovery área.
 Valor default é de 1.440 minutos (24 horas).
116

DG Broker Filtros
 Use os seguintes parâmetros no DGMGRL para
“filtrar” transações:
 LsbyASkipCfgPr: Comandos SQL explicitamente
especificados serão ignorados.
 LsbyASkipErrorCfgPr: Comandos SQL com erros
serão ignorados.
 LsbyASkipTxnCfgPr: Transações explicitamente
especificadas devem ser ignoradas.
117

DG Broker Filtros
 Use os seguintes parâmetros no DGMGRL para
“deletar” comandos SQL:
 LsbyDSkipCfgPr: Comandos SQL explicitamente
especificados serão deletados.
 LsbyDSkipErrorCfgPr: Comandos SQL com erros
explicitamente especificados serão ignorados.
 LsbyDSkipTxnCfgPr: Reverte ou deleta ações
especificadas em LsbyDSkipCfgPr.
118

Veja suas configurações
 Para saber as configurações ativas, consulte a view
DBA_LOGSTDBY_SKIP:
119
SQL> SELECT error, statement_opt, name
2 FROM dba_logstdby_skip
3 WHERE owner='HR';
ERROR STATEMENT_OPT NAME
---------- -------------------- ----------
N DML JOBS

Usando DBMS_SCHEDULER
 Você pode criar Jobs em seu standby lógico.
 Quando um job é criado, ele por padrão ele assumirá
LOCAL_ROLE.
 Você pode editar o atributo DATABASE_ROLE com a
DBMS_SCHEDULER.SET_ATTRIBUTE com os seguintes
valores:
 PRIMARY: O job executa somente quando a instancia estiver
como primária.
 LOGICAL STANDBY: O job executa somente quando a
instancia está como logical standby.
120

Resumo
 Determinar quando criar um Data Guard Lógico.
 Criar um Data Guard Lógico.
 Gerenciamento do SQL-Apply.
121

Modos de
Proteção

Neste Capítulo
 Descrever e entender os modos de proteção.
 Alterar os modos de proteção de sua configuração.
123

Modo: Proteção x Transporte
 Cada modo de proteção requer um modo de
transporte específico.
 Um modo de transporte por si só, não define um
modo de proteção.
124

Modo: Proteção dos Dados
 Há três modos de proteção de dados:
 Máxima Proteção.
 Máxima Disponibilidade.
 Máxima Performance.
 Estes modos lhe ajudam a equilibrar seu ambiente
no aspecto da disponibilidade x performance.
125

Máxima Proteção
 Garante “zero” perda de dados caso alguma falha
ocorra no banco de dados primário, na rede ou no
banco de dados standby.
 O banco de dados primário é desligado caso haja
alguma falha que gere perda de sincronismo com o
banco de dados standby.
 Os dados de redo devem ser escritos nos arquivos de
redo log local e nos standby redo logs
obrigatoriamente.
 Obrigatório: Um standby database com os valores
SYNC e AFFIRM nos atributos de transporte dos
arquivos de redo log.
126

Máxima Disponibilidade
 Garante “zero” perda de dados, sem comprometer a
disponibilidade do banco de dados primário.
 Os dados de redo devem ser escritos nos arquivos de redo
log local e nos standby redo logs obrigatoriamente.
 O banco de dados primário, não será desligado enquanto
houver pelo menos um standby redo log sincronizado.
 Se houver perda de sincronia entre os bancos de dados, o
banco de dados standby continua a operar até que tudo de
restabeleça.
 Obrigatório: Um standby database com os valores SYNC e
AFFIRM nos atributos de transporte dos arquivos de redo
log.
127

Máxima Performance
 Modo default de proteção.
 Oferece maior nível de proteção possível sem
afetar a performance.
 Transações que recebem commit, são rapidamente
escritas no redo log local.
 Redo logs são enviados ao banco de dados
standby de maneira assíncrona.
 Obrigatório: Obrigatório: Um standby database
com os valores ASYNC e NOAFFIRM nos atributos
de transporte dos arquivos de redo log.
128

Comparando
129
Modo Risco de
Perda
Transporte Se nenhuma
confirmação
é recebida.
Máxima
Proteção
Zero de Perda
Proteção dupla
SYNC DB Primário é
desligado
Máxima
Disponibilidade
Zero de Perda SYNC Aguarda até o
re-sincronismo
Máxima
Performance
Perda mínima ASYNC Nunca aguarda
um feedback
do DB
primários

Configuração DGMGRL
 Configure os standby redo logs.
 Configure LogXptMode (se preciso).
 Máxima proteção: SYNC
 Máxima Disponibilidade: SYNC
 Máxima Performance: ASYNC
 Defina o modo de proteção:
130
DGMGRL> EDIT DATABASE 'STBY' SET PROPERTY LogXptMode'='SYNC';
Property "LogXptMode" updated
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.

Resumo
 Descrever e entender os modos de proteção.
 Alterar os modos de proteção da sua configuração.
131

Monitoramento
Do
Data Guard

Neste Capítulo
 Usar o OEM Cloud Control para monitoramento.
 Usar o DGMGRL para monitoramento e status.
133

Enterprise Manager
 Através da pagina de monitoramento você pode:
 Gráfico de transporte e aplicação dos arquivos de
redo log.
 Informações adicionais de configuração e
performance:
 Informações a respeito dos archivelogs aplicados e o
progresso do standby database.
 Informações a respeito dos redo logs do banco de
dados primário.
 Verificação da performance.
134

Enterprise Manager
 Métricas e Alertas:
 Métricas: Unidades de medidas para chegar a saúde
do banco de dados.
 Thresholds: Limites de valores para as métricas.
 Alerta: Indicação de que um threshold foi excedido.
136

DGMGRL Diagnóstico
 As informações do DG Broker são guardadas:
 Alert.log das instancias.
 Data Guard Broker log files.
 Status e informações são coletadas com o comando
SHOW DATABASE.
 Você pode usar as propriedades:
 StatusReport
 LogXptStatus
 InconsistentProperties
 InconsistentLogXptProps
139
DGMGRL> SHOW DATABASE 'STBY' 'StatusReport';

DGMGRL Diagnóstico
 Verificando o status da configuração:
 Verificando o status de um banco de dados.
 Verificando o status do monitoramento.
 Com o comando SHOW DATABASE você pode
adicionar qualquer propriedade para consulta-la
exclusivamente.
140
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW DATABASE 'PRIM';
DGMGRL> SHOW DATABASE 'PRIM' 'StatusReport';

DGMGRL Diagnóstico
 Comando SHOW CONFIGURATION:
 Fornece um resumo das configuração de seu ambiente:
141
DGMGRL> show configuration
Configuration
Name: DGConfig1
Enabled: YES
Databases:
STBY2 - Physical standby database
SUCCESS

DGMGRL Diagnóstico
 Comando SHOW DATABASE:
 Fornece um resumo das configuração de um banco de
dados em especifico::
142
DGMGRL> show database STBY
Database
Name: STBY
OEM Name: STBY.oradata.com
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: APPLY-ON
Instance(s):
STBY
Current status for “STBY":
SUCCESS

DGMGRL Diagnóstico
 Comando SHOW DATABASE VERBOSE:
 Fornece informações completas (todas propriedades)
de um banco de dados:
143
DGMGRL> show database verbose STBY
Database
Name: STBY
OEM Name: STBY.oradata.com
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: APPLY-ON
Instance(s):
pc00sby1
Properties:
DGConnectIdentifier = 'STBY'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
…

SQL*Plus Diagnóstico
 Informações sobre os arquivos de redo log.
144
SQL> SELECT group#, status, member
2 FROM v$logfile
3 WHERE type = 'STANDBY';
GROUP# STATUS MEMBER
------ ------ ------------------------------------------
4 /u01/app/oracle/oradata/STBY/srl01.log

 Informações sobre os standby redo log.
145
SQL> SELECT group#, dbid, archived, status
2 FROM v$standby_log;
GROUP# DBID ARC STATUS
---------- -------------- --- ----------
4 UNASSIGNED NO UNASSIGNED
5 3303427449 YES ACTIVE
6 UNASSIGNED YES UNASSIGNED
7 UNASSIGNED YES UNASSIGNED

 Identificando o destino dos arquivos de redo log.
146
SQL> SELECT dest_id,valid_type,valid_role,valid_now
2 FROM v$archive_dest;
DEST_ID VALID_TYPE VALID_ROLE VALID_NOW
------- --------------- ------------ --------------
1 ALL_LOGFILES ALL_ROLES YES
2 STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE
3 ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE
4 ALL_LOGFILES ALL_ROLES UNKNOWN
11 ALL_LOGFILES ALL_ROLES YES
11 rows selected.

Parâmetro
LOG_ARCHIVE_TRACE
 Opcional, utilizado para questões de tuning.
 Defina este parâmetro para um valor inteiro para
ver o progresso da geração dos archivelogs dentro
do seu sistema.
 No banco de dados primário, será gerado um arquivo
de trace contendo as informações de todos os arquivos
enviados ao banco de dados standby.
 No Banco de dados standby, um arquivo de trace de
todos arquivos vindos do banco de dados primário.
 Os arquivos são escritos no diretório do ADR, para
ver o caminho consulte no spfile o parâmetro
DIAGNOSTIC_DEST.
147

 Monitorando o processo de aplicação dos arquivos
de redo log no banco de dados standby.
148
SQL> SELECT process, status, group#, thread#, sequence#
2 FROM v$managed_standby
3 order by process, group#, thread#, sequence#;
PROCESS STATUS GROUP# THREAD# SEQUENCE#
--------- ------------ ---------- ---------- ----------
ARCH CLOSING 4 1 142
MRP0 APPLYING_LOG N/A 1 149
RFS IDLE 2 1 149
RFS IDLE N/A 0 0
RFS IDLE N/A 0 0

 Verificando a diferença de tempo (quanto a
aplicação dos arquivos de redo) entre as instancias.
149
SQL> SELECT name, value, time_computed
2 FROM v$dataguard_stats;
NAME VALUE TIME_COMPUTED
------------------------- --------------- --------------
apply finish time +00 00:00:00.0 13-FEB-2008 02:44:21
apply lag +00 00:00:00 13-FEB-2008 02:44:21
estimated startup time 12 13-FEB-2008 02:44:21
standby has been open N 13-FEB-2008 02:44:21
transport lag +00 00:00:00 13-FEB-2008 02:44:21

 Verificando o log das operações realizadas pelo
processo de Data Guard.
150
SQL> SELECT timestamp, facility, dest_id, message_num,
2 error_code, message
3 FROM v$dataguard_status
4 ORDER by timestamp;
TIMESTAMP FACILITY DEST_ID MESSAGE_NUM ERROR_CODE
--------- --------------- ------- ----------- ----------
MESSAGE
--------------------------------------------------------
13-FEB-08 Log Apply Servi 0 562 0
Media Recovery Waiting for thread 1 sequence 151
13-FEB-08 Remote File Ser 0 563 0
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[25]: Successfully opened standby log 5:
'/u01/app/oracle/oradata/pc00sby1/srl02.log'

 Verificando informações de todas as transações
ativas que estão aplicando instrução SQL no banco
de dados standby.:
151
SQL> SELECT primary_xid, type,
2 mining_status, apply_status
3 FROM v$logstdby_transaction;

Resumo
 Usar o OEM Cloud Control para monitoramento
 Usar o DGMGRL para monitoramento e status.
152

Otimizando
o
Data Guard

Neste Capítulo
 Monitorar a performance do Data Guard.
 Otimizar o transporte para melhor performance.
 Otimizar a aplicação dos SQL.
154

Performance via OEM
 Você pode monitorar a performance de seu
ambiente via Enterprise Manager.
155

Otimizando a Performance
 Para otimizar o processo de transporte dos
arquivos de redo log, use as técnicas:
 Transporte assíncrono com múltiplos processos de
archive (parâmetro LOG_ARCHIVE_MAX_PROCESSES).
 Compactando os arquivos de redo log.
156

 Propriedade ReopenSecs:
 Numero em segundos que o processo de archive
aguarda antes de tentar acessar um destino que houve
falha.
 DG Broker 300 (Default).
 Defina essa propriedade no Standby Database.
 Também pode ser alterada no parâmetro
LOG_ARCHIVE_DEST_n através do atributo REOPEN.
Ou no DG Broker:
157
DGMGRL> EDIT DATABASE 'STBY' SET PROPERTY 'ReopenSecs'=600;

 Propriedade NetTimeout:
 Numero em segundos que o processo de log writer
(LGWR) aguarda a resposta para escrever um arquivo.
 DG Broker 30 (Default).
 Também pode ser alterada como atributo
NET_TIMEOUT no parâmetro LOG_ARCHIVE_DEST_n
no banco de dados primário.
158
DGMGRL> EDIT DATABASE 'PRIM' SET PROPERTY 'NetTimeout'=20;

159
MaxConnections

 Propriedade MaxConnections:
 Numero de processos ARCn, que são usados para
transmitir dados de um arquivo de redo log para o site
remoto quando há um GAP no processo.
 Broker Default: 1
 Também pode ser alterada através do SPFILE no
atributo MAX_CONNECTIONS no parâmetro
LOG_ARCHIVE_DEST_n no banco de dados primário.
160
DGMGRL> EDIT DATABASE 'PRIM' SET PROPERTY 'MaxConnections'=5;

 Propriedade RedoCompression:
 Habilita a compressão dos archived redo logs, durante
um processo de transmissão para resolução de algum
GAP de arquivo.
 Pode ser definida na propriedade COMPRESSION do
parâmetro LOG_ARCHIVE_DEST_n, dentro do SPFILE.
 Você pode ver se a compressão está habilitada NA
view V$ARCHIVE_DEST coluna COMPRESSION.
161
DGMGRL> EDIT DATABASE 'STBY' SET PROPERTY 'RedoCompression'='ENABLE';

 Delay (atraso intencional) na aplicação dos redos:
 Pode ajudar a previnir:
 Corrupção de dados.
 Erros humanos.
162
PRIM STBY

 Propriedade DelayMins:
 Especifica em minutos, o tempo que um standby redo
log deve aguardar antes de ser aplicado.
 Broker Default: 0 (enviou aplicou).
 Pode ser alterada no atributo DELAY no parâmetro do
SPFILE chamado LOG_ARCHIVE_DEST_n (no banco de
dados primário).
163
DGMGRL> EDIT DATABASE 'PRIM' SET PROPERTY 'DelayMins'=5;

 Aplicação dos SQL.
 O numero de processos pode ser ajustado como
 APPLIER
 PREPRARER
 Modifique esses parâmetros para controlar o
numero de processos que aplicam SQL.
 APLLY_SERVERS: Numero de processos APPLIER.
 PREPARE_SERVERS: Numero de processos PREPARER.
 Para alterar esses parâmetro use a package
DBMS_LOGSTDBY.
164

Aplicação dos SQL (Ajustando APPLIERS).
 Veja se o numero de appliers é maior que o
throughoput.
 Determine se os appliers estão ocupados.
 Determine se há trabalho para mais appliers.
 Ajuste o parâmetro MAX_SERVERS (se preciso).
 Ajuste o parâmetro APPLY_SERVERS para aumentar o
numero de processos appliers.
165
SQL> SELECT COUNT(*) AS IDLE_APPLIER
2 FROM V$LOGSTDBY_PROCESS
3 WHERE TYPE = 'APPLIER' and status_code = 16166;
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
2 WHERE NAME LIKE 'transactions%';

Aplicação dos SQL (Ajustando PREPARER).
 Veja se o numero de preparers é o correto.
 Veja se todos os preparers estão ocupados.
 Determine se o numero de transações prontas para
serem aplicadas é menor do que o numero de
preparers disponíveis.
166
SQL> SELECT COUNT(*) AS IDLE_PREPARER
3 WHERE TYPE = 'PREPARER' and status_code = 16166;
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
2 WHERE NAME LIKE 'transactions%';
SQL> SELECT COUNT(*) AS APPLIER_COUNT
2 FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';

Aplicação dos SQL (Ajustando PREPARER).
 Veja se há processos APPLIER como idle.
 Ajuste o parâmetro MAX_SERVERS (se preciso).
 Ajuste o parâmetro PREPARE_SERVERS para aumentar
o numero de PREPARERS.
167
SQL> SELECT COUNT(*) AS IDLE_APPLIER
3 WHERE TYPE = 'APPLIER' and status_code = 16166;

Resumo
 Monitorar a performance do Data Guard.
 Otimizar o transporte para melhor performance.
 Otimizar a aplicação dos SQL.
168

Flashback

Neste Capítulo
 Vantagens de Flashback com Data Guard.
 Configurar o Flashback Database.
170

Flashback & Data Guard
 Com Flashback você tem:
 Uma alternativa para restaurar a instancia primaria.
 Uma alternativa para um reinstate da instancia primária, no
caso de um failover.
 Uma alternativa de retardar a aplicação de um redo que
contenha possíveis erros lógicos (de aplicação).
 Flashback Database deve ser configurado usando:
 Fast-Start-Failover
 Snapshot Standby
 Flashback Database é recomendado com o uso do DG
Broker, porque ele automaticamente habilita “real-time
apply”.
171

Flashback Database
 Overview:
 É como se fosse o CTRL+Z (desfaz tudo que foi feito).
 Pode ser usado apenas em caso de falhas lógicas.
172

Flashback Database
 Configuração (requisitos):
 Instancia em modo archivelo.
 FRA configurada.
 Configuração (algoritmo):
 Shutdown da instancia.
 Startup em modo mount.
 Definir Flashback Retention Target.
 Habilitar o Flashback Database.
 Abrir a instancia.
173

Flashback Database
175
RFS
Standby
redo log
MRP
ARC0
Archived
redo logs
PRIM
STBY

Flashback Database
176
Redo
Redo
DB Primário
DB Primário
DB Standby
DB Standby
RESETLOGS
Depois de um PIT Flashback

Flashback Database
e Role Transitions
 Use Flashback para recuperar a instancia para um
momento antes de um switchover ou failover.
 As instancias (primária e standby) mantém seus
papeis quando um flashback é executado (standby
físico).
 É possível haver “role transitions” quando se
executa um flashback em standby lógico.
 Flashback database pode ser usado para reverter
uma ativação indevida de um banco de dados.
177

Flashback Database
Após um Failover178
Redo
Redo
DB Primário
Novo DB Standby
DB Standby
Novo DB Primário
Flashback Failover

Resumo
 Vantagens de Flashback com Data Guard.
 Configurar o Flashback Database.
179

Role
Transition

Neste Capítulo
 Explicar as duas roles possíveis em um Data Guard.
 Executar um switchover.
 Executar um Failover.
181

Gerenciamento de papeis
 Em um ambiente com Data Guard, é possivel se
trabalhar com dois papeis (roles).
 Primary Role (Produção).
 Standby Role (Standby).
 Com o gerenciamento de papeis, você pode
inverter estas posição de maneia automática.
182

Switchover & Failover
 Switchover:
 Planejado.
 Manutenção de hardware ou sistema operacional.
 Manualmente executado.
 Failover:
 Não Planejado.
 Usado emergencialmente.
 Mínima ou zero perda de dados (depende do modo
de proteção).
 Fast-Start Failover pode ser habilitado para acontecer
automaticamente.
183

Switchover
 Troca de papel entre os servidores (primário vira
standby e o standby vira primário).
 Não é preciso usar OPEN RESETLOGS.
 Não há perda de dados.
184

Switchover (Antes)
185
Leitura / Escrita
Transações
São Paulo
Somente Leitura
Relatórios
Belo Horizonte
Banco de Dados
De Produção
Banco de Dados
Standby

Switchover (Depois)
186
Somente Leitura
Relatórios
São Paulo
Leitura / Escrita
Transações
Belo Horizonte
Banco de Dados
De Standby
Banco de Dados
Produção

Switchover - Preparo
 Para executar um switchover confira:
 Há conectividade entre os servidores?
 O estados das instancias TRANSPORT-ON e APPLY-ON.
 As propriedades do banco de dados standby devem
estar definidas no banco de dados primário.
 O banco de dados, possui standby redo logs?
 LogXptMode deve estar como SYNC e operante em
máxima disponibilidade ou máxima proteção.
187

Switchover - DGMGRL
 Se tudo estiver correto, execute o SWITCHOVER.
188
DGMGRL> SWITCHOVER TO 'STBY';
Performing switchover NOW, please wait...
New primary database "STBY" is opening...
Operation requires shutdown of instance "PRIM" on database
"PRIM"
Shutting down instance "PRIM"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "PRIM" on database
"PRIM"
Starting instance "PRIM"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "STBY"

Switchover – DG Lógico
 Quando seu standby for lógico:
 As operações deste processo não executam shutdown
na instancia primária.
 Não é preciso derrubar as sessões dos usuários, mas é
recomendado.
 O standby lógico, pode não ter todas as informações.
 Invalida e desabilita todas as configurações de
standby físicos e snapshot.
189

Switchover - Restrições
 Você não pode fazer um switchover quando:
 Não houver archivelogs disponíveis.
 Point in Time recovery (PIT) é necessário.
 O banco de dados de produção (primário) não pode
ser aberto.
190

Failover
191
São Paulo
Leitura / Escrita
Transações
Belo Horizonte
Banco de Dados
De Produção
Banco de Dados
Standby se torna Produção
Redo log local Archivelog log local
Leitura / Escrita
Transações

Tipos de Failover
 Manual (Feito pelo DBA).
 Completo: Tenta aplicar todos os redo logs para
minimizar a perda de dados.
 Imediato: Nenhum passo adicional é executado.
 Fast-Start Failover: Executado automaticamente
pelo Data Guard Broker.
192

Failover - Considerações
 O antigo banco de dados primário, não faz mais
parte da configuração.
 É possível haver perda de dados.
 Deve ser usado apenas em casos de emergências.
 Ao executar um failover você deve:
 Escolher um standby físico quando possível.
 Escolher o standby database mais atualizado.
193

Failover Manual DGMGRL
 Execute o comando FAILOVER para executar a
operação:
 Redefina o modo de proteção (se preciso).
 Reinstate o banco de dados primário como standby.
 Redefina ou recrie outro standby database.
194
DGMGRL> FAILOVER TO 'STBY' [IMMEDIATE];

Reabilitando a Instancia
Primária DGMGRL
 Bancos de dados que era primários, precisam ser
recriados esse processo chama-se “reinstate”
 No DGMGRL use o comando REINSTATE DATABASE.
 Se você não puder executar um reinstate de seu
banco de dados, deve recriá-lo a partir de uma
copia do banco de dados atual. E então reabilitar
dentro do DGMGRL.
195
DGMGRL> REINSTATE DATABASE PRIM;
DGMGRL> ENABLE DATABASE PRIM;

Resumo
 Explicar as duas roles possíveis em um Data Guard.
 Executar um switchover.
 Perform a failover.
196

Fast Start
Failover

Neste Capítulo
 Configurar o Fast Start Failover.
 Ver as configurações do Fast Start Failover.
 Gerenciar o Observer.
 Role transition com Fast Start Failover.
 Manual Reisntate do banco de dados primário.
198

Fast Start Failover
199
Banco de dados
de produção
Banco de dados
Standby
Observer

Fast Start Failover
Quando não acontece?200
Banco de dados
de produção
Banco de dados
Standby
Observer
> Threshold
Fast Start Failover

Instalação Observer
 Ferramenta cliente que fica monitorando a
disponibilidade da instancia primária.
 Deve ser instalado em um servidor que não seja
parte do Data Guard.
 Gerenciado pelo OEM e pelo DGMGRL.
201

FSFO – Pre requisitos
 Configuração em máxima disponibilidade ou
máxima performance.
 Propriedade LogXptMode:
 SYNC: em máxima disponibilidade
 ASYN: em máxima performance
 Flashback database nas instancias primária e
standby.
 TNSNAMES.ora no servidor do observer.
 Entrada estática no listener, para que o observer
possa rematamente reiniciar os serviços.
202

Configurações.
 Especifique o standby database “target”.
 Defina o modo de proteção.
 Defina a propriedade FastStartFailoverThreshold.
 Defina as propriedades adicionais.
 Defina as condições para o Fast Start Failover.
 Habilite o Fast Start Failover.
 Inicie o Fast Start Failover.
 Verifique as configurações.
203

Target Standby Database
204
Banco de dados
de produção
PRIM
Banco de dados
Standby
STBY
DGMGRL> EDIT DATABASE PRIM
2 SET PROPERTY FastStartFailoverTarget = STBY;
DGMGRL> EDIT DATABASE STBY
2 SET PROPERTY FastStartFailoverTarget = PRIM;

Modo de Proteção
205
> LogXptMode=SYNC;
DGMGRL> EDIT DATABASE STBY SET PROPERTY
> LogXptMode=SYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
> MaxAvailability;
> LogXptMode=ASYNC;
DGMGRL> EDIT DATABASE STBY SET PROPERTY
> LogXptMode=ASYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
> MaxPerformance;

Fast Start Failover - Threshold
206
EDIT CONFIGURATION
SET PROPERTY FastStartFailoverThreshold =
threshold-val;
Banco de dados
Standby
PRIM

Propriedades Adicionais
 FastStartFailoverLagLimit: Estabelece um
tempo limite para que o banco de dados standby
aplique os redo logs vindos do banco de produção.
 FastStartFailoverPmyShutdown: Informa se o
servidor primário será desligado, caso haja algum
gap no envio dos arquivos de redo log, ou se houver
perda de conectividade com o observer.
 FastStartFailoverAutoReinstate: Informe
se o antigo banco de dados primário vai sofrer o
processo de reinstate caso um failover automático
aconteça.
207

Lag Time Limit
 O propriedade FastStartFailoverLagLimit configura
um tempo máximo de tolerância para atraso no
recebimento dos arquivos de redo log, no modo de
máxima performance.
 Destinos que recebem os arquivos de redo no modo
ASYNC são aceitáveis para fast start failover.
 É necessário estar usano real-time-apply.
208
DGMGRL> EDIT CONFIGURATION
> SET PROPERTY FastStartFailoverLagLimit = {n};

Shutdown Automático
 Você pode definir se o servidor primário vai sofrer
um shutdown automático, caso a geração de redo
pare ou atrase, ou haja perda de conectividade
com o observer, além do período definido no
threshold.
 Acerte o valor para TRUE.
209
DGMGRL> EDIT CONFIGURATION SET PROPERTY
> FastStartFailoverPmyShutdown = {TRUE|FALSE};

Reinstate Automático
 Você pode definir se o servidor primário vai sofrer
um reinstate automático, haja um failover
automático por falta de comunicação com o
observer, ou com o banco de dados standby.
 Acerte o valor para TRUE.
210
DGMGRL> EDIT CONFIGURATION SET PROPERTY
> FastStartFailoverAutoReinstate = {TRUE | FALSE};

Identificador de Conexão
 Você pode definir um identificador de conexão
para especificar como o observer deve se conectar
e monitorar um standby database.
 Habilitando essa propriedade, o observer usa para
controlar o envio dos arquivos de redo log.
 Por default ele assume o valor da propriedade já
definida antes DGCOnnectIdentifier.
211
DGMGRL> EDIT DATABASE PRIM
> SET PROPERTY ObserverConnectIdentifier = 'PRIM';

Condições de Failover
 Dentro do DG Broker você pode usar propriedade
ENABLE/DISABLE FAST_START_FAILOVER.
 O observer iniciar o processe de monitoramento
para fast start failover automaticamente.
 Condições configuráveis:
 Situações apontadas pelo health check.
 Erros lançados pelo próprio servidor.
 Use o comando SHOW FAST_START_FAILOVER
para ver a lista de condições habilitadas.
212
ENABLE FAST_START FAILOVER CONDITION "value";

Condições de Failover
 Condições adicionais para o FSFO.
 Valores default: Datafile Offline, Corrupted
Controlfile e Corrupted Dictionary.
213
Condição Descrição
Datafile Offline Datafile off-line por erro de escrita.
Corrupted Controlfile Controlfile corrompido
Corrupted Dictionary Corrupção lógica de objeto importante
do dicionário de dados.
Inaccessible Logfile LGWR não consegue escrever devido
a erros de I/O
Stuck Archiver Impossibilidade de gerar archivelogs
ORA-00257

Fast Start Failover – Enable
214
DGMGRL> ENABLE FAST_START FAILOVER;
Banco de dados
de produção
Banco de dados
Standby

Start Observer
215
DGMGRL> START OBSERVER;
Banco de dados
de produção
Banco de dados
Standby

Checando a Configuração
216
DGMGRL> show configuration verbose
Configuration
Name: DGConfig1
Enabled: YES
Databases:
- Fast-Start Failover target
Fast-Start Failover: ENABLED
Threshold: 90 seconds
Target: STBY
Observer: ordt-srv-001
Lag Limit: 60 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
SUCCESS

217
DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
Threshold: 90 seconds
Target: STBY
Observer: ordt-srv-001
Lag Limit: 60 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle Error Conditions:
(none)

FSFO - Aplicação
218
PRIM
Observer
STBY
DBMS_DG.INITIATE_FS_FAILOVER

FSFO - Aplicação
 A package DBMS_DG, contém uma procedure de
nome INITIATE_FS_FAILOVER, que pode ser
utilizada para executar um failover diretamente
pela aplicação.
 Para que a aplicação possa usar desta
característica, o usuário deve ter direitos de
execução nesta package.
219
FUNCTION dbms_dg.initiate_fs_failover
(condstr IN VARCHAR2) RETURN BINARY_INTEGER;

220
SELECT fs_failover_status as STATUS,
fs_failover_current_target as CURR_TGET,
fs_failover_threshold as THRESHOLD,
fs_failover_observer_present as OBS_PRES,
fs_failover_observer_host as OBS_HOST
FROM v$database;
STATUS CURR_TGET THRESHOLD OBS_PRES
---------------------- --------- --------- --------
TARGET UNDER LAG LIMIT STBY 90 YES
OBS_HOST
-----------------------
Ordt-srv-001

Porque houve um FSFO?
 Quando houver um failover e você quiser/precisar
descobrir a razão, execute a query abaixo:
221
SQL> SELECT last_failover_time, last_failover_reason
2 FROM v$fs_failover_stats;
LAST_FAILOVER_TIME LAST_FAILOVER_REASON
-------------------- ------------------------------
02/14/2008 22:30:12 Primary Disconnected

Operações Proibidas
 Após habilitar o FSFO, algumas operações que
podem danificar o funcionamento do ambiente se
tornam proibidas, como:
 Alterar a configuração para máxima proteção.
 Alterar a propriedade LogXptMode.
 Desabilitar a configuração do DG Broker.
 Desabilitar/Remover um standby database que faça
parte do FSFO.
 Fazer um failover ou switchover para um servidor fora
da configuração do FSFO.
222

Fast Start Failover – Disable
223
DGMGRL> DISABLE FAST_START FAILOVER [FORCE];
Banco de dados
de produção
Banco de dados
Standby

Desabilitando Condições
 Ao utilizar o FSFO, você pode (se for o caso)
desabilitar algumas condições que disparam o
processo. Exemplo:
224
DGMGRL> DISABLE FAST_START FAILOVER CONDITION value;

Opção FORCE
 A opção FORCE, pode ser utilizada em algumas
situações especificas como:
 O ambiente está sincronizado e perde conectividade
com o observer e o standby database.
 Prevenir que um FSFO aconteça, explicitamente.
 Um failover manual, quando o FSFO está fora de
sincronia.
225

Parando o Observer
226
DGMGRL> STOP OBSERVER;
Banco de dados
de produção
Banco de dados
Standby

Manual Reinstate
227
DGMGRL> REINSTATE DATABASE PRIM;
Banco de dados
de produção
Banco de dados
Standby

Observer em novo host
 Se precisar você pode mover seu observer para um
novo host, para isso execute:
 Executar o comando STOP OBSERVER, para romper a
comunicação entre ele e os servidores de produção e
standby.
 Com o comando SHOW CONFIGURATION VERBOSE.
Veja se a configuração aceitou o stop.
 Inicie o observer em outro host.
228

Resumo
 Configurar o Fast Start Failover.
 Ver as configurações do Fast Start Failover.
 Gerenciar o Observer.
 Role transition com Fast Start Failover.
 Manual Reisntate do banco de dados primário.
229

Snapshot
Standby
Database

Neste Capítulo
 Criar um snapshot standby database a partir de um
standby database físico.
 Converter um snapshot standby database de volta
para um standby database físico.
231

Overview
 Um snapshot standby database, é um banco de
dados que pode ser completamente alterado após
a sua criação, e depois ser convertido em um
standby físico novamente.
 Durante o período de snapshot standby, o archives
são recebidos mas não aplicados.
 Quando um standby físico é convertido para
snapshot, implicitamente é criado um restore point e
o Flashback Database é habilitado.
232

Conversão
Físico > Snapshot
 Para criar um snapshot standby, primeiro crie um
standby físico e na sequencia o converta para um
standby lógico:
234
DGMGRL> CONVERT DATABASE STBY
>TO SNAPSHOT STANDBY;
Converting database "STBY" to a Snapshot Standby
database, please wait...
Database "STBY" converted successfully

Atenção
 Potencial perda de dados com archivelogs
corrompidos.
 Longo tempo de conversão de um snapshot standby
database para um banco de dados primário caso
haja falhas no banco de dados primário original.
235

Restrições
 Um snapshot standby database não pode ser:
 O único standby database no modo de máxima
proteção.
 O “target” (alvo) no caso de um switchover.
 O “target” (alvo) no caso de um fast start failover.
236

Consultando SQL*Plus
 Para saber qual “role” se encontra seu servidor,
você pode executar o select:
237
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
SNAPSHOT STANDBY

Consultando DGMGRL
 Para ver as informações de seu snapshot standby
database pelo DGMGRL execute o comando
SHOW CONFIGURATION VERBOSE:
238
DGMGRL> show configuration
Configuration
Name: DGConfig
Enabled: YES
Databases:
STBY - Snapshot standby database
Current status for "DGConfig":
SUCCESS

Consultando DGMGRL
 Para informações especificas de seu banco de
dados, use SHOW DATABASE [NOME DO BANCO]
239
DGMGRL> show database pc00sby1
Database
Name: pc00sby1
Role: SNAPSHOT STANDBY
Enabled: YES
Intended State: APPLY-OFF
Instance(s):
pdb1
Current status for "pc00sby1":
SUCCESS

Voltando para Standby Físico
 Para transformar seu standby snapshot de volta em
um standby físico, execute o comando:
240
DGMGRL> CONVERT DATABASE STBY TO PHYSICAL STANDBY;

Resumo
 Criar um snapshot standby database a partir de um
standby database físico.
 Converter um snapshot standby database de volta
para um standby database físico.
241

Active
Data Guard

Neste Capítulo
 Usar o Real-Time Query para acessar o standby físico.
 Habilitar “block change tracking” para um standby
físico.
243

Oracle Active Data Guard
 Uma option (licenciada à parte) que nasceu na
versão 11g do Oracle database.
 Melhora a qualidade do serviço, eliminando a
necessidade de executar relatórios “pesados” no
banco de produção, a abrir o standby para leitura.
 Features inclusas:
 Real-Time Query
 RMAN Block change trancking.
244

Habilitando Real-Time Apply
 Pare o processo de aplicação de redo:
 Abra o banco de dados:
 Reinicie o processo de aplicação de redo:
246
DGMGRL> EDIT DATABASE 'STBY' set state='apply-off';
Succeeded.
DGMGRL> EDIT DATABASE 'STBY' set state='apply-on';
Succeeded.
SQL> ALTER DATABASE OPEN;
Database Altered.

Desabilitando Real-Time Apply
 Shutdown a instancia standby.
 Reinicie a instancia standby em modo MOUNT.
247
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

Block Change Tracking
 É habilitado no banco de dados standby para que
backups incrementais sejam executados mais
rapidamente.
 Toda vez que um bloco for alterado (após um
backup) ele é registrado no arquivo do block
change tracking.
 É um arquivo binário usado pelo RMAN para
registrar o endereço dos blocos com alterações.
248

 Otimiza o processo de backup incremental.
 Registra os blocos alterados desde o ultimo backup.
 É usado um arquivo binário para este procedimento.
 Os blocos são gerados quando a transação gera redo.
 A instancia identifica os blocos automaticamente.
249

 Para habilitar o block change tracking, use o
SQL*Plus ou o Enterprise Manager.
250
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
[USING FILE ......];

 Monitoramento:
251
SQL> SELECT filename, status, bytes
2 FROM v$block_change_tracking;
SQL> SELECT file#, avg(datafile_blocks),
2 avg(blocks_read),
3 avg(blocks_read/datafile_blocks)
4 * 100 AS PCT_READ_FOR_BACKUP,
5 avg(blocks)
5 FROM v$backup_datafile
6 WHERE used_change_tracking = 'YES'
7 AND incremental_level > 0
8 GROUP BY file#;

Resumo
 Usar o Real-Time Query para acessar o standby físico.
 Habilitar “block change tracking” para um standby
físico.
252

Backup &
Recovery

Neste Capítulo
 Usar o RMAN para backup/restore em Data Guard
 Backup Offloads no Standby Database.
 Recuperar o banco de dados de produção usando um
backup do banco de dados standby
254

RMAN e Data Guard
 RMAN pode ser usado para as operações de backup,
restore e recover em um ambiente com Data Guard.
 Backups do standby database físico podem ser usados
no banco de dados primário.
 Backups de standby databases lógicos não são uteis no
banco de dados primário.
 O uso do catalogo do RMAN é obrigatório com o uso
do Data Guard.
 RMAN e Data Guard (boas práticas)
 Faça backups no banco de dados primário e standby, para
reduzir o MTTR.
 Use backups incrementais.
255

RMAN e Data Guard
 Backups com o RMAN de datafiles e archivelogs
são completamente intercambiáveis entre os dois
ambientes.
 Backups de controlfile NÃO!
 Banco de dados primário e standby, precisam usar
o mesmo catálogo.
 Não é preciso registrar o standby database no
catálogo.
256

Importante
 Seu standby database deve ser físico.
 Você deve estar conectado ao catálogo quando for
fazer o backup.
 Você deve estar conectado ao standby físico como
TARGET quando for fazer o backup.
257

Standby Lógico
 Backup Considerações:
 Use a mesma politica de backup que o banco de
dados primário.
 Os backups não são intercambiáveis entre as
instancias.
 Recovery Considerações:
 Se perder arquivos individuais, faça o recovery normal
como um banco de dados de produção.
 Se perder todo seu standby database, recrie do
“zero”.
 Use uma cópia comum do controlfile para restaurá-lo
em caso de perdas.
258

Catálogo do RMAN
 Ao usar o catálogo do RMAN, é possível que o
backup de um servidor possa ser restaurado no
outro.
 O catálogo do RMAN usa os meta dados de
maneira transparentemente através das instancias
na configuração do Data Guard.
 Use um servidor separa para o catálogo (nem o
primário nem o standby), pois em caso de algum
desastre, seus backups não estarão comprometidos.
259

Criando o Catálogo
 Crie um banco de dados.
 Crie o usuário com RECOVERY_CATALOG_OWNER.
 No RMAN crie o catálogo.
260

Criando o Catálogo
 Registro o banco de dados primário no catálogo.
 O standby database é registrado automaticamente,
quanto o comando CONFIGURE_DB_UNIQUE_NAME é
executado.
 Ações do RMAN:
 Cria algumas linhas em tabelas do owner do catalogo.
 Copia os dados do controlfile do target database
para tabelas do catálogo.
261
$ rman target / CATALOG user/pass@tns_alias
RMAN> CREATE CATALOG;
RMAN> REGISTER DATABASE;

Configurações Persistentes
 No comando CONFIGURE, use uma clausula a mais
para que as configurações tenham efeito no
standby database: FOR DB_UNIQUE_NAME.
 Você não deve conectar no standby database ou
no banco de dados primário como target.
 O RMAN deve estar conectado no catálogo
quando qualquer alteração, configuração for feita.
262
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON for db_unique_name STBY;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored.

 Política de retenção:
 Politica para expurgo dos archivelogs.
 Identificadores de conexão:
263
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
RMAN> CONFIGURE DB_UNIQUE_NAME PRIM CONNECT IDENTIFIER ‘PRIM’;
RMAN> CONFIGURE DB_UNIQUE_NAME STBY CONNECT IDENTIFIER ‘STBY’;

 Use os parâmetros para backups em bancos de
dados standby físicos.
 Backup automático do controlfile:
 Ignore datafiles que já tenham backups recentes, para
evitar duplicar backups e desperdiçar recursos.
 Quando deletar os archivelogs.
264
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE BACKUP OTIMIZATION ON;
RMAN> CONFIGURE ARCHIVELOG DELETETION POLICY TO BACKED UP 1 TIMES
2> TO DEVICE TYPE DISK;

 Se você optar por não fazer backup de seu
standby database, é possível especificar que seus
archivelogs sejam deletados imediatamente após
serem aplicados:
265
RMAN> CONFIGURE ARCHIVELOG DELETETION POLICY TO APPLIED ON ALL STANDBY;

Backups incrementais
 Você pode usar uma estratégia de backup assim:
 Primeiro dia: Um backup full.
 Segundo dia: Um backup incremental.
 Terceiro dia: Um backup incremental.
Os backups feitos no dia anterior, podem ser mesclados com o
backup atual. Script exemplo:
266
RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RMAN> RECOVER COPY OF DATABASE WITH TAG ‘DGBKP’;
RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY
2> WITH TAG ‘DGBKP’ DATABASE;
RMAN> BACKUP DEVICE TYPE DISK ARCHIVELOG ALL;
RMAN> BACKUP BACKUPSET ALL;
RMAN> DELETE ARCHIVELOG ALL;

Recover de Datafile
Instancia Primária
 Usando backups.
 Usando um datafile do standby database.
267
RMAN> RESTORE DATAFILE 5;
RMAN> RECOVER DATAFILE 5;

Recover de Datafile
Entre Instancias (S x P)
 Conecte no standby database como TARGET e na
instancia auxiliar como AUXILIARY.
 Faça o backup do datafile na instancia standby
para a instancia primária, já colocando-o em seu
local definitivo:
268
RMAN> BACKUP AS COPY DATAFILE 5 AUXILIARY FORMAT ‘/disk001/df005.dbf’
RMAN> CONNECT TARGET sys/oracle_4U@STBY
RMAN> CONNECT AUXILIARY sys/oracle_4U@PRIM

Recover de Datafile
Entre Instancias (S x P)
 Conecte no banco de dados primário como TARGET
e também no catalogo do RMAN.
 Catalogue o datafile:
 Faça um switch de datafile:
269
RMAN> CONNECT TARGET sys/oracle_4U@PRIM
RMAN> CONNECT CATALOG rcatowner/oracle_4U@CATDB
RMAN> CATALOG DATAFILECOPY ‘/disk001/df005.dbf’;
RMAN> run {
2> SET NEWNAME FOR DATAFILE 5 TO ‘/disk001/df005.dbf’;
3> switch datafile 5;
4> }

Recover de Datafile
Entre Instancias (P x S)
 Se os archivelogs estiverem acessíveis:
 Execute RESTORE DATAFILE.
 Reinicie o processo de Redo-Apply.
 Se os archivelogs não estiverem disponíveis:
 Restause o datafile: RESTORE DATAFILE
 Recupere o banco de dados, até o último SCN
disponível.
 Reinicie o processo de Redo-Apply
 Use o datafile corrente do banco de dados
primário.
270

Resumo
 Usar o RMAN para backup/restore em Data Guard
 Backup Offloads no Standby Database.
 Recuperar o banco de dados de produção usando um
backup do banco de dados standby
271

Conectividade

Neste Capítulo
 Configurar a conectividade dos clients em um ambiente
com Data Guard.
 Implementar os procedimentos de failover automático e
redirecionamento dos clients para um novo banco de
dados primário.
273

Entendendo
 Usando Data Guard esteja ciente que:
 Os bancos de dados encontram-se em diferentes hosts.
 Os clients deve se conectar em:
 Bancos de dados primários.
 Bancos de dados Standby Físicos (Active Data Guard).
 Bancos de dados Standby Lógicos.
 Bancos de dados Snapshots Standby.
 Se os clients enviarem conexões para um banco de
dados standby (erroneamente) receberão uma
mensagem de erro.
 Os clients devem se reconectar automaticamente ao
banco de dados correto, caso haja um failover.
274

Entendendo
275
PRIM STBY
Listener
PRIM = (DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = HOST-01)(PORT = 1521))
(ADDRESS=(PROTOCOL = TCP)(HOST = HOST-02)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = PRIM)))

Evitando Erros
 Use “serviços” (DBMS_SERVICE) para prevenir que
seus usuários conectem-se na base de dados
errada.
 Serviços vão funcionar como uma camada de
abstração entre as instancias.
 Registre os serviços no listener de cada instancia.
 Conecte os clients nos serviços e não nas instancias
diretamente.
 Listeners podem redirecionar as conexões para a
instancia correta em caso de falhas.
276

Serviços
 Para gerenciar os serviços dentro de cada banco
de dados, use a package DBMS_SERVICE.
 Atributos dos serviços:
 Service Name: Para administração do serviço.
 Network Name: Para conexões externas.
 Transparent Application Failover (TAF): Para a
implementação de failovers automáticos.
277

Entendendo
278
PRIM STBY
Listener
PRIM = (DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-01)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = PRIM)))
Listener

Criando Serviços
279
DBMS_SERVICE.CREATE_SERVICE( -
SERVICE_NAME => 'DG_PROD', -
NETWORK_NAME => 'DG_PROD', -
FAILOVER_METHOD => 'BASIC', -
FAILOVER_TYPE => 'SELECT', -
FAILOVER_RETRIES => 180, -
FAILOVER_DELAY => 1);
SERVICE_NAME => 'DG_RTQ', -
NETWORK_NAME => 'DG_RTQ');
SERVICE_NAME => 'DG_LSBY', -
NETWORK_NAME => 'DG_LSBY');
SERVICE_NAME => 'DG_SNAP', -
NETWORK_NAME => 'DG_SNAP');

Serviços
 Use uma trigger de evento de banco de dados
para garantir a conectividade no “momento certo”
com o “papel certo”.
 Com o banco de dados no “papel” errado, a
trigger garante que nada seja acessível.
 Use uma trigger para inicializar os serviços.
 DG_PROD: Banco de dados primário/produção.
 DG_RTQ: Standby físico no modo REAL TIME QUERY.
 DG_SNAP: Snapshot Standby.
 DG_LSBY: Standby lógico.
280

Serviços (Trigger)
281
CREATE TRIGGER MANAGE_SERVICES AFTER STARTUP ON DATABASE
DECLARE
ROLE VARCHAR(30);
OMODE VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO ROLE FROM V$DATABASE;
SELECT OPEN_MODE INTO OMODE FROM V$DATABASE;
IF ROLE = 'PRIMARY' THEN
DBMS_SERVICE.START_SERVICE ('DG_PROD');
ELSIF ROLE = 'PHYSICAL STANDBY' THEN
IF OMODE = 'READ ONLY' THEN
DBMS_SERVICE.START_SERVICE ('DG_RTQ');
END IF;
ELSIF ROLE = 'LOGICAL STANDBY' THEN
DBMS_SERVICE.START_SERVICE ('DG_LSBY');
ELSIF ROLE = 'SNAPSHOT STANDBY' THEN
DBMS_SERVICE.START_SERVICE ('DG_SNAP');
END IF;
END;
/

Serviços (tnsnames)
282
PROD = (DESCRIPTION =
(CONNECT_DATA = (SERVICE_NAME = DG_PROD)))
RTQ = (DESCRIPTION =
(CONNECT_DATA = (SERVICE_NAME = DG_RTQ)))
SNAP = (DESCRIPTION =
(CONNECT_DATA = (SERVICE_NAME = DG_SNAP)))
LSBY = (DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = ORDT-02) PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = DG_LSBY)))

Failover Automático
 Realoque os serviços de banco de dados no novo
banco de dados primário, como parte do seu
processo de failover.
 Notifique os clients que um failover ocorreu.
 Redirecione os clients para o novo banco de dados
primário.
283

Failover Automático
Componentes Client
 Você pode fazer uso das seguintes features no
processo de failover, a fim de minimizar os
impactos aos clientes.
 Connect time failover.
 Fast Application Notification.
 Fast Connection Failover.
 DB_ROLE_CHANGE Evento de sistema.
284

Client Failover
Melhores Práticas
 Use OCI e FAN OCI
 AQ_HA_NOTIFICATIONS.
 Configure DBC para Fast Connection Failover e
FAN ONS:
 ONS deamons no servidor primário e standby.
 Clients JDBC usam remote subscriptions para todos os
deamons.
 Implemente ADDRESS_LIST transversal.
 OCI OUTBOUUND_CONNECT_TIMEOUT
 JDBC SQLnetDef.TCP_CONNTIMEOUT_STR
285

Client Failover
Melhores Práticas
 Na instancia de banco de dados:
 Use DBMS_SERVICE.CREATE_SERVICE para criar um
serviço e habilitar politicas de HA TAF e etc.
 Crie uma trigger de banco de dados para que o
serviço seja realocado de maneira correta, após a
“role transition” do banco de dados.
 Configure OCI Clients.
 Use o parâmetro OCI Events para inicializar o
ambiente.
 Defina SQLNET.OUTBOUND_CONNECT_TIMEOUT no
sqlnet.ora para um valor de 3 segundos.
 Registre um event call-back.
286

Clients OLE DB
 Na instancia de banco de dados, garanta que o
data guard broker gerencie e configuração.
 Execute DBMS_SERVICE.CREATE_SERVICE para
criar um serviço e habilitar a HA juntamente com
TAF.
 Crie uma trigger de banco de dados para realocar
o serviço depois da “role transition”.
287

Clients OLE DB
 Na string de conexão, defina os atributos
DBNotifications e DBNotificationPort e OraOLEDB.
 No arquivo sqlnet.ora, defina o parâmetro
SQLNET.OUTBOUND_CONNECT_TIMOUT para um
valor de 3 segundos.
288

Clients JDBC
 Execute DBMS_SERVICE.CREATE_SERVICE para
criar um serviço e habilitar a HA juntamente com
TAF.
 Configure o ONS no diretório:
 $ORACLE_HOME/opmn/conf
 Inicie o deamon do ONS.
 Crie uma trigger de banco de dados para realocar
o serviço depois da “role transition”.
 Crie a trigger com o evento de sistema
DB_ROLE_CHANGE.
289

Clients JDBC
 Os parâmetro a seguir devem ser definidos como TRUE:
 FastConnectionFailoverEnabled.
 DataSource.
 Em seu data source a propriedade a seguir deve ser
definida com o valor de 3 segundos.
 oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR
 Crie um serviço que tenha no atributo “host” o hostname
do servidor de produção e de todos os servidores
standby.
 Configure subscrição remota no ONS para o client
JDBC.
 Habilite comunicações via SSL.
290

Resumo
 Configurar a conectividade dos clients em um ambiente
com Data Guard.
 Implementar os procedimentos de failover automático e
redirecionamento dos clients para um novo banco de
dados primário.
291

Treinamento Data Guard

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Treinamento Data Guard

Treinamento Data Guard