Você está na página 1de 55

FACULDADE DE INFORMTICA E ADMINISTRAO PAULISTA

MICHEL TEMER FERES


RAFAEL BIAZETTO AYUSSO FERNANDES
SINSIO CARLOS MATOS FERREIRA

I M P L A N TA O F S I C A D O O R A C L E S TAN D B Y

So Paulo
2011

MICHEL TEMER FERES


RAFAEL BIAZETTO AYUSSO FERNANDES
SINSIO CARLOS MATOS FERREIRA

I M P L A N TA O F S I C A D O O R A C L E - S TAN D B Y

Trabalho
de
Concluso
de
Curso
apresentado Faculdade de Informtica e
Administrao Paulista, como um dos
requisitos para concluso do Curso de PsGraduao em Administrao de Banco de
Dados Oracle na turma 22ORC.
Orientador: Prof. Vidal Olavo Plessmann
Gonalves

So Paulo
2011

MICHEL TEMER FERES


RAFAEL BIAZETTO AYUSSO FERNANDES
SINSIO CARLOS MATOS FERREIRA

I M P L A N TA O F S I C A D O O R A C L E - S TAN D B Y
Trabalho de Concluso de Curso
apresentado Faculdade de Informtica
e Administrao Paulista, como um dos
requisitos para concluso do Curso de
Ps-Graduao em Administrao de
Banco de Dados Oracle na turma
22ORC.

Aprovada em ____________ de 2011.

BANCA EXAMINADORA

Prof. Vidal Olavo Plessmann Gonalves


Orientador

Prof.() Ms. ou Dr.


Componente da Banca

Prof.() Ms. ou Dr.


Componente da Banca

AGRADECIMENTOS

Agradecimentos:

Queremos

agradecer

primeiramente a DEUS, por nos conceder a


oportunidade de concluir mais essa etapa em
nossas vidas, que o trmino desse curso de
MBA, e tambm aos nossos mestres que muito
nos apoiaram no decorrer do curso, e em
especial o nosso Orientador professor Vidal,
pela dedicao e por nos dirigir durante
desenvolvimento desse trabalho.

RESUMO
Atualmente, a necessidade de disponibilizar as informaes com confiana,
eficincia, e tempo hbil para os casos que exigem a recuperao do mesmo, algo
preocupante perante qualquer empresa que possua informao digital. Com essa
preocupao, existem diversos recursos/ferramentas disponveis no mercado com o
objetivo de atender essa questo to arriscada e sensvel. Entre as principais
empresas atuantes na rea de TI, a Oracle oferece esse recurso para o seu produto
mais respeitado no mundo: O Sistema de Gerenciador de Banco de dados. Esse
recurso chamado Stand By, possui os seguintes objetivos:
- Desempenho aprimorado;
- Manter mltiplos bancos de dados Stand By(Reserva) para um banco de
dados principal;
- Existncia de uma ou vrias cpias de dados idnticas com os originais;
- Garantia de que os dados no sero perdidos durante o processo;
- Possibilidade dos servidores stand by estarem em locais diferentes do
servidor principal;
- Disponibilizao do servio de banco de dados permanente;
- Realizao simples e rpida para os casos de reparo ou troca do servidor
principal.
Este trabalho tem o objetivo de demonstrar esse recurso de banco de
dados, assim como as suas principais configuraes, desde a criao do ambiente,
a sua monitorao at as tomadas de decises a serem adotadas em casos de
falhas dos equipamentos envolvidos ou at mesmo em catstrofes naturais que
possam interferir na disponibilidade das informaes.

Palavras-chave: Banco de Dados. Oracle. Alta Disponibilidade. Stand By.

ABSTRACT
Currently, the necessity of providing information in a reliable, efficient and timely
manner in cases that its restoring is required, is concerning for any company which
possesses digital information. For that purpose, there are different resources/tools
available in the market aiming at meeting this risky and sensitive need. Among the
main companies in the IT industry, Oracle offers a resource for its most respected
product in the world: Database Administration System. Called Stand By, this resource
has the following objectives:
-

Enhanced performance;
Maintenance of multiple Stand By databases for a same primary database;
Existence of one or several backup copies identical to the originals;
Assurance that data wont be lost during the process;
Possibility of running the stand by server on a remote server;
Availability of the permanent database service;
Quick and simple execution in cases of restoring or changing the primary
database.

This paper aims at demonstrating this database resource, as well as its mains
settings, from environment creation and its monitoring to decisions to be made in
cases of hardware failure or even in natural disaster situations which can affect
information availability.

Key words: Database, Oracle, High Availability, Stand By.

LISTA DE ILUSTRAES

FIGURAS
Figura 1: Ambiente Stand By..................................................................15
Figura 2: Configurao simples do Oracle Stand By..............................18
Figura 3: Arquitetura de Processos do Oracle Stand By........................19
Figura 4: Comunicao entre o SRV_PROD e SRV_STD.....................28
Figura 5: Comunicao entre o SRV_STD e SRV_PROD.....................29

SUMRIO

INTRODUO............................................................................................................10
TEMA....................................................................................................................... 11
JUSTIFICATIVA...........................................................................................................11
PROBLEMA DE PESQUISA..........................................................................................12
HIPTESE................................................................................................................ 13
1.

2.

3.

4.

5.

OBJETIVOS.........................................................................................................14
1.1.

OBJETIVO GERAL.......................................................................................... 14

1.2.

OBJETIVO ESPECFICO...................................................................................14

O RECURSO ORACLE STAND BY....................................................................15


2.1.

APRESENTAO/DEFINIES..........................................................................15

2.2.

TIPOS DE BANCOS DE DADOS STAND BY........................................................17

2.3.

ARQUITETURA DE PROCESSO DO ORACLE STAND BY......................................19

2.4.

SERVIOS DO ORACLE STAND BY..................................................................21

2.5.

DATA GUARD BROKER...................................................................................23

2.6.

INVESTIMENTO...............................................................................................23

2.7.

PR-REQUISITOS........................................................................................... 24

ESTUDO DE CASO.............................................................................................25
3.1.

DESCRIO DO CENRIO...............................................................................25

3.2.

PROBLEMAS..................................................................................................26

3.3.

SOLUES INDICADAS...................................................................................27

CRIAO DO BANCO DE DADOS STAND BY..................................................28


4.1.

DESCRIO DOS SERVIDORES.......................................................................28

4.2.

VERIFICANDO A COMUNICAO ENTRE OS DOIS SERVIDORES..........................28

4.3.

CONFIGURANDO O SERVIDOR PRIMRIO.........................................................29

4.4.

CONFIGURANDO O SERVIDOR SECUNDRIO....................................................39

ADMINISTRANDO OS BANCOS DE DADOS....................................................44


5.1.

INICIALIZANDO O SERVIDOR PRIMRIO............................................................44

5.2.

CRIANDO

ARQUIVO

DE

INICIALIZAO DINMICO

DO

BANCO

DE

DADOS

PRINCIPAL................................................................................................................44
5.3.

INICIALIZANDO O SERVIDOR SECUNDRIO.......................................................44

5.4.

CRIANDO

BY

45

5.5.

APLICAO DOS ARCHIVES............................................................................45

5.6.

CANCELANDO A APLICAO DOS ARCHIVES....................................................46

5.7.

FINALIZANDO A APLICAO DOS ARCHIVES.....................................................46

5.8.

ABRINDO O BANCO DE DADOS STAND BY NO MODO DE LEITURA.....................46

5.9.

CHECAGEM DE APLICAO/SINCRONIZAO ENTRE OS SERVIDORES...............46

5.10.
6.

ARQUIVO

DE INICIALIZAO

DINMICO

DO

BANCO

DE

DADOS STAND

FALHAS NA APLICAO DOS ARCHIVES.......................................................47

OPERAES DE SWITCHOVERS E FAILOVERS............................................48


6.1.

SWITCHOVER.................................................................................................48

6.2.

FAILOVER......................................................................................................50

7.

CONCLUSO......................................................................................................52

8.

BIBLIOGRAFIA....................................................................................................53

9.

GLOSSRIO........................................................................................................55

10

Introduo
Com o uso e a grande dependncia da tecnologia da informao, estamos
cada vez mais nos necessitando dessa preciosidade e inovador mundo digital.
Diante desse cenrio real, muitas vezes passamos por alguns minutos,
podendo chegar a horas, dias e at semanas em uma determinada situao
cotidiana, como por exemplo, ao efetuar algum pagamento bancrio, uma simples
ligao telefnica, ou at mesmo se locomovermos, onde somos totalmente lesados,
devido ausncia temporria de um sistema informatizado, causado diretamente
pela indisponibilidade do servidor de banco de dados, por no oferecer ou no
utilizar algum recurso de banco de dados reserva, usando-o quando necessitado,
para que em momentos como esses apresentados no ocorram. Ao utilizar o banco
de dados Oracle, disponibilizado esse recurso, ou seja, um banco de dados
reserva, que em apenas alguns minutos, desde que bem configurado e um
profissional capacitado, o administrador do banco de dados possa tornar o banco de
dados reserva como o principal, evitando a perda de dados, prejuzo financeiro,
insatisfao dos clientes, perda de inmeras pesquisas de vrios anos de estudos e
at mesmo perder vidas.
E por sermos estudantes/profissionais de tecnologia, demonstraremos atravs
de um estudo de caso, o uso, configurao, monitorao, gerenciamento, e tambm
as possveis condutas a serem tomadas em momentos planejados ou no da parada
do servio de banco de dados, ou diante de um provvel desastre desse servio,
utilizando um dos vrios recursos oferecidos pela Oracle em termos de segurana e
recuperao de dados, que a soluo eficaz e eficiente: O recurso Oracle - Stand
By.

11

Tema
A pesquisa sobre a utilizao do Oracle Stand By fsico ir demonstrar os
benefcios a serem oferecidos, juntamente com as configuraes adequadas, que
sero apresentadas atravs de uma seqncia de comandos, conhecidos tambm
como scripts, aplicando-os em um ambiente bem configurado, proporcionando o
xito durante os procedimentos.

Justificativa
Com o avano e a necessidade do mundo digital, as empresas esto
aplicando grandes recursos financeiros na rea de tecnologia, proporcionando
agilidade, confiana e autonomia em suas informaes. E diante das necessidades
de armazenamentos desses dados, que futuramente se constituir em uma
informao, ou seja, o conjunto de dados, conseqentemente necessitar de um
banco de dados que atender a isso.
E para no correr o risco de um banco de dados se tornar indisponvel,
acarretando em perdas de numerrios, dados, extrao de relatrios para futuras
tomadas de decises e at a incapacidade de dispor servios atrelados a aplicaes
que se interagem diretamente com o banco de dados, surgiu o recurso Oracle
Stand By na verso 7.3, garantindo a alta disponibilidade, proteo e recuperao
dos dados empresariais, que cada vez mais est sendo explorado esse grande
mecanismo oferecido pela Oracle.

12

Problema de Pesquisa
Minayo(1994, p.23), considera a pesquisa como uma atividade bsica das
cincias na sua indagao e descoberta da realidade. uma atitude e uma prtica
terica de constante busca que define um processo intrinsecamente inacabado e
permanente. uma atividade de aproximao sucessiva da realidade que nunca se
esgota,fazendo uma combinao particular entre teoria e dados.
Para Ruiz (1996, p.48), Pesquisa cientfica a realizao concreta de uma
investigao planejada, desenvolvida e redigida de acordo com as normas da
metodologia consagradas pela cincia. o mtodo de abordagem de um problema
em estudo que caracteriza o aspecto cientfico de uma pesquisa. .
Segundo Paviani (2005, p.207), O problema cientfico surge da descoberta
de que o nosso conhecimento no suficiente para descrever e explicar certas
situaes..
Mas para Cervo e Bervian (2002, p.84), o problema ... uma questo que
envolve intrinsecamente uma dificuldade terica ou prtica, para a qual se deve
encontrar uma soluo.
Com o uso da informao digital, toda empresa almeja a existncia, qualidade
e disponibilizao das suas informaes corporativas.
Diante do exposto, o problema de pesquisa :
Garantir a alta disponibilidade dos servios de bancos de dados Oracle,
atravs de um recurso confivel e eficaz, sem grandes esforos de manuseio,
quando necessrio.

13

Hiptese
Severino(2000, p.161) afirma que preciso no confundir hiptese com
pressuposto, com evidncia prvia. Hiptese o que se pretende demonstrar e no
o que j se tem demonstrado evidente, desde o ponto de partida.
Mas para Kelinger (1980, p.30), as hipteses so sentenas declarativas e
relacionam de alguma forma variveis a variveis. So enunciados de relaes, e,
como os problemas, devem envolver os testes das relaes enunciadas. Problemas
e hipteses so semelhantes, s que os problemas so sentenas interrogativas e
as hipteses so as sentenas afirmativas.
E complementando com Lakatos e Marconi (2007, p.139), uma varivel pode
ser considerada como uma classificao ou medida; uma quantidade que varia; um
conceito operacional que contm ou apresenta valores; ou ainda, um aspecto,
propriedade ou fator, discernvel em um objeto de estudo e passvel de
mensurao.
Assim, a hiptese sugerida para a soluo do problema de pesquisa
apresentado, : A indisponibilidade do servio de banco de dados Oracle, seja por
falhas de software ou hardware.

14

1. OBJETIVOS
1.1.

Objetivo Geral

O objetivo principal deste trabalho apresentar uma implementao fsica do


Oracle Stand By, proporcionando a alta disponibilidade, segurana da informao,
gerenciamento e monitorao de um ou mais banco de dados, em modo de espera
(Stand By).

1.2.

Objetivo Especfico

Durante o desenvolvimento deste trabalho, ser explorado o tema Oracle


Stand By, como uma alternativa de evitar futuros problemas em empresas que usam
o gerenciador de banco de dados Oracle, para armazenar com segurana o que tem
de mais importante, que so os dados corporativos.
Ser demonstrado todo um embasamento terico que ilustraro sua
arquitetura, tipos de banco de dados Stand By, os seus pr-requisitos e as
configuraes dos parmetros necessrios. E na seqencia uma aplicao prtica,
exemplificando a utilizao e a configurao adequada, desde a implantao,
acompanhamento dirio at as melhores prticas desse extraordinrio recurso
oferecido, alm de apresentar as possveis tomadas de decises para as situaes
de desastres causados por software ou hardware.

15

2. O RECURSO ORACLE STAND BY


2.1.

Apresentao/Definies

O Oracle Stand BY um recurso de banco de dados Oracle, que tem o


objetivo de garantir a alta disponibilidade, proteger e recuperar seus dados. Ele
constitudo por vrios pacotes, entre eles: o pacote de servios, criao,
manuteno, gerenciamento e monitorao de um ou maus banco de dados que
esto em modo de espera, conhecidos como Stand By, que na verdade so
databases (banco de dados) com cpias sincronizadas de uma base de produo,
podendo ou no estar no mesmo local fsico. Com isso ele mantm seus dados
totalmente seguros e a disponibilidade de servio de banco de dados, caso o banco
de produo principal, se torna indisponvel, seja por uma ao planejada, como por
exemplo, uma manuteno tcnica preventiva/corretiva, ou no.
Em um ambiente utilizando esse recurso, a composio formada por um
banco de dados de produo, conhecido como servidor primrio e de um ou mais
banco de dados em modo de espera, conhecido como servidor secundrio contendo
uma cpia consistente com o de produo.
Para ter uma melhor viso, apresentamos a figura abaixo, que nos relata que
para esse contexto, existe um servidor de aplicao que est realizando todas as
suas transaes em um servidor de produo (servidor primrio) e que atravs do
oracle net essas transaes so replicadas para os servidores stand by(servidor
secundrio) exatamente no momento que finalizado o processo (processo de
background do servidor oracle) de arquivamento dos redo logs.

Figura 1: Ambiente Stand By

16

Pode-se criar at nove bando de dados Stand Ny. O Oracle Stand By mantm
automaticamente atualizados todos esses bancos de dados Stand By, aplicando
todas as modificaes ocorridas no servidor primrio. Um banco de dados primrio
pode ser composto por uma ou mais instncia de banco de dados.
Os banco de dados Stand By pode ser usado apenas para consultas, ou seja,
podem ser utilizados como servidores de relatrios, fazendo com que ocorra um
aumento na disponibilidade dos servios de banco de dados de produo.

17

2.2.

Tipos de Bancos de Dados Stand By

Existem dois tipos de Bancos de Dados em Stand By: Fsico e Lgico.


Fsico: Nessa estrutura o banco de dados possui uma cpia idntica do
servidor primrio, ele tem as mesmas estruturas, mantendo uma cpia bloco a bloco
do banco de dados principal, tornando-o totalmente sincronizado. O seu uso
indicado para backups de banco de dados. Na ausncia do servidor primrio, seja
em caso de desastre ou no, ele pode ser substitudo tranquilamente, pois possui e
uma cpia totalmente segura e atualizada.
Para que essa sincronizao ocorra com sucesso, usado o processo REDO
APPLY, que tem o papel de aplicar os dados dos archives ou dos redo logs do banco
principal para o stand by, atravs do Processo de Recuperao Gerenciada (MRP),
que uma extenso de recuperao de mdia padro da Oracle que reconhece o
Stand By, que ocorre em paralelo para obter o mximo de desempenho.
Lgico: Nessa estrutura o banco de dados possui apenas as estruturas
lgicas idnticas do servidor primrio, a organizao fsica e a estrutura dos dados
podem ser diferentes. Ele sincronizado com o banco de dados principal, atravs do
processo SQL APPLY, que realiza a transformao das informaes capturadas dos
arquivos de redo log do banco principal em linguagem SQL aplicando-as no banco
secundrio.
Ao contrrio do Stand By Fsico, ele no precisa ficar em modo de leitura.
Enquanto iniciado ou no o processo sql apply, os usurios podem acessar esse
banco, alm do primrio, para fins de consultas a qualquer momento, caracterizando
como uma proteo de dados, permitindo at possuir objetos diferentes entre eles.
A figura abaixo apresenta uma configurao simples do Oracle Stand By. H
um banco de dados principal (servidor primrio) que transmite os dados do redo
para o Stand By Fsico ou Lgico, que podero ou no estar em locais distintos, e
para essa configurao o stand by fsico est preparado para uma recuperao em
caso de desastres e operaes de backup, j o stand by lgico principalmente para

18

extrao de relatrios, mas ele pode ser usado tambm para uma recuperao em
caso de desastres. possvel configurar o Oracle Stand By, tanto o fsico quanto o
lgico, nos mesmos locais fsicos do servidor primrio.
A Oracle recomenda que o banco de dados stand by seja configurado em
local diferente do servidor principal.

Figura 2: Configurao simples do Oracle Stand By

19

2.3.

Arquitetura de Processo do Oracle Stand By

A arquitetura ser apresentada atravs da figura abaixo, demonstrando o


funcionamento dos seus processos, assim como a descrio de cada um deles.

Figura 3: Arquitetura de Processos do Oracle Stand By

LGWR (Log Writer): Processo responsvel por gravar os dados existentes nos
redo logs on-line, e um dos integrantes do servio de transporte dos logs.
ARCH (Archiver): Realiza o arquivamento dos dados dos redo logs on-line,
gera os archived redo logs que so utilizados pelo Oracle Net com o objetivo de ser
transportado ao servidor secundrio, e tambm um dos integrantes do servio de
transporte dos logs.
FAL (Fetch Archive Log): Gerenciador das possveis falhas geradas durante o
recebimento dos archived redo logs. Este processo faz parte somente do Stand By

20

Fsico, e constitudo por um FAL Cliente e um FAL Servidor. O FAL Cliente,


requisita a transferncia dos archived redo logs faltantes no servidor secundrio, j o
FAL Servidor, atende as requisies do processo cliente. Esse processo
configurado atravs dos parmetros FAL_CLIENT e FAL_SERVER no servidor
secundrio, e tambm um dos integrantes do servio de transporte dos logs.
RFS (Remote File Server): Processo existente no servidor secundrio, ele
recebe os redo logs do servidor primrio, e tambm um dos integrantes do servio
de transporte dos logs.
LSP (Logical Standby Process) : Aplica os archived redo logs atravs do uso
sql, existente apenas no Stand By Lgico, e tambm um dos integrantes do
servio de transporte dos logs.
MRP (Managed Recovery Process): Aplica os archived redo, existente apenas
no Stand By Fsico, e tambm um dos integrantes do servio de transporte dos
logs.
DMON (Data Guard Monitor): Processo que auxilia na juno do servidor
primrio e do servidor secundrio para um nico processo, ele gerencia outros
processos como o Switchover e Failover que responsvel pela mudana de papis
e tambm por fazer a monitorao dos servios de aplicao e transportao dos
logs.

21

2.4.

Servios do Oracle Stand By

O Oracle Stand By utiliza os servios abaixo, para gerenciar a transmisso e


aplicao dos dados dos redo logs on-line, assim como tambm controlar as regras
para as trocas dos bancos de dados.
Log Transport Services (Servio de Transporte de Log): Esse servio controla o
arquivamento e transporte dos dados do redo log on-line do servidor primrio para o
servidor secundrio.
Log Apply Services (Servio de Aplicao de Log): Esse servio aplica os
archived redo logs no servidor secundrio, mantendo o sincronismo com o servidor
primrio, possibilitando a realizao de consultas consistentes.
Role Management Services (Servio de Gerenciamento de Regra ): Esse servio
fornece a troca entre os bancos: Servidor primrio para o secundrio ou vice-versa,
para as situaes:
Failover - Processo utilizado para tornar um servidor secundrio em primrio,
devido algum desastre do servidor primrio, indicado somente em caso de total
urgncia, e, alm disso, existe a possibilidade de perder dados.
Switchover - Processo utilizado para tornar um servidor primrio em secundrio,
garantindo que no h qualquer perda de dados.
Para as operaes de Failover, ainda possvel configurar:
Failover sem perda de dados. possvel quando o servidor primrio estiver
operando no modo de Proteo Mxima ou Mxima Disponibilidade.
Failover com perda mnima de dados. Poder ocorrer quando as alteraes no
estiverem disponveis no momento do Failover, caso esteja operando no modo de
Mxima Performance.
Os servios responsveis por enviar e aplicar os logs podem ser realizados
atravs das seguintes opes:

22

Delayed Apply (Aplicao atrasa): Poder ocorrer, caso o servidor primrio esteja
ativo e o servidor secundrio no esteja sincronizado com o servidor primrio, ou
seja, aplicado as transaes de forma atrasada. No modo de proteo mxima ou
mxima disponibilidade esse recurso no est disponvel, podemos utiliz-lo
somente no modo de mxima performance.
Cascade StandBy Database (Banco de Dados Stand BY em cascata): Indicado
quando houver mais de um banco de dados Stand By, pois quando for enviado os
dados do redo do servidor primrio para o secundrio, ele ir ser responsvel por
passar esses dados tambm ao terceiro servidor (segundo servidor secundrio),
fazendo com que a carga do servidor primrio se reduza.
Automatic

Resynchronization

(Ressincronizao

Automtica):

Opo

Resynchronization (Ressincronizao Automtica):Opo extremamente importante,


caso o banco de dados secundrio se tornar indisponvel temporariamente, o
servidor principal armazena todos os logs que sero automaticamente enviado ao
servidor secundrio, assim que o mesmo voltar a estar disponvel.

23

2.5.

Data Guard Broker

O Data Guard Broker um software que pode ser usado tanto para gerenciar,
como dar manuteno nos bancos Stand By, atravs de uma interface grfica ou
linha de comando, e as suas principais funes so:
- Gerenciar os bancos de dados stand by;
- Habilitar as configuraes do servidor secundrio, incluindo o servio de
transporte e aplicao dos logs, alm dos procedimentos de switchover e failover;
- Criar um Stand By Fsico ou lgico, partir de uma cpia de backup do servidor
primrio;
- Monitorar as taxas de aplicao de logs;
- Detectar possveis problemas existentes no processo de execuo de aplicao
dos logs;
Alm das funes j informadas, ele permite um controle e um monitoramento
eficiente no ambiente, devido a sua automao das tarefas de gerenciamento. Essa
ferramenta aumenta a alta disponibilidade e auxilia com agilidade nas operaes de
failover e switchover.

2.6.

Investimento

Para obter esse recurso, necessrio analisar um conjunto de possibilidades.


Primeiramente deve-se adquirir a licena da Oracle Database Enterprise Edition
(EE), e posteriormente realizar um estudo aprofundado com a equipe da infraestrutura para optar qual tipo de banco de dados Stand By a ser implantando,
quantidades/configuraes das mquinas a serem usadas, uso do storage ou no,
tempo/custo estimado para esse projeto (investimento em profissionais, hardware e
software), alm de capacitar os usurios responsveis para monitorar e realizar
alguns procedimentos quando necessrios.

24

2.7.

Pr-requisitos

Aps a definio de qual tipo de banco de dados Stand By a ser implantado,


devemos verificar alguns pr-requisitos bsicos, so eles:
- Sistema operacional e a plataforma no servidor primrio e secundrio, serem
idnticas, mas a verso deles pode ser diferente;
- A mesma verso do banco de dados em ambas as mquinas;
- Ambos os servidores podem ter configurao diferente, como nmero de
processadores, tipo/tamanho de memria e outros;
- Mesma estrutura lgica nos servidores envolvidos;
- Privilgios de SYSDBA (permisso de administrador do banco de dados) para
gerenciar os servidores.
Para as demais configuraes/requisitos, iremos abordar em outro tpico,
quando de fato, formos implantar o Stand By, que ser demonstrado atravs de um
passo a passo com maiores detalhes.

25

3. ESTUDO DE CASO
Para ilustrar a utilizao prtica desse recurso, iremos realizar a instalao de um
Oracle Stand By em uma instituio de pequeno porte, atuante na rea educacional
por mais de 20 (vinte) anos, e que, a pedido da prpria instituio, no devemos
divulgar o seu nome, assim como qualquer informao que possa compromet-la.

3.1.

Descrio do Cenrio

Para atender as necessidades de TI da empresa, ela utiliza sistemas de


desenvolvimento interno para gerenciar seus dados corporativos, nos seguintes
mdulos:
- Processo Seletivo;
- Acadmico;
- Financeiro;
- Bolsas;
- Eventos.
Existem tanto sistemas voltados para web, como desktop, mas ambos utilizam o
Oracle verso 10.2.0.1.0, como o seu sistema de gerenciador de banco de dados
principal. A equipe da tecnologia da informao trabalha com vrias ferramentas,
algumas da Oracle, como por exemplo, o Oracle Discoverer para a gerao de
relatrios, adquiriu recentemente o OBIEE (Oracle Business Intelligence Suite
Enterprise Edition Plus), ferramenta a ser utilizada no segmento de BI (Business
Intelligence Sitemas Inteligentes) e outras ferramentas no Oracle.
Falando um pouco da arquitetura utilizada pela instituio, ela possui um servidor
especfico para o banco de dados Oracle com as caractersticas abaixo:
- Sistema MS Windows Enterprise Edition 2003 - SP2;
- Dois cores de processamento;
- 8 GB de Ram;
- Arquitetura de 32 Bits;

26

- 2 discos SCSI de 500 GB.


O tamanho da sua base de dados est por volta de 50 GB, sendo 23 GB de
dados e 27 GB de ndices. realizado um backup full toda madrugada utilizando o
RMAN(Recovery Manager), e posteriormente copiado para uma Fita Dat(sempre no
final do ms).
Para minimizar qualquer desastre, seja ele fsico ou lgico, e tornar os seus
sistemas indisponveis por um pequeno intervalo, eles possuem uma mquina
reserva como uma mquina de backup do servidor Oracle, porm sem sincronizao
alguma com o servidor padro, pois a mesma s ligada, quando houver a
necessidade do seu uso.

3.2.

Problemas

Diante do cenrio apresentado acima, notamos que mesmo com o procedimento


de backup realizado diariamente, e tambm por possuir um servidor de backup,
existe uma grande possibilidade de perda de dados e indisponibilidade de servio de
banco de dados, pois no h um controle rgido nas aplicaes de paths, tanto de
banco de dados, quanto do sistema operacional, podendo gerar grandes impactos
na restaurao desses dados, alm do tempo de restaurao. Simulaes
realizadas com essa mesma base de dados, juntamente com uma mquina
compatvel com as mesmas configuraes, podem levar em mdia de 8 10 horas
para ser restaurada a base de dados, alm do tempo a ser gasto para a aplicao
dos paths (SO e Banco), verificao de funcionamento de hardware, configuraes
de rede e disponibilidade de profissionais.
Alm de todos esses possveis acontecimentos desastrosos e da no
sincronizao de dados com o servidor de dados em produo, no podemos
esquecer-nos das grandes perdas numerrias, insatisfaes e vrias geraes de
problemas dos alunos, funcionrios, docentes e proprietrios. Caso ocorra uma falha
em poca de matrcula/re-matrcula o impacto acabado sendo superior a qualquer
outro, pois durante esse processo, h toda uma busca de dados anteriores, como

27

disciplinas cursadas, se foram aprovadas ou no, entrega de trabalhos, pendncias


financeiras e vrias outras consistncias que podem impossibilitar de dar
continuidade durante esse processo.

3.3.

Solues Indicadas

Aps a anlise do ambiente, e uma breve apresentao dos benefcios que


podem ser alcanados atravs desse recurso que foi passado aos profissionais de
TI/Diretores da instituio, ficou definido que iremos implantar o Oracle Stand By
fsico, pois h a necessidade/exigncia de possuir/manter uma cpia idntica,
ntegra, confivel e sincronizada com o servidor Oracle de produo, evitando que o
servidor secundrio tenha objetos que no existem no servidor primrio,
desatualizaes de paths, alm de todas as pr-verificaes para disponibilizar esse
servidor na rede da empresa, toda vez que ela ligada.
Como eles j tinham esse outro servidor parado, ou seja, ligava-o somente
quando necessrio, e por ter um hardware bem semelhante ao servidor de
produo, foi solicitado equipe de infra-estrutura, que eles preparassem essa
mquina como se fosse um espelho da outra, ou melhor, com as mesmas estruturas
e configuraes de software.

28

4. CRIAO DO BANCO DE DADOS STAND BY


4.1.

Descrio dos Servidores

SERVIDOR PRIMRIO
Nome do servidor : SRV_PROD
IP .......................... : 193.168.1.1
SERVIDOR SECUNDRIO
Nome do servidor : SRV_STD
IP .......................... : 193.168.1.2

4.2.

Verificando a Comunicao entre os dois Servidores


Antes de iniciarmos a nossa implementao, deveremos validar se

ambos os servidores esto se comunicando. Para isso, iremos utilizar um


comando simples, que executado atravs do prompt do MS DOS, conforme
a figura abaixo:

Figura 4: Comunicao entre o SRV_PROD e SRV_STD

29

Figura 5: Comunicao entre o SRV_STD e SRV_PROD

4.3.

Configurando o Servidor Primrio

Aps logar na instncia como sysdba, devemos seguir os passos abaixo:


- Verificar se todos os valores dos parmetros esto configurados, pois eles
influenciam nos dados de log de redo, so as configuraes padres:
SQL> select par.name,
par.value
from v$parameter par
where upper(par.name) in
('DB_NAME','DB_UNIQUE_NAME','SERVICE_NAMES','CONTROL_FILES'
,'REMOTE_LOGIN_PASSWORDFILE');
NAME

VALUE

remote_login_passwordfile

EXCLUSIVE

service_names

PROD

db_name

PROD

db_unique_name

PROD
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\CONTROL01.CTL,
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\CONTROL02.CTL,
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\CONTROL03.CTL

control_files

30

DB_NAME (Nome do banco de dados): Utilize o mesmo nome para todos os


bancos de dados de reserva e principal
DB_UNIQUE_NAME (Nome nico para o banco de dados): Esse valor deve
ser diferente para cada banco de dados de reserva e deve diferir do banco
de dados principal.
SERVICE_NAMES (Nomes do servio para os bancos de dados): Configure
nomes de servio separados para cada banco de dados (primrio e
secundrio.
CONTROL_FILES (Arquivos de controle): Configura a localizao dos
arquivos de controle.
REMOTE_LOGIN_PASSWORDFILE (Arquivo de senha/modo de login):
Dever configurar como EXCLUSIVE, para suportar acesso remoto dos
usurios sysdba e a mesma senha do sys, tanto para a instncia primria
como a secundria.
- Forando a gerao de logs para todas as alteraes:
Verificando se o banco j est parametrizado:
SQL> select v.force_logging from v$database v;
Caso o valor esteja diferente de YES:
SQL> alter database force logging;
-

Crie o arquivo de senha do usurio sys para um diretrio temporrio, caso


no exista. Geralmente ele se encontra no ORACLE_HOME\DATABASE
ou ORACLE_HOME\DBS com o seguinte nome:
PWD_NOME_INSTANCIA.ora,ou podemos verificar se existe atravs do
seguinte comando:
SQL> select * from v$pwfile_users;
Se no existir, dever criar um novo arquivo de senhas no servidor
primrio, atravs do seguinte comando a ser executado no prompt do MS
DOS:

orapwd file=d:\oracle\product\10.2.0\db2\database\orapwPROD.ora
password= senha_sys entries=5

31

Executando a criao do Redo Log StandBy, esse tipo de redo


requerido por manter o mximo de disponibilidade e proteo. A Oracle
recomenda que os redos devem ser do mesmo tamanho do servidor
primrio, assim como a mesma quantidade de grupos, alm de que as
alteraes sero aplicadas em tempo real no servidor secundrio.

SQL>select distinct ((bytes/1024)/1024) tamanho_redo_mb from v$log;


Verificando quantos grupos e membros existentes:
SQL>select v.group#, v.member from v$logfile v order by 1 ;
Para esse caso existem 3 grupos com um membro cada um, portanto:
SQL>alter database add standby logfile group 4
('D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO_STD_01.LOG')
size 50m;
SQL>alter database add standby logfile group 5
('D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO_STD_02.LOG')
size 50m;
SQL>alter database add standby logfile group 6
('D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO_STD_03.LOG')
size 50m;
Confirmando a criao:
SQL>select group#, dbid, status, archived, bytes from v$standby_log;
- Criando um diretrio para armazenar os archives:
C:\>mkdir d:\oracle\product\10.2.0\oradata\PROD\Archive_Prod
-

Ativando o ArchiveLog

Fechar o banco de dados:


SQL>shutdown immediate;
Iniciar o banco em Mount:
SQL> startup mount;

32

Especificando o local de destino do arquivamento no banco principal:


SQL> alter system set
log_archive_dest_1='location=d:\oracle\product\10.2.0\oradata\prod\Archive_Pr
od\ valid_for=(all_logfiles,all_roles) db_unique_name=prod' scope=spfile;
O atributo VALID_FOR, identifica quando os Log Transport Services podem
transmitir dados de redo para destinos baseados nos seguintes casos:
1) Se o banco de dados atualmente exercendo o papel do servidor primrio
ou secundrio;
2) Se os arquivos de log de redo on-line, os arquivos de log de redo do stand
by ou ambos esto atualmente sendo arquivados no destino informado.O
valor padro all_log_files e all_roles.
Formatar os Archives:
SQL>alter system set log_archive_format = 'arc_%t_%s_%r.log'
scope=spfile;
Colocar o banco de dados em ArchiveLog:
SQL>alter database archivelog;
Abrindo o Banco de dados:
SQL>alter database open;
Confirmando se est ativo o modo Archivelog:
SQL>archive log list;
Fechar o banco de dados:
SQL>shutdown immediate;
Iniciar o banco:
SQL> startup ;
Forando a gerao do Archive:
SQL> alter system switch logfile;
Ir ao diretrio Archive_Prod e confirmar a gerao do arquivo.

33

Gerar um arquivo de inicializao para fazer as alteraes futuras


necessrias, assim como utiliz-lo no servidor secundrio:

1) Verificando a existncia de um SPFILE (arquivo de inicializao no


formato binrio. Arquivo a ser utilizado, conforme a indicao da prpria
Oracle).
SQL> show parameter spfile;
2) Caso no tenha, dever ser criado um spfile:
SQL> create spfile from pfile;
Criando o arquivo a ser utilizado. Vale lembrar que o PFILE um arquivo
texto, fazendo com que seja fcil a sua alterao, para gerar basta executar o
comando abaixo:
SQL> create pfile='d:\prod\InitProd.ora' from spfile;
-

Editando o arquivo de parmetro (InitProd.ora) para o servidor primrio:


db_cache_size=205520896
java_pool_size=4194304
large_pool_size=4194304
shared_pool_size=67108864
streams_pool_size=0
audit_file_dest='d:\oracle\product\10.2.0/admin/PROD/adump'
background_dump_dest='d:\oracle\product\10.2.0/admin/PROD/bdump'
compatible='10.2.0.1.0'
control_files='d:\oracle\product\10.2.0/oradata/PROD/\control01.ctl','d:\ora
cle\product\10.2.0/oradata/PROD/\control02.ctl','d:\oracle\product\10.2.0/o
radata/PROD/\control03.ctl'
core_dump_dest='d:\oracle\product\10.2.0/admin/PROD/cdump'
db_block_size=8192
db_domain=''
db_file_multiblock_read_count=16
db_name='PROD'
db_recovery_file_dest='d:\oracle\product\10.2.0/flash_recovery_area'
db_recovery_file_dest_size=2147483648
dispatchers='(PROTOCOL=TCP) (SERVICE=PRODXDB)'
job_queue_processes=10

34

log_archive_dest_1='location=d:\oracle\product\10.2.0\oradata\prod\Archiv
e_Prod\ valid_for=(all_logfiles,all_roles) db_unique_name=PROD'
log_archive_format='arc_%t_%s_%r.log'
nls_language='BRAZILIAN PORTUGUESE'
nls_territory='BRAZIL'
open_cursors=300
pga_aggregate_target=95420416
processes=150
remote_login_passwordfile='EXCLUSIVE'
sga_target=287309824
undo_management='AUTO'
undo_tablespace='UNDOTBS1'
user_dump_dest='d:\oracle\product\10.2.0/admin/PROD/udump'
# Adicionais para o Stand By
db_unique_name='PROD'
log_archive_dest_2='service=stdby lgwr async
valid_for=(online_logfiles,primary_role) db_unique_name=std'
log_archive_dest_state_1='ENABLE'
log_archive_dest_state_2='ENABLE'
log_archive_config='DG_CONFIG=(PROD,STD)'
fal_client='PROD'
fal_server='STD'
standby_file_management='AUTO'
db_file_name_convert='d:\oracle\product\10.2.0\oradata\std','d:\oracl
e\product\10.2.0\oradata\prod'
log_file_name_convert='d:\oracle\product\10.2.0\oradata\std','d:\oracl
e\product\10.2.0\oradata\prod'

35

Onde:
log_archive_dest_2 : a localizao remota utilizada para os arquivos
de redo log do stand by.
service=stdby lgwr async : O nome stdby o alias que estar no
tnsames(banco secundrio) e o logw async especifica que a entrada e a
sada de rede deve ser feita de forma assncrona quando for utilizar o
processo de lgwr
log_archive_dest_state_1='ENABLE' : Habilitando o primeiro local de
destino de arquivamento.
log_archive_dest_state_2='ENABLE' : Habilitando o segundo local de
destino de arquivamento.
log_archive_config='DG_CONFIG=(PROD,STD)' : Lista o banco de
dados primrio e o secundrio.
Os parmetros relacionados ao banco stand by incluem os parmetros
FAL (Fetch Archive Log) utilizados durante o processo de cpia dos logs
archives para o banco stand by, so eles:
fal_client='PROD' : Especifica o nome do service do sevidor FAL(em
geral, o servidor primrio).
fal_server=STD

: Especifica o nome do service do cliente de FAL(o

servidor secundrio, aquele que busca os logs).


standby_file_management='AUTO' : Gerenciamento automtico dos
arquivos stand by.
db_file_name_convert : Caso os bancos de dados utilizarem estruturas
de diretrios diferentes, especifique o nome do caminho e a localizao
do nome do arquivo dos arquivos de dados do servidor primrio, seguidos
pela localizao do stand by, ou vice-versa.

36

log_file_name_convert : Caso os bancos de dados utilizarem estruturas


de diretrios diferentes, especifique o nome do caminho e a localizao
do nome dos arquivos de log dados do servidor primrio, seguidos pela
localizao do stand by, ou vice-versa.
-

Faa um backup frio do servidor primrio, inclusive dos redo log stand by:
1)Listar os arquivos de dados e as suas localizaes para sem copiados
ao servidor secundrio, ou seja, replicando a estrutura para preservar a
estrutura original, atravs do seguinte comando:

SQL> select name from v$datafile;


NAME
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\SYSTEM01.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\UNDOTBS01.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\SYSAUX01.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\USERS01.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\DF_DADOS_ACAD.
DBF

SQL> select member from v$logfile;


MEMBER
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO03.LOG
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO02.LOG
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO01.LOG
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO_STD_01.LOG
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO_STD_02.LOG
D:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\REDO_STD_03.LOG

Copiar todos os arquivos listados acima, para um diretrio temporrio


qualquer, como por exemplo, um diretrio chamado STD:

SQL> shutdown immediate;


Poder ser realizado a cpia atravs do MSDOS:
D:\>copy D:\oracle\product\10.2.0\oradata\PROD\*.* d:\std\oradata
-

Gerar um arquivo de controle para o banco Stand By.Deve ser


especificado o local a ser criado, no utilize o mesmo diretrio e o mesmo
nome de arquivo de controle que utilizado no banco de dados primrio:

SQL> startup mount;

37

SQL>

alter

database

create

standby

controlfile

'd:\std\oradata\CONTROL01_STD.ctl';
Faa duas cpias do arquivo criado com os seguintes nomes:
CONTROL02_STD.ctl e CONTROL03_STD.ctl
SQL> alter database open;
-

Configurando o Oracle Net Service:


O Oracle Net Service pode ser configurado editando ou criando os
arquivos listener.ora e tnsnames.ora.
Configurando o arquivo $ORACLE_HOME\network\admin\listener.ora:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(HOST = SRV_PROD)(PORT =
1521))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PROD)
(GLOABAL_NAME = PROD)
(ORACLE_HOME = d:\oracle\product\10.2.0\db_2)
(PROGRAM = extproc)
)
)
Depois que for alterado, devemos reiniciar o listener.Podemos realizar
esse procedimento atravs do MSDOS:
1) lsnrctl stop
2) lsnrctl start

as

38

3) Para confirmar:
lsnrctl status
Configurando o arquivo $ORACLE_HOME\network\admin\tnsnames.ora:
PROD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = SRV_PROD)(PORT =
1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PROD)
)
)

STDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = SRV_STD)(PORT =
1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = STD)
)
)

EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)

39

4.4.

Configurando o Servidor Secundrio


-

Criar uma pasta chamada STD em D:\oracle\product\10.2.0\oradata\

Copiar os arquivos copiados na pasta do servidor primrio


d:\std\oradata,

com

exceo

dos

arquivos

de

controle(CONTROL01.CTL, CONTROL02.CTL e CONTROL03.CTL),


mas os arquivos de controle do tipo de stand by que devero ser
copiados tambm.
-

Criar as pastas necessrias:

Mkdir D:\oracle\product\10.2.0\admin\STD\ adump


Mkdir D:\oracle\product\10.2.0\admin\STD\ bdump
Mkdir D:\oracle\product\10.2.0\admin\STD\ cdump
Mkdir D:\oracle\product\10.2.0\admin\STD\ dpdump
Mkdir D:\oracle\product\10.2.0\admin\STD\ udump
-

Criar um arquivo de parmetro chamado InitSTD.ora com os


seguintes parmetros:
db_cache_size=205520896
java_pool_size=4194304
large_pool_size=4194304
shared_pool_size=67108864
streams_pool_size=0
audit_file_dest='d:\oracle\product\10.2.0/admin/STD/adump'
background_dump_dest='d:\oracle\product\10.2.0/admin/STD/bdump'
compatible='10.2.0.1.0'
control_files='d:\oracle\product\10.2.0/oradata/STD/\CONTROL01_ST
D.CTL','d:\oracle\product\10.2.0/oradata/STD/\CONTROL02_STD.CT
L','d:\oracle\product\10.2.0/oradata/STD/\CONTROL03_STD.CTL'
core_dump_dest='d:\oracle\product\10.2.0/admin/STD/cdump'

40

db_block_size=8192
db_domain=''
db_file_multiblock_read_count=16
db_name='PROD'
db_recovery_file_dest='d:\oracle\product\10.2.0/flash_recovery_area'
db_recovery_file_dest_size=2147483648
dispatchers='(PROTOCOL=TCP) (SERVICE=PRODXDB)'
job_queue_processes=10
log_archive_dest_1='location=d:\oracle\product\10.2.0\oradata\STD\Ar
chive_Std\ valid_for=(all_logfiles,all_roles) db_unique_name=STD'
log_archive_format='arc_%t_%s_%r.log'
nls_language='BRAZILIAN PORTUGUESE'
nls_territory='BRAZIL'
open_cursors=300
pga_aggregate_target=95420416
processes=150
remote_login_passwordfile='EXCLUSIVE'
sga_target=287309824
undo_management='AUTO'
undo_tablespace='UNDOTBS1'
user_dump_dest='d:\oracle\product\10.2.0/admin/STD/udump'
# Adicionais para o Stand By
db_unique_name='STD'
log_archive_dest_2='service=prod lgwr async
valid_for=(online_logfiles,primary_role) db_unique_name=PROD'
log_archive_dest_state_1='ENABLE'
log_archive_dest_state_2='ENABLE'
log_archive_config='DG_CONFIG=(PROD,STD)'
fal_client='STD'
fal_server='PROD'
standby_file_management='AUTO'
db_file_name_convert='d:\oracle\product\10.2.0\oradata\prod','d:\
oracle\product\10.2.0\oradata\std'

41

log_file_name_convert=
'd:\oracle\product\10.2.0\oradata\prod','d:\oracle\product\10.2.0\or
adata\std'
O parmetro db_unique_name = STD, o parmetro fundamental que
diferencia os dois bancos de dados.
-

Configurando o Oracle Net Service:


O Oracle Net Service pode ser configurado editando ou criando os
arquivos listener.ora e tnsnames.ora.
Configurando o arquivo $ORACLE_HOME\network\admin\listener.ora:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(HOST = SRV_STD)(PORT =
1521))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PROD)
(GLOABAL_NAME = STD)
(ORACLE_HOME = d:\oracle\product\10.2.0\db_2)
(PROGRAM = extproc)
)
)

42

Depois que for alterado, devemos reiniciar o listener. Podemos realizar


esse procedimento atravs do MSDOS:
1) lsnrctl stop
2) lsnrctl start
3) Para confirmar:
lsnrctl status
Configurando o arquivo $ORACLE_HOME\network\admin\tnsnames.ora:
PROD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = SRV_PROD)(PORT =
1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PROD)
)
)

STD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = SRV_STD)(PORT =
1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = STD)
)
)

43

EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
-

Para o arquivo $ORACLE_HOME\network\admin\sqlnet.ora, devemos


informar o parmetro SQLNET.EXPIRE_TIME = 1, para ativar a
deteco de conexo quebrada depois de um minuto, conforme
abaixo:
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.EXPIRE_TIME = 1

Criao de um servio Windows, para permitir que a instncia acesse


os seus arquivos, e para isso, utilizaremos o utilitrio ORADIM, como
segue:
ORADIM NEW SID STD -INTPWD oracle STARTMODE M

44

5. ADMINISTRANDO OS BANCOS DE DADOS


5.1.

Inicializando o Servidor Primrio.


Para inicializarmos o Servidor Primrio, basta seguir a seguinte

seqencia, atravs do MSDOS:


- Informar o Oracle_sid
set Oracle_sid= prod
- Conectar ao banco com o auxlio do utilitrio sqlplus:
sqlplus sys/senha as sysdba
- Inicializar o banco:
SQL> startup pfile=d:\prod\InitProd.ora;

5.2.

Criando o Arquivo de Inicializao Dinmico do Banco de

Dados Principal
Segundo a Oracle, ela recomenda que se deve usar o arquivo de
parmetro binrio,o SPFILENOME_INSTNCIA, pois ele possui parmetros
de inicializao avanados, alm de reduzir os ajustes dirios:
SQL> create spfile from pfile=d:\prod\InitProd.ora;

5.3.

Inicializando o Servidor Secundrio


Para inicializarmos o Servidor Secundrio, basta seguir a seguinte

seqencia, atravs do MSDOS:


- Informar o Oracle_sid
set Oracle_sid= std
- Conectar ao banco com o auxlio do utilitrio sqlplus:

45

sqlplus sys/senha as sysdba

- Inicializar o banco:
SQL> startup mount pfile=d:\std\InitStd.ora;

5.4.

Criando o Arquivo de Inicializao Dinmico do Banco de

Dados Stand By
SQL> create spfile from pfile=d:\std\InitStd.ora;

5.5.

Aplicao dos Archives


Logo aps montar o banco de dados secundrio, devemos iniciar o

processo de aplicao dos Redos:


1) O comando abaixo permite que seja executado em segundo plano,
depois que se desconectar da sesso.
SQL> alter database recover managed standby database disconnect
from session;
2) J para o prximo comando, ele ativa a aplicao dos Redos em tempo
real:
SQL> alter database recover managed standby database using current
logfile;
Para saber qual a configurao est sendo utilizada na aplicao dos
Redos, basta executar a consulta abaixo:
SQL> Select recovery_mode from v$archive_d_status;
Caso o valor retornado seja MANAGED REAL-TIME-APPLY, a aplicao
estar em tempo real, caso contrrio, estar no modo padro.

46

5.6.

Cancelando a Aplicao dos Archives

Para cancelar o processo de aplicao dos archives, deve-se executar:


SQL> alter database recover managed standby database cancel;

5.7.

Finalizando a Aplicao dos Archives

Para finalizar o processo de aplicao dos archives, deve-se executar:


SQL> alter database recover managed standby database finish;

5.8.

Abrindo o Banco de Dados Stand By no Modo de Leitura


Para abrir o servidor secundrio no modo de leitura, para uma

ao/manuteno, dever ser finalizado o processo de aplicao dos


archives, conforme mostrado no item anterior, e logo em seguida aplicar o
comando abaixo:
SQL> alter database open;

5.9.

Checagem de Aplicao/Sincronizao entre os Servidores


Com os dois bancos de dados configurados e inicializados, desde que

o servidor secundrio, esteja em modo de recuperao, podemos analisar se


ambos esto sincronizados, atravs de um simples procedimento:
- Servidor Primrio:
- Criar uma tabela simples:
SQL> create table t_teste as select * from dba_users;

Forar uma alternncia de log:

47

SQL> alter system switch logfile;


Consultar a seqencia da gerao dos Archives:
SQL>select sequence#, first_time, next_time
from v$archived_log order by sequence#;
- Servidor Secundrio
Verificar a seqencia da gerao dos archives recebidos, alm de analisar a
sua aplicao:
SQL>select sequence#, first_time, next_time,applied
from v$archived_log order by sequence#;
Caso o valor da coluna APPLIED, seja YES, isso significa que foi
realizado a aplicao dos Archives no Stand By.

5.10.

Falhas na Aplicao dos Archives


Caso o banco de dados stand by no tenha recebido algum log gerado

pelo servidor primrio, no houve uma transao com sucesso no servidor


primrio. O recurso Stand By detecta automaticamente a ausncia desse
log, e realiza uma nova cpia para o servidor secundrio.
Para saber se houve ou no alguma pendncia de algum log, pode-se fazer
uma consulta na view V$ARCHIVE_GAP. Essa viso lista o nmero mais
baixo e mais alto da seqncia do log, do conjunto de logs ausentes no
servidor secundrio e em seguida, possvel copiar os arquivos
manualmente para o banco de dados stand by e registr-los com em seguida
com o seguinte comando:
SQL> alter database register logfile nm_do_arquivo;
Depois da execuo da aplicao, s realizar a consulta novamente para
verificar se foi concludo o processamento, ou se h uma nova pendncia.

48

6. OPERAES DE SWITCHOVERS E FAILOVERS


Cada banco de dados existente dentro de um ambiente Stand By tem um papel,
um pode ser o banco de dados principal e o outro(s) o servidor stand by, mas em
algum momento esses papis podem ser alterados devido a algum problema de
hardware ou at mesmo de software.Tudo isso possvel realizar com as operaes
abaixo:
- Switchover - Processo utilizado para tornar um servidor primrio em secundrio,
garantindo que no h qualquer perda de dados.
- Failover - Processo utilizado para tornar um servidor secundrio em primrio,
devido algum desastre do servidor primrio, indicado somente em caso de total
urgncia, e, alm disso, existe a possibilidade de perder dados.
Ambas as operaes exigem interveno manual do administrador do banco de
dados.

6.1.

Switchover
Essa realizao de procedimento, normalmente feita de forma

planejada, como por exemplo, em alguma atividade de manuteno no


servidor primrio, e em seguida, selecionado um banco de dados
secundrio para atuar o papel de servidor principal. Quando isso realizado,
os dados so gravados nesse novo banco de dados principal. Ainda
possvel alternar os bancos de dados de volta para seus papis originais no
futuro. Essa troca de papis iniciada no servidor primrio, e contempladas
no banco stand by.
Devemos seguir as fases abaixo, nas seguintes ordens:
- Checar se o banco de dados primrio capaz de realizar o
switchover, atravs da coluna switchover_status da view V$DATABASE.
SQL>Select switchover_status from v$database;

49

Caso o retorno dessa consulta, seja diferente de TO STANDBY, no


ser possvel continuar esse procedimento, normalmente devido a questes
de configuraes ou de hardware, se o valor for SESSIONS ACTIVE, dever
ser terminado todas as sesses de usurios ativas. Os valores vlidos dessa
consulta podem ser:
1) NOT ALLOWED : O banco de dados atual no um banco de dados
principal com banco de dados stand by;
2) PREPARING DICTIONARY : Esse banco de dados stand by lgico
est enviando seus dados do redo para um banco de dados principal e
outros bancos de dados stand by para preparar o switchover;
3) PREPARING SWITCHOVER : Utilizado por configuraes de stand
by lgico enquanto os dados so aceitos para o switchover;
4) RECOVERY NEEDED : Esse banco de dados stand by no recebeu
a solicitao de switchover;
5) SESSIONS ACTIVE : H sesses ativas de SQL no banco de dados
primrio, elas devem ser desconectadas para continuar;
6) SWITCHOVER PENDING : Vlido para banco de dados stand by em
que a solicitao de switchover do banco de dados principal foi recebida,
mas no processada;
7) SWITCHOVER LATENT : O switchover no completou e voltou para
o banco de dados principal;
8) TO LOGICAL STANDBY : O banco de dados principal recebeu um
dicionrio completo de um banco de dados stand by lgico.
9) TO PRIMARY : O banco de dados stand by pode alternar para um
banco de dados principal;
10) TO STANDBY : O banco de dados principal pode alternar para um
bando de dados stand by.
- Iniciar a transao para tornar o banco de dados stand by:
SQL> alter database commit to switchover to physical standby;
Com a execuo desse comando, o Oracle far o backup do arquivo de
controle do banco de dados principal atual em um arquivo de rastreamento.
Deve-se dar um shutdown immediate e em seguida um startup mount , e
nesse momento o banco de dados principal preparado para o switchover.

50

- Ir ao banco de dados stand by que se tornar o banco de dados


principal e verificar se ele est preparado: SQL>Select switchover_status
from v$database;
Se o retorno for igual a TO PRIMARY, ele est em condies
adequadas, basta executar:
SQL> alter database commit to switchover to primary;
- Para concluir o processo, reinicie o novo banco de dados principal
para completar a transao.

6.2.

Failover
Essa operao ocorre quando o banco de dados primrio no pode

mais fazer parte da configurao de servidor primrio, devido algum desastre


fsico ou lgico, e com isso, iremos promover um banco de dados stand by
em banco de dados primrio. Esse procedimento deve ser realizado em
ltimo caso, somente quando tiver a certeza que o servidor primrio no
tenha mais condio de executar as suas tarefas.
Para efetuar essa troca, devemos seguir as fases abaixo, nas
seguintes ordens:
- Checar no banco de dados stand by, o qual se tornar o novo servidor
primrio, se h alguma pendncia de alguma aplicao de log, na view
V$ARCHIVE_GAP, conforme demonstrado no item 5.10 Falhas na Aplicao
dos Archives;
- Terminar o processo de recuperao. Se o servidor secundrio estiver
configurado com arquivos de log redo stand by, como o nosso caso, o
comando a executar:
SQL> alter database recover managed standby database finish;
Caso contrrio, dever ser executado:
SQL> alter database recover managed standby database finish skip
standby logfile;

51

- Aps finalizar a operao de recuperao, s realizar o switchover


com o seguinte comando:
SQL> alter database commit to switchover to primary;
- Para concluir o processo, reinicie o novo banco de dados principal
para completar a transao. O banco de dados primrio antigo no faz mais
parte da configurao do servidor primrio, e se quiser recriar o banco de
dados primrio antigo e utiliz-lo como um banco de dados stand by, basta
cri-lo como um banco de dados stand by.

52

7. CONCLUSO
Com a realizao desse trabalho de concluso de curso, confirmou-se a extrema
importncia desse recurso de alta disponibilidade de servio de banco de dados, que
to valioso tanto para os profissionais de informtica, por garantir a alta
disponibilidade juntamente com a disponibilizao, integridade e armazenamento em
grande escala dos dados, assim como por atender as necessidades da empresa,
atravs do uso de tecnologia de banco de dados garantindo a segurana da
informao.
Alm de colocar em prtica todo o conhecimento acadmico adquirido durante
as aulas assistidas, pudemos nos aprofundar e recomendar o seu uso para todas as
empresas, independentemente da sua rea de atuao.

53

8. BIBLIOGRAFIA
LONEY, Kevin; BRYLA, Bob. Oracle 10 g. O Manual do DBA Guia Oficial Oracle
Press. Rio de Janeiro: Campus Ltda e Elsevier, 2005.
IMASTERS, Data Guard na verso 10g Release 2 (10.2) - Parte 01, ltimo acesso
em: 08 de dezembro de 2010.
Link: http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=4494
UNIVERSO DO BRAGA, Sdandby 11g, ltimo acesso em: 08 de dezembro de
2010.Link: http://sites.google.com/site/universodobraga/oracle/standby-11g
ORACLE-BASE, Articles. Data Guard, ltimo acesso em: 08 de dezembro de 2010.
Link: http://www.oracle-base.com/articles/9i/DataGuard.php
ORACLE SERVICE BUS, ltimo acesso em: 25 de abril de 2011.Link:
http://gustavofsantos.blogspot.com
ARQUIVO PARA DATA GARD CATEGORIA, Oracle Standby Database, ltimo
acesso em: 25 de abril de 2011.Link:
http://profissionaloracle.com.br/blogs/douglaspaiva/category/data-guard
CONFIGURANDO STANDBY DATABASE, Configurando o Standby Database
Criando um Physical Standby Database , ltimo acesso em: 25 de abril de 2011.Link:
http://kb.paxtecnologia.com.br/kb/index.php?View=entry&EntryID=971
DATA GUARD ORACLE, ltimo acesso em: 25 de abril de 2011.Link:
http://marcolin.wordpress.com/2010/06/02/data-guard-oracle
ORACLE DATABASE DOCUMENTATIOS LIBRARY,10G RELEASE 2(10.2), ltimo
acesso em: 25 de abril de 2011.Link:
http://www.oracle.com/pls/db102/portal.portal_db?selected=4

54

MINAYO, Maria Ceclia de Souza et al. (Org). Pesquisa social: teoria, mtodo e
criatividade. 2 ed. Rio de Janeiro: Vozes, 1994.
RUIZ, Joo lvaro. Metodologia Cientfica: guia para eficincia nos estudos. 4. ed.
So Paulo: Atlas, 1996.
PAVIANI, Jayme. O problema de pesquisa como ponto de partida. In: Rev. Trabalho
e Ambiente, Caxias do Sul, v. 3, no 5, 2005.
CERVO, A. L. e BERVIAN, P. A.. Metodologia Cientfica, 5 ed. So Paulo: Prentice
Hall, 2002.
SEVERINO, Antnio Joaquim. Metodologia do Trabalho Cientfico. 22. ed. 7.
reimpr. So Paulo: Cortez, 2006.
KERLINGER, Fred N. Metodologia da pesquisa em cincias sociais: um tratamento
conceitual. So Paulo: EPU, 1980.
LAKATOS, Eva M.; MARCONI, Marina A. Fundamentos de Metodologia Cientfica. 6.
ed. 4. reimpr. So Paulo:Atlas, 2007.

55

9. GLOSSRIO
ORACLE NET um servio que habilita uma conexo de rede entre o computador
cliente e o servidor. Ele pode ser configurado atravs do arquivo listener.ora e
tnsnames.ora .
PL/SQL Procedural Language/Structured Query Language, e uma extenso da
linguagem padro SQL para o SGBD Oracle da Oracle Corporation.
SQL Structured Query Language, ou Linguagem de Consulta Estruturada. uma
linguagem de pesquisa declarativa para banco de dados relacional.