Este documento descreve como configurar um banco de dados primário e standby físico utilizando o Oracle Data Guard. Ele explica como preparar o servidor primário definindo parâmetros como FORCE LOGGING, standby redo logs e LOG_ARCHIVE_DEST para transportar os logs para o standby. Também mostra como criar a instância standby usando o RMAN para duplicar o banco de dados primário.
2. 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
3. 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
4. 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.
5. 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
7. 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
9. 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
10. 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
11. 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
12. 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
14. 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
19. 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
20. 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
21. 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
22. 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
23. 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
25. Neste Capítulo
Neste capítulo você vai aprender:
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
26. 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
27. 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
28. 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
30. 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.
31. 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
5 STANDBY /u01/app/oracle/oradata/pc00prmy/srl02.log
6 STANDBY /u01/app/oracle/oradata/pc00prmy/srl03.log
7 STANDBY /u01/app/oracle/oradata/pc00prmy/srl04.log
SQL> SELECT group#, dbid, thread#, sequence#, status
2 FROM v$standby_log;
GROUP# DBID THREAD# SEQUENCE# STATUS
---------- ---------- ---------- ---------- ----------
4 UNASSIGNED 0 0 UNASSIGNED
5 UNASSIGNED 0 0 UNASSIGNED
6 UNASSIGNED 0 0 UNASSIGNED
7 UNASSIGNED 0 0 UNASSIGNED
32. 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.
33. 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)'
34. 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;
37. 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
38. 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.
39. 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/’);
40. 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/’);
41. 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;
44. 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)
)
)
45. 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
46. 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
47. 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
48. 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
49. 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’
50. 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';
}
51. 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
53. 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;
54. Resumo
Neste capítulo foi abordado:
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
56. Neste Capítulo
Neste capítulo você vai aprender:
Arquitetura.
Conceitos.
Benefícios.
Configurações.
Usar o DGMGRL para gerenciar seu ambiente.
56
57. 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
58. 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
59. 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
62. 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
63. 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
64. 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.
65. 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
66. 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
69. 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
70. Resumo
Neste capítulo foi abordado:
Arquitetura.
Conceitos.
Benefícios.
Configurações.
Usar o DGMGRL para gerenciar seu ambiente.
Linha de comando.
OEM 12c.
70
71. Oracle Data Guard – Implementação & Manutenção
Criando o
Data Guard
Broker
72. Neste Capítulo
Neste capítulo você vai aprender:
Criar as configurações do Data Guard Broker.
Gerenciar o seu ambiente com o Data Guard Broker.
72
73. 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
74. 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
75. 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
76. 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
77. 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
78. 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
79. 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>
80. Habilitando a Configuração
80
DGMGRL> ENABLE CONFIGURATION;
Enabled.
DGMGRL> SHOW CONFIGURATION
Configuration
Name: DGConfig1
Enabled: YES
Protection Mode: MaxPerformance
Databases:
PRIM - Primary database
STBY - Physical standby database
Fast-Start Failover: DISABLED
Current status for "DGConfig1":
SUCCESS
81. 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';
82. 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
83. 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
84. 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
87. 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
88. 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;
89. Resumo
Neste capítulo foi abordado:
Criar as configurações do Data Guard Broker.
Gerenciar o seu ambiente com o Data Guard Broker.
89
91. Neste Capítulo
Neste capítulo você vai aprender:
Determinar quando criar um Data Guard Lógico.
Criar um Data Guard Lógico.
Gerenciamento do SQL-Apply.
91
92. 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
93. 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
96. 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
97. 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
98. 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
99. 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.
100. 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.
101. 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
102. 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
103. 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;
104. 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
105. Criando o Data Guard Lógico
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
106. Criando o Data Guard Lógico
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.
107. Criando o Data Guard Lógico
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
108. 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;
109. 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;
110. 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;
111. 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>
112. 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;
113. 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;
114. 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
116. 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
117. 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
118. 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
119. 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
120. 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
121. Resumo
Neste capítulo foi abordado:
Determinar quando criar um Data Guard Lógico.
Criar um Data Guard Lógico.
Gerenciamento do SQL-Apply.
121
123. Neste Capítulo
Neste capítulo você vai aprender:
Descrever e entender os modos de proteção.
Alterar os modos de proteção de sua configuração.
123
124. 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
125. 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
126. 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
127. 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
128. 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
129. 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
130. 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.
131. Resumo
Neste capítulo foi abordado:
Descrever e entender os modos de proteção.
Alterar os modos de proteção da sua configuração.
131
132. Oracle Data Guard – Implementação & Manutenção
Monitoramento
Do
Data Guard
133. Neste Capítulo
Neste capítulo você vai aprender:
Usar o OEM Cloud Control para monitoramento.
Usar o DGMGRL para monitoramento e status.
133
134. 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
136. 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
139. 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';
140. 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';
141. DGMGRL Diagnóstico
Comando SHOW CONFIGURATION:
Fornece um resumo das configuração de seu ambiente:
141
DGMGRL> show configuration
Configuration
Name: DGConfig1
Enabled: YES
Protection Mode: MaxPerformance
Databases:
PRIM - Primary database
STBY - Physical standby database
STBY2 - Physical standby database
Fast-Start Failover: DISABLED
Current status for "DGConfig1":
SUCCESS
142. 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
144. 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
5 /u01/app/oracle/oradata/STBY/srl02.log
6 /u01/app/oracle/oradata/STBY/srl03.log
7 /u01/app/oracle/oradata/STBY/srl04.log
145. SQL*Plus Diagnóstico
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
147. 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
148. SQL*Plus Diagnóstico
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
ARCH CLOSING 4 1 146
ARCH CLOSING 4 1 148
ARCH CLOSING 5 1 141
ARCH CLOSING 5 1 147
MRP0 APPLYING_LOG N/A 1 149
RFS IDLE 2 1 149
RFS IDLE N/A 0 0
RFS IDLE N/A 0 0
149. SQL*Plus Diagnóstico
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
150. SQL*Plus Diagnóstico
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
13-FEB-08 Remote File Ser 0 564 0
Standby controlfile consistent with primary
13-FEB-08 Remote File Ser 0 565 0
RFS[25]: Successfully opened standby log 5:
'/u01/app/oracle/oradata/pc00sby1/srl02.log'
151. SQL*Plus Diagnóstico
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;
152. Resumo
Neste capítulo foi abordado:
Usar o OEM Cloud Control para monitoramento
Usar o DGMGRL para monitoramento e status.
152
153. Oracle Data Guard – Implementação & Manutenção
Otimizando
o
Data Guard
154. Neste Capítulo
Neste capítulo você vai aprender:
Monitorar a performance do Data Guard.
Otimizar o transporte para melhor performance.
Otimizar a aplicação dos SQL.
154
155. Performance via OEM
Você pode monitorar a performance de seu
ambiente via Enterprise Manager.
155
156. 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
157. Otimizando a Performance
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;
158. Otimizando a Performance
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;
160. Otimizando a Performance
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;
161. Otimizando a Performance
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';
162. Otimizando a Performance
Delay (atraso intencional) na aplicação dos redos:
Pode ajudar a previnir:
Corrupção de dados.
Erros humanos.
162
PRIM STBY
163. Otimizando a Performance
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;
164. Otimizando a Performance
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
165. Otimizando a Performance
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%';
166. Otimizando a Performance
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
2 FROM V$LOGSTDBY_PROCESS
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';
167. Otimizando a Performance
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
2 FROM V$LOGSTDBY_PROCESS
3 WHERE TYPE = 'APPLIER' and status_code = 16166;
168. Resumo
Neste capítulo foi abordado:
Monitorar a performance do Data Guard.
Otimizar o transporte para melhor performance.
Otimizar a aplicação dos SQL.
168
170. Neste Capítulo
Neste capítulo você vai aprender:
Vantagens de Flashback com Data Guard.
Configurar o Flashback Database.
170
171. 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
172. 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
173. 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
177. 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
178. Flashback Database
Após um Failover178
Redo
Redo
DB Primário
Novo DB Standby
DB Standby
Novo DB Primário
Flashback Failover
179. Resumo
Neste capítulo foi abordado:
Vantagens de Flashback com Data Guard.
Configurar o Flashback Database.
179
181. Neste Capítulo
Neste capítulo você vai aprender:
Explicar as duas roles possíveis em um Data Guard.
Executar um switchover.
Executar um Failover.
181
182. 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
183. 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
184. 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
185. 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
187. 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
188. 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"
189. 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
190. 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
191. 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
192. 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
193. 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
194. 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];
195. 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;
196. Resumo
Neste capítulo foi abordado:
Explicar as duas roles possíveis em um Data Guard.
Executar um switchover.
Perform a failover.
196
198. Neste Capítulo
Neste capítulo você vai aprender:
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
200. Fast Start Failover
Quando não acontece?200
Banco de dados
de produção
Banco de dados
Standby
Observer
> Threshold
Fast Start Failover
201. 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
202. 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
203. 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
204. 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;
205. Modo de Proteção
205
DGMGRL> EDIT DATABASE PRIM SET PROPERTY
> LogXptMode=SYNC;
DGMGRL> EDIT DATABASE STBY SET PROPERTY
> LogXptMode=SYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
> MaxAvailability;
DGMGRL> EDIT DATABASE PRIM SET PROPERTY
> LogXptMode=ASYNC;
DGMGRL> EDIT DATABASE STBY SET PROPERTY
> LogXptMode=ASYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
> MaxPerformance;
206. Fast Start Failover - Threshold
206
EDIT CONFIGURATION
SET PROPERTY FastStartFailoverThreshold =
threshold-val;
Banco de dados
Standby
PRIM
207. 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
208. 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};
209. 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};
210. 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};
211. 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';
212. 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";
213. 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
214. Fast Start Failover – Enable
214
DGMGRL> ENABLE FAST_START FAILOVER;
Banco de dados
de produção
Banco de dados
Standby
219. 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. Checando a Configuração
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
221. 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
222. 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
223. Fast Start Failover – Disable
223
DGMGRL> DISABLE FAST_START FAILOVER [FORCE];
Banco de dados
de produção
Banco de dados
Standby
224. 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;
225. 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
228. 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
229. Resumo
Neste capítulo foi abordado:
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
231. Neste Capítulo
Neste capítulo você vai aprender:
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
232. 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
234. 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
235. 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
236. 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
237. 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
238. 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
Protection Mode: MaxPerformance
Databases:
PRIM - Primary database
STBY - Snapshot standby database
Fast-Start Failover: DISABLED
Current status for "DGConfig":
SUCCESS
239. 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
240. 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;
241. Resumo
Neste capítulo foi abordado:
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
243. Neste Capítulo
Neste capítulo você vai aprender:
Usar o Real-Time Query para acessar o standby físico.
Habilitar “block change tracking” para um standby
físico.
243
244. 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
246. 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.
247. Desabilitando Real-Time Apply
Shutdown a instancia standby.
Reinicie a instancia standby em modo MOUNT.
247
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
248. 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
249. Block Change Tracking
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
250. Block Change Tracking
Para habilitar o block change tracking, use o
SQL*Plus ou o Enterprise Manager.
250
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
[USING FILE ......];
251. Block Change Tracking
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#;
252. Resumo
Neste capítulo foi abordado:
Usar o Real-Time Query para acessar o standby físico.
Habilitar “block change tracking” para um standby
físico.
252
254. Neste Capítulo
Neste capítulo você vai aprender:
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
255. 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
256. 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
257. 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
258. 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
259. 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
260. Criando o Catálogo
Crie um banco de dados.
Crie o usuário com RECOVERY_CATALOG_OWNER.
No RMAN crie o catálogo.
260
261. 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;
262. 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.
263. Configurações Persistentes
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’;
264. Configurações Persistentes
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;
265. Configurações Persistentes
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;
266. 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;
267. Recover de Datafile
Instancia Primária
Usando backups.
Usando um datafile do standby database.
267
RMAN> RESTORE DATAFILE 5;
RMAN> RECOVER DATAFILE 5;
268. 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
269. 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> }
270. 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
271. Resumo
Neste capítulo foi abordado:
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
273. Neste Capítulo
Neste capítulo você vai aprender:
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
274. 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
276. 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
277. 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
280. 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
281. 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;
/
283. 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
284. 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
285. 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
286. 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
287. 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
288. 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
289. 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
290. 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
291. Resumo
Neste capítulo foi abordado:
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