oracle data guard
TRANSCRIPT
1
CENTRO UNIVERSITÁRIO MAURICIO DE NASSAU ESPECIALIZAÇÃO EM BANCO DE DADOS ORACLE
FABIANE TELLES L. MACIEL JOSÉ KARLOS SOARES DA SILVA
WASHINGTON LUIZ VAZ
ORACLE DATA GUARD
Recife
2012
2
FABIANE TELLES L. MACIEL JOSÉ KARLOS SOARES DA SILVA
WASHINGTON LUIZ VAZ
ORACLE DATA GUARD
Trabalho realizado pelos discentes Fabiane Telles L. Maciel, José Karlos Soares da Silva e Washington Luiz Vaz para obtenção de nota na disciplina Procedimentos de Contingência e Alta Disponibilidade, ministrada pelo professor Flavio Rocha
Recife
2012
3
INDICE
INTRODUÇÃO .................................................................................................... 4
1 DATA GUARD .................................................................................................. 5
1.1 Visão geral do Data Guard .................................................................... 6
2 COMO O DATA GUARD FUNCIONA – DETALHES TÉCNICOS ................... 9
2.1 Serviços de transporte do Data Guard ................................................. 9
3 MODOS DE PROTEÇÃO ................................................................................ 12
4 SERVIÇOS DE APLICAÇÃO DO DATA GUARD ............................................ 13
5 REDO APPLY - BANCO DE DADOS FÍSICO EM STANDBY .......................... 14
6 REDO APPLY E ACTIVE DATA GUARD ......................................................... 15
7 SQL APPLY - BANCO DE DADOS FÍSICO EM STANDBY ............................. 17
8 RESOLUÇÃO AUTOMÁTICA DE FALHAS ...................................................... 18
9 VALIDAÇÃO DE DADOS ORACLE ................................................................. 19
10 GERENCIANDO UMA CONFIGURAÇÃO DO DATA GUARD ....................... 20
11 MELHORES PRÁTICAS DO DATA GUARD .................................................. 21
11.1 Melhores práticas para o modo de proteção: ...................................... 24
11.2 Gestor de Recuperação de usar para criar Bancos de Dados ............ 26
11.3 Usar o modo registro FORÇA ............................................................. 27
11.4 Estratégia de arquivamento e Configuração ...................................... 28
12 CRIANDO UMA BASE DE RÉPLICA FÍSICA ................................................. 32
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 44
4
INTRODUÇÃO
As operações comerciais eficazes, o atendimento ao cliente de alta qualidade,
a conformidade com as normas do governo e a proteção dos ativos de informações
corporativas exigem o mais alto nível de proteção e disponibilidade de dados. Sendo
assim, não é de surpreender que a proteção e a disponibilidade de dados estejam
entre as principais prioridades de empresas de todos os tamanhos e diferentes
áreas.
O backup e a recuperação a partir de fita, o espelhamento remoto do
armazenamento ou o envio de log do banco de dados são soluções tradicionais de
proteção de dados e recuperação de desastres (DR). Infelizmente, essas soluções
não conseguem fornecer de forma confiável objetivos agressivos de pontos de
recuperação (RPO - proteção de dados) e tempo de recuperação (RTO -
disponibilidade de dados). Eles também não conseguem fornecer um retorno de
investimento adequado devido aos altos custos de aquisição e utilização ineficaz de
sistemas em standby que ficam ociosos até que sejam chamados para assumir um
papel principal.
O Data Guard está incluído no Oracle Database Enterprise Edition e fornece
os softwares de gerenciamento, monitoramento e automação para criar e manter um
ou mais bancos de dados sincronizados em standby que protegem os dados de
falhas, desastres, erros e corrupção. Ele pode atender às exigências de Alta
disponibilidade e Recuperação de desastres e é ideal para complementar o Oracle
Real Application Clusters.
O Data Guard possui o conhecimento necessário do banco de dados Oracle
para fornecer o mais alto nível de proteção para os dados Oracle. O Data Guard é
direto para implementar e gerenciar. Os administradores estão sempre certos sobre
a capacidade de um banco de dados em standby assumir o papel de produção,
eliminando o risco da empresa de tempo de failover. Finalmente, em uma época em
que todas as empresas precisam reduzir os gastos, os bancos de dados em standby
do Data Guard fornecem alto retorno do investimento quando usados para
consultas, relatórios, backups, testes ou implantação de upgrades no banco de
dados e outras atividades de manutenção, enquanto também fornecem proteção
contra desastres.
5
2 DATA GUARD
“O Active Data Guard 11g é uma solução com retorno rápido! Nós facilmente atribuímos duas funções ao nosso banco de dados em standby de dez terabytes: proteção contra desastres e acesso somente para leitura seguro para nossas aplicações de comércio eletrônico voltadas para o cliente. Ficamos felizes em descobrir, após avaliar outras alternativas, que utilizar nosso banco de dados em standby Data Guard existente era a solução mais simples para fornecer aos clientes acesso constante a informações atualizadas”
(Sue Merrigan, Intermap Technologies)
Oracle Data Guard é a solução para proteção de dados da Oracle,
disponibilidade de dados e recuperação de desastres.
Oracle Data Guard oferece o gerenciamento, monitoramento e software de
automação para criar e manter um ou mais bancos de dados standby para proteger
os dados da Oracle contra falhas, desastres, erro humano, e corrupções de dados,
fornecendo alta disponibilidade para aplicações de missão crítica.
Arquitetura flexível Data Guard oferece proteção de dados e disponibilidade
ideais:
Alterações de dados são transmitidas diretamente da memória, isolando a
espera de I / O corrupções que ocorrem no primário.
Um banco de dados de espera usa um software de código diferente do que o
caminho-primário - isolando-o de erros de firmware e software que impactam o
banco de dados principal.
Oráculo detecção da corrupção de dados assegura que é logicamente e
fisicamente compatíveis antes de ser aplicado a um banco de dados em espera.
Data Guard detecta corrupções silenciosas provocadas por erros de hardware
(memória, CPU, disco, placa de rede) e falhas na transferência de dados, e os
impede de afetar o banco de dados de espera.
Um banco de dados de espera é usado para realizar a manutenção planejada
de forma rolamento, minimizando o tempo de inatividade e eliminar os riscos
inerentes à introdução de mudanças para ambientes de produção.
6
Oracle Active Data Guard 11g estende a funcionalidade da Guarda básico de
dados, permitindo o acesso somente leitura a um banco de dados físico de espera
enquanto continuamente aplicar as alterações recebeu do banco de dados
primário. Isso aumenta o desempenho e retorno sobre o investimento, transferindo
consultas ad-hoc, acesso baseado na Web, relatórios e cópias de segurança do
banco de dados principal, enquanto também fornecendo proteção contra desastres.
2.1 Visão geral do Data Guard
O Oracle Data Guard proporciona a infraestrutura de software de automação,
monitoração e gerenciamento para criar e manter um ou mais bancos de dados em
standby para proteger os dados Oracle contra falhas, desastres, erros e corrupção
de dados. Existem dois tipos de banco de dados em standby. Um standby físico usa
Redo Apply para manter uma réplica exata, bloco a bloco, do banco de dados
principal. Um standby lógico usa SQL Apply e contém as mesmas informações
lógicas que o banco de dados principal, embora a organização física e a estrutura
dos dados possam ser diferentes.
Os administradores podem escolher fazer o failover manual ou automático da
produção para um sistema em standby se o principal falhar para poder manter a alta
disponibilidade para aplicativos de missão crítica. A arquitetura do Data Guard é
descrita na Figura 1. O Data Guard é um dos inúmeros recursos integrados de Alta
disponibilidade (HA) do banco de dados Oracle descritos na Figura 2 que garantem
7
a continuidade dos negócios minimizando o impacto do tempo de inatividade
planejado e não planejado.
Os bancos de dados em standby Data Guard fornecem alto retorno do
investimento também suportando consultas ad-hoc, geração de relatórios, backups
ou atividades de teste, ao mesmo tempo em que fornecem proteção contra
desastres. Especificamente:
• A opção Active Data Guard, disponível a partir do Oracle Database 11g,
permite que um banco de dados físico seja usado para aplicações somente
leitura enquanto recebe simultaneamente atualizações do banco de dados
principal. As consultas executadas em um banco de dados em standby ativo
recebem resultados atualizados.
• O recurso Snapshot Standby permite que um banco de dados físico em
standby seja aberto como leitura-gravação para testes ou qualquer outra
atividade que exija uma réplica dos dados de produção para leitura-gravação.
Um Snapshot Standby continua a receber, mas não a aplicar, as atualizações
geradas pelo banco de dados principal. Essas atualizações são aplicadas no
banco de dados em standby automaticamente quando o Snapshot Standby é
convertido de volta para um banco de dados físico em standby. Os dados do
banco de dados principal sempre permanecem protegidos.
• Um banco de dados lógico em standby tem a flexibilidade adicional de estar
aberto como leitura-gravação. Apesar de os dados que estão sendo mantidos
8
pelo SQL Apply não poderem ser modificados, outras tabelas locais podem ser
adicionadas e estruturas locais de índice podem ser criadas para otimizar a
geração de relatórios ou para utilizar o banco de dados em standby como um
data warehouse ou para transformar a informação usada para carregar
datamarts.
• Os bancos de dados em standby podem ser usados para realizar manutenção
planejada de maneira contínua. A manutenção é realizada primeiro em um
banco de dados em standby. A produção é chaveada para o banco de dados
em standby quando as tarefas de manutenção estiverem concluídas. O único
tempo de inatividade é o temponecessário para efetuar essa operação de
chaveamento. Isso aumenta a disponibilidade e reduz os riscos ao realizar
manutenção no hardware ou no sistema operacional, manutenção no site ou ao
aplicar novos conjuntos de patches do banco de dados, atualizar versões
completas de banco de dados ou implementar outras alterações significativas no
banco de dados.
• Um banco de dados físico em standby, por ser uma réplica exata do banco de
dados principal, pode também ser usado para tirar a sobrecarga dos bancos de
dados principais ao realizar backups.
9
3 COMO O DATA GUARD FUNCIONA – DETALHES TÉCNICOS
Uma configuração do Data Guard inclui um banco de dados de produção,
chamado de banco de dados principal, e até 30 bancos de dados em standby. Os
bancos de dados principal e em standby se conectam através de TCP/IP usando o
Oracle Net Services. Não há restrições em relação à localização dos bancos de
dados desde que eles possam se comunicar entre eles. Um banco de dados em
standby é criado inicialmente a partir de uma cópia de backup do banco de dados
principal. O Data Guard sincroniza automaticamente o banco de dados principal e
todos os seus bancos de dados em standby transmitindo os dados de recuperação
(informação usada pela Oracle para recuperar transações) do banco de dados
principal e aplicando-os no banco de dados em standby.
3.1 Serviços de transporte do Data Guard
Conforme os usuários confirmam as transações no banco de dados principal,
o Oracle gera registros de recuperação e os grava em um arquivo de log on-line
local. Os serviços de transporte do Data Guard transmitem os dados de recuperação
para um banco de dados em standby tanto de forma síncrona como assíncrona,
onde eles são gravados em um arquivo de redo log de standby (etapa um na Figura
3). Os dados de recuperação podem ser transmitidos em um formato comprimido
para reduzir os requisitos de largura de banda através da Opção de Compressão
Avançada Oracle.
O Transporte de dados de recuperação síncrono (SYNC) faz com que o
banco de dados principal aguarde por uma confirmação do banco de dados em
standby de que os dados de recuperação foram gravados em disco antes de
reconhecer o sucesso da confirmação para o aplicativo, proporcionando proteção
com zero de perda de dados. O desempenho do banco de dados principal é
impactado pela soma do tempo necessário para que a E/S do arquivo de redo log
de standby seja concluída e o tempo do percurso de ida e volta da rede.
10
O Data Guard 11g Release 2 é projetado para reduzir o impacto no
desempenho principal do transporte síncrono. Os dados de recuperação são então
transmitidos para o standby remoto em paralelo com a E/S do arquivo de log on-line
local no banco de dados principal, evitando de forma efetiva que a E/S de standby
impacte o tempo total do percurso de ida e volta. Isso possibilita maior separação
geográfica entre os bancos de dados principal e em standby em uma configuração
síncrona com perda de dados zero. Em redes com baixa latência, isso pode reduzir
o impacto da replicação do SYNC no desempenho do banco de dados principal para
próximo de zero, tornando interessante complementar um standby ASYNC remoto
com um standby SYNC local para proteção de alta disponibilidade com perda de
dados zero contra falhas no componente e no banco de dados (falha no SAN, por
exemplo).
O Transporte assíncrono dos dados de recuperação (ASYNC) evita o impacto
no desempenho do banco de dados principal fazendo com que o banco de dados
principal reconheça o sucesso da confirmação para o aplicativo sem aguardar pelo
reconhecimento de que os dados de recuperação tenham sido recebidos pelo banco
de dados em standby. Os aprimoramentos no Data Guard 11g eliminaram
virtualmente qualquer impacto no desempenho do banco de dados principal ao
enviar diretamente do buffer de log principal (em vez de um arquivo de redo log on-
line) e ao melhorar o throughput de rede em redes de longa distância (WAN) de alta
latência. A vantagem de desempenho do ASYNC, entretanto, é acompanhada do
11
potencial de uma pequena quantidade de perda de dados uma vez que não há
garantia de que todos os dados de recuperação tenham sido recebidos pelo banco
de dados em standby.
12
4 MODOS DE PROTEÇÃO
O Data Guard fornece três modos de proteção de dados para equilibrar
custos, disponibilidade, desempenho e proteção de dados. Cada modo usa um
método de transporte de dados de recuperação específico e estabelece regras que
controlam o comportamento da configuração do
Data Guard caso o banco de dados principal perca contato com seu banco de
dados standby. A tabela a seguir descreve as características de cada modo.
13
5 SERVIÇOS DE APLICAÇÃO DO DATA GUARD
Os Serviços de aplicação leem os dados de recuperação de um arquivo de
redo log de standby, valida-os e, em seguida, os aplica no banco de dados em
standby (etapa dois na Figura 3) usando Redo Apply (standby físico) ou SQL Apply
(standby lógico). Observe que os serviços de transporte e de aplicação são
totalmente diferentes. O status ou desempenho da aplicação no standby não
impacta o transporte dos dados de recuperação ou o desempenho do banco de
dados principal. O isolamento é muito importante. O transporte dos dados de
recuperação é o principal determinador do ponto de recuperação, a exposição em
potencial à perda de dados.
Qualquer coisa que impacte negativamente no transporte irá aumentar o
potencial da perda de dados. O transporte dos dados de recuperação em
configurações síncronas é também o principal determinador do impacto no tempo de
resposta e throughput do banco de dados principal.
Qualquer coisa que impacte negativamente no transporte em uma
configuração síncrona pode reduzir o throughput do banco de dados principal e
aumentar o tempo de resposta. O isolamento entre o transporte e a aplicação é
projetado para otimizar o desempenho do banco de dados, o tempo de resposta e a
proteção dos dados.
14
6 REDO APPLY - BANCO DE DADOS FÍSICO EM STANDBY
Um banco de dados físico em standby aplica os dados de recuperação
recebidos do banco de dados principal através do Processo de Recuperação
Gerenciada (MRP), uma extensão de recuperação de mídia padrão da Oracle que
reconhece o Data Guard usada em todos os bancos de dados Oracle. Um banco de
dados físico em standby é idêntico ao banco de dados principal (bloco por bloco) e,
portanto, os esquemas de banco de dados, incluindo os índices, são os mesmos. O
processo MRP ocorre totalmente em paralelo para obter o máximo desempenho. Os
testes de desempenho do Data Guard 11g conduzidos pela Oracle obtiveram taxas
de recuperação de mais de 50 MB/segundo para carga de trabalho estilo OLTP e
mais de 100 MB/segundo para cargas de caminho direto (veja a seção Exadata
posteriormente neste artigo para obter informações sobre os dados de desempenho
específicos para o armazenamento Exadata). O Redo Apply é o método mais
simples, mais rápido e mais confiável de manter réplicas sincronizadas de um banco
de dados principal.
15
7 REDO APPLY E ACTIVE DATA GUARD
A opção Active Data Guard inclui um número de recursos que ampliam a
capacidade do Redo Apply e um banco de dados físico em standby, incluindo:
• A consulta em tempo real permite o acesso somente para leitura a um ou mais
bancos de dados físicos em standby para consultas, classificação, geração de
relatórios, acesso com base na web, etc., enquanto o Redo Apply aplica
continuamente alterações recebidas do banco de dados de produção. Nos
casos onde a carga de trabalho somente leitura pode ser isolada das transações
de leitura-gravação, o Active Data Guard pode efetivamente dobrar a
capacidade de produção através de um banco de dados físico em standby
existente que estava anteriormente ocioso em papel de standby (é possível
adicionar outros bancos de dados em standby ativos à configuração para
dimensionar posteriormente a capacidade de somente leitura sem impactar nas
transações de leitura-gravação).
O Active Data Guard fornece desempenho excepcional – ele pode ser usado
para aplicações de alto throughput onde é impossível para qualquer outro método de
replicação manter o ritmo com o volume de transações gerado pelo banco de dados
de origem.
• Os contratos de serviço (SLA) do Active Data Guard podem ser
implementados através do parâmetro de sessão
STANDBY_MAX_DATA_DELAY. O valor deste parâmetro especifica um limite
para a quantidade de tempo (em segundos) permitida entre o momento em que
as alterações são confirmadas no banco de dados principal e o momento em
que elas podem ser consultadas em um banco de dados em standby ativo (novo
com o Data Guard 11g Release 2).
O banco de dados em standby ativo retornará um código de erro ORA-3172
se o limite for excedido. Os aplicativos podem reagir a este erro da mesma forma
que uma desconexão e redirecionar a consulta para outro banco de dados ativo em
standby ou outro banco de dados principal para obter o SLA exigido.
16
• O Active Data Guard 11g Release 2 possibilita o reparo automático de blocos
corrompidos. A perda de dados no nível de bloco normalmente resulta de erros
de E/S aleatórios e intermitentes, bem como de corrupções na memória que são
gravadas no disco. Quando o Oracle descobre uma corrupção, ele marca o
bloco como mídia corrompida, o grava no disco e normalmente retorna o
resultado de um erro ORA-1578 para o aplicativo. Nenhuma leitura subsequente
do bloco será bem-sucedida até que o bloco seja recuperado manualmente.
Entretanto, se a corrupção ocorrer em um banco de dados principal que tenha
um Active Data Guard em standby, a recuperação da mídia do bloco é realizada
automaticamente, de forma transparente para o aplicativo, usando uma cópia
boa do bloco do banco de dados em standby. Por outro lado, os blocos ruins no
banco de dados em standby são recuperados automaticamente usando a
versão boa do banco de dados principal.
17
8 SQL APPLY - BANCO DE DADOS FÍSICO EM STANDBY
Um banco de dados standby lógico contém as mesmas informações lógicas
que o banco de dados principal, embora a organização física e a estrutura dos
dados possam ser diferentes. O SQL Apply mantém o standby lógico sincronizado
transformando os dados de recuperação recebidos do banco de dados principal em
declarações SQL e, em seguida, executando as declarações SQL em um banco de
dados em standby que seja aberto para leitura-gravação. O SQL Apply tem alguns
restrições em relação aos tipos de dados, tipos de tabelas e tipos de operações DDL
e DML (consulte a documentação para saber os tipos de dados não suportados e os
atributos de armazenagem).
Use o SQL Apply se atender aos pré-requisitos e se:
‘ “O Standby lógico do Data Guard é um componente importante de uma plataforma de hardware e software estratégica e de longa duração, aumentando drasticamente a capacidade e a escalabilidade de nossos usuários. Após a implementação desta solução completa, obtivemos melhorias de desempenho de 50 a 95% na maioria de nossas operações de processamento em massa.”
(David Sink, e-Rewards Market Research)
18
9 RESOLUÇÃO AUTOMÁTICA DE FALHAS
Nos casos onde os bancos de dados principal e em standby se desconectam
(falhas na rede ou no servidor em standby), e dependendo do modo de proteção
usado, o banco de dados principal continuará a processar as transações e acumular
um log de dados de recuperação que não podem ser enviados para o standby até
que uma nova conexão de rede possa ser estabelecida. Enquanto estiver neste
estado, o Data Guard monitora continuamente o status do banco de dados em
standby, detecta quando a conexão for restabelecida e sincroniza novamente de
forma automática o banco de dados em standby com o principal. Nenhuma
intervenção administrativa é necessária desde que os log arquivados necessários
para sincronizar novamente o banco de dados em standby estejam disponíveis em
disco no banco de dados principal. No caso de uma parada longa onde não é viável
reter os logs arquivados necessários, um standby físico pode ser sincronizado
novamente através do backup incremental rápido RMAN do banco de dados
principal.
19
10 VALIDAÇÃO DE DADOS ORACLE
Uma das vantagens mais significativas do Data Guard é a capacidade de usar
os processos da Oracle para validar os dados de recuperação antes de serem
aplicados no banco de dados em standby. O Data Guard é uma arquitetura flexível
associada onde os bancos de dados em standby permanecem sincronizados
aplicando os blocos de recuperação, completamente desassociados de possíveis
corrupções nos arquivos de dados que podem ocorrer no banco de dados principal.
Os dados de recuperação também são enviados diretamente da memória (área
global do sistema) e, portanto, são completamente desassociados de corrupções de
E/S no banco de dados principal.
Verificações para detecção de dados corrompidos ocorrem em várias
interfaces-chave durante o transporte e a aplicação dos dados de recuperação. O
código de software executado no banco de dados em standby é também
fundamentalmente diferente do código do banco de dados principal, isolando de
forma eficaz o banco de dados em standby de erros no firmware e no software que
podem impactar o banco de dados principal.
O standby físico também utiliza o parâmetro: DB_LOST_WRITE_PROTECT
disponível com o Oracle Database 11g Release 1. Uma gravação perdida ocorre
quando um subsistema de E/S reconhece a conclusão de uma gravação enquanto
na verdade a gravação não ocorreu no armazenamento persistente. Em uma leitura
de bloco subsequente, o subsistema de E/S retorna a versão obsoleta do bloco de
dados, que pode ser usada para atualizar outros blocos do banco de dados e,
portanto, corrompendo-o. Quando o parâmetro de inicialização
DB_LOST_WRITE_PROTECT estiver definido, o banco de dados irá gravar leituras
do bloco de cache do buffer no redo log e essa informação será usada pelo recurso
Redo Apply para determinar se houve uma gravação perdida, evitando o tempo de
inatividade e a perda de dados.
20
11 GERENCIANDO UMA CONFIGURAÇÃO DO DATA GUARD
Os bancos de dados principal e em standby e suas diversas interações
podem ser gerenciadas através do SQL*Plus. O Data Guard também oferece uma
estrutura de gerenciamento distribuído chamada Data Guard Broker, que automatiza
e centraliza a criação, manutenção e monitoramento de uma configuração do Data
Guard. Os administradores podem interagir com o Broker usando o Enterprise
Manager Grid Control ou a interface de linha de comando do Broker (DGMGRL).
O Enterprise Manager Grid Control inclui assistentes que simplificam a
criação de uma configuração do Data Guard. As principais métricas do Data Guard,
como o atraso na aplicação, atraso no transporte, taxa de dados de recuperação e
status da configuração, estão incluídos em um novo Console de Alta disponibilidade
consolidado (consulte a Figura 4).
O Enterprise Manager habilita a análise de tendência histórica nas métricas
do Data Guard que ele monitora; por exemplo, qual o desempenho da métrica nas
últimas 24 horas, ou nos últimos 5 dias, etc. Além disso, através do Enterprise
Manager, é possível configurar alarmes de notificação de forma que os
administradores possam ser notificados caso a métrica ultrapasse o valor do limite
configurado.
21
12 MELHORES PRÁTICAS DO DATA GUARD
Data Guard é a solução Oracle otimizado para disponibilidade de dados e
proteção. É excelente em simples, rápido e confiável replicação unidirecional de um
completo banco de dados Oracle para oferecer alta disponibilidade e recuperação de
desastres. Data Guard oferece várias opções de implantação que abordam
interrupções não planejadas, pré-produção, testes e manutenção planejada. Active
Data Guard, uma extensão de capacidades básicas do Data Guard, ainda permite o
descarregamento de produção de somente leitura para uma carga de trabalho
sincronizado standby físico, reparo automático de blocos de corruptos, e offload de
backups incrementais rápidos.
O foco do Data Guard é de alta disponibilidade e recuperação de
dados. Princípios de design do Data Guard são a simplicidade, alto desempenho e
transparência da aplicação.
Data Guard não se destina a ser uma solução de replicação completo. Oracle
GoldenGate é a solução recomendada para as necessidades avançadas de replicação,
como o multi-mestre de replicação, replicação granular de um subconjunto de um
banco de dados, muitos para um topologias de replicação e integração de
dados. Oracle GoldenGate também oferece opções adicionais para reduzir o tempo
de inatividade para manutenção e para migrações de plataformas heterogêneas.
Dependendo de suas necessidades, a solução mais eficiente para usar pode
estar usando Data Guard sozinho, usando Data Guard, com Oracle GoldenGate de
forma complementar, ou apenas usando o Oracle GoldenGate.
Tabela 1 - Requisitos e dados de opções de implantação da Guarda
Exigência Implantação de dados Opções Guarda
22
Zero proteção contra perda de dados e
disponibilidade para banco de dados
Oracle
Protecção de Dados máxima Guarda ou a
máxima disponibilidade (SYNC transporte)
e Redo Apply (standby físico)
Perto de zero perda de dados (de um
dígito segundos) e disponibilidade para o
Oracle Database
Data Guard desempenho máximo (ASYNC
transporte) e Refazer Aplicar
Multi-site proteção, incluindo topologia
com espera perda zero de dados local
para HA e espera remota assíncrona para
recuperação de desastres geográfica para
Oracle Database
Multi-espera configuração do Data Guard
e Redo Apply
Failover do banco de dados o mais rápido
possível
Data Guard Fast-Start Failover com o
Oracle Data Guard corretor para detecção
automática de falhas e failover de banco
de dados. Failover automático de
acompanhar aplicativos cliente para o
banco de dados nova produção é
implementado usando o Oracle
Notificação Fast Application (FAN) e
Práticas cliente Oracle Melhores de
failover.
Offload consultas somente leitura e
rápidos backups incrementais para um
banco de dados sincronizados de
espera. Use o banco de dados de espera
para reparar automaticamente blocos
Data Guard ativa. Data Guard ativo pode
ser comprado em qualquer uma das
seguintes formas: (1) como uma licença
autônoma opção para Oracle Database
Enterprise Edition, ou (2) incluído com
23
corrompidos, transparente para a
aplicação e do usuário
uma licença GoldenGate Oracle.
A pré-produção de testes Espera instantâneo. A espera instantâneo
é um banco de dados físico de espera que
está temporariamente abrir leitura /
escrita para teste e atividade de leitura /
gravação de outro independente de
transações de banco de dados
primários. A espera instantâneo é
facilmente convertido novamente em um
banco de dados sincronizados de espera
quando o teste for concluído. Snapshot
Standby é um recurso incluído de Dados
Refazer Guarda Aplicar e é um
complemento ideal para o Oracle Real
Application Testing.
Manutenção planejada: algumas
migrações de plataforma como o
Windows para o Linux, move-se do centro
de dados, aplicação de patches e
software de sistema atualizar ou banco de
dados Oracle
Data Guard transição, transição função
planejada, usando Refazer
Aplicar. Refazer Aplicar e espera-primeiro
patch para a qualificação Aplicar patches
de 11.2.0.1 em diante. SQL Apply e Data
Guard atualizações sem interrupção de
banco de dados (10,1 em diante). Data
Guard espera Lógico transitória
(Upgrades Made Easy) de 11.1.0.7 em
diante.
24
Data Protection para os dados que
residem fora do banco de dados Oracle
Sempre que possível, coloque os
dados do sistema de operação do
sistema de arquivos em banco de
dados Oracle usando o Oracle Banco
de Dados do Sistema de Arquivos
(DSPF). Data Guard protege os dados
dBFS da mesma forma que quaisquer
outros dados Oracle.
Dados que devem permanecer nos
arquivos do sistema operacional pode
ser protegido usando o Oracle ASM
Cluster File System (Oracle ACFS) ou
espelhamento, armazenamento e Data
Guard.
12.1 Melhores práticas para o modo de proteção:
Modo de Protecção máxima garante que não haja perda de dados irá
ocorrer se a base de dados principal falhar, mesmo no caso de falhas de
múltiplas (por exemplo, a falha de rede entre o primário de espera e, em
seguida, em um momento posterior, o primário falhar). Isso é reforçado por
nunca sinalização sucesso de confirmação de uma transação de banco de
dados principal, pelo menos até uma espera Guarda síncrona de dados
reconheceu que refazer foi endurecido para o disco. Sem essa confirmação
do banco de dados primário vai parar e, eventualmente, encerrar em vez de
permitir transações desprotegidos a cometer. Para manter a disponibilidade
nos casos em que o banco de dados principal é operacional, mas o banco de
dados de espera não é, a melhor prática é sempre ter um mínimo de dois
bancos de dados standby síncronas em uma configuração de proteção
máxima. Disponibilidade de dados primário não é afectado se receber
confirmação de pelo menos um banco de dados síncrona de espera.
25
Modo a máxima disponibilidade garante que nenhuma perda de dados irá
ocorrer nos casos em que o banco de dados principal experimenta a primeira
falha para impactar a configuração. Ao contrário do modo de proteção
anterior, a disponibilidade máxima vai esperar um máximo de segundos
NET_TIMEOUT por uma confirmação de um banco de dados de espera, após
o que será sinal de comprometer o sucesso da aplicação e passar para a
próxima transação. Disponibilidade banco de dados primário (daí o nome do
modo de proteção) não é afetado por uma incapacidade de se comunicar com
o modo de espera (por exemplo, devido a falhas de espera ou de
rede). Oracle Data Guard vai continuar a executar ping no modo de espera e
automaticamente conexão restabelecer e voltar a sincronizar o banco de
dados standby quando possível, mas durante o período primário e espera ter
divergido haverá perda de dados deve ser um impacto segunda falha do
banco de dados primário. Por esta razão, é uma boa prática para monitorar o
nível de proteção (simples usando o Enterprise Manager Grid Control) e
resolver rapidamente qualquer interrupção na comunicação entre primário e
de espera antes de uma segunda falha pode ocorrer.
Modo de desempenho máximo (o modo padrão) fornece o mais alto nível de
protecção de dados que é possível, sem afetar o desempenho ou a
disponibilidade do banco de dados primário. Isso é realizado por permitir que
uma transação de cometer tão logo os dados de redo necessários para
recuperar a transação é escrita no log de redo on-line local no banco de
dados primário (o mesmo comportamento como se não houvesse nenhum
banco de dados de espera). Oracle Data Guard transmite refazer o banco de
dados de espera diretamente do assíncrona principal log buffer para a
gravação de log on-line redo local. Nunca há qualquer espera por
reconhecimento de espera. Semelhante a máxima disponibilidade, é uma boa
prática para monitorar o nível de proteção (simples usando o Enterprise
Manager Grid Control) e resolver rapidamente qualquer interrupção na
comunicação entre primário e de espera antes de uma segunda falha pode
ocorrer.
26
12.2 Gestor de Recuperação de usar para criar Bancos de Dados
A Oracle recomenda que você use o Recovery Manager (RMAN) utilitário
para simplificar o processo de criação de um banco de dados físico de espera.
Você pode criar um banco de dados de espera a partir de cópias de
segurança de seu banco de dados primário, ou criar um banco de dados de espera
na rede:
Usar o RMAN DUPLICATE TARGET DATABASE FOR STANDBY comando
para criar um banco de dados de espera a partir de cópias de segurança de
seu banco de dados primário.
Você pode usar qualquer cópia de backup do banco de dados principal para
criar o banco de dados físico de espera se as necessárias arquivos de log
redo arquivados para recuperação completa do banco de dados são
acessíveis a sessão do servidor no host de espera. RMAN restaura os
arquivos de dados mais recentes, a menos que você executar o SET
UNTIL comando.
Usar o RMAN FROM ACTIVE DATABASE opção para criar o banco de dados
de espera na rede se um backup de banco de dados pré-existente não é
acessível para o sistema de espera.
RMAN copia os arquivos de dados diretamente do banco de dados primário
para o banco de dados de espera. O banco de dados principal deve ser
montado ou aberto.
Você deve escolher entre a duplicação ativo e backup baseado. Se você não
especificar o FROM ACTIVE DATABASE opção, então, faz o backup RMAN
baseada em duplicação. A criação de um banco de dados sobre a rede de espera é
vantajosa porque:
Você pode transferir dados de redo diretamente para o host remoto através
da rede sem ter que seguir os passos de realizar um backup do banco de
27
dados primário. (Restauração requer várias etapas, incluindo o
armazenamento de backup local no banco de dados principal, transferindo o
backup através da rede, armazenando o backup localmente no banco de
dados de espera, e então restaurar o backup do banco de dados de espera.)
Com a duplicação ativa, você pode fazer backup de um banco de dados
(como ele está sendo executado) da Oracle ASM, e restaurar o backup para
um host na rede e colocar os arquivos diretamente para o Oracle ASM.
Antes este recurso, restauração necessário que você faça backup do primário
e copiar os arquivos de backup no sistema principal arquivo host, transferir os
arquivos de backup através da rede, coloque os arquivos de backup no
sistema de espera arquivo host, e em seguida, restaurar os arquivos em
Oracle ASM .
12.3 Usar o modo registro FORÇA
Quando o banco de dados primário está em FORCE LOGGING FORCE
LOGGING modo, todas as alterações de dados do banco de dados são
registrados. FORCE LOGGING modo garante que o banco de dados standby
permanece consistente com o banco de dados principal. Se isso não é possível
porque é necessário o desempenho de carga com NOLOGGING operações, então
se deve garantir que os físicos correspondentes arquivos de dados de espera são
posteriormente sincronizados. Para sincronizar os arquivos físicos de dados de
espera, ou aplicar um backup incremental criado a partir do banco de dados primário
ou substituir os arquivos afetados espera de dados com um backup dos arquivos de
dados primários tomadas após a operação nologging. Antes da transferência de
arquivos, deve parar Refazer Aplique no banco de dados físico de espera.
O usuário pode ativar o registro vigor imediatamente, emitindo um ALTER
DATABASE FORCE LOGGING comunicado. Se você especificar FORCE
LOGGING , o Oracle espera que todas as operações em curso não registrados ao
fim.
28
12.4 Estratégia de arquivamento e Configuração
Este estratégia de arquivamento é baseada nos seguintes pressupostos:
Cada banco de dados utiliza uma área de recuperação rápida.
O principal banco de dados de arquivo casos remotamente a um só aplicar
exemplo.
Tabela 2 - Recomendações Arquivamento
Recomendação Descrição
Iniciar arquivamento nas
bases de dados primário e
de espera
A manutenção de um banco de dados standby requer
que ative e começe a arquivar no banco de dados
principal, como segue:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
O arquivamento também deve ser habilitado no banco
de dados de espera para apoiar transições papel. Para
habilitar o arquivamento no banco de dados de
espera:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
Use um formato de registro
consistente
(LOG_ARCHIVE_FORMAT
).
O LOG_ARCHIVE_FORMAT parâmetro deve
especificar o fio, sequência e atributos de identificação
RESETLOGS, e os ajustes de parâmetros deve ser
consistente em todas as instâncias. Por
exemplo:LOG_ARCHIVE_FORMAT=arch_%t_%S_%r.
arc
29
Nota: Se a área de recuperação rápida é usado, então
este formato é ignorado.
Executar arquivamento
remoto para apenas uma
instância de espera e nó
para cada banco de dados
Oracle RAC espera.
Tudo banco de dados primário casos de arquivo para
um destino de espera, usando o mesmo nome de
serviço líquido. Oracle Net Services failover tempo de
conexão é usada para mudar automaticamente para o
host "secundário" modo de espera quando a instância
de "primário" de espera tem uma interrupção.
Se os arquivos são acessíveis a partir de todos os nós
porque a Oracle ASM ou algum outro sistema de
arquivos compartilhado está sendo usado para a área
de recuperação rápida, em seguida, o arquivamento
remoto pode ser espalhado em diferentes nós de um
banco de dados Oracle RAC espera.
Especifique baseadas em
função destinos com
o VALID_FOR atributo
O VALID_FOR VALID_FOR atributo permite que
configure os atributos do destino para o primário e os
papéis de banco de dados standby em um servidor de
arquivos parâmetro (SPFILE), de modo que a
configuração do Data Guard funciona corretamente
após uma transição de papel. Isto simplifica
switchovers e failovers, removendo a necessidade de
ativar e desativar os arquivos de papel de parâmetros
específicos após uma transição de papel.
O exemplo a seguir ilustra a recomendada parâmetros de inicialização para
um banco de dados primário comunicar a um banco de dados físico de
espera. Há duas instâncias, SALES1 e SALES2 , correndo em modo de
proteção máxima.
*. DB_RECOVERY_FILE_DEST = + RECO
30
*. LOG_ARCHIVE_DEST_1 = 'SERVIÇO = SALES_stby SYNC AFFIRM
NET_TIMEOUT = 30
REABRIR = 300 = (VALID_FOR ONLINE_LOGFILES, ALL_ROLES)
DB_UNIQUE_NAME = SALES_stby '
*. LOG_ARCHIVE_DEST_STATE_1 ENABLE
Comandos:
Maximize I / O em Taxas de Logs Refazer espera e redo logs
Meça leitura de E / S nos preços redo logs de espera e redo diretórios de
log. Gravação simultânea de refazer enviado em um banco de dados standby pode
reduzir a taxa de leitura de refazer devido à saturação de E / S. A taxa de
recuperação total é sempre limitada pela taxa na qual redo pode ser lido, por isso
assegurar que a taxa de leitura de redo ultrapassa a sua taxa de recuperação
necessários.
Taxa de Recuperação Avaliação
Para obter o histórico das taxas de recuperação, use a seguinte consulta para
obter uma história de progresso de recuperação:
SELECT * FROM V RECOVERY_PROGRESS $;
Se o ACTIVE APPLY RATE é maior do que a taxa máxima de geração de
redo no banco de dados primário ou duas vezes a taxa de geração de média no
banco de dados primário, então é necessário nenhum ajuste, caso contrário, seguir
as dicas de ajuste abaixo. A taxa de geração de redo para o banco de dados
primário pode ser monitorado a partir do Enterprise Manager ou extraída de
relatórios AWR sob estatística REDO SIZE . Se CHECKPOINT TIME PER LOGé
maior do que dez segundos, então, investigar ajuste I / O e postos de controle.
31
Set DB_BLOCK_CHECKSUM DB_BLOCK_CHECKSUM = FULL e DB_BLOCK_CH
ECKING=MEDIUMDB_BLOCK_CHECKING=MEDIUM ou FULL
Refazer aplicar desempenho deve ser rápido o suficiente para manter-se com
taxas mais das aplicações de geração de refazer, mas você pode desativar
temporariamente DB_BLOCK_CHECKING para acelerar a recuperação. Se você
desativar DB_BLOCK_CHECKING , você irá desativar na memória cheques blocos
semânticos.
Para verificar a corrupção bloco que não era evitável através
da DB_BLOCK_CHECKING parâmetro, utilize:
RMAN BACKUP com o comando VALIDATE opção
DBVERIFY utilitário
ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE instrução
SQL
32
12 CRIANDO UMA BASE DE RÉPLICA FÍSICA
Nos capítulos anteriores verificamos o que é o Oracle DataGuard, qual sua
finalidade e suas principais características. Neste capítulos iremos criar uma Base
de Replica Física.
Lembrando que uma réplica física nada mais é do que uma cópia real do
banco de dados, sem quaisquer alterações ou customização na sua estrutura. Como
laboratório, foram criadas duas máquinas virtuais.
1. Realizar conexão via SQLPLUS no servidor de produção [oracle@localhost ~]$ sqlplus /nolog SQL*Plus: Release 11.2.0.2.0 Production on Sat Dec 8 10:41:49 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved.
SQL> conn sys/oracle as sysdba Connected.
2. Verificar se o servidor encontra-se em modo de arquivamento: SQL> select log_mode from v$database; LOG_MODE ------------ ARCHIVELOG
3. Acessar novamente o SQLPLUS, desconectar o Banco de Dados e montá-lo: SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down.
SQL> startup mount; ORACLE instance started. Total System Global Area 456146944 bytes Fixed Size 1344840 bytes Variable Size 369101496 bytes Database Buffers 79691776 bytes Redo Buffers 6008832 bytes Database mounted.
4. Sair do SQLPLUS e conectar no RMAN: [oracle@localhost ~]$ rman target / Recovery Manager: Release 11.2.0.2.0 - Production on Sat Dec 8 11:33:16 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1229390655, not open)
33
5. Ainda no banco de produção, realizar backup um backup da base: RMAN> run { backup database format '/tmp/bkp_cold_full_%d_%t_%p.bkp' include current controlfile spfile; } Starting backup at 08-DEC-12 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00002 name=/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf input datafile file number=00001 name=/home/oracle/app/oracle/oradata/orcl/system01.dbf input datafile file number=00004 name=/home/oracle/app/oracle/oradata/orcl/users01.dbf input datafile file number=00005 name=/home/oracle/app/oracle/oradata/orcl/example01.dbf input datafile file number=00003 name=/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf input datafile file number=00008 name=/home/oracle/app/oracle/oradata/orcl/rman.dbf1 input datafile file number=00007 name=/home/oracle/app/oracle/oradata/orcl/APEX_2041602962184952.dbf input datafile file number=00006 name=/home/oracle/app/oracle/oradata/orcl/APEX_1930613455248703.dbf channel ORA_DISK_1: starting piece 1 at 08-DEC-12 channel ORA_DISK_1: finished piece 1 at 08-DEC-12 piece handle=/tmp/bkp_cold_full_ORCL_801491495_1.bkp tag=TAG20121208T123135 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:04:06 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set channel ORA_DISK_1: starting piece 1 at 08-DEC-12 channel ORA_DISK_1: finished piece 1 at 08-DEC-12 piece handle=/tmp/bkp_cold_full_ORCL_801491742_1.bkp tag=TAG20121208T123135 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 08-DEC-12 channel ORA_DISK_1: finished piece 1 at 08-DEC-12 piece handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2012_12_08/o1_mf_nnsnf_TAG20121208T123135_8d7957ok_.bkp tag=TAG20121208T123135 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 08-DEC-12 Starting Control File and SPFILE Autobackup at 08-DEC-12 piece handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/autobackup/2012_12_08/o1_mf_s_801485350_8d7958z0_.bkp comment=NONE Finished Control File and SPFILE Autobackup at 08-DEC-12
6. No SQLPLUS, criar um controlfile standby para ser usado no banco replica: SQL> alter database create standby controlfile as '/tmp/controlfile_stb.ctl';
34
Database altered.
7. Ainda no SQLPLUS, criar um PFILE a partir do SPFILE SQL> create pfile='/tmp/initteste.ora' from spfile; File created. 8. No Linux, enviar os arquivos de backup para o servidor de standby: [oracle@localhost ~]$ scp bkp_cold_full_ORCL_801491495_1.bkp standby:/tmp [oracle@localhost ~]$ scp /tmp/controlfile_stb.ctl standby:/tmp/ [oracle@localhost ~]$ scp /tmp/initteste.ora standby:/tmp/
9. Com os arquivos de backup no servidor de standby, mover o init para a pasta padrão do Oracle: [oracle@standby ~]$ mv /tmp/initteste.ora /home/oracle/app/oracle/product/11.2.0/dbs/inittester.ora
10. Após mover o init, iremos editá-lo para que possamos iniciar o banco com este novo init. Primeiramente, iremos incluir as seguintes linhas no init. Deveremos também substituir no campo orcl por standby. A única exceção será o campo DB_NAME,mantendo a referencia ao servidor principal. *.db_unique_name=’standby’ *.log_archive_dest_1=’LOCATION=+ORADATA/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=standby’ *.log_archive_dest_2=’SERVICE=teste VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLES) DB_UNIQUE_NAME=standby’ *.LOG_ARCHIVE_DEST_STATE_1=ENABLE *.LOG_ARCHIVE_DEST_STATE_2=ENABLE *.LOG_ARCHIVE_CONFIG=’DG_CONFIG=(orcl,standby)’ *.FAL_SERVER=orcl *.FAL_CLIENT=standby *.STANDBY_FILE_MANAGEMENT=AUTO *.LOG_FILE_NAME_CONVERT=’+ORAFRA/ORCL’, ‘+ORAFRA/STANDBY’ *.DB_FILE_NAME_CONVERT=’+ORADATA/ORCL’, ‘+ORADATA/STANDY’
11. No final o init ficará conforme abaixo. O texto destacado em vermelho apresenta onde foi realizada a alteração, enquanto que o texto em destaque verde remete-se ao o que foi inserido ao init: standby.__db_cache_size=41943040 standby.__java_pool_size=8388608 standby.__large_pool_size=8388608 standby.__oracle_base='/home/oracle/app/oracle'#ORACLE_BASE set from environment standby.__pga_aggregate_target=197132288 standby.__sga_target=260046848 standby.__shared_io_pool_size=12582912 standby.__shared_pool_size=171966464 standby.__streams_pool_size=8388608 *.audit_file_dest='/home/oracle/app/oracle/admin/standby/adump' *.audit_trail='DB' *.client_result_cache_lag=3000 *.client_result_cache_size=67108864 *.compatible='11.2.0.0.0' *.control_files='/home/oracle/app/oracle/oradata/standby/control01.ctl','/home/oracle/app/oracle/flash_recovery_area/standby/control02.ctl' *.db_block_size=8192 *.db_domain='' *.db_name='orcl' *.db_unique_name=’standby’
35
*.log_archive_dest_1=’LOCATION=+ORADATA/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=standby’ *.log_archive_dest_2=’SERVICE=teste VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLES) DB_UNIQUE_NAME=standby’ *.LOG_ARCHIVE_DEST_STATE_1=ENABLE *.LOG_ARCHIVE_DEST_STATE_2=ENABLE *.LOG_ARCHIVE_CONFIG=’DG_CONFIG=(orcl,standby)’ *.FAL_SERVER=orcl *.FAL_CLIENT=standby *.STANDBY_FILE_MANAGEMENT=AUTO *.LOG_FILE_NAME_CONVERT=’+ORAFRA/ORCL’, ‘+ORAFRA/STANDBY’ *.DB_FILE_NAME_CONVERT=’+ORADATA/ORCL’, ‘+ORADATA/STANDY’ *.db_recovery_file_dest_size=4039114752 *.db_recovery_file_dest='/home/oracle/app/oracle/flash_recovery_area' *.diagnostic_dest='/home/oracle/app/oracle' *.dispatchers='(PROTOCOL=TCP) (SERVICE=standbyXDB)' *.event='' *.local_listener='LISTENER_STANDBY' *.log_archive_start=TRUE *.max_shared_servers=5 *.memory_target=457179136 *.open_cursors=300 *.processes=150 *.remote_login_passwordfile='EXCLUSIVE' *.shared_servers=10 *.undo_tablespace='UNDOTBS1'
12. Agora, iremos criar os diretórios nomeados como standby, uma vez que os mesmos foram definidos no novo init criado anteriormente: [oracle@standby ~]$ mkdir –p /home/oracle/app/oracle/admin/standby/adump mkdir: cannot create directory `/home/oracle/app/oracle/admin/standby/adump': No such file or directory
13. O próximo passo será acessar o SQLPLUS e, com o novo init, iniciar o banco de dados. [oracle@standby ~]$ sqlplus /nolog SQL*Plus: Release 11.2.0.2.0 Production on Wed Dec 12 16:42:10 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. SQL> conn sys/oracle as sysdba Connected to an idle instance. SQL> startup nomount pfile=’/home/oracle/app/oracle/product/11.2.0/ dbhome_2/dbs/inittester.ora’; ORACLE instance started. Total System Global Area 456146944 bytes Fixed Size 1344840 bytes Variable Size 360712888 bytes Database Buffers 88080384 bytes Redo Buffers 6008832 bytes
14. Dado o startup, deverá ser criado um spfile a partir do init: SQL> create spfile from pfile=’/home/oracle/app/oracle/product/11.2.0/ dbhome_2/dbs/inittester.ora’; File created.
15. Criado o Spfile, iremos criar um arquivo de password do Oracle na instancia Replica, que ser importante para o funcionamento do Data Guard: [oracle@standby ~]$ orapwd file=$ORACLE_HOME/dbs/orapwstandby password=oracle
36
16. Agora iremos começar a restaurar os controlfiles no servidor Standby , via RMAN e colocando a instancia em modo mount. Observe abaixo que os documentos foram restaurados no diretório standby, de acordo com o especificado no init. [oracle@standby] rman target / RMAN> restore controlfile from ‘/tmp/controlfile_stb.ctl’; channel ORA_DISK_1: copied control file copy output filename=+ORADATA/standby/controlfile/controlfile01.ctl output filename=+ORAFRA/standby/controlfile/controlfile02.ctl Finished restore at 10-DEC-12
17. Restaurados os controlfiles, iremos tirar montar os dois bancos (orcl e standby), podendo ser pelo RMAN ou SQLPLUS. Optamos pelo RMAN, conforme script abaixo: RMAN> startup force mount; Oracle instance started database mounted Total System Global Area 456146944 bytes Fixed Size 1344840 bytes Variable Size 364907192 bytes Database Buffers 83886080 bytes Redo Buffers 6008832 bytes
18. Instancias montadas, agora iremos restaurar o backup da instancia utilizando o RMAN, no banco standby: RMAN> restore database; Starting restore at 13-DEC-12 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=18 device type=DISK channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /home/oracle/app/oracle/oradata/orcl/system01.dbf channel ORA_DISK_1: restoring datafile 00002 to /home/oracle/app/oracle/oradata/orcl/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00003 to /home/oracle/app/oracle/oradata/orcl/undotbs01.dbf channel ORA_DISK_1: restoring datafile 00004 to /home/oracle/app/oracle/oradata/orcl/users01.dbf channel ORA_DISK_1: restoring datafile 00005 to /home/oracle/app/oracle/oradata/orcl/example01.dbf channel ORA_DISK_1: restoring datafile 00006 to /home/oracle/app/oracle/oradata/orcl/APEX_1930613455248703.dbf channel ORA_DISK_1: restoring datafile 00007 to /home/oracle/app/oracle/oradata/orcl/APEX_2041602962184952.dbf channel ORA_DISK_1: restoring datafile 00008 to /home/oracle/app/oracle/oradata/orcl/rman.dbf1 channel ORA_DISK_1: reading from backup piece /tmp/bkp_cold_full_ORCL_801679009_1.bkp channel ORA_DISK_1: ORA-19870: error while restoring backup piece /tmp/bkp_cold_full_ORCL_801679009_1.bkp ORA-19505: failed to identify file "/tmp/bkp_cold_full_ORCL_801679009_1.bkp" ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory Additional information: 3 failover to previous backup channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /home/oracle/app/oracle/oradata/orcl/system01.dbf
37
channel ORA_DISK_1: restoring datafile 00002 to /home/oracle/app/oracle/oradata/orcl/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00003 to /home/oracle/app/oracle/oradata/orcl/undotbs01.dbf channel ORA_DISK_1: restoring datafile 00004 to /home/oracle/app/oracle/oradata/orcl/users01.dbf channel ORA_DISK_1: restoring datafile 00005 to /home/oracle/app/oracle/oradata/orcl/example01.dbf channel ORA_DISK_1: restoring datafile 00006 to /home/oracle/app/oracle/oradata/orcl/APEX_1930613455248703.dbf channel ORA_DISK_1: restoring datafile 00007 to /home/oracle/app/oracle/oradata/orcl/APEX_2041602962184952.dbf channel ORA_DISK_1: restoring datafile 00008 to /home/oracle/app/oracle/oradata/orcl/rman.dbf1 channel ORA_DISK_1: reading from backup piece /tmp/bkp_cold_full_ORCL_801678673_1.bkp channel ORA_DISK_1: ORA-19870: error while restoring backup piece /tmp/bkp_cold_full_ORCL_801678673_1.bkp ORA-19505: failed to identify file "/tmp/bkp_cold_full_ORCL_801678673_1.bkp" ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory Additional information: 3 failover to previous backup channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /home/oracle/app/oracle/oradata/orcl/system01.dbf channel ORA_DISK_1: restoring datafile 00002 to /home/oracle/app/oracle/oradata/orcl/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00003 to /home/oracle/app/oracle/oradata/orcl/undotbs01.dbf channel ORA_DISK_1: restoring datafile 00004 to /home/oracle/app/oracle/oradata/orcl/users01.dbf channel ORA_DISK_1: restoring datafile 00005 to /home/oracle/app/oracle/oradata/orcl/example01.dbf channel ORA_DISK_1: restoring datafile 00006 to /home/oracle/app/oracle/oradata/orcl/APEX_1930613455248703.dbf channel ORA_DISK_1: restoring datafile 00007 to /home/oracle/app/oracle/oradata/orcl/APEX_2041602962184952.dbf channel ORA_DISK_1: restoring datafile 00008 to /home/oracle/app/oracle/oradata/orcl/rman.dbf1 channel ORA_DISK_1: reading from backup piece /tmp/bkp_cold_full_ORCL_801491495_1.bkp channel ORA_DISK_1: ORA-19870: error while restoring backup piece /tmp/bkp_cold_full_ORCL_801491495_1.bkp ORA-19505: failed to identify file "/tmp/bkp_cold_full_ORCL_801491495_1.bkp" ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory Additional information: 3 failover to previous backup channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /home/oracle/app/oracle/oradata/orcl/system01.dbf channel ORA_DISK_1: restoring datafile 00002 to /home/oracle/app/oracle/oradata/orcl/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00003 to /home/oracle/app/oracle/oradata/orcl/undotbs01.dbf channel ORA_DISK_1: restoring datafile 00004 to /home/oracle/app/oracle/oradata/orcl/users01.dbf channel ORA_DISK_1: restoring datafile 00005 to /home/oracle/app/oracle/oradata/orcl/example01.dbf channel ORA_DISK_1: restoring datafile 00006 to /home/oracle/app/oracle/oradata/orcl/APEX_1930613455248703.dbf channel ORA_DISK_1: restoring datafile 00007 to /home/oracle/app/oracle/oradata/orcl/APEX_2041602962184952.dbf
38
channel ORA_DISK_1: reading from backup piece /home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2012_12_01/o1_mf_nnndf_TAG20121201T085031_8cnfbr6d_.bkp channel ORA_DISK_1: piece handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2012_12_01/o1_mf_nnndf_TAG20121201T085031_8cnfbr6d_.bkp tag=TAG20121201T085031 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:03:16 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00008 to /home/oracle/app/oracle/oradata/orcl/rman.dbf1 channel ORA_DISK_1: reading from backup piece /home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2012_12_01/o1_mf_nnndf_TAG20121201T104620_8cnn3wpz_.bkp channel ORA_DISK_1: piece handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2012_12_01/o1_mf_nnndf_TAG20121201T104620_8cnn3wpz_.bkp tag=TAG20121201T104620 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:04 Finished restore at 13-DEC-12
19. Voltando a instância principal (orcl), iremos realizar algumas alteraçãos em seu init. O intuito desta alteração é inserir parâmetros do Data Guard no init do servidor principal. As alterações propostas serão as que encontram-se logo abaixo: *.db_unique_name=’orcl’ *.log_archive_dest_1=’LOCATION=+ORADATA/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl’ *.log_archive_dest_2=’SERVICE=standby VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLES) DB_UNIQUE_NAME=standby” *.LOG_ARCHIVE_CONFIG=’DG_CONFIG=(orcl,standby)’ *.LOG_ARCHIVE_DEST_STATE_1=ENABLE *.LOG_ARCHIVE_DEST_STATE_2=ENABLE *.FAL_SERVER=standby *.FAL_CLIENT=standby
20. Inserindo o trecho acima (destacado em verde), o init ficará conforme abaixo: orcl.__db_cache_size=75497472 orcl.__java_pool_size=8388608 orcl.__large_pool_size=8388608 orcl.__oracle_base='/home/oracle/app/oracle'#ORACLE_BASE set from environment orcl.__pga_aggregate_target=163577856 orcl.__sga_target=293601280 orcl.__shared_io_pool_size=12582912 orcl.__shared_pool_size=171966464 orcl.__streams_pool_size=8388608 *.audit_file_dest='/home/oracle/app/oracle/admin/orcl/adump' *.audit_trail='DB' *.client_result_cache_lag=3000 *.client_result_cache_size=67108864 *.compatible='11.2.0.0.0' *.control_files='/home/oracle/app/oracle/oradata/orcl/control01.ctl','/home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl' *.db_block_size=8192 *.db_domain='' *.db_name='orcl' *.db_unique_name=’orcl’ *.log_archive_dest_1=’LOCATION=+ORADATA/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl’ *.log_archive_dest_2=’SERVICE=standby VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLES) DB_UNIQUE_NAME=standby” *.LOG_ARCHIVE_CONFIG=’DG_CONFIG=(orcl,standby)’ *.LOG_ARCHIVE_DEST_STATE_1=ENABLE *.LOG_ARCHIVE_DEST_STATE_2=ENABLE
39
*.FAL_SERVER=standby *.FAL_CLIENT=standby *.db_recovery_file_dest_size=4039114752 *.db_recovery_file_dest='/home/oracle/app/oracle/flash_recovery_area' *.diagnostic_dest='/home/oracle/app/oracle' *.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)' *.event='' *.local_listener='LISTENER_ORCL' *.max_shared_servers=5 *.memory_target=457179136 *.open_cursors=300 *.processes=150 *.remote_login_passwordfile='EXCLUSIVE' *.shared_servers=10 *.undo_tablespace='UNDOTBS1'
20. No SQLPLUS, parar o banco da instancia principal (orcl), com o comando abaixo: RMAN> exit Recovery Manager complete. [oracle@localhost ~]$ sqlplus /nolog SQL*Plus: Release 11.2.0.2.0 Production on Thu Dec 13 08:19:20 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. SQL> conn sys/oracle as sysdba Connected. SQL> shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down.
21. O próximo passo será realizar a alteração do Listener, para que ambos os servidores se comuniquem entre si. Este procedimento será agora realizado no sistema operacional. Antes iremos utilizar o comando lsnrct status para verificar os dados de cada servidor no Linux (porta, host e service): [oracle@localhost ~]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 13-DEC-2012 08:30:33 Copyright (c) 1991, 2010, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST= localhost)(PORT=1521))) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Linux: Version 11.2.0.2.0 - Production Start Date 12-DEC-2012 15:16:26 Uptime 0 days 17 hr. 14 min. 7 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /home/oracle/app/oracle/product/11.2.0/dbhome_2/network/admin/listener.ora Listener Log File /home/oracle/app/oracle/diag/tnslsnr/localhost/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
40
Services Summary… Service “orcl” has 1 instance(s). Instance “orcl”, status UNKNOWN, has 1 handler(s) for this service… The command completed successfully
[oracle@standby ~]$ lsnrctl status LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 13-DEC-2012 15:05:17 Copyright (c) 1991, 2010, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standby)(PORT=1521))) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Linux: Version 11.2.0.2.0 - Production Start Date 12-DEC-2012 15:27:55 Uptime 0 days 23 hr. 37 min. 22 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /home/oracle/app/oracle/product/11.2.0/dbhome_2/network/admin/listener.ora Listener Log File /home/oracle/app/oracle/diag/tnslsnr/standby/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=standby)(PORT=1521))) Listening Endpoints Summary… (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=standby)(PORT=1521))) Services Summary… Service “standby” has 1 instance(s). Instance “standby”, status UNKNOWN, has 1 handler(s) for this service… The listener supports no services The command completed successfully /home/oracle/app/oracle/product/11.2.0/dbhome_2/network/admin
22. Com os dados coletados acima, poderemos agora criar o TNSNAMES.ora para ambos os servidores. Neste caso, iremos alterar o arquivo TNSNAMES.ora do diretório /home/oracle/app/oracle/product/11.2.0/dbhome_2/network/admin tanto do servidor principal, quanto do servidor de standby. [oracle@localhost ~]$ tnsping 192.168.0.1 TNS Ping Utility for Linux: Version 11.2.0.2.0 - Production on 13-DEC-2012 16:21:47 Copyright (c) 1997, 2010, Oracle. All rights reserved. Used parameter files: Used HOSTNAME adapter to resolve the alias Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.1)(PORT=1521))) OK (10 msec) [oracle@localhost ~]$ tnsping 192.168.0.2
41
TNS Ping Utility for Linux: Version 11.2.0.2.0 - Production on 13-DEC-2012 16:21:53 Copyright (c) 1997, 2010, Oracle. All rights reserved. Used parameter files: Used HOSTNAME adapter to resolve the alias Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.2)(PORT=1521))) OK (70 msec)
23. O mesmo teste deve ser realizado no servidor de standby: [oracle@standby ~]$ tnsping standby TNS Ping Utility for Linux: Version 11.2.0.2.0 - Production on 13-DEC-2012 16:29:21 Copyright (c) 1997, 2010, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = standby))) OK (10 msec) [oracle@standby ~]$ tnsping 192.168.0.1 TNS Ping Utility for Linux: Version 11.2.0.2.0 - Production on 13-DEC-2012 16:29:24 Copyright (c) 1997, 2010, Oracle. All rights reserved. Used parameter files: Used HOSTNAME adapter to resolve the alias Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.1)(PORT=1521))) OK (0 msec)
24. No vigésimo passo, realizamos a parada da instancia principal (orcl) para alterar os parâmetros do init. Com isso, teremos que iniciar apontando para o initfile do /tmp, ou seja, /tmp/initteste.ora: SQL> startup nomount pfile=’/tmp/initteste.ora’; ORACLE instance started. Total System Global Area 456146944 bytes Fixed Size 1344840 bytes Variable Size 360712888 bytes Database Buffers 88080384 bytes Redo Buffers 6008832 bytes Com a instancia orcl montada, vamos criar o SPFILE a partir deste init:
25. Com a instancia em modo nomount já criamos o SPFILE a partir desse init. SQL> create spfile from pfile=’/tmp/initteste.ora’; File created.
42
26, O Dataguard faz uso de Standby Redologs para realizar a replicação. Nas duas instancias (principal e standby), deverá ser criados grupos com os comandos abaixo: SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/home/oracle/app/oracle/oradata/orcl/logstb4a.rdo') SIZE 50M; Database altered. SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('/home/oracle/app/oracle/oradata/orcl/logstb5a.rdo') SIZE 50M; Database altered. SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('/home/oracle/app/oracle/oradata/orcl/logstb6a.rdo') SIZE 50M; Database altered. SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('/home/oracle/app/oracle/oradata/orcl/logstb7a.rdo') SIZE 50M; Database altered.
27. Agora, voltamos para a instancia standby, onde iremos inicia-la read-only para iniciar sua replicação física: SQL> alter database open read only; Database altered.
28. Ainda na instancia standby, iremos iniciar o processo de replicação, fazendo com que a base fique em modo mount, com o comando abaixo: SQL> alter database recover managed standby database disconnect from session;
29. Finalizado toda a parametrização, agora iremos realizar testes. No SQLPLUS da instancia principal, iremos criar uma tabela simples e inserir dados: create table funcionario (chapa number(4), nome varchar2(15)); Table created.; SQL> insert into funcionario values (10, ‘Lucas’); 1 row created. SQL> insert into funcionario values (12, ‘Deodoro’); 1 row created. SQL> insert into funcionario values (15, ‘Fonseca’); 1 row created. SQL> commit; Commit complete.
29. Depois de criada esta tabela, geramos o log switch que será responsável por gerar um archive: SQL> alter system switch logfile;
30. Observando o logs do Alert, observamos que o standby logfile gerou sequencia de archive 42, ficando no aguardo da sequencia da 43. Em resumo, a S a replicação foi realizada com êxito! [oracle@standby ~]$ tail -f / home/oracle/app/oracle/admin alert_tester.log . . . RFS[1]: Successfully opened standby log 4: ‘/home/oracle/app/oracle/oradata/orcl/logstb4a.rdo'’
43
Wed Dec 13 22:18:57 BRST 2012 Media Recovery Log /home/oracle/app/oracle/flash_recovery_area/standby/012_01_04/thread_1_seq_42.295.771685375 Media Recovery Waiting for thread 1 sequence 43
44
REFERÊNCIAS BIBLIOGRÁFICAS
BANCO DE DADOS ORACLE 11G RELEASE 2
<http://www.oracle.com/technetwork/pt/database/enterprise-edition> Acesso em: 03 dez.
2012.
DATA GUARD BROKER 11G COM RMAN (STANDBY 11G COM RMAN) <http://profissionaloracle.com.br/blogs/braga/2010/01/04/data-guard-broker-11g-com-rman-
standby-11g-com-rman/> Acesso em: 04 dez. 2012.
MEEKS, Joe. ORACLE DATA GUARD COM ORACLE DATABASE 11G RELEASE 2. 2009
ORACLE ACTIVE DATA GUARD
<http://www.oracle.com/br/products/database/options/active-data-
guard/overview/index.html> Acesso em: 04 dez. 2012.
ORACLE DATA GUARD
<http://www.oracle.com/technetwork/database/features/availability/dataguardoverview-
083155.html> Acesso em: 03 dez. 2012.