1

CENTRO UNIVERSITRIO MAURICIO DE NASSAU

ESPECIALIZAO 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, J os Karlos Soares da Silva e Washington Luiz
Vaz para obteno de nota na disciplina Procedimentos
de Contingncia e Alta Disponibilidade, ministrada pelo
professor Flavio Rocha











Recife
2012

3

INDICE

INTRODUO .................................................................................................... 4
1 DATA GUARD .................................................................................................. 5
1.1 Viso geral do Data Guard .................................................................... 6
2 COMO O DATA GUARD FUNCIONA DETALHES TCNICOS ................... 9
2.1 Servios de transporte do Data Guard ................................................. 9
3 MODOS DE PROTEO ................................................................................ 12
4 SERVIOS DE APLICAO DO DATA GUARD ............................................ 13
5 REDO APPLY - BANCO DE DADOS FSICO EM STANDBY .......................... 14
6 REDO APPLY E ACTIVE DATA GUARD ......................................................... 15
7 SQL APPLY - BANCO DE DADOS FSICO EM STANDBY ............................. 17
8 RESOLUO AUTOMTICA DE FALHAS ...................................................... 18
9 VALIDAO DE DADOS ORACLE ................................................................. 19
10 GERENCIANDO UMA CONFIGURAO DO DATA GUARD ....................... 20
11 MELHORES PRTICAS DO DATA GUARD .................................................. 21
11.1 Melhores prticas para o modo de proteo: ...................................... 24
11.2 Gestor de Recuperao de usar para criar Bancos de Dados ............ 26
11.3 Usar o modo registro FORA ............................................................. 27
11.4 Estratgia de arquivamento e Configurao ...................................... 28
12 CRIANDO UMA BASE DE RPLICA FSICA ................................................. 32
REFERNCIAS BIBLIOGRFICAS .................................................................... 44
4

INTRODUO
As operaes comerciais eficazes, o atendimento ao cliente de alta qualidade,
a conformidade com as normas do governo e a proteo dos ativos de informaes
corporativas exigem o mais alto nvel de proteo e disponibilidade de dados. Sendo
assim, no de surpreender que a proteo e a disponibilidade de dados estejam
entre as principais prioridades de empresas de todos os tamanhos e diferentes
reas.
O backup e a recuperao a partir de fita, o espelhamento remoto do
armazenamento ou o envio de log do banco de dados so solues tradicionais de
proteo de dados e recuperao de desastres (DR). Infelizmente, essas solues
no conseguem fornecer de forma confivel objetivos agressivos de pontos de
recuperao (RPO - proteo de dados) e tempo de recuperao (RTO -
disponibilidade de dados). Eles tambm no conseguem fornecer um retorno de
investimento adequado devido aos altos custos de aquisio e utilizao ineficaz de
sistemas em standby que ficam ociosos at que sejam chamados para assumir um
papel principal.
O Data Guard est includo no Oracle Database Enterprise Edition e fornece
os softwares de gerenciamento, monitoramento e automao para criar e manter um
ou mais bancos de dados sincronizados em standby que protegem os dados de
falhas, desastres, erros e corrupo. Ele pode atender s exigncias de Alta
disponibilidade e Recuperao de desastres e ideal para complementar o Oracle
Real Application Clusters.
O Data Guard possui o conhecimento necessrio do banco de dados Oracle
para fornecer o mais alto nvel de proteo para os dados Oracle. O Data Guard
direto para implementar e gerenciar. Os administradores esto sempre certos sobre
a capacidade de um banco de dados em standby assumir o papel de produo,
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, relatrios, backups, testes ou implantao de upgrades no banco de
dados e outras atividades de manuteno, enquanto tambm fornecem proteo
contra desastres.
5

2 DATA GUARD

O Active Data Guard 11g uma soluo com retorno rpido! Ns
facilmente atribumos duas funes ao nosso banco de dados em standby
de dez terabytes: proteo contra desastres e acesso somente para leitura
seguro para nossas aplicaes de comrcio eletrnico voltadas para o
cliente. Ficamos felizes em descobrir, aps avaliar outras alternativas, que
utilizar nosso banco de dados em standby Data Guard existente era a
soluo mais simples para fornecer aos clientes acesso constante a
informaes atualizadas
(Sue Merrigan, Intermap Technologies)

Oracle Data Guard a soluo para proteo de dados da Oracle,
disponibilidade de dados e recuperao de desastres.
Oracle Data Guard oferece o gerenciamento, monitoramento e software de
automao para criar e manter um ou mais bancos de dados standby para proteger
os dados da Oracle contra falhas, desastres, erro humano, e corrupes de dados,
fornecendo alta disponibilidade para aplicaes de misso crtica.
Arquitetura flexvel Data Guard oferece proteo de dados e disponibilidade
ideais:
Alteraes de dados so transmitidas diretamente da memria, isolando a
espera de I / O corrupes que ocorrem no primrio.
Um banco de dados de espera usa um software de cdigo diferente do que o
caminho-primrio - isolando-o de erros de firmware e software que impactam o
banco de dados principal.
Orculo deteco da corrupo de dados assegura que logicamente e
fisicamente compatveis antes de ser aplicado a um banco de dados em espera.
Data Guard detecta corrupes silenciosas provocadas por erros de hardware
(memria, CPU, disco, placa de rede) e falhas na transferncia de dados, e os
impede de afetar o banco de dados de espera.
Um banco de dados de espera usado para realizar a manuteno planejada
de forma rolamento, minimizando o tempo de inatividade e eliminar os riscos
inerentes introduo de mudanas para ambientes de produo.
6

Oracle Active Data Guard 11g estende a funcionalidade da Guarda bsico de
dados, permitindo o acesso somente leitura a um banco de dados fsico de espera
enquanto continuamente aplicar as alteraes recebeu do banco de dados
primrio. Isso aumenta o desempenho e retorno sobre o investimento, transferindo
consultas ad-hoc, acesso baseado na Web, relatrios e cpias de segurana do
banco de dados principal, enquanto tambm fornecendo proteo contra desastres.

2.1 Viso geral do Data Guard

O Oracle Data Guard proporciona a infraestrutura de software de automao,
monitorao e gerenciamento para criar e manter um ou mais bancos de dados em
standby para proteger os dados Oracle contra falhas, desastres, erros e corrupo
de dados. Existem dois tipos de banco de dados em standby. Um standby fsico usa
Redo Apply para manter uma rplica exata, bloco a bloco, do banco de dados
principal. Um standby lgico usa SQL Apply e contm as mesmas informaes
lgicas que o banco de dados principal, embora a organizao fsica e a estrutura
dos dados possam ser diferentes.
Os administradores podem escolher fazer o failover manual ou automtico da
produo para um sistema em standby se o principal falhar para poder manter a alta
disponibilidade para aplicativos de misso crtica. A arquitetura do Data Guard
descrita na Figura 1. O Data Guard um dos inmeros recursos integrados de Alta
disponibilidade (HA) do banco de dados Oracle descritos na Figura 2 que garantem
7

a continuidade dos negcios minimizando o impacto do tempo de inatividade
planejado e no planejado.


Os bancos de dados em standby Data Guard fornecem alto retorno do
investimento tambm suportando consultas ad-hoc, gerao de relatrios, backups
ou atividades de teste, ao mesmo tempo em que fornecem proteo contra
desastres. Especificamente:
A opo Active Data Guard, disponvel a partir do Oracle Database 11g,
permite que um banco de dados fsico seja usado para aplicaes somente
leitura enquanto recebe simultaneamente atualizaes 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 fsico em
standby seja aberto como leitura-gravao para testes ou qualquer outra
atividade que exija uma rplica dos dados de produo para leitura-gravao.
Um Snapshot Standby continua a receber, mas no a aplicar, as atualizaes
geradas pelo banco de dados principal. Essas atualizaes so aplicadas no
banco de dados em standby automaticamente quando o Snapshot Standby
convertido de volta para um banco de dados fsico em standby. Os dados do
banco de dados principal sempre permanecem protegidos.
Um banco de dados lgico em standby tem a flexibilidade adicional de estar
aberto como leitura-gravao. Apesar de os dados que esto sendo mantidos
8

pelo SQL Apply no poderem ser modificados, outras tabelas locais podem ser
adicionadas e estruturas locais de ndice podem ser criadas para otimizar a
gerao de relatrios ou para utilizar o banco de dados em standby como um
data warehouse ou para transformar a informao usada para carregar
datamarts.
Os bancos de dados em standby podem ser usados para realizar manuteno
planejada de maneira contnua. A manuteno realizada primeiro em um
banco de dados em standby. A produo chaveada para o banco de dados
em standby quando as tarefas de manuteno estiverem concludas. O nico
tempo de inatividade o temponecessrio para efetuar essa operao de
chaveamento. Isso aumenta a disponibilidade e reduz os riscos ao realizar
manuteno no hardware ou no sistema operacional, manuteno no site ou ao
aplicar novos conjuntos de patches do banco de dados, atualizar verses
completas de banco de dados ou implementar outras alteraes significativas no
banco de dados.
Um banco de dados fsico em standby, por ser uma rplica exata do banco de
dados principal, pode tambm ser usado para tirar a sobrecarga dos bancos de
dados principais ao realizar backups.


9

3 COMO O DATA GUARD FUNCIONA DETALHES TCNICOS

Uma configurao do Data Guard inclui um banco de dados de produo,
chamado de banco de dados principal, e at 30 bancos de dados em standby. Os
bancos de dados principal e em standby se conectam atravs de TCP/IP usando o
Oracle Net Services. No h restries em relao localizao dos bancos de
dados desde que eles possam se comunicar entre eles. Um banco de dados em
standby criado inicialmente a partir de uma cpia 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 recuperao
(informao usada pela Oracle para recuperar transaes) do banco de dados
principal e aplicando-os no banco de dados em standby.

3.1 Servios de transporte do Data Guard

Conforme os usurios confirmam as transaes no banco de dados principal,
o Oracle gera registros de recuperao e os grava em um arquivo de log on-line
local. Os servios de transporte do Data Guard transmitem os dados de recuperao
para um banco de dados em standby tanto de forma sncrona como assncrona,
onde eles so gravados em um arquivo de redo log de standby (etapa um na Figura
3). Os dados de recuperao podem ser transmitidos em um formato comprimido
para reduzir os requisitos de largura de banda atravs da Opo de Compresso
Avanada Oracle.
O Transporte de dados de recuperao sncrono (SYNC) faz com que o
banco de dados principal aguarde por uma confirmao do banco de dados em
standby de que os dados de recuperao foram gravados em disco antes de
reconhecer o sucesso da confirmao para o aplicativo, proporcionando proteo
com zero de perda de dados. O desempenho do banco de dados principal
impactado pela soma do tempo necessrio para que a E/S do arquivo de redo log
de standby seja concluda 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 sncrono. Os dados de recuperao so ento
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 separao
geogrfica entre os bancos de dados principal e em standby em uma configurao
sncrona com perda de dados zero. Em redes com baixa latncia, isso pode reduzir
o impacto da replicao do SYNC no desempenho do banco de dados principal para
prximo de zero, tornando interessante complementar um standby ASYNC remoto
com um standby SYNC local para proteo de alta disponibilidade com perda de
dados zero contra falhas no componente e no banco de dados (falha no SAN, por
exemplo).


O Transporte assncrono dos dados de recuperao (ASYNC) evita o impacto
no desempenho do banco de dados principal fazendo com que o banco de dados
principal reconhea o sucesso da confirmao para o aplicativo sem aguardar pelo
reconhecimento de que os dados de recuperao 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 distncia (WAN) de alta
latncia. A vantagem de desempenho do ASYNC, entretanto, acompanhada do
11

potencial de uma pequena quantidade de perda de dados uma vez que no h
garantia de que todos os dados de recuperao tenham sido recebidos pelo banco
de dados em standby.











12

4 MODOS DE PROTEO

O Data Guard fornece trs modos de proteo de dados para equilibrar
custos, disponibilidade, desempenho e proteo de dados. Cada modo usa um
mtodo de transporte de dados de recuperao especfico e estabelece regras que
controlam o comportamento da configurao do
Data Guard caso o banco de dados principal perca contato com seu banco de
dados standby. A tabela a seguir descreve as caractersticas de cada modo.



13

5 SERVIOS DE APLICAO DO DATA GUARD

Os Servios de aplicao leem os dados de recuperao 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 fsico) ou SQL Apply
(standby lgico). Observe que os servios de transporte e de aplicao so
totalmente diferentes. O status ou desempenho da aplicao no standby no
impacta o transporte dos dados de recuperao ou o desempenho do banco de
dados principal. O isolamento muito importante. O transporte dos dados de
recuperao o principal determinador do ponto de recuperao, a exposio 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 recuperao em
configuraes sncronas tambm 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
configurao sncrona pode reduzir o throughput do banco de dados principal e
aumentar o tempo de resposta. O isolamento entre o transporte e a aplicao
projetado para otimizar o desempenho do banco de dados, o tempo de resposta e a
proteo dos dados.

14

6 REDO APPLY - BANCO DE DADOS FSICO EM STANDBY

Um banco de dados fsico em standby aplica os dados de recuperao
recebidos do banco de dados principal atravs do Processo de Recuperao
Gerenciada (MRP), uma extenso de recuperao de mdia padro da Oracle que
reconhece o Data Guard usada em todos os bancos de dados Oracle. Um banco de
dados fsico em standby idntico ao banco de dados principal (bloco por bloco) e,
portanto, os esquemas de banco de dados, incluindo os ndices, so os mesmos. O
processo MRP ocorre totalmente em paralelo para obter o mximo desempenho. Os
testes de desempenho do Data Guard 11g conduzidos pela Oracle obtiveram taxas
de recuperao 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 seo Exadata
posteriormente neste artigo para obter informaes sobre os dados de desempenho
especficos para o armazenamento Exadata). O Redo Apply o mtodo mais
simples, mais rpido e mais confivel de manter rplicas sincronizadas de um banco
de dados principal.

15

7 REDO APPLY E ACTIVE DATA GUARD

A opo Active Data Guard inclui um nmero de recursos que ampliam a
capacidade do Redo Apply e um banco de dados fsico em standby, incluindo:
A consulta em tempo real permite o acesso somente para leitura a um ou mais
bancos de dados fsicos em standby para consultas, classificao, gerao de
relatrios, acesso com base na web, etc., enquanto o Redo Apply aplica
continuamente alteraes recebidas do banco de dados de produo. Nos
casos onde a carga de trabalho somente leitura pode ser isolada das transaes
de leitura-gravao, o Active Data Guard pode efetivamente dobrar a
capacidade de produo atravs de um banco de dados fsico em standby
existente que estava anteriormente ocioso em papel de standby ( possvel
adicionar outros bancos de dados em standby ativos configurao para
dimensionar posteriormente a capacidade de somente leitura sem impactar nas
transaes de leitura-gravao).
O Active Data Guard fornece desempenho excepcional ele pode ser usado
para aplicaes de alto throughput onde impossvel para qualquer outro mtodo de
replicao manter o ritmo com o volume de transaes gerado pelo banco de dados
de origem.
Os contratos de servio (SLA) do Active Data Guard podem ser
implementados atravs do parmetro de sesso
STANDBY_MAX_DATA_DELAY. O valor deste parmetro especifica um limite
para a quantidade de tempo (em segundos) permitida entre o momento em que
as alteraes so 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 cdigo de erro ORA-3172
se o limite for excedido. Os aplicativos podem reagir a este erro da mesma forma
que uma desconexo 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 automtico de blocos
corrompidos. A perda de dados no nvel de bloco normalmente resulta de erros
de E/S aleatrios e intermitentes, bem como de corrupes na memria que so
gravadas no disco. Quando o Oracle descobre uma corrupo, ele marca o
bloco como mdia 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 corrupo ocorrer em um banco de dados principal que tenha
um Active Data Guard em standby, a recuperao da mdia do bloco realizada
automaticamente, de forma transparente para o aplicativo, usando uma cpia
boa do bloco do banco de dados em standby. Por outro lado, os blocos ruins no
banco de dados em standby so recuperados automaticamente usando a
verso boa do banco de dados principal.

17

8 SQL APPLY - BANCO DE DADOS FSICO EM STANDBY

Um banco de dados standby lgico contm as mesmas informaes lgicas
que o banco de dados principal, embora a organizao fsica e a estrutura dos
dados possam ser diferentes. O SQL Apply mantm o standby lgico sincronizado
transformando os dados de recuperao recebidos do banco de dados principal em
declaraes SQL e, em seguida, executando as declaraes SQL em um banco de
dados em standby que seja aberto para leitura-gravao. O SQL Apply tem alguns
restries em relao aos tipos de dados, tipos de tabelas e tipos de operaes DDL
e DML (consulte a documentao para saber os tipos de dados no suportados e os
atributos de armazenagem).
Use o SQL Apply se atender aos pr-requisitos e se:

O Standby lgico do Data Guard um componente importante de uma
plataforma de hardware e software estratgica e de longa durao,
aumentando drasticamente a capacidade e a escalabilidade de nossos
usurios. Aps a implementao desta soluo completa, obtivemos
melhorias de desempenho de 50 a 95% na maioria de nossas operaes de
processamento em massa.
(David Sink, e-Rewards Market Research)


18

9 RESOLUO AUTOMTICA 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 proteo
usado, o banco de dados principal continuar a processar as transaes e acumular
um log de dados de recuperao que no podem ser enviados para o standby at
que uma nova conexo 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 conexo for restabelecida e sincroniza novamente de
forma automtica o banco de dados em standby com o principal. Nenhuma
interveno administrativa necessria desde que os log arquivados necessrios
para sincronizar novamente o banco de dados em standby estejam disponveis em
disco no banco de dados principal. No caso de uma parada longa onde no vivel
reter os logs arquivados necessrios, um standby fsico pode ser sincronizado
novamente atravs do backup incremental rpido RMAN do banco de dados
principal.


19

10 VALIDAO DE DADOS ORACLE

Uma das vantagens mais significativas do Data Guard a capacidade de usar
os processos da Oracle para validar os dados de recuperao antes de serem
aplicados no banco de dados em standby. O Data Guard uma arquitetura flexvel
associada onde os bancos de dados em standby permanecem sincronizados
aplicando os blocos de recuperao, completamente desassociados de possveis
corrupes nos arquivos de dados que podem ocorrer no banco de dados principal.
Os dados de recuperao tambm so enviados diretamente da memria (rea
global do sistema) e, portanto, so completamente desassociados de corrupes de
E/S no banco de dados principal.
Verificaes para deteco de dados corrompidos ocorrem em vrias
interfaces-chave durante o transporte e a aplicao dos dados de recuperao. O
cdigo de software executado no banco de dados em standby tambm
fundamentalmente diferente do cdigo 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 fsico tambm utiliza o parmetro: DB_LOST_WRITE_PROTECT
disponvel com o Oracle Database 11g Release 1. Uma gravao perdida ocorre
quando um subsistema de E/S reconhece a concluso de uma gravao enquanto
na verdade a gravao no ocorreu no armazenamento persistente. Em uma leitura
de bloco subsequente, o subsistema de E/S retorna a verso obsoleta do bloco de
dados, que pode ser usada para atualizar outros blocos do banco de dados e,
portanto, corrompendo-o. Quando o parmetro de inicializao
DB_LOST_WRITE_PROTECT estiver definido, o banco de dados ir gravar leituras
do bloco de cache do buffer no redo log e essa informao ser usada pelo recurso
Redo Apply para determinar se houve uma gravao perdida, evitando o tempo de
inatividade e a perda de dados.

20

11 GERENCIANDO UMA CONFIGURAO DO DATA GUARD

Os bancos de dados principal e em standby e suas diversas interaes
podem ser gerenciadas atravs do SQL*Plus. O Data Guard tambm oferece uma
estrutura de gerenciamento distribudo chamada Data Guard Broker, que automatiza
e centraliza a criao, manuteno e monitoramento de uma configurao 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
criao de uma configurao do Data Guard. As principais mtricas do Data Guard,
como o atraso na aplicao, atraso no transporte, taxa de dados de recuperao e
status da configurao, esto includos em um novo Console de Alta disponibilidade
consolidado (consulte a Figura 4).
O Enterprise Manager habilita a anlise de tendncia histrica nas mtricas
do Data Guard que ele monitora; por exemplo, qual o desempenho da mtrica nas
ltimas 24 horas, ou nos ltimos 5 dias, etc. Alm disso, atravs do Enterprise
Manager, possvel configurar alarmes de notificao de forma que os
administradores possam ser notificados caso a mtrica ultrapasse o valor do limite
configurado.


21

12 MELHORES PRTICAS DO DATA GUARD

Data Guard a soluo Oracle otimizado para disponibilidade de dados e
proteo. excelente em simples, rpido e confivel replicao unidirecional de um
completo banco de dados Oracle para oferecer alta disponibilidade e recuperao de
desastres. Data Guard oferece vrias opes de implantao que abordam
interrupes no planejadas, pr-produo, testes e manuteno planejada. Active
Data Guard, uma extenso de capacidades bsicas do Data Guard, ainda permite o
descarregamento de produo de somente leitura para uma carga de trabalho
sincronizado standby fsico, reparo automtico de blocos de corruptos, e offload de
backups incrementais rpidos.
O foco do Data Guard de alta disponibilidade e recuperao de
dados. Princpios de design do Data Guard so a simplicidade, alto desempenho e
transparncia da aplicao.
Data Guard no se destina a ser uma soluo de replicao completo. Oracle
GoldenGate a soluo recomendada para as necessidades avanadas de replicao,
como o multi-mestre de replicao, replicao granular de um subconjunto de um
banco de dados, muitos para um topologias de replicao e integrao de
dados. Oracle GoldenGate tambm oferece opes adicionais para reduzir o tempo
de inatividade para manuteno e para migraes de plataformas heterogneas.
Dependendo de suas necessidades, a soluo 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 opes de implantao da Guarda
Exigncia Implantao de dados Opes
Guarda

22

Zero proteo contra perda de dados e
disponibilidade para banco de dados
Oracle
Proteco de Dados mxima Guarda ou a
mxima disponibilidade (SYNC transporte)
e Redo Apply (standby fsico)

Perto de zero perda de dados (de um
dgito segundos) e disponibilidade para o
Oracle Database
Data Guard desempenho mximo (ASYNC
transporte) e Refazer Aplicar


Multi-site proteo, incluindo topologia
com espera perda zero de dados local
para HA e espera remota assncrona para
recuperao de desastres geogrfica para
Oracle Database
Multi-espera configurao do Data Guard
e Redo Apply






Failover do banco de dados o mais rpido
possvel
Data Guard Fast-Start Failover com o
Oracle Data Guard corretor para deteco
automtica de falhas e failover de banco
de dados. Failover automtico de
acompanhar aplicativos cliente para o
banco de dados nova produo
implementado usando o Oracle
Notificao Fast Application (FAN) e
Prticas cliente Oracle Melhores de
failover.



Offload consultas somente leitura e
rpidos 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 licena
autnoma opo para Oracle Database
Enterprise Edition, ou (2) includo com
23

corrompidos, transparente para a
aplicao e do usurio
uma licena GoldenGate Oracle.


A pr-produo de testes Espera instantneo. A espera instantneo
um banco de dados fsico de espera que
est temporariamente abrir leitura /
escrita para teste e atividade de leitura /
gravao de outro independente de
transaes de banco de dados
primrios. A espera instantneo
facilmente convertido novamente em um
banco de dados sincronizados de espera
quando o teste for concludo. Snapshot
Standby um recurso includo de Dados
Refazer Guarda Aplicar e um
complemento ideal para o Oracle Real
Application Testing.

Manuteno planejada: algumas
migraes de plataforma como o
Windows para o Linux, move-se do centro
de dados, aplicao de patches e
software de sistema atualizar ou banco de
dados Oracle
Data Guard transio, transio funo
planejada, usando Refazer
Aplicar. Refazer Aplicar e espera-primeiro
patch para a qualificao Aplicar patches
de 11.2.0.1 em diante. SQL Apply e Data
Guard atualizaes sem interrupo de
banco de dados (10,1 em diante). Data
Guard espera Lgico transitria
(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 possvel, coloque os
dados do sistema de operao 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 prticas para o modo de proteo:
Modo de Proteco mxi ma garante que no haja perda de dados ir
ocorrer se a base de dados principal falhar, mesmo no caso de falhas de
mltiplas (por exemplo, a falha de rede entre o primrio de espera e, em
seguida, em um momento posterior, o primrio falhar). Isso reforado por
nunca sinalizao sucesso de confirmao de uma transao de banco de
dados principal, pelo menos at uma espera Guarda sncrona de dados
reconheceu que refazer foi endurecido para o disco. Sem essa confirmao
do banco de dados primrio vai parar e, eventualmente, encerrar em vez de
permitir transaes desprotegidos a cometer. Para manter a disponibilidade
nos casos em que o banco de dados principal operacional, mas o banco de
dados de espera no , a melhor prtica sempre ter um mnimo de dois
bancos de dados standby sncronas em uma configurao de proteo
mxima. Disponibilidade de dados primrio no afectado se receber
confirmao de pelo menos um banco de dados sncrona de espera.
25

Modo a mxima 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 configurao. Ao contrrio do modo de proteo
anterior, a disponibilidade mxima vai esperar um mximo de segundos
NET_TIMEOUT por uma confirmao de um banco de dados de espera, aps
o que ser sinal de comprometer o sucesso da aplicao e passar para a
prxima transao. Disponibilidade banco de dados primrio (da o nome do
modo de proteo) no 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 conexo restabelecer e voltar a sincronizar o banco de
dados standby quando possvel, mas durante o perodo primrio e espera ter
divergido haver perda de dados deve ser um impacto segunda falha do
banco de dados primrio. Por esta razo, uma boa prtica para monitorar o
nvel de proteo (simples usando o Enterprise Manager Grid Control) e
resolver rapidamente qualquer interrupo na comunicao entre primrio e
de espera antes de uma segunda falha pode ocorrer.
Modo de desempenho mximo (o modo padro) fornece o mais alto nvel de
proteco de dados que possvel, sem afetar o desempenho ou a
disponibilidade do banco de dados primrio. Isso realizado por permitir que
uma transao de cometer to logo os dados de redo necessrios para
recuperar a transao escrita no log de redo on-line local no banco de
dados primrio (o mesmo comportamento como se no houvesse nenhum
banco de dados de espera). Oracle Data Guard transmite refazer o banco de
dados de espera diretamente do assncrona principal log buffer para a
gravao de log on-line redo local. Nunca h qualquer espera por
reconhecimento de espera. Semelhante a mxima disponibilidade, uma boa
prtica para monitorar o nvel de proteo (simples usando o Enterprise
Manager Grid Control) e resolver rapidamente qualquer interrupo na
comunicao entre primrio e de espera antes de uma segunda falha pode
ocorrer.

26

12.2 Gestor de Recuperao de usar para criar Bancos de Dados

A Oracle recomenda que voc use o Recovery Manager (RMAN) utilitrio
para simplificar o processo de criao de um banco de dados fsico de espera.
Voc pode criar um banco de dados de espera a partir de cpias de
segurana de seu banco de dados primrio, 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 cpias de segurana de
seu banco de dados primrio.
Voc pode usar qualquer cpia de backup do banco de dados principal para
criar o banco de dados fsico de espera se as necessrias arquivos de log
redo arquivados para recuperao completa do banco de dados so
acessveis a sesso 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 opo para criar o banco de dados
de espera na rede se um backup de banco de dados pr-existente no
acessvel para o sistema de espera.
RMAN copia os arquivos de dados diretamente do banco de dados primrio
para o banco de dados de espera. O banco de dados principal deve ser
montado ou aberto.
Voc deve escolher entre a duplicao ativo e backup baseado. Se voc no
especificar o FROM ACTIVE DATABASE opo, ento, faz o backup RMAN
baseada em duplicao. A criao de um banco de dados sobre a rede de espera
vantajosa porque:
Voc pode transferir dados de redo diretamente para o host remoto atravs
da rede sem ter que seguir os passos de realizar um backup do banco de
27

dados primrio. (Restaurao requer vrias etapas, incluindo o
armazenamento de backup local no banco de dados principal, transferindo o
backup atravs da rede, armazenando o backup localmente no banco de
dados de espera, e ento restaurar o backup do banco de dados de espera.)
Com a duplicao 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, restaurao necessrio que voc faa backup do primrio
e copiar os arquivos de backup no sistema principal arquivo host, transferir os
arquivos de backup atravs 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 FORA

Quando o banco de dados primrio est em FORCE LOGGING FORCE
LOGGING modo, todas as alteraes de dados do banco de dados so
registrados. FORCE LOGGING modo garante que o banco de dados standby
permanece consistente com o banco de dados principal. Se isso no possvel
porque necessrio o desempenho de carga com NOLOGGING operaes, ento
se deve garantir que os fsicos correspondentes arquivos de dados de espera so
posteriormente sincronizados. Para sincronizar os arquivos fsicos de dados de
espera, ou aplicar um backup incremental criado a partir do banco de dados primrio
ou substituir os arquivos afetados espera de dados com um backup dos arquivos de
dados primrios tomadas aps a operao nologging. Antes da transferncia de
arquivos, deve parar Refazer Aplique no banco de dados fsico de espera.
O usurio pode ativar o registro vigor imediatamente, emitindo um ALTER
DATABASE FORCE LOGGING comunicado. Se voc especificar FORCE
LOGGING , o Oracle espera que todas as operaes em curso no registrados ao
fim.

28

12.4 Estratgia de arquivamento e Configurao

Este estratgia de arquivamento baseada nos seguintes pressupostos:
Cada banco de dados utiliza uma rea de recuperao rpida.
O principal banco de dados de arquivo casos remotamente a um s aplicar
exemplo.
Tabela 2 - Recomendaes Arquivamento
Recomendao Descri o
Iniciar arquivamento nas
bases de dados primrio e
de espera
A manuteno de um banco de dados standby requer
que ative e comee 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 tambm deve ser habilitado no banco
de dados de espera para apoiar transies 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 parmetro deve
especificar o fio, sequncia e atributos de identificao
RESETLOGS, e os ajustes de parmetros deve ser
consistente em todas as instncias. Por
exemplo:LOG_ARCHIVE_FORMAT=arch_%t_%S_%r.
arc
29

Nota: Se a rea de recuperao rpida usado, ento
este formato ignorado.

Executar arquivamento
remoto para apenas uma
instncia de espera e n
para cada banco de dados
Oracle RAC espera.
Tudo banco de dados primrio casos de arquivo para
um destino de espera, usando o mesmo nome de
servio lquido. Oracle Net Services failover tempo de
conexo usada para mudar automaticamente para o
host "secundrio" modo de espera quando a instncia
de "primrio" de espera tem uma interrupo.
Se os arquivos so acessveis a partir de todos os ns
porque a Oracle ASM ou algum outro sistema de
arquivos compartilhado est sendo usado para a rea
de recuperao rpida, em seguida, o arquivamento
remoto pode ser espalhado em diferentes ns de um
banco de dados Oracle RAC espera.

Especifique baseadas em
funo destinos com
o VALID_FOR atributo
O VALID_FOR VALID_FOR atributo permite que
configure os atributos do destino para o primrio e os
papis de banco de dados standby em um servidor de
arquivos parmetro (SPFILE), de modo que a
configurao do Data Guard funciona corretamente
aps uma transio de papel. Isto simplifica
switchovers e failovers, removendo a necessidade de
ativar e desativar os arquivos de papel de parmetros
especficos aps uma transio de papel.

O exemplo a seguir ilustra a recomendada parmetros de inicializao para
um banco de dados primrio comunicar a um banco de dados fsico de
espera. H duas instncias, SALES1 e SALES2 , correndo em modo de
proteo mxima.
*. DB_RECOVERY_FILE_DEST =+RECO
30

*. LOG_ARCHIVE_DEST_1 = 'SERVIO = 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
Mea leitura de E / S nos preos redo logs de espera e redo diretrios de
log. Gravao simultnea de refazer enviado em um banco de dados standby pode
reduzir a taxa de leitura de refazer devido saturao de E / S. A taxa de
recuperao 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 recuperao
necessrios.
Taxa de Recuperao Avaliao
Para obter o histrico das taxas de recuperao, use a seguinte consulta para
obter uma histria de progresso de recuperao:
SELECT * FROM V RECOVERY_PROGRESS $;
Se o ACTIVE APPLY RATE maior do que a taxa mxima de gerao de
redo no banco de dados primrio ou duas vezes a taxa de gerao de mdia no
banco de dados primrio, ento necessrio nenhum ajuste, caso contrrio, seguir
as dicas de ajuste abaixo. A taxa de gerao de redo para o banco de dados
primrio pode ser monitorado a partir do Enterprise Manager ou extrada de
relatrios AWR sob estatstica REDO SIZE . Se CHECKPOINT TIME PER LOG
maior do que dez segundos, ento, 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 rpido o suficiente para manter-se com
taxas mais das aplicaes de gerao de refazer, mas voc pode desativar
temporariamente DB_BLOCK_CHECKING para acelerar a recuperao. Se voc
desativar DB_BLOCK_CHECKING , voc ir desativar na memria cheques blocos
semnticos.
Para verificar a corrupo bloco que no era evitvel atravs
da DB_BLOCK_CHECKING parmetro, utilize:
RMAN BACKUP com o comando VALIDATE opo
DBVERIFY utilitrio
ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE instruo
SQL











32

12 CRIANDO UMA BASE DE RPLICA FSICA

Nos captulos anteriores verificamos o que o Oracle DataGuard, qual sua
finalidade e suas principais caractersticas. Neste captulos iremos criar uma Base
de Replica Fsica.
Lembrando que uma rplica fsica nada mais do que uma cpia real do
banco de dados, sem quaisquer alteraes ou customizao na sua estrutura. Como
laboratrio, foram criadas duas mquinas virtuais.

1. Realizar conexo via SQLPLUS no servidor de produo
[oracle@localhost ~]$ sqlplus /nolog
SQL*Pl us: Rel ease 11. 2. 0. 2. 0 Pr oduct i on on Sat Dec 8 10: 41: 49 2012
Copyr i ght ( c) 1982, 2010, Or acl e. Al l r i ght s r eser ved.

SQL> conn sys/oracle as sysdba
Connect ed.

2. Verificar se o servidor encontra-se em modo de arquivamento:
SQL> select log_mode from v$database;
LOG_MODE
- - - - - - - - - - - -
ARCHI VELOG

3. Acessar novamente o SQLPLUS, desconectar o Banco de Dados e mont-lo:
SQL> shutdown immediate
Dat abase cl osed.
Dat abase di smount ed.
ORACLE i nst ance shut down.

SQL> startup mount;
ORACLE i nst ance st ar t ed.
Tot al Syst emGl obal Ar ea 456146944 byt es
Fi xed Si ze 1344840 byt es
Var i abl e Si ze 369101496 byt es
Dat abase Buf f er s 79691776 byt es
Redo Buf f er s 6008832 byt es
Dat abase mount ed.

4. Sair do SQLPLUS e conectar no RMAN:
[oracle@localhost ~]$ rman target /
Recover y Manager : Rel ease 11. 2. 0. 2. 0 - Pr oduct i on on Sat Dec 8 11: 33: 16 2012
Copyr i ght ( c) 1982, 2009, Or acl e and/ or i t s af f i l i at es. Al l r i ght s r eser ved.
connect ed t o t ar get dat abase: ORCL ( DBI D=1229390655, not open)

33

5. Ainda no banco de produo, realizar backup um backup da base:
RMAN> r un {
backup dat abase f or mat ' / t mp/ bkp_col d_f ul l _%d_%t _%p. bkp' i ncl ude cur r ent
cont r ol f i l e spf i l e;
}
St ar t i ng backup at 08- DEC- 12
usi ng channel ORA_DI SK_1
channel ORA_DI SK_1: st ar t i ng f ul l dat af i l e backup set
channel ORA_DI SK_1: speci f yi ng dat af i l e( s) i n backup set
i nput dat af i l e f i l e number =00002
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / sysaux01. dbf
i nput dat af i l e f i l e number =00001
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / syst em01. dbf
i nput dat af i l e f i l e number =00004
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / user s01. dbf
i nput dat af i l e f i l e number =00005
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / exampl e01. dbf
i nput dat af i l e f i l e number =00003
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / undot bs01. dbf
i nput dat af i l e f i l e number =00008
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / r man. dbf 1
i nput dat af i l e f i l e number =00007
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / APEX_2041602962184952. dbf
i nput dat af i l e f i l e number =00006
name=/ home/ or acl e/ app/ or acl e/ or adat a/ or cl / APEX_1930613455248703. dbf
channel ORA_DI SK_1: st ar t i ng pi ece 1 at 08- DEC- 12
channel ORA_DI SK_1: f i ni shed pi ece 1 at 08- DEC- 12
pi ece handl e=/ t mp/ bkp_col d_f ul l _ORCL_801491495_1. bkp t ag=TAG20121208T123135
comment =NONE
channel ORA_DI SK_1: backup set compl et e, el apsed t i me: 00: 04: 06
channel ORA_DI SK_1: st ar t i ng f ul l dat af i l e backup set
channel ORA_DI SK_1: speci f yi ng dat af i l e( s) i n backup set
i ncl udi ng cur r ent cont r ol f i l e i n backup set
channel ORA_DI SK_1: st ar t i ng pi ece 1 at 08- DEC- 12
channel ORA_DI SK_1: f i ni shed pi ece 1 at 08- DEC- 12
pi ece handl e=/ t mp/ bkp_col d_f ul l _ORCL_801491742_1. bkp t ag=TAG20121208T123135
comment =NONE
channel ORA_DI SK_1: backup set compl et e, el apsed t i me: 00: 00: 01
channel ORA_DI SK_1: st ar t i ng f ul l dat af i l e backup set
channel ORA_DI SK_1: speci f yi ng dat af i l e( s) i n backup set
i ncl udi ng cur r ent SPFI LE i n backup set
channel ORA_DI SK_1: st ar t i ng pi ece 1 at 08- DEC- 12
channel ORA_DI SK_1: f i ni shed pi ece 1 at 08- DEC- 12
pi ece
handl e=/ home/ or acl e/ app/ or acl e/ f l ash_r ecover y_ar ea/ ORCL/ backupset / 2012_12_08/ o1_mf _
nnsnf _TAG20121208T123135_8d7957ok_. bkp t ag=TAG20121208T123135 comment =NONE
channel ORA_DI SK_1: backup set compl et e, el apsed t i me: 00: 00: 01
Fi ni shed backup at 08- DEC- 12

St ar t i ng Cont r ol Fi l e and SPFI LE Aut obackup at 08- DEC- 12
pi ece
handl e=/ home/ or acl e/ app/ or acl e/ f l ash_r ecover y_ar ea/ ORCL/ aut obackup/ 2012_12_08/ o1_mf
_s_801485350_8d7958z0_. bkp comment =NONE
Fi ni shed Cont r ol Fi l e and SPFI LE Aut obackup 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

Dat abase al t er ed.

7. Ainda no SQLPLUS, criar um PFILE a partir do SPFILE
SQL> create pfile='/tmp/initteste.ora' from spfile;
Fi l e cr eat ed.

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 padro do
Oracle:
[oracle@standby ~]$ mv /tmp/initteste.ora
/home/oracle/app/oracle/product/11.2.0/dbs/inittester.ora

10. Aps 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 tambm substituir no
campo orcl por standby. A nica exceo 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 alterao, 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'
*. audi t _t r ai l =' DB'
*. cl i ent _r esul t _cache_l ag=3000
*. cl i ent _r esul t _cache_si ze=67108864
*. compat i bl e=' 11. 2. 0. 0. 0'
*.control_files='/home/oracle/app/oracle/oradata/standby/control01.ctl','/home/oracle/app/orac
le/flash_recovery_area/standby/control02.ctl'
*. db_bl ock_si ze=8192
*. db_domai n=' '
*. db_name=' or cl '
*.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_r ecover y_f i l e_dest _si ze=4039114752
*. db_r ecover y_f i l e_dest =' / home/ or acl e/ app/ or acl e/ f l ash_r ecover y_ar ea'
*. di agnost i c_dest =' / home/ or acl e/ app/ or acl e'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=standbyXDB)'
*. event =' '
*.local_listener='LISTENER_STANDBY'
*. l og_ar chi ve_st ar t =TRUE
*. max_shar ed_ser ver s=5
*. memor y_t ar get =457179136
*. open_cur sor s=300
*. pr ocesses=150
*. r emot e_l ogi n_passwor df i l e=' EXCLUSI VE'
*. shar ed_ser ver s=10
*. undo_t abl espace=' UNDOTBS1'

12. Agora, iremos criar os diretrios 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 prximo 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 comear a restaurar os controlfiles no servidor Standby , via RMAN e
colocando a instancia em modo mount. Observe abaixo que os documentos foram
restaurados no diretrio 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_TAG20121201T
085031_8cnfbr6d_.bkp
channel ORA_DISK_1: piece
handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2012_12_01/o1_mf_nnndf_TAG20
121201T085031_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_TAG20121201T
104620_8cnn3wpz_.bkp
channel ORA_DISK_1: piece
handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2012_12_01/o1_mf_nnndf_TAG20
121201T104620_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 instncia principal (orcl), iremos realizar algumas alteraos em seu init. O
intuito desta alterao inserir parmetros do Data Guard no init do servidor principal. As
alteraes propostas sero 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
Recover y Manager compl et e.

[oracle@localhost ~]$ sqlplus /nolog
SQL*Pl us: Rel ease 11. 2. 0. 2. 0 Pr oduct i on on Thu Dec 13 08: 19: 20 2012
Copyr i ght ( c) 1982, 2010, Or acl e. Al l r i ght s r eser ved.

SQL> conn sys/oracle as sysdba
Connect ed.

SQL> shutdown immediate;
ORA- 01109: dat abase not open
Dat abase di smount ed.
ORACLE i nst ance shut down.

21. O prximo passo ser realizar a alterao 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 f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on on 13- DEC- 2012 08: 30: 33
Copyr i ght ( c) 1991, 2010, Or acl e. Al l r i ght s r eser ved.

Connect i ng t o ( DESCRI PTI ON=( ADDRESS=( PROTOCOL=TCP) ( HOST= l ocal host ) ( PORT=1521) ) )
STATUS of t he LI STENER
- - - - - - - - - - - - - - - - - - - - - - - -
Al i as LI STENER
Ver si on TNSLSNR f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on
St ar t Dat e 12- DEC- 2012 15: 16: 26
Upt i me 0 days 17 hr . 14 mi n. 7 sec
Tr ace Level of f
Secur i t y ON: Local OS Aut hent i cat i on
SNMP OFF
Li st ener Par amet er Fi l e
/ home/ or acl e/ app/ or acl e/ pr oduct / 11. 2. 0/ dbhome_2/ net wor k/ admi n/ l i st ener . or a
Li st ener Log Fi l e
/ home/ or acl e/ app/ or acl e/ di ag/ t nsl snr / l ocal host / l i st ener / al er t / l og. xml
Li st eni ng Endpoi nt s Summar y. . .
( DESCRI PTI ON=( ADDRESS=( PROTOCOL=t cp) ( HOST=l ocal host ) ( PORT=1521) ) )

40

Ser vi ces Summar y
Ser vi ce orcl has 1 i nst ance( s) .
I nst ance or cl , st at us UNKNOWN, has 1 handl er ( s) f or t hi s ser vi ce

The command compl et ed successf ul l y

[oracle@standby ~]$ lsnrctl status

LSNRCTL f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on on 13- DEC- 2012 15: 05: 17

Copyr i ght ( c) 1991, 2010, Or acl e. Al l r i ght s r eser ved.

Connect i ng t o ( DESCRI PTI ON=( ADDRESS=( PROTOCOL=TCP) ( HOST=st andby) ( PORT=1521) ) )
STATUS of t he LI STENER
- - - - - - - - - - - - - - - - - - - - - - - -
Al i as LI STENER
Ver si on TNSLSNR f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on
St ar t Dat e 12- DEC- 2012 15: 27: 55
Upt i me 0 days 23 hr . 37 mi n. 22 sec
Tr ace Level of f
Secur i t y ON: Local OS Aut hent i cat i on
SNMP OFF
Li st ener Par amet er Fi l e
/ home/ or acl e/ app/ or acl e/ pr oduct / 11. 2. 0/ dbhome_2/ net wor k/ admi n/ l i st ener . or a
Li st ener Log Fi l e
/ home/ or acl e/ app/ or acl e/ di ag/ t nsl snr / st andby/ l i st ener / al er t / l og. xml
Li st eni ng Endpoi nt s Summar y. . .
( DESCRI PTI ON=( ADDRESS=( PROTOCOL=t cp) ( HOST=st andby) ( PORT=1521) ) )
Li st eni ng Endpoi nt s Summar y
( DESCRI PTI ON=( ADDRESS=( PROTOCOL=t cp) ( HOST=st andby) ( PORT=1521) ) )
Ser vi ces Summar y
Ser vi ce st andby has 1 i nst ance( s) .
I nst ance st andby, st at us UNKNOWN, has 1 handl er ( s) f or t hi s ser vi ce
The l i st ener suppor t s no ser vi ces
The command compl et ed successf ul l y

/ home/ or acl e/ app/ or acl e/ pr oduct / 11. 2. 0/ dbhome_2/ net wor k/ admi n

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 diretrio
/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 Pi ng Ut i l i t y f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on on 13- DEC- 2012 16: 21: 47

Copyr i ght ( c) 1997, 2010, Or acl e. Al l r i ght s r eser ved.

Used par amet er f i l es:

Used HOSTNAME adapt er t o r esol ve t he al i as
At t empt i ng t o cont act
( DESCRI PTI ON=( CONNECT_DATA=( SERVI CE_NAME=) ) ( ADDRESS=( PROTOCOL=TCP) ( HOST=192. 168. 0. 1
) ( PORT=1521) ) )
OK ( 10 msec)

[oracle@localhost ~]$ tnsping 192.168.0.2

41

TNS Pi ng Ut i l i t y f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on on 13- DEC- 2012 16: 21: 53

Copyr i ght ( c) 1997, 2010, Or acl e. Al l r i ght s r eser ved.

Used par amet er f i l es:

Used HOSTNAME adapt er t o r esol ve t he al i as
At t empt i ng t o cont act
( DESCRI PTI ON=( CONNECT_DATA=( SERVI CE_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 Pi ng Ut i l i t y f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on on 13- DEC- 2012 16: 29: 21

Copyr i ght ( c) 1997, 2010, Or acl e. Al l r i ght s r eser ved.

Used par amet er f i l es:


Used TNSNAMES adapt er t o r esol ve t he al i as
At t empt i ng t o cont act ( DESCRI PTI ON = ( ADDRESS = ( PROTOCOL = TCP) ( HOST =
192. 168. 0. 2) ( PORT = 1521) ) ( CONNECT_DATA = ( SERVER = DEDI CATED) ( SERVI CE_NAME =
st andby) ) )
OK ( 10 msec)

[oracle@standby ~]$ tnsping 192.168.0.1

TNS Pi ng Ut i l i t y f or Li nux: Ver si on 11. 2. 0. 2. 0 - Pr oduct i on on 13- DEC- 2012 16: 29: 24

Copyr i ght ( c) 1997, 2010, Or acl e. Al l r i ght s r eser ved.

Used par amet er f i l es:

Used HOSTNAME adapt er t o r esol ve t he al i as
At t empt i ng t o cont act
( DESCRI PTI ON=( CONNECT_DATA=( SERVI CE_NAME=) ) ( ADDRESS=( PROTOCOL=TCP) ( HOST=192. 168. 0. 1
) ( PORT=1521) ) )
OK ( 0 msec)

24. No vigsimo passo, realizamos a parada da instancia principal (orcl) para alterar os
parmetros 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

Coma i nst anci a or cl mont ada, vamos cr i ar o SPFI LE a par t i r dest e i ni t :

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 replicao. 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 replicao fsica:
SQL> alter database open read only;
Database altered.

28. Ainda na instancia standby, iremos iniciar o processo de replicao, 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 parametrizao, 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 responsvel 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 replicao 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

REFERNCIAS BIBLIOGRFICAS

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, J oe. 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.