UNIVERSIDADE ANHEMBI MORUMBI
PAMELA CRISTINA MACHADO DE OLIVEIRA
RENAN MILHOMEM PARISOTTO
RODRIGO DA SILVA SIMÕES
ALTA DISPONIBILIDADE EM SISTEMAS DE BANCO DE DADOS ORACLE
São Paulo
2009
PAMELA CRISTINA MACHADO DE OLIVEIRA
RENAN MILHOMEM PARISOTTO
RODRIGO DA SILVA SIMÕES
ALTA DISPONIBILIDADE EM SISTEMAS DE BANCO DE DADOS ORACLE
Trabalho de Conclusão de Curso apresentado
como exigência parcial para a obtenção do título
de Graduação do Curso de Ciência da
Computação, Habilitação em Desenvolvimento
de Software da Universidade Anhembi Morumbi.
Orientador: Prof. Dr. Augusto Mendes Gomes Junior.
São Paulo
2009
PAMELA CRISTINA MACHADO DE OLIVEIRA
RENAN MILHOMEM PARISOTTO
RODRIGO DA SILVA SIMÕES
ALTA DISPONIBILIDADE EM SISTEMAS DE BANCO DE DADOS ORACLE
Trabalho de Conclusão de Curso apresentado
como exigência parcial para a obtenção do título
de Graduação do Curso de Ciência da
Computação, Habilitação em Desenvolvimento
de Software da Universidade Anhembi Morumbi.
Orientador: Prof. Dr. Augusto Mendes Gomes Junior.
Aprovado em
Prof.: __________________________________
Universidade Anhembi Morumbi
Prof.: __________________________________
Universidade Anhembi Morumbi
Prof.: __________________________________
Universidade Anhembi Morumbi
Dedicamos esse trabalho àqueles que nos
ajudaram a crescer e desenvolver nossas vidas
como profissionais, sempre trabalhando com
simplicidade, honestidade e compreensão.
AGRADECIMENTOS
Agradecemos primeiramente a Deus, independente de credo e religião.
Agradecemos ao professor Augusto Mendes Gomes Junior, pela excelente orientação
que nos deu e também por sempre se mostrar disposto a nos auxiliar.
Agradecemos ao Rodrigo Salviatto Oracle Database Specialist, pela orientação e
dedicação em nos auxiliar a desenvolver este trabalho.
Aos nossos familiares, pelos incentivos e motivações nos momentos de maior cansaço
e dificuldade.
Agradecemos também aos professores que com seus ensinamentos e lições fornecidas
ao decorrer do curso, nos auxiliaram no desenvolvimento deste projeto.
RESUMO
A utilização de uma arquitetura de alta disponibilidade em ambiente de Banco de
dados apresenta diversas vantagens comparadas com uma arquitetura única, como por
exemplo: redundância, disponibilidade, contingência, continuidade do negócio, entre outros.
Em caso de falhas de hardware em um ambiente distribuído, os sistemas usuários do
banco de dados permanecerão ativos, sem qualquer indisponibilidade.
As desvantagens de implementar um ambiente distribuído de Banco de dados estão
relacionadas ao custo do projeto e licenças dos softwares, pois elas são adquiridas conforme a
quantidades de usuários que irão utilizá-lo ou através da quantidade do número de
processadores dos equipamentos utilizados.
Existem diversos métodos de alta disponibilidade, onde ressaltos a replicação de dados
transacionais. O objetivo deste ambiente é replicar dados transacionais e em casos de falhas
em alguma das bases é feito um switch de servidores, garantindo que os dados sejam sempre
replicados e estejam sempre disponíveis.
O trabalho tem como objetivo pesquisar a melhor opção a ser implementada em um
ambiente distribuído com Banco de dados Oracle.
Palavras-Chave: Alta disponibilidade em Banco de dados Oracle.
ABSTRACT
The use of architecture for high availability environment Database has several
advantages compared to single architecture, such as: redundancy, availability, contingency,
business continuity, among others.
In case of hardware failures in a distributed environment, the systems users of the
database will remain active without any downtime.
The disadvantages of implementing a distributed environment Database are related to
the project cost and software licenses as they are acquired as the numbers of users who will
use it by the amount or the number of processors used equipment.
There are several methods of high availability which bumps the replication of
transactional data. The objective of this environment is to replicate transactional data and in
cases of failures in any of the bases is done by switch servers, ensuring that data is always
replicated and always available.
The study aims to research the best option to be implemented in a distributed
environment with Oracle Database.
Keywords: High Availability in Database Oracle.
LISTA DE SIGLAS
ARCN
Archiver
ASM
Automatic Storage Manager
CBLC
Central Depositária. Compensação e Liquidação
CHKPT
Checkpoint
CPU
Unidade Central de Processamento
CRS
Cluster Read Services
DBA
Administration Data Base
DBF
Datafile
DBWR
Database Whiter
E/S
Entrada e Saída
LGRW
Log Whiter
MSCS
Microsoft Cluster Server
OCFS
Oracle Cluster File System
OEM
Oracle Entreprise Manager
OFA
Optimal Flexibile Architecture
PGA
Program Global Area
PMON
Process Monitor
RAC
Real Application Cluster
RAID
Redundant Array of Independent Drivers
RDBMS
Relational Database Management System
RECO
Recovery
RMAN
Recovery Manager
SGA
System Global Area
SGBD
Sistema Gerenciador de Banco de Dados
SMON
System Monitor
SQL
Structured Query Language
TI
Tecnologia da Informação
LISTA DE FIGURAS
Figura 1 - Processos Oracle. Fonte: Oracle (2005) ................................................................ 21
Figura 2 – Instância. Fonte: Oracle (2005)............................................................................. 24
Figura 3 – Arquitetura Fail Safe. Fonte: Oracle (2005) ......................................................... 26
Figura 4 - Active Data Guard. Fonte: Oracle (2008).............................................................. 28
Figura 5 - Oracle Fail Safe antes da falha. Fonte: Oracle (2003)...........................................30
Figura 6 - Oracle Fail Safe depois da falha. Fonte: Oracle (2003)......................................... 30
Figura 7 - Oracle RAC Configuração de IP. Fonte: Oracle (2008)........................................ 34
Figura 8 - Vendas Online. ...................................................................................................... 45
Figura 9 - Oracle FailSafe x Oracle RAC após queda de um nó ( em segundos ) ................. 47
Figura 10 - Conexões que permaneceram ativas após falha de um nó. (em percentual)..........48
Figura 11 – Custo. .................................................................................................................... 48
Figura 12 - Oracle Real Application Clusters on Extended Distance Clusters 10gR2 (Oracle
2005)......................................................................................................................................... 51
SUMÁRIO
1
INTRODUÇÃO ............................................................................................................. 12
1.1
OBJETIVO ...................................................................................................................... 12
1.2
JUSTIFICATIVA ............................................................................................................ 13
1.3
ABRANGÊNCIA ............................................................................................................ 13
1.4 ESTRUTURAS DO TRABALHO..................................................................................13
2
DISPONIBILIDADES EM BANCO DE DADOS ...................................................... 15
2.1 DEFINIÇÃO.................................................................................................................... 15
2.2 VANTAGENS................................................................................................................. 16
2.3
DESVANTAGENS ......................................................................................................... 17
2.4
GARANTIA DE DISPONIBILIDADE ..........................................................................17
3
ALTA DISPONIBILIDADE NO ORACLE ...............................................................19
3.1 CARACTERÍSTICAS DO ORACLE .............................................................................19
3.1.1 Instância ......................................................................................................................... 19
3.1.2 System Global Area ....................................................................................................... 20
3.2
ARQUITETURA DE PROCESSOS DO ORACLE ....................................................... 21
3.3
ORGANIZAÇÃO DOS DADOS NO ORACLE ............................................................23
3.3.1 Índices ............................................................................................................................. 24
3.3.2 Tablespaces e Datafiles.................................................................................................. 24
3.4
FERRAMENTAS EXISTENTES ...................................................................................25
3.4.1 Oracle Fail Safe.............................................................................................................. 26
3.4.2 Oracle Streams............................................................................................................... 26
3.4.3 Oracle Real Application Cluster ( RAC ).................................................................... 27
3.4.4 Oracle Active Data Guard ............................................................................................ 27
4
ORACLE FAILSAFE ...................................................................................................29
4.1
RECURSOS E APLICAÇÕES ALTAMENTE DISPONÍVEIS .................................... 29
4.2
FACILIDADES DE UTILIZAÇÃO ...............................................................................30
4.3 APLICAÇÕES DE SISTEMAS TOLERANTES A FALHAS....................................... 31
5
ORACLE RAC REAL APPLICATION CLUSTER ................................................. 32
5.1
CONFIGURAÇÕES........................................................................................................ 32
5.1.1 Configuração de Hardware .......................................................................................... 32
5.1.2 Configuração de Software ............................................................................................ 33
5.1.3 Configuração de Rede ................................................................................................... 33
5.2
REQUISITOS DE MEMÓRIA E DISCO.......................................................................34
5.3
CLUSTER READY SERVICES..................................................................................... 35
5.4 CARACTERÍSTICAS DO BANCO DE DADOS ORACLE RAC................................ 35
5.5 CARACTERÍSTICAS DO ARQUIVO DE PARÂMETRO DE SERVIDOR ............... 35
6
ESTRATÉGIA DE BACKUP ...................................................................................... 37
6.1
CONFIGURANDO DEFINIÇÕES DE BACKUP ......................................................... 37
6.2
BACKUP LÓGICO......................................................................................................... 38
6.3
BACKUPS FÍSICOS....................................................................................................... 39
6.3.1 Backups Off-line ............................................................................................................ 39
6.3.2 Backups On-line............................................................................................................. 40
6.4
ESTRATÉGIA DE BACKUP SUGERIDA PELA ORACLE........................................40
6.4.1 Componentes do RMAN ............................................................................................... 41
6.4.2 RMAN versus método de backup tradicional............................................................. 42
6.4.3 Tipos de backups ........................................................................................................... 42
7
ANALISE COMPARATIVA ENTRE ORACLE RAC E ORACLE FAILSAFE ..44
7.2 ANALISE DOS RESULTADOS .................................................................................... 47
7.3 CONSIDERAÇÕES IMPORTANTES ...........................................................................48
8
CONCLUSÃO................................................................................................................ 50
8.1 TRABALHOS FUTUROS ..............................................................................................50
REFERÊNCIA BIBLIOGRÁFICA...................................................................................... 52
12
1 INTRODUÇÃO
Um banco de dados distribuído Oracle é composto de diversos bancos de dados
armazenados em múltiplos computadores, porém sendo visto pelo usuário como um banco de
dados único. Funcionalmente, os dados são alocados em uma storage, permitindo assim o
acesso simultâneo ao dado por qualquer computador da rede.
Para um relacionamento eficiente entre os diversos bancos de dados, desde o início da
sua concepção até sua implementação, fez-se necessário distribuí-los de forma bem planejada.
Eventualmente, com a expansão das empresas, as exigências aumentaram e um eficiente
planejamento é muito importante.
A tecnologia de banco de dados distribuídos Oracle permite a administração e
manipulação de dados oferecendo um complexo conjunto de ferramentas e aplicativos.
Um servidor Oracle controla cada um dos seus bancos de dados, mas mantém a
coerência do Banco de dados global porque possui a capacidade de interligação entre os
Bancos de dados distribuídos como se fosse um só. Logo, são permitidas pesquisas, inclusões,
exclusões e transações distribuídas, retenção, replicação e particionamento em diferentes
locais (HILL, 2008).
Dados entre vários servidores podem ser compartilhados através de consultas e
atualizações distribuídas com a garantia do mecanismo two-phase commit na consistência dos
dados. Através da replicação de dados, os usuários podem criar cópias de leitura de tabelas
com consistência transacional e garantia de integridade de dados. Dados remotos podem ser
tratados como se fossem locais por meio de database links. Sendo que, havendo transferência
de dados de um nó a outro não implica na recodificação dos aplicativos.
A junção de base de dados com sistemas distribuídos é um conceito que já é funcional,
porém ainda existe muito que pode ser feito com o intuito de tornar este conceito cada vez
mais aplicável em diversas situações. “A chave para esta compreensão é a percepção de que o
objeto mais importante da tecnologia de banco de dados é a integração, não a centralização”
(ÖZSU, 2001, p. 2).
1.1 OBJETIVO
O objetivo do trabalho é pesquisar as ferramentas Oracle RAC (Real Application
Cluster) e Oracle FailSafe para um ambiente de sistemas distribuídos, definindo suas
características e infra-estrutura. Além de analisar o desempenho destas ferramentas. Com esta
13
pesquisa, as pessoas que não sabem qual sistema utilizar possa ter algumas das informações
necessárias para entender qual o melhor sistema para cada situação, sabendo sobre erros e
falhas que venha a ocorrer em cada um e como evitá-los.
1.2 JUSTIFICATIVA
A disponibilidade de dados é um fator fundamental para empresas e aplicações que
sejam tolerantes a falha. A ausência de elementos centralizadores em um sistema distribuído
aumenta a disponibilidade dos dados, bem como a confiabilidade do sistema como um todo.
Entretanto a garantia de disponibilidade envolve mecanismos de controle a consistência de
dados, de modo que os servidores estejam idênticos durante todo o tempo de funcionamento
do sistema.
Com isso, além da disponibilidade dos dados que garante um sistema altamente
disponível, outro fator bastante atraente é a possibilidade de balanceamento de carga de
trabalho que o Oracle possui, principalmente em operações de consultas a dados. Estando em
elementos distintos, todas as instalações Oracle podem ser acessadas simultaneamente por
diferentes clientes, evitando a sobrecarga de um único elemento (ORACLE, 2008).
1.3 ABRANGÊNCIA
O trabalho consiste em explorar a arquitetura do uso de um sistema distribuído para
banco de dados Oracle capaz de gerenciar transações executadas no sistema gerenciador de
banco de dados (SGBD), inclusive, tratar situações de falhas em hardware e software,
simulando situações de rollback, recovery e estratégia de backup.
Os resultados analisados foram obtidos por testes realizados em laboratórios
especializados com servidores e aplicações específicas para cada ambiente.
Não faz parte do escopo do trabalho o desenvolvimento de algum tipo de aplicativo,
apenas utilizou-se aplicativos já existentes no mercado, para análise do desempenho das
ferramentas RAC e Fail Safe.
1.4 ESTRUTURAS DO TRABALHO
14
A estrutura do trabalho está dividida da seguinte forma: O capítulo 2 aborda o tema
Disponibilidade em Banco de dados; o capítulo 3 apresenta Alta Disponibilidade no Oracle; o
capítulo 4 apresenta Oracle Fail Safe; o capítulo 5 apresenta o Oracle RAC (Real Aplication
Cluster); o capítulo 6 apresenta estratégia de Backup e Recovery; o capítulo 7 apresenta a
Comparação entre o Oracle RAC e Oracle Fail Safe; o capítulo 8 apresenta Conclusão e
trabalhos futuros.
15
2 DISPONIBILIDADES EM BANCO DE DADOS
Para que se entenda a disponibilidade é necessário, antes de qualquer coisa, perceber
que a disponibilidade não é apenas um produto ou uma aplicação que se instale, e sim uma
característica de um sistema computacional. Existem mecanismos e técnicas, blocos básicos,
que podem ser utilizados para aumentar a disponibilidade de um Sistema de Banco de dados
distribuídos. A simples utilização destes blocos, entretanto, não garante este aumento se não
for acompanhado de um completo estudo e projeto de configuração (ÖZSU, 2001, p. 2).
2.1 DEFINIÇÃO
A Disponibilidade de um sistema computacional é a probabilidade de que este sistema
esteja funcionando e pronto para uso em um dado instante de tempo. Esta disponibilidade
pode ser enquadrada em três classes:
A disponibilidade Básica: é aquela encontrada em máquinas comuns, sem nenhum
mecanismo especial, em software ou hardware, que vise de alguma forma mascarar as
eventuais falhas destas máquinas. Costuma-se dizer que máquinas nesta classe apresentam
uma disponibilidade de 99% a 99,9%. Isto equivale a dizer que em um ano de operação a
máquina pode ficar indisponível por um período de 9 horas a quatro dias. Estes dados são
empíricos e os tempos não levam em consideração a possibilidade de paradas planejadas (que
serão abordadas mais adiante), porém são aceitas como o senso comum na literatura da área
(FREEMAN, 2008).
Alta disponibilidade: mecanismos especializados de detecção, recuperação e
mascaramento de falhas, podem-se aumentar a disponibilidade do sistema, de forma que este
venha a se enquadrar na classe de alta disponibilidade. Nesta classe as máquinas tipicamente
apresentam disponibilidade na faixa de 99,99% a 99,999%, podendo ficar indisponíveis por
um período de pouco mais de 5 minutos até uma hora em um ano de operação. Aqui se
encaixam grande parte das aplicações comerciais de alta disponibilidade, como centrais
telefônicas (WATSON; BERSINIC, 1 / 2006).
Máxima disponibilidade: garante o sistema integro e disponível a todo o momento.
Dentre os novos recursos encontram-se o Flashback Transaction, que possibilita a reversão de
uma transação efetuada com erro, bem como de qualquer transação dependente Parallel
Backup and Restore, que ajuda a melhorar o desempenho do backup e restauro de grandes
base de dados e ‘hot patching’, que melhora a disponibilidade do sistema ao permitir que as
16
correções sejam aplicadas sem necessidade de interromper a aplicacão. Além disso, existem
outros recursos que ajudam os administradores a reduzir significativamente a parada para
recuperação, o que permite automatizar investigação de falhas, determinar planos de
recuperação e lidar com várias situações de crise (ORACLE, 2006).
2.2 VANTAGENS
A gerência de banco de dados distribuídos foi proposta por vários motivos,
abrangendo desde a descentralização organizacional e o processamento econômico até uma
maior autonomia.
Gerência de banco de dados distribuídos de certo modo esconde os detalhes de onde
cada arquivo, tabela ou relação, está fisicamente armazenado dentro do sistema. Há dois tipos
de transparência possíveis:
Transparência de distribuição ou de rede: Refere-se a liberar o usuário dos detalhes sobre a
rede. Pode ser dividida em transparência de localização e transparência de nomeação. A
transparência de localização se refere ao fato de que o comando utilizado para realizar uma
tarefa é independente do servidor conectado e da localização do sistema no qual o comando
foi executado. A transparência de nomeação implica que, uma vez que se especifica um nome
pode-se acessar objetos nomeados de maneira não ambígua sem especificações adicionais
(FREEMAN, 2008).
Transparência de replicação: Refere-se ao armazenamento em diferentes sites para
melhor disponibilidade, desempenho e confiabilidade. A transparência de replicação faz com
que o cliente não se torne ciente da existência de servidores replicados(ÖZSU, 2001, p. 2).
A confiabilidade e disponibilidade crescente são duas entre as vantagens potenciais
mais comuns citadas para banco de dados distribuídos. A disponibilidade é geralmente
definida como probabilidade de que um sistema esteja funcionando (não esteja parado) em
certo momento. Quando os dados e o software do SGBD estão distribuídos em diversos sites,
um site pode falhar enquanto outros continuam a operar. Somente o software que existe no
site que falhou não pode ser acessado. Isso melhora tanto a confiabilidade quanto a
disponibilidade.
Um SGBD distribuído fragmenta o banco de dados mantendo os dados mais próximo
possíveis do local onde são mais necessitados. A localização de dados reduz a disputa de
17
serviços da CPU e de E/S (Entrada/Saída), e ao mesmo tempo reduz a demora no acesso de
sistemas distantes. (NEWLAN, 2008).
2.3 DESVANTAGENS
A principal desvantagem do sistema de banco de dados distribuído é a complexidade
adicional necessária para assegurar a própria coordenação entre os nós. Esta complexidade
aumentada o custo de desenvolvimento de software, contudo é mais difícil implementar um
sistema de banco de dados distribuído, portanto, mais caro. A seguir as desvantagens mais
encontradas no mercado coorporativo:
Maior potencial de defeitos: Uma vez que o nó que forma o sistema distribuído opera
em paralelo, é difícil assegurar que os algoritmos estão corretos. Existe potencial para defeitos
extremamente sutis, precisando ter maior atenção em sua implementação (HILL, 2008).
Aumento de sobrecarga de processamento: A troca de mensagens e a computação
adicional necessárias para realizar a coordenação inter-nó é uma forma de sobrecarga que não
surgem em sistemas centralizados. Escolhendo o projeto para um sistema de banco de dados,
o projetista precisa analisar as vantagens e as desvantagens de distribuição de dados (ÖZSU,
2001, p. 2).
2.4 GARANTIA DE DISPONIBILIDADE
O que garante a alta disponibilidade de informações e sistemas são o suporte técnico,
os planos de contingência e redundância de equipamentos, detalhados a seguir:
Suporte Técnico: O suporte tecnico monitora todo o hardware do cluster, incluindo
CPU’s, espaçco em disco, E/S em disco e memoria utilizada. Monitora também energia,
fatores ambientais, como temperatura e umidade, estado do gerador e conectividade de rede.
A comunicação íntima e constante com os provedores de conexão, garantem a todos os
clientes uma performance máxima de acesso e garantia de 99,9% de uptime. Qualquer falha
irá disparar um alarme, acionando o especialista para resolver o problema (ÖZSU, 2001, p. 2).
Planos de contingência: Trata-se do conjunto de procedimentos e medidas de
segurança, previamente planejadas, a serem adotados após a ocorrência de uma falha, que
permitem o restabelecimento da rede de comunicação em caso de situações anormais (falha de
hardware, base de dados corrompida, perda de link de comunicação, destruição de prédios,
entre outras), com o objetivo de minimizar os impactos da mesma.
18
Redundância: O termo redundância descreve a capacidade de um sistema em superar a
falha de um de seus componentes através do uso de recursos redundantes, ou seja, um sistema
redundante possui um segundo dispositivo que está imediatamente disponível para uso
quando falhar o dispositivo primário do sistema.
Fonte de energia, placa de rede, disco com RAID (Redundant Array of Independent
Drives), processadores e memória esses são os hardwares que com duplicidade em um
servidor garante a disponibilidade caso outro venha falhar.
Porém, apenas fontes de energia com duplicidade não garante o servidor ser
alimentado por energia a todo o momento, se faz necessário um ambiente complexo com
geradores e No-Break (ÖZSU, 2001, p. 2).
19
3 ALTA DISPONIBILIDADE NO ORACLE
Uma solução de alta disponibilidade mascara os efeitos da falha de um hardware ou
software e mantém a disponibilidade dos aplicativos, de modo a minimizar o tempo de
inatividade percebido pelos usuários.
A Oracle disponibiliza diversas ferramentas que proporcionam a alta disponibilidade em
diversos cenários. Caso ocorra uma falha no banco de dados em um ambiente configurado
com alta disponibilidade, o Oracle consegue manter as aplicações em execução durante o failover sendo totalmente transparente para os usuários (WATSON; BERSINIC, 1 / 2006).
3.1 CARACTERÍSTICAS DO ORACLE
Independente da versão do sistema operacional, existem três níveis diferentes de
software Oracle disponíveis para instalação com base no produto comprado. Os tipos
disponíveis são:
Oracle Enterprise Edition: Instalação completa que inclui um banco de dados préconfigurado, serviços de rede, Oracle options que pode ser licenciado, ferramentas do
ambiente e banco de dados, estrutura do Oracle Enterprise Manager (ferramentas de
gerenciamento) e os produtos mais utilizados para armazenamento de dados e processamento
de transações. Esta instalação permite o uso de recursos de Paralell Server e Stand-by
Database (HILL, 2008).
Oracle Standard Edition: Instalação parcial que inclui um banco de dados preconfigurado, serviços de rede, Oracle Enterprise Manager e os utilitários Oracle;
Oracle Personal Edition: Instalação de um banco de dados pré-configurado com suporte a um
ambiente de desenvolvimento e distribuição de um único usuário. Esta versão é recomendada
para microcomputadores pessoais com o intuito de auxiliar no aprendizado da linguagem de
programação SQL (FREEMAN, 2008).
3.1.1 Instância
Toda vez que um banco de dados é iniciado, uma System Global Area (SGA) é
alocada e os processos de segundo plano do Oracle são iniciados. A System Global Area é
uma área de memória usada para as informações do banco de dados que são compartilhadas
pelos usuários. A combinação entre processos de segundo plano e os buffers de memória se
20
chama Instância do Oracle. Uma instância executa processos de usuário e processos do
Oracle. Os processos do usuário são aplicativos que são executados a partir de uma estação de
trabalho, sejam eles um programa executável que conecta na base, como uma ferramenta
Oracle como, por exemplo, o SQL/PLUS (WATSON; BERSINIC, 1 / 2006).
3.1.2 System Global Area
A System Global Area (SGA) é uma região de memória compartilhada que contém as
informações de dados e controle para uma instância do Oracle. O Oracle aloca a SGA quando
uma instância Oracle é iniciada e desaloca quando a instância é desalocada. Cada instância
tem sua própria System Global Area. Os usuários que estão conectados a um servidor Oracle
compartilham os dados na mesma System Global Area. Para se obter o desempenho ideal,
toda SGA deve ser o maior possível, ou seja, deve caber com tranquilidade na memória real
do servidor. A seguir estratégias para minimizar a E/S de disco:
Cache de Buffer de Banco de Dados: Os buffers de banco de dados da SGA armazenam os
blocos de dados usados mais recentemente. Um conjunto dos buffers de banco de dados de
uma instância é o cache do buffer de banco de dados. Este possui blocos de dados alterados e
inalterados. Os dados mais recentes geralmente são dados usados mais frequentemente,
portanto estes minimizam também a E/S de disco melhorando o desempenho do Oracle
(GOPALAKRISHNAN, 2008).
Buffer de registro redo: Os buffers de registro redo armazenam as entradas de redo
onde podemos considerar como o registro das alterações realizadas no banco de dados. As
entradas de registro armazenadas nos buffers de registro redo são posteriormente gravadas em
um arquivo de registro redo on-line o qual eventualmente é utilizado quando a recuperação do
banco de dados for necessária.
Pool Compartilhado: Pool compartilhado é uma parte da SGA que contém as
construções da memória compartilhada tais como áreas da SQL compartilhadas. Uma única
área de SQL compartilhada é utilizada por vários aplicativos que emitem a mesma declaração,
isto faz com que se minimize E/S de disco.
Large Pool: Large Pool é uma área opcional da SGA que fornece grandes alocações
de memória para as operações de backup e recuperação do Oracle.
Program Global Area (PGA): A Program Global Area é um buffer de memória que contém
21
as informações de dados e controle para um processo de servidor. Uma PGA é criada quando
um processo de servidor é iniciado (GOPALAKRISHNAN, 2008).
Na figura 1 é demonstrado uma instância Oracle e seus vários processos.
Figura 1 - Processos Oracle. Fonte: Oracle (2005)
3.2 Arquitetura de Processos do Oracle
O conhecimento da arquitetura interna do ORACLE é de extrema importância para a
compreensão das técnicas de otimização do produto. Basicamente, os seus mecanismos de
execução são as estruturas de memória e os processos executados em background. Todas as
vezes que um banco é inicializado, uma SGA é alocada e os processos são inicializados. A
combinação das estruturas de memória na SGA e dos processos em background é chamada de
instância ORACLE. Algumas arquiteturas de hardware permitem múltiplos computadores
compartilharem os mesmos dados, softwares ou periféricos. Com a opção Parallel Server do
ORACLE, podemos tirar proveito dessa característica através da execução de múltiplas
instâncias que compartilham um único banco de dados. Assim, os usuários de diversas
máquinas podem acessar o mesmo banco de dados com uma melhoria na performance. A
seguir processos da arquitetura Oracle:
Processos de Usuário: Um processo de usuário é criado e atualizado para executar o
código de software de um programa aplicativo ou uma ferramenta Oracle. O processo de
usuário também gerencia a comunicação com os processos de servidor. Os processos de
22
usuário se comunicam com os processos de servidor por meio da interface de programa
(HILL, 2008).
Processos de Servidor: O Oracle cria processos de servidor para lidar com as
solicitações dos processos dos usuários conectados. Um processo de servidor tem a
responsabilidade de se comunicar com o processo de usuário e interagir com o Oracle para
executar as solicitações. Por exemplo, se um usuário realiza uma consulta de dados que não
estejam nos buffers de banco de dados da SGA, o processo de servidor lê os dados solicitados
nos blocos de dados dos datafiles na SGA (WATSON; BERSINIC, 1 / 2006).
Processos de segundo plano: Quando uma instância é iniciada o Oracle cria uma série
de processos de segundo plano. Estes processos são a consolidação de diversas funções que
serão tratadas por vários programas. Abaixo os processos de segundo plano:
• Database Writer (DBWR): Responsável pela gravação dos blocos de dados do chache
de buffer do banco de dados para os datafiles.
• Log Writer (LGWR): Faz a gravação das entradas do registro redo que estão contidas
nos buffers de registro redo para os arquivos redo do disco.
• Checkpoint (CHKPT): O Checkpoint é responsável por sinalizar o DBWriter para que
seja feita a gravação dos dados nos datafiles. Em intervalos especificados, todos os buffers de
bancos de dados modificados na SGA são gravados nos datafiles pelo DBWriter.
• System Monitor (SMON): O System Monitor executa a recuperação de pane quando
uma instância falhada é reinicializada. Em um sistema de várias instâncias o SMON pode
eventualmente executar a recuperação de uma instância quando esta falhar.
• Process Monitor (PMON): O Process Monitor executa a recuperação de um processo
de usuário quando este falha. O PMON também limpa o cache e libera os recuros que o
processo estava usando.
• Archiver (ARCN): O archiver copia os arquivos de registro redo online para o
armazenamento de arquivamento quando eles estão cheios ou quando ocorre a troca de
registros. Para que isto seja possível o banco de dados deve estar no modo ARCHIVELOG e o
arquivamento automático deverá estar ativado.
• Recoverer (RECO): O Recoverer é usado para determinar as transações distribuídas
que estão pendentes devido a uma falha de rede ou sistema em um banco de dados distribuído.
Em determinados momentos o reco tenta se conectar ao banco de dados para completar
automaticamente um commit ou rollback de uma transação qualquer (WATSON; BERSINIC,
1 / 2006).
23
3.3 ORGANIZAÇÃO DOS DADOS NO ORACLE
Cada banco de dados possui um dicionário de dados. Um dicionário de dados Oracle é
um conjunto de tabelas e visões que são usadas como referência somente para leitura do
banco de dados. Um dicionário de dados armazena as informações sobre a estrutura lógica e
física do banco de dados, usuários válidos de um banco de dados, informações sobre
restrições e integridade das tabelas do banco de dados, espaço alocado para determinado
objeto ou esquema e quanto desse espaço está sendo utilizado etc. Um Dicionário de Dados é
criado quando um banco de dados é criado. Para refletir com precisão o status do banco de
dados o dicionários de dados é atualizado automaticamente pelo Oracle em resposta às ações
específicas como, por exemplo, alterações na estrutura do banco de dados (TOLEDO
JUNIOR, 2000).
Visões: Uma Visão é uma apresentação personalizada dos dados de uma ou mais
tabelas. Uma visão pode ser vista como uma consulta armazenada. As visões não contém nem
armazenam dados, elas derivam os dados das tabelas nas quais elas se baseiam, chamadas
tabelas base de visões. Do ponto de vista de administração de banco de dados temos as visões
fixas. Estas visões são chamadas de visões desempenho dinâmico devido ao fato de serem
atualizadas continuamente enquanto o banco de dados está aberto. Estas fornecem dados de
estruturas internas de discos, estruturas de memória e configurações da base de dados
instalada. Algumas das visões mais usadas na administração de um banco de dados Oracle
são: V$SESSION, V$INSTANCE, V$DATABASE, V$CONTROLFILE, V$LOCK,
V$NLS_PARAMETERS, V$OPTION, V$PARAMETER, V$PROCESS.
Seqüências: Uma sequência gera uma lista serial de números exclusivos para as colunas
numéricas das tabelas de um banco de dados. As sequências simplificam a programação de
aplicativos, gerando automaticamente valores numéricos exclusivos para as linhas de uma
única tabela ou várias tabelas. Por exemplo, assumindo que dois usuários estejam inserindo
simultaneamente linhas novas de empregados em uma tabela chamada EMPREGADOS01.
Usando uma sequência para gerar números exclusivos de empregados para a coluna
EMPNUM. Nenhum usuário terá que esperar que outro dê entrada no próximo número de
empregado disponível. A sequência gera automaticamente os valores corretos para cada
24
usuário. Os números de sequência são independentes das tabelas de modo que a mesma
sequência pode ser usada por uma ou mais tabelas (LONEY; THERIAULT, 2005). Figura 2 – Instância. Fonte: Oracle (2005)
3.3.1 Índices
Um Índice é uma estrutura de banco de dados usada pelo servidor para localizar
rapidamente uma linha de uma tabela aperfeiçoando o desempenho de uma consulta em uma
determinada tabela. Existem três tipos primários de índices:
Índices de cluster: Referem-se ao aglutinamento de certo número de tabelas
pertencentes a uma mesma aplicação em cluster, este procedimento minimiza E/S de disco e
organiza as tabelas para fins de administração.
Índices de tabela: Armazenam os valores das linhas de uma determinada tabela
juntamente com a localização física na qual a linha está localizada.
Índice Bitmap: É um tipo especial de índice de tabela criado para dar suporte às consultas de
tabelas grandes que têm poucos valores distintos (HART; JESSE, 2005).
3.3.2 Tablespaces e Datafiles
Quando um banco de dados é criado, ele se divide em diversas seções lógicas
chamadas tablespaces. No momento da criação do tablespace o datafile é criado para
armazenar os dados da tablespace. Esses arquivos alocam imediatamente o espaço
especificado durante a sua criação. Assim sendo, existe um relacionamento um para muitos
entre os tablespaces e os datafiles. Você pode incluir datafiles em um tablespace e os
datafiles existentes podem ser extendidos. O tablespace SYSTEM é o primeiro tablespace
criado. Os tablespaces adicionais são criados para conter diferentes tipos de dados. Por
exemplo imaginem que vamos criar tablespaces para o projeto chamado Porto Seguro. Estes
25
tablespaces serão as unidades lógicas de armazenamento das tabelas que serão criadas pelos
desenvolvedores do projeto (HART; JESSE, 2005).
Nome da tablespace: tablespace1_data – Usando a técnica OFA, considere que esta
seria a primeira tablespace de dados do projeto. Posteriormente viriam as tablespaces
tablespace2_data, tablespace3_data etc. Por outro lado no futuro é possivel criar um índice
referenciando esta tablespace onde este seria chamado tablespace1_index (HILL, 2008).
Datafile: Caminho onde será criado o arquivo DBF.
Size : Tamanho inicial da tablespace.
Extent management local autoallocate: Toda tablespace requer um gerenciamento,
este gerenciamento pode ser realizado pelo dicionário de dados ou pode ser local. O
gerenciamento de um tablespace realizado pelo dicionário de dados significa que o Oracle
está utilizando a tablespace SYSTEM para armazenar informações da tablespace
tablespace2_data. Esses dados contemplam tamanho da tablespace, quais usuários estão
permitidos acessar este tablespace, qual a quantidade de extents que esta tablespace possui,
quantos extents estão sendo utilizados no momento e quantos extents estão livres. Quando
falamos de uma o duas tablespaces gerenciadas pelo dicionário de dados a situação até que é
tranquila, as quando pensamos em aproximadamente 40 Tablespaces, onde cada Tablespace
possui aproximadamente 150 tabelas, o gerenciamento realizado pelo dicionário de dados faz
com que se tenha perda de performance ocasionada pelo auto número de E/S no disco para
atualizar a tablespace SYSTEM, esta ocorrência também fragmenta a tablespace. Portanto o
melhor procedimento é fazer com que a tablespace seja gerenciada localmente onde o banco
de dados aloca uma área no próprio tablespace para realizar o gerenciamento da mesma. Isto
minimiza a fragmentação tanto da tablespace System quanto da tablespace em questão,
fazendo com que não se perca performance no banco de dados (HART; JESSE, 2005).
3.4 FERRAMENTAS EXISTENTES
A Oracle possui diversos aplicativos que contemplam o conceito de alta
disponibilidade com diferentes características. Esta seção, apresenta um breve descritivo das
principais disponíveis no mercado, sendo FailSafe, Streams, Replicação, Real Application
Cluster entre outros.
26
3.4.1 Oracle Fail Safe
O Oracle Fail Safe provê alta disponibilidade em ambiente Windows. Deve-se utilizar
o Windows Cluster, onde é criado 2 ou mais nós utilizando o conceito ATIVO/PASSIVO. Se
ocorrer a falha no nó ativo, todos os recursos do Oracle Group serão movidas para o nó
PASSIVO automaticamente. É Importante ressaltar que durante o procedimento de
movimentação dos recursos para o outro nó disponível, haverá indisponibilidade dos recursos
e do banco de dados, até os mesmos serem restabelecidos no nó funcional (TOLEDO
JUNIOR, 2000).
Figura 3 – Arquitetura Fail Safe. Fonte: Oracle (2005)
As principais características deste cenário são:
1. Rapidez no failover;
2. Baixo custo
3.4.2 Oracle Streams
Oracle Streams é uma ferramenta do Oracle database que permite compartilhar
informações para outros databases.
Trata-se de um replicador de dados e integrador. Ele provê maior flexibilidade em ambiente
de infra-estrutura variada. Com ele é possível habilitar a propagação de dados, transações e
27
eventos de um database para outro de forma simples e eficiente. A flexibilidade do Streams
está na tradicional solução de replicação de dados e mensagens em fila, permitindo que
clientes consultem informações de forma singular provenientes de um ambiente
compartilhado com diferentes cenários em menor tempo e custo (HART; JESSE, 2005).
3.4.3 Oracle Real Application Cluster ( RAC )
Oracle RAC é uma solução onde se pode ter 2 ou mais nós ativos para um banco de
dados único, provendo tolerância a falhas, alta performance e escalabilidade sem impactar na
operação dos usuários. Principais benefícios:
•
24/7 disponibilidade: Prove alta disponibilidade 100% do tempo.
•
Escalabilidade sob demanda: É possível expandir a capacidade do RAC, adicionando
novos servidores ao cluster.
•
Baixo custo: baixo investimento e baixo custo de downtime, pois ambiente pode
trabalhar com load balancing.
Performance record mundial: Em testes de laboratório, o RAC mostrou-se mais rápido do que
ambiente mainframe (TOLEDO JUNIOR, 2000).
3.4.4 Oracle Active Data Guard
Oracle Active Data Guard é uma solução de banco de dados standby read-only. Com
este cenário, é possível disponibilizar o servidor standby para leitura, geração de relatórios e
consultas diversas durante a aplicação dos archives provenientes de produção, ou seja, todo
dado alterado em produção, será aplicado no servidor standby, mantendo-o atualizado. Desta
forma, podemos disponibilizar o standby para consultas minimizando assim a carga de acesso
ao servidor principal. As principais características são:
Recuperação de desastres e alta disponibilidade: O Oracle Data Guard fornece uma eficiente
e completa solução de recuperação e alta disponibilidade. Failover automático, fácil e rápido
permite reversões entre os servidores de bases de dados de produção e de standby,
minimizando o downtime do servidor de produção (TOLEDO JUNIOR, 2000).
Completa proteção de dados: Uma espera de dados também fornece uma proteção
eficaz contra as corrupções de dados e erros. O Oracle garante que a validação física de
28
corrupções não se propague. Usando o Flashback Database, erros lógicos que podem causar
corrupções a base de produção podem ser rapidamente resolvidos.
Eficiente utilização dos recursos do sistema: A espera física de dados pode ser usada
para backups e também de informação de leitura, reduzindo, assim, o consumo CPU e E/S do
servidor de produção. A espera física de dados pode ser facilmente convertida para frente e
para trás, sem comprometer a proteção de dados e oferecendo a flexibilidade para a inclusão
de novos índices para otimizar o desempenho de leitura.
Proteção de comunicação falhas: Se a conectividade de rede for perdida entre o
servidor de produção e o standby, o Data Guard automaticamente irá reconectar e sincronizar
os dados, uma vez que o problema original foi resolvido.
Gestão simples e centralizada: Data Guard Broker automatiza as tarefas de gestão e de
acompanhamento em todas as bases de dados configuradas no Data Guard. Os
administradores podem utilizar o Oracle Enterprise Manager ou o Broker da própria interface
de linha de comando para tirar proveito desse quadro de gestão integrada.
O Data Guard está disponível como um recurso integrado do Oracle Database
(Enterprise Edition), sem custo adicional (TOLEDO JUNIOR, 2000).
Figura 4 - Active Data Guard. Fonte: Oracle (2008)
29
4 ORACLE FAILSAFE
Oracle Fail Safe é um software que funciona com o Microsoft Cluster Server (MSCS).
Ele proporciona soluções empresariais altamente disponíveis em cluster. Trata-se de uma
solução de alta disponibilidade de aplicações e de instância única de dados que deve ser
executada em cluster.
O cluster é uma camada de aplicação entre dois ou mais sistemas servidores rodando o
Microsoft Windows e são apresentados ao usuário final, como um único servidor disponível.
Cada servidor em um cluster é referenciado como um nó do cluster.
Quando um nó do cluster falhar, os recursos alocados no nó ativo são redirecionados
automaticamente para o nó disponível no cluster. Esta operação é denominada de failover
(MICROSOFT, 2003).
Alguns benefícios do Oracle Fail Safe:
•
Provê alta disponibilidade;
•
Facilidade de uso
•
Facilidade de integração com aplicações diversas
•
Interatividade através do Oracle Manager Fail Safe
•
Failover automático
4.1 RECURSOS E APLICAÇÕES ALTAMENTE DISPONÍVEIS
O Oracle Fail Safe trabalha com MSCS, para configurar ambos os recursos de
hardware e software de alta disponibilidade. Uma vez configurado os nó do cluster, aparecem
para os usuários finais e clientes como um único servidor virtual; usuários finais e aplicações
são conectados a um único endereço de rede fixa, chamado endereço um endereço virtual,
sem necessidade de qualquer conhecimento do cluster. Então, se um nó no cluster se torna
indisponível, MSCS move o trabalho do nó que falhou para outro nó.
A figura 5 mostra um cluster configurado onde ambos os nó estão disponíveis, ativos e
processando. Na arquitetura, essa configuração não poderá ser diferente na criação de dois
servidores independentes, com exceção de que o armazenamento está configurado para que os
discos estejam ligados fisicamente a ambos os nó. Embora os nó estejam fisicamente
conectados a mesmos discos, o MSCS garante que cada disco pode ser e acessado apenas por
um nó por vez (ORACLE, 2003).
30
Figura 5 - Oracle Fail Safe antes da falha. Fonte: Oracle (2003)
A figura 6 mostra, quando hardware ou software torna-se indisponível em um nó, a
sua função automaticamente movimenta seu processamento para o nó sobrevivente e o nó
com falha é reiniciado, sem intervenção administrador. Durante o failover, as propriedades de
discos são liberadas a partir do servidor (nó A) e adquiridas pelo servidor sobrevivente (nó B).
Clientes então podem acessar o banco de dados através do nó B, utilizando o mesmo endereço
virtual que eles utilizavam para acessar o banco de dados quando ele estava no nó A.
Figura 6 - Oracle Fail Safe depois da falha. Fonte: Oracle (2003)
4.2 FACILIDADES DE UTILIZAÇÃO
31
Devido ao grande número de hardware e software que são envolvidos na configuração de
todos os seus dependentes (discos, endereços IP, rede), para trabalhar em um cluster pode ser
um processo complexo. Em contraste, Oracle Fail Safe é projetado para ser fácil de instalar,
administrar, utilizar e simplifica a configuração (FREEMAN, 2008).
4.3 APLICAÇÕES DE SISTEMAS TOLERANTES A FALHAS
Existem várias técnicas para a implementação de sistemas tolerantes a falha. A
utilização de todas elas na construção de um sistema, embora desejável, é inviável, pois pode
elevar o custo do projeto de forma excessiva. Por isso, a escolha da especificação do projeto
de acordo com a sua aplicação e sua exigência deve ser bem explorada. Nesta seção são
mostrados algumas aplicações que tradicionalmente exigem a implementação de um ou mais
mecanismos de tolerância à falhas. As áreas tradicionais onde são empregados sistemas
tolerantes a falhas são:
• Aplicações críticas de sistemas em tempo real, como medicina, controle de processos
e transporte aéreo;
• Aplicações seguras de tempo real, como transporte urbano;
• Aplicações em sistemas de tempo real de longo período de duração sem manutenção,
como viagens espaciais, satélites e sondas;
• Telefonia e telecomunicações;
Exigências de disponibilidade e confiabilidade são encontradas em todas as áreas, mas os
sistemas tolerantes a falha são caros e, portanto empregados apenas em situações em que a
sua não-utilização acarretaria prejuízos irrecuperáveis (FREEMAN, 2008).
32
5 ORACLE RAC REAL APPLICATION CLUSTER
Um banco de dados Real Application Clusters é altamente disponível e escalonável. A
falha de um dos nós no cluster não afeta as sessões de clientes nem a disponibilidade do
próprio cluster até o último nó no cluster falhar; o único impacto que um nó perdido tem
sobre o cluster é uma leve degradação no tempo de resposta, dependendo do número total de
nós no cluster.
Um banco de dados Oracle RAC tem algumas desvantagens o custo de licenciamento
são mais altos, porque cada nó no cluster possui uma licença Oracle própria. A proximidade
física dos nós no cluster, devido aos requisitos de alta velocidade de interconexão do cluster,
significa que um desastre natural pode parar todo cluster; utilizar um banco de dados remoto
de reserva ajuda a aliviar algumas dessas preocupações. Você terá de comparar o custo de alta
disponibilidade (ou a falta dela) com aumento do custo e um pequeno aumento na
manutenção de um banco de dados Real Application Clusters (ORACLE, 2003, 2005, 2008).
5.1 CONFIGURAÇÕES
A instalação do Oracle RAC requer algumas configurações e recomendações mínimas
relacionadas à hardware, software e topologia de redes.
A implementação destas
recomendações são obrigatórias com o intuito de maximizar o conceito de alta disponibilidade
de um ambiente Oracle RAC. 5.1.1 Configuração de Hardware
Uma discussão completa de todas as possíveis configurações de hardware do banco de dados
Real Application Clusters está além do escopo dos livros estudados. É recomendado ter pelo
menos dois e, preferivelmente, três nós para um banco de dados Real Application Clusters,
cada um com fonte de energia, placa de rede, CPU’s dual e memórias de erro redundantes;
essas são as características desejáveis para qualquer tipo de servidor, não apenas para um
servidor Oracle. Quanto maior o número de nó configurados no cluster menor o impacto
sobre o desempenho quando um dos nós do cluster falhar. Os subsistemas de discos
compartilhados também devem ter a redundância de hardware pré-definida – Múltiplas fontes
de alimentação de energia, disco com RAID ativado etc. Divide a redundância pré-definida do
disco compartilhado entre os tipos de grupos de discos que serão criados para o RAC. Uma
33
redundância mais alta pré-definida no hardware do subsistema de disco pode reduzir
potencialmente a quantidade de redundância do software que você especifica ao criar dos
grupos de disco do banco de dados (GOPALAKRISHNAN, 2008).
5.1.2 Configuração de Software
Embora as soluções de clusterização do Oracle estejam disponíveis desde a versão 6,
só na versão 10g houve uma solução de clusterware nativo que une mais compactadamente o
banco de dados à solução de gerenciamento do volume. O Cluster Ready Services (CRS) é a
solução de clusterização que pode ser utilizada nas principais plataformas em vez de um
fornecedor de OS ou um clusterware de terceiros.
O CRS é instalado antes do RDBMS e precisa estar em diretório inicial próprio,
conhecido como CRS_HOME. Se, no futuro próximo, você utilizar uma única instância, mas
pensar um clusterizá-la posteriormente, será útil primeiro instalar o CRS de modo que os
componentes do CRS necessário para o ASM e RAC já estejam na estruturas de do diretório
RDBMS. Se não instalar o CRS primeiro, mais tarde, terá de seguir alguns passos extras para
remover os executáveis relacionados ao processo CRS do diretório inicial do RDBMS.
Depois que o CRS é instalado, instale o software do banco de dados no diretório
inicial, conhecido como ORACLE_HOME (GOPALAKRISHNAN, 2008).
5.1.3 Configuração de Rede
Cada nó em um RAC tem no mínimo três endereços IP: um para rede pública um para
interconexão de rede privada e um endereço IP virtual para suportar failover mais rápido no
caso de uma falha no nó. Como resultado, no mínimo duas placas de rede físicas são
necessários para suportar o RAC; as placas de redes adicionais são utilizadas para fornecer
redundância na rede publica e assim um caminho de rede alternativo para as conexões
recebidas. Para a rede privada placas de redes adicionais podem aprimorar o desempenho
fornecendo mais largura de banda total para o trafego interconectado (HILL, 2008).
34
Figura 7 - Oracle RAC Configuração de IP. Fonte: Oracle (2008)
A rede pública é utilizada por todas as conexões de rotina para e do servidor; a rede de
interconexão ou rede privada suporta a comunicação entre os nós no cluster, como as
informações sobre o status dos nós e os blocos de dados reais compartilhados entre os nós.
Essa interface deve ser a mais rápida possível e nenhum tipo de comunicação entre os nós
deve ocorrer nessa interface, do contrario, o desempenho do banco de dados RAC poderia
sofrer.
O endereço virtual é o endereço atribuído ao processo ouvinte Oracle e suporta
failover rápido por tempo de conexão, que é capaz de comutar o trafego de rede e a conexão
Oracle para um instância diferente no banco de dados RAC muito mais rápida do que uma
solução de alta disponibilidade de terceiros. (ORACLE, 2006)
5.2 REQUISITOS DE MEMÓRIA E DISCO
Para cada nó no cluster, 512Mb é o mínimo recomendável. O espaço de troca deve ter
pelo menos duas vezes esses valor, ou 1Gb. Para uma instalação bem sucedida, deve haver
400mb livres no sistema de arquivos /tmp.
O próprio software Oracle requer aproximadamente 2,5 Gb de espaço em disco e os
arquivos de banco de dados padrão requer outros 1,2Gb; o crescimento do seu banco de dados
depende, naturalmente, da aplicação.
No subsistema de discos compartilhados, precisa de duas partições especiais: uma para um
disco de votação e outra para o Oracle Cluster Registry (OCR). O disco de rotação é utilizado
pelo software de clusterização do Oracle, o Cluster Ready Services (CRS), para arbitrar a
posse do cluster no caso de uma falha da rede privada. O disco OCR é utilizado para manter
todos os metadados sobre o cluster: a configuração do cluster e a configuração de banco de
dados do Cluster (GOPALAKRISHNAN, 2008).
35
5.3 CLUSTER READY SERVICES
Os CRS devem ser instalados em um diretório inicial próprio chamado CRS_HOME.
Como parte da instalação do CRS, você terá de configurar dois locais particulares que
não sejam específicos a qualquer instância, mas que seja utilizado pelo próprio cluster: o
Oracle Cluster Registry e o disco de votação. O Oracle Cluster Registry (OCR) é a
localização em que o cluster armazena seus metadados e o espaço em disco de 100Mb é mais
do que suficiente para armazenar os metadados para um cluster muito grande. O disco de
votação é utilizado pelo cluster para resolver situações nas quais um ou mais nó no cluster
perdem contato com outros nó no cluster em uma interconexão privada. Dessa maneira, você
pode evitar que um dos nó ou um dos grupo de nó gravem nos arquivos de discos
compartilhados por que eles supõe que esteja controlando o armazenamento compartilhado;
como com o disco OCR, o disco de votação requer não mais do que 100Mb
(GOPALAKRISHNAN, 2008).
As localizações dos discos OCR e do disco de votação devem estar em dispositivos
brutos separados, mesmo quando você utiliza o ASM para os seus outros arquivos de banco
de dados; entretanto, se utilizar o OCFS, o disco OCR e o disco de votação podem existir
como arquivo de em um volume OCFS (ORACLE, 2008).
5.4 CARACTERÍSTICAS DO BANCO DE DADOS ORACLE RAC
Uma instância RAC é de varias formas, diferentes de uma instância diferente
[Standalone]; aqui mostraremos os parâmetros de inicialização que são específicos de uma
instância RAC. Alem disso mostraremos algumas versões de dicionários de dados e visões de
desempenho dinâmico que são únicas de um RAC ou tem colunas que só são preenchidas
quando a instância faz parte de um RAC (HILL, 2008).
5.5 CARACTERÍSTICAS DO ARQUIVO DE PARÂMETRO DE SERVIDOR
O arquivo de parâmetro de servidor (SPFILE) reside no grupo de disco DATA1 e,
portanto, é compartilhado por cada nó no cluster. Dentro do SPFILE, você pode atribuir
diferentes valores a determinados parâmetros instância por instância, em outras palavras o
valor para um parâmetro de inicialização pode diferir entre instâncias. Se um parâmetro de
36
inicialização for o mesmo para todos os clusters, ele será prefixado com “*.”; do contrario,
será prefixado com o nome do nó (GOPALAKRISHNAN, 2008).
37
6 ESTRATÉGIA DE BACKUP
O ponto chave para o desenvolvimento de uma boa estratégia de backup está
diretamente associada à disponibilidade do dado para a empresa. O bom senso deve imperar
nesse momento, pois de nada adianta ter um ambiente complexo de backup e restore
instalado, quando na verdade o que a empresa precisa é simplesmente ter um backup ativo e
operante.
O resultado a ser alcançado é manter os ambientes de desenvolvimento, teste,
integração, homologação e produção disponíveis e atualizados para uso constante. As equipes
envolvidas: DBA, Data Center (responsável pela execução e checklist do processo) e a
gerência da empresa devem estar sempre atualizadas em relação às informações geradas pelo
processo de backup (WATSON; BERSINIC, 1 / 2006).
O Oracle fornece uma variedade de procedimentos e opções de backup que ajudam a
proteger um banco de dados. Se adequadamente implementadas, essas opções permitirão um
eficiente backup de seu banco de dados e, posteriormente, uma fácil recuperação.
As capacidades de backup do Oracle incluem backups lógicos e físicos ambos com
diferentes opções a serem implementadas. Neste capitulo é abordado o uso das melhores
opções, e maneiras mais eficiente.
6.1 CONFIGURANDO DEFINIÇÕES DE BACKUP
Há três métodos padrão de fazer backup de um banco de dados Oracle: exportações,
backups off-line e backups on-line. Uma exportação é um backup lógico do banco de dados;
os outros dois métodos de backup são backups físicos de arquivos. Uma estratégia robusta de
backup inclui tanto backups físicos e lógicos.
Em geral, bancos de dados de produção contam com backups físicos como seu
principal método de backup e backup lógicos serve como um método secundário. Para bancos
de dados de desenvolvimento e para alguns pequenos processamentos de movimentação de
dados, os backups lógicos são uma solução viável. Deve-se entender as implicações e uso dos
backups físicos e lógicos a fim de desenvolver a melhor solução para aplicações (WATSON;
BERSINIC, 1 / 2006).
38
6.2 BACKUP LÓGICO
Um backup lógico de um banco de dados envolve a leitura de um conjunto de registros
do banco de dados e a gravação destes em um arquivo. Esses registros são independentes das
suas localizações físicas. No Oracle, o utilitário Data Pump Export realiza esse tipo de backup
do banco de dados. Para recuperação, com o arquivo gerado em um Data Pump Export,
utiliza-se o Data Pump Import. O utilitário Data Pump Export do Oracle consulta o banco de dados, incluindo o
dicionário de dados, e grava a saída em um arquivo XML chamado arquivo de dump de
exportação. Pode exportar todo o banco de dados, usuários específicos, espaços de tabelas ou
tabelas especificas. Durante as exportações, pode escolher entre exportar as informações dos
dicionários de dados associados as tabelas, como concessões, índices e restrições. O arquivo
gravado pelo Data Pump Export conterá os camandos necessários para recriar completamente
todos os objetos e dados escolhidos (WATSON; BERSINIC, 1 / 2006).
Depois que os dados foram exportados por meio do Data Pump Export, eles poderão
ser importados por meio do utilitário Data Pump Import. O Data Pump Import lê o arquivo
dump criado pelo Data Pump Export e executa os comandos localizados. Por exemplo, esses
comandos podem incluir comando CREATE TABLE, seguido de um comando INSERT para
carregar dados para tabela.
Os dados que não foram exportados tem de ser importados para o mesmo banco de
dados, ou para o mesmo esquema, tal como foram utilizados para gerar o arquivo de dump de
exportação. Pode-se utilizar o arquivo de dump de exportação para criar um conjunto
duplicado dos objetos exportados sob um esquema diferente ou em um banco de dados
diferentes.
Podem ser importados todos dados exportados, ou somente uma parte deles. Se
importar todo o arquivo de dump de exportação apartir de uma exportação completa, então
todos os objetos do banco de dados – incluindo os espaços de tabelas arquivos de dados e
usuários - serão criados durante a importação. Entretanto, é freqüentemente útil pré-criar
espaços de tabelas e usuários a fim de especificar a distribuição física dos objetos no banco de
dados.
Se for importado apenas parte dos dados a partir do arquivo de dump de importação,
os dados de tabelas, arquivos de dados e usuários que possuirão e armazenarão esses dados
deverão ser configurados antes da importação (WATSON; BERSINIC, 2007).
39
6.3 BACKUPS FÍSICOS
Backups físicos envolvem a copia dos arquivos que constituem o banco de dados.
Esses backups são também conhecidos como backups do sistema de arquivos porque
envolvem o uso de comandos para backup de arquivos do sistema operacional. O Oracle
suporta dois tipos diferentes de backups físicos de arquivos: backups off-line e backups online (também conhecido como cold backups e hot backups, respectivamente). Podendo utilizar
o utilitário RMAN (Recovery Manager) para realizar todos os backups físicos.
Opcionalmente, pode optar por escrever seus próprios scripts para realizar backups físicos,
mas isso fará com que não obtenha boa parte dos benefícios da abordagem RMAN
(WATSON; BERSINIC, 1 / 2006).
6.3.1 Backups Off-line
Backups off-line ocorrerem quando o banco de dados é desligado de maneira normal
(isto é, não devido à falha da instância). Enquanto o banco de dados estiver off-line, deve-se
fazer o backup dos seguintes arquivos:
a. De todos os arquivos de dados
b. De todos os arquivos de controle
c. De todos os logs de redo on-line
Do arquivo init.ora (opcional) e do arquivo de parâmetro de servidor (spfile), se
utilizado.
É fácil fazer backups dos arquivos de dados se a arquitetura de arquivos do banco de
dados utiliza uma estrutura de diretórios consistentes.
Fazer o backup de todos esses arquivos enquanto o banco de dados esta desligado
fornece uma imagem completa do banco de dados tal como ele existia no momento em que
foi desligado. O conjunto completo desses arquivos poderia ser recuperado a partir dos
backups em uma data posterior e o banco de dados seria capaz de funcionar. Não é valido
realizar um backup do sistema de arquivos do banco de dados enquanto ele está aberto a
menos que um backup on-line está sendo realizado. Backups off-line que ocorrem depois da
interrupção do banco de dados também serão considerados inconsistentes e talvez requeiram
mais esforços para que possam ser utilizados durante a recuperação (HILL, 2008).
40
6.3.2 Backups On-line
Pode ser utilizado backups on-line para qualquer banco de dados em execução no
modo ARCHIVELOG. Nesse modo, os logs de redo on-line são arquivados criando um
registro em log de todas as transações dentro do banco de dados.
O Oracle grava nos arquivos de log de redo on-line de uma maneira cíclica: depois de
preencher o primeiro arquivo de log, ele começa a gravar o segundo, até que este esteja
preenchido, e então começa a gravar o terceiro. Depois que o ultimo arquivo de log de redo
on-line é preenchido, o segundo plano do LGWR (Log Writer) começa a sobrescrever o
conteúdo do primeiro arquivo do log de redo (HILL, 2008).
Quando o Oracle é executado no modo ARCHIVELOG, o processo do segundo plano
do ARCH (Archiver) cria uma cópia de cada arquivo de log de redo antes de sobrescrevê-lo.
Esses arquivos de log de redo arquivados em repositórios de arquivos normalmente são
gravados em um dispositivo de disco. Os arquivos de log de redo arquivados em repositórios
de arquivos também podem ser gravados em fita, mas isso tende a utilizar o operador
intensivamente.
A maioria dos Bancos de dados de produção, particularmente aqueles que suportam
aplicações de processamento de transações, deve ser executado no modo ARCHIVELOG.
Também pode ser realizado backup de sistema de arquivo de um banco de dados
enquanto esse banco de dados está aberto, desde que o banco de dados esteja executando no
modo ARCHIVELOG. Um backup on-line envolve configurar cada espaço de tabela em um
estado de backup, fazer backup de seus arquivos de dados e restaurar o espaço de tabela ao
seu estado normal. (HILL, 2008)
Ao utilizar o utilitário Recovery Manager (RMAN) fornedico pela Oracle, usuário não
precisa colocar manualmente cada espaço de tabela em um estado de backup. O RMAN lê os
blocos de dados tal como o Oracle usa consultas (WATSON; BERSINIC, 1 / 2006).
6.4 ESTRATÉGIA DE BACKUP SUGERIDA PELA ORACLE
Os backups físicos do banco de dados asseguram que a transação não-confirmada é
perdida, podendo-se restaurar o banco de dados a partir de qualquer backup anterior até o
ponto atual no tempo ou qualquer ponto intermediário. Os backups lógicos permitem que o
DBA ou usuário capture o conteúdo de objetos de dados individuais em ponto particular no
41
tempo, fornecendo uma opção de recuperação alternativa quando uma operação de
restauração de banco de dados completa teria um impacto muito grande no restante do banco
de dados
O Recovery Manager (RMAN) do Oracle leva o backup e a recuperação a um novo
nível de proteção e facilidade de uso. Desde o aparecimento do RMAN na versão 8 do Oracle,
há varias melhoras e aprimoramentos importantes que podem fazer do RMAN uma solução
única para quase todo o ambiente de banco de dados. (HILL, 2008)
O RMAN é mais do que um simples executável do lado do cliente que pode ser
utilizado com uma interface Web. Ele abrange vários outros componentes, inclusive o banco
de dados do qual será feito o backup (Banco de dados Alvo), um catalogo de recuperação
opcional, uma Flash Recovery Area opcional e um software de gerenciamento de mídia para
suportar sistemas de backup de fita.
Muitos recursos RMAN não têm equivalentes nos métodos de backup apresentados
anteriormente (WATSON; BERSINIC, 1 / 2006).
6.4.1 Componentes do RMAN
O primeiro componente no ambiente RMAN é o executável RMAN. Ele está
disponível junto com os outros utilitários Oracle no diretório $ORACLE_HOME/bin e é
instalado por padrão com as edições Standard e Enterprise do Oracle 10g. A partir de um
prompt de linha de comando o RMAN pode ser invocado com ou sem argumento de linha de
comando.
Os argumentos de linha de comando são opcionais, também podem especificar o
banco de dados alvo e um catalogo de recuperação a partir do prompt RMAN>.
No Oracle 10g, a Flash Recovery Area simplifica o backup e a restauração baseada em
disco, ao definir um local em disco para armazenar todos os backups de RMAN. Junto com o
local, o DBA também pode especificar um limite superior para a quantidade de espaço em
disco utilizada na Flash Recovery Area. Uma vez que uma diretiva de retenção é definida
dentro do RMAN, este gerenciara automaticamente os arquivos de backup excluindo os
backups obsoletos tanto do disco como da fita (HILL, 2008).
42
6.4.2 RMAN versus método de backup tradicional
Há pouquíssimas razões para não utilizar RMAN como sua ferramenta principal para
gerenciamento de backup. Alguns dos principais recursos do RMAN que não estão
disponíveis com métodos de backups tradicionais, e tem as significativas restrições desses
métodos:
a. Backup Compression: além de pular blocos que nunca foram utilizados, o RMAN
também pode utilizar um modo de compactação binária especifico do Oracle para salvar
espaços no dispositivo de backup. Embora as técnicas de compactação especificas do sistema
operacional estejam disponíveis com os métodos de backup tradicionais, os algoritmos de
compactação utilizados pelo RMAN são personalizado para maximizar a compactação dos
tipos comuns de dados encontrados em bloco de dados Oracle.
Embora haja um ligeiro aumento no tempo de CPU durante uma operação de
recuperação ou backup compactado do RMAN, a quantidade de mídia utilizada para backup
pode ser significadamente reduzida, bem como a largura de banda de rede se o backup for
realizado na rede. Múltiplas CPU’s podem ser configuradas para um backup RMAN para
ajudar a aliviar o overhead de compactação (HILL, 2008).
b. Open database backups: backups de espaços de tabelas podem ser realizados no
RMAN sem utilizar a clausula begin/end backup como alter tablespace. Mas, seja utilizando
RMAN ou um método de backup tradicional, o banco deve estar no modo ARCHIVELOG
c. True incremental backups: para qualquer backup incremental RMAN, os blocos de
dados inalterados desde o ultimo backup não serão gravado no arquivo de backup. Isso poupa
uma quantidade significativa de espaços de restauração e recuperação, o RMAN suporta
backups incrementalmente atualizados. Os blocos de dados de um backup incremental são
aplicados a um backup anterior para reduzir potencialmente a quantidade de tempo e o
numero de arquivos que precisam ser acessados para realizar uma operação de recuperação
(WATSON; BERSINIC, 1 / 2006).
6.4.3 Tipos de backups
O RMAN suporta diversos métodos de backups diferentes, dependendo de suas
43
necessidades de disponibilidade, do tamanho desejado da janela de recuperação e da
quantidade de tempo de inatividade que pode suportar enquanto o banco de dados ou parte do
banco estiver envolvido em uma operação de recuperação.
Um backup físico pode ser classificado como backup consistente ou inconsistente. Em
um backup consistente, todos os arquivos de dado têm o mesmo SCN. Em outras palavras,
todas as alterações nos logs de redo foram aplicadas aos arquivos de dados. Como um banco
de dados aberto sem transações confirmadas pode ter alguns blocos sujos no cache de buffer,
é raro que um backup aberto de banco de dados possa ser considerado consistente. Como
resultados, os backups consistentes são adotados quando um banco é desligado normalmente
em um estado MOUNT (HILL, 2008).
Ao contrario, um backup inconsistente é realizado enquanto o banco de dados está
aberto e os usuários estão acessando o banco. Como, em geral os SNCs dos arquivos de dados
não se correspondem quando um backup inconsistente está acontecendo (WATSON;
BERSINIC, 1 / 2006).
44
7 ANALISE COMPARATIVA ENTRE ORACLE RAC E ORACLE FAILSAFE
O Oracle RAC e o Oracle Failsafe são os dois principais produtos RDBMS
(Relational Database Management Systems - Sistemas de Gerenciamento de Banco de Dados
Relacional) no mercado. Ambos são plataformas de gerenciamento de dados com recursos
que comprovaram a capacidade de lidar com aplicações críticas, de larga escala. Contudo, as
duas arquiteturas oferecem visões diferentes para aplicações de larga escala e críticas.
A Oracle está oferecendo concentradamente seus “Clusters Reais de Aplicações”
(RAC), uma tecnologia de “escalabilidade horizontal”, como uma solução para todos os tipos
de aplicações de bancos de dados, essencialmente dispensando a abordagem tradicional de
escalabilidade. A Oracle alega que o RAC oferece escalabilidade e disponibilidade inéditas a
baixo custo devido à sua capacidade de utilizar hardware comercial de baixo custo. A principal diferença entre o Oracle RAC e o Oracle Failsafe está na infra-estrutura.
No Oracle RAC, é possível acessar dois ou mais nós simultaneamente. Já o Oracle Failsafe,
tem acesso à apenas um único nó ativo, este que por sua vez concentram todos os recursos do
cluster mapeados.
Com isto, pode concluir que a principal característica entre Oracle RAC e o Oracle
Failsafe está no balanceamento de carga, na aplicação isso fica bem implícito.
7.1 APLICAÇÃO
O mercado financeiro brasileiro cresceu muito nos últimos anos. Este grande avanço
proporcionou às pessoas físicas (e não somente instituições financeiras) a participarem
ativamente do mercado de ações, comprando e vendendo papéis de empresas brasileiras.
Com o surgimento dos “Home Brokers”, que é o instrumento que permite a
negociação de ações via Internet, onde é efetuado a compra ou venda de ações através da
internet, o usuário (pessoa física) não precisa de um corretor muito menos de muito dinheiro
para iniciar a aplicar na Bolsa de Valores de São Paulo (Bovespa) (http://www.cblc.com.br,
2009).
O mercado tornou-se acessível a qualquer pessoa com qualquer volume de dinheiro e
que esteja disposta a arriscar e apostar nas empresas brasileiras, mas isto não quer dizer que
você não deve levar os negócios online a sério. Há muita tecnologia por trás dos famosos
“Home Brokers” (http://www.cblc.com.br, 2009).
45
Ações e mercados
Uma quota de ações é basicamente uma minúscula parte de uma empresa. Os
acionistas, pessoas que compram ações, estão investindo no futuro de uma empresa durante o
tempo em que estiverem de posse de suas quotas. O preço de uma quota varia de acordo com
as condições econômicas, o desempenho da empresa e as atitudes dos investidores. A primeira
vez que uma empresa oferece suas ações para venda ao público é chamada de oferta pública
inicial (OPI), também conhecida como "going public" (indo ao público).
Quando um negócio dá lucro, o dinheiro pode ser dividido com seus acionistas através
de dividendos. O lucro também pode ser guardado ou reinvestido, aprimorando o negócio ou
contratando novas pessoas.
As corretoras intermediam a compra e venda de ações através da Bolsa de Valores de
São Paulo, cobrando uma comissão por esta intermediação.
Figura 8 - Vendas Online. Fonte: IGF (2009).
Quando se compra e vende ações online, utiliza-se um “corretor online” que muitas
vezes substitui um corretor “humano”. A grande diferença, é que você executa suas ordens de
compra e venda diretamente pelo “Home Broker” ao contrário de um corretor, onde as ordens
de compra ou venda são executadas por ele, de dentro da corretora (http://www.cblc.com.br,
2009).
Home Broker
Para permitir que cada vez mais pessoas possam participar do mercado acionário e, ao
mesmo tempo, tornar ainda mais ágil e simples a atividade de compra e venda de ações, foi
46
criado um moderno canal de relacionamento entre os investidores e as Corretoras da
BOVESPA: o Home Broker.
Garantias
Com a finalidade de oferecer o máximo de segurança nas operações realizadas em seu
sistema de negociação, a BOVESPA as acompanha minuciosamente. Além disso, exige
limites e garantias para a execução dessas operações. A CBLC (Central Depositária.
Compensação e Liquidação) administra o risco que essas operações podem associar aos
mercados, estabelecendo limites operacionais para os Agentes de Compensação; estes, por sua
vez, às Corretoras; e as mesmas a seus clientes.
Outra exigência da CBLC, é que todas as corretoras que possuem Home Broker,
utilizem as melhores práticas em gestão de TI, utilizando-se de recursos confiáveis e seguros,
como backup´s offsite (armazenamento de backup em outra localidade), servidores de
contingência em locais distintos, bem como sistemas gerenciadores de banco de dados de alta
capacidade e disponibilidade, como por exemplo o Oracle RAC ou Oracle FailSafe.
O Oracle RAC é recomendado para ambiente de alta criticidade, onde não devem
suportar qualquer falha de hardware, rede ou sistemas. Geralmente, denominamos que um
ambiente deste teria 99% de disponibilidade. Em caso de falhas, os usuários serão
direcionados para o nó que estiver ativo, sem qualquer intervenção humana e também sem
perda de conexão. A transação que estava alocada no nó que falhou, será direcionado para o
nó que estiver ativo automaticamente e dará sequência ao processamento da mesma. Para o
usuário final, esta movimentação é totalmente transparente.
Já no Oracle FAILSAFE, em caso de falha do hardware onde se encontra o Oracle
ativo, todos os serviços de acesso ao Oracle ficarão indisponíveis, forçando a queda de
conexão com todos os usuários, sem salvar quaisquer transações e após alguns segundos, o
acesso ao Oracle poderá ser restabelecido no outro nó (que se encontrava passivo). Todos os
usuários, sistemas, etc. necessitarão reconectar-se ao Oracle para darem continuidade às
atividades/execuções (http://www.cblc.com.br, 2009). Em seguida, relacionado os equipamentos
comparados:
Corretora A – Oracle RAC 10gR2
2 servidores com a seguinte configuração:
47
Item
Descrição
Processador(es)
4 Intel(R) Xeon(R) CPU 5140 @ 2.33GHz
Memória
10GB RAM
Storage
MSA 500 G2 ( 350GB )
Rede
2 Placas de Rede NC1020 1000T Gigabit
Corretora B – Oracle Failsafe 10gR2
2 servidores com a seguinte configuração:
Item
Descrição
Processador(es)
2 Intel(R) Dual Core 3.0 GHz
Memória
8 GB RAM
Storage
MSA 500 G2 ( 350GB )
Rede
2 Placas de Rede NC1020 1000T Gigabit
7.2 ANALISE DOS RESULTADOS
Os testes efetuados em laboratório, constaram que:
Tempo de restauro de uma conexão com Oracle FailSafe x Oracle Rac.
ORACLE RAC – entre 2 e 4 segundos de “delay “ para transferir.
ORACLE FAILSAFE – entre 15 e 20 segundos de transferências dos recursos para o
outro nó, com indisponibilidade de acesso, queda das conexões e cancelamento das transações
pendentes, sendo necessário restabelecer as conexões.
Figura 9 - Oracle FailSafe x Oracle RAC após queda de um nó ( em segundos )
48
Figura 10 - Conexões que permaneceram ativas após falha de um nó. (em percentual)
Esta é uma área em que a alegação da Oracle é mais fraca. Embora seja verdade que o
RAC pode reduzir os custos de hardware usando um cluster de servidores de mercado mais
baratos e menores, qualquer economia em hardware é compensada pelo custo extra do(s):
Software RAC, custos adicionais de armazenamento e rede e custo extra de administração.
O RAC é uma arquitetura bastante cara. O preço de lista do RAC é de US$ 20.000 por
processador. Isso é mais que a diferença entre servidores de mercado populares.
Para o RAC, deve-se licenciar a quantidade total de processadores que estarão ativos no
Oracle (2 nós, cada um com 1 processador ).
Para o failsafe, apenas 1 processador é utilizado, pois haverá apenas um único nó
ativo.
Figura 11 – Custo.
É interessante que o RAC use servidores populares, mas exija chaves de
armazenamento sofisticadas e de alta capacidade. Também é importante notar que, contrário
às alegações da Oracle, o RAC não é executado em nenhum hardware de mercado de
prateleira. O RAC precisa de hardware “certificado” que limita a escolha e conseqüentemente
aumenta o custo.
7.3 CONSIDERAÇÕES IMPORTANTES
49
As informações e dados apresentados no capitulo 7.3 foram obtidas com base em
servidores Oracle Rac e Failsafe, utilizados por Corretoras da Bolsa de Valores de São Paulo.
Estas corretoras são responsáveis por efetuar o controle das transações de compra e venda de
ações no mercado financeiro brasileiro, utilizando aplicativos específicos para compra e
venda via internet (home broker), sistemas administrativos (ERP), controle financeiro e conta
corrente, entre outros.
Ressaltado que os servidores de banco de dados Oracle em cada empresa avaliada são
distintos com base na configuração de processador, memória, discos, etc. Estas diferenças
podem alterar o resultado final da avaliação.
50
8 CONCLUSÃO
Com a pesquisa pode-se concluir que a otimização dos recursos na área de TI,
especialmente á distribuição de processamentos e de infra estrutura existentes nas empresas,
através de soluções em cluster, tanto para ambiente de produção e desenvolvimento,
proporciona uma alternativa de custo benefícios muito interessante.
Grandes volumes de dados processados pelas empresas aumentam diariamente. Para
acompanhar essa demanda são necessários procedimentos cada vez mais rigorosos e
ferramentas adequadas. As áreas que necessitam de maior atenção para acompanhar essas
demandas são bancos de dados e servidores.
Os bancos de dados têm adquirido uma importância extrema, pois armazenam dados
críticos para o sucesso das empresas. A utilização de SGBDs em Cluster no ambiente
corporativo tem amadurecido com o passar dos anos, pois, proporciona maior disponibilidade,
integridade e desempenho no tratamento dos dados da empresa.
Este estudo apresenta uma proposta de análise sobre a utilização SGBDs em Cluster.
Através dos testes de desempenho e disponibilidade de SGBDs Oracle em Cluster em
diferentes plataformas é possível identificar quais os cenários propícios para a implementação
de determinada arquitetura.
O Oracle RAC apesar de ser financeiramente mais caro e ter uma administração
completa, é a melhor opção quando falamos de alta disponibilidade e missão critica. O Oracle
Fail Safe é uma arquitetura mais antiga e menos confiável quando o assunto é disponibilidade.
Contudo o Oracle RAC é a melhor opção para empresas que querem o seu sistema integro e
disponível a todo o momento.
8.1 TRABALHOS FUTUROS
Oracle Real Application Clusters on Extended Distance Clusters
Para trabalho futuro temos como objetivo estudar cada particularidade do Oracle Real
Application Clusters on Extended Distance Clusters, uma arquitetura nova disponibilizada
pela Oracle para ambientes de grande criticidade. No Oracle Real Application Clusters on
Extended Distance Clusters, temos 2 sites em lugares distintos, caso um site venha a falhar
por completo, todas as conexões serão direcionadas para o outro site.
51
A falha de um dos sites do cluster não afeta as sessões de clientes nem a
disponibilidade do próprio cluster até o último nó do segundo site falhar; o único impacto que
um site perdido tem sobre o cluster é uma leve degradação no tempo de resposta, dependendo
do número total de nós no cluster.
Figura 12 - Oracle Real Application Clusters on Extended Distance Clusters 10gR2. Fonte: Oracle (2005)
52
REFERÊNCIA BIBLIOGRÁFICA
LONEY, Kevin; THERIAULT, Marlene. O Manual do DBA. São Paulo: Campus, 2005
HART, Matthew; JESSE, Scott. Oracle Database 10g. Eua: Osborne, 2005.
FREEMAN, Robert G.. Oracle Database 10g: New Features. Eua: Osborne, 2008.
TOLEDO JUNIOR, Hugo. Oracle Networking. Usa: Osborne, 2000.
UNIVERSITY, Oracle. Oracle Real Application Clusters. Usa: Oracle, 2003.
GOPALAKRISHNAN. Oracle Database 10g: Real Application Cluster. Usa: Oracle, 2008.
WATSON; BERSINIC. Oracle Database 10g: RMAN Backup & Recovery. Usa: Oracle,
2006.
JOHN WATSON, Oracle Database 10g: Certificação OCP. Oracle, 2005
ÖZSU, M. TAMER, Principios de Sistemas de Banco de Dados Distribuídos, 2001
NETWORK, Oracle Technology (Org.). Instalação. Disponível em:
<http://download.oracle.com/docs/cd/B25329_01/doc/install.102/b25144.pdf>. Acesso em:
17 fev. 2009.
ORACLE (Org.). Oracle. Disponível em:
<http://www.oracle.com/technologies/virtualization/docs/p2v-whitepaper.pdf>. Acesso em:
23 mar. 2009.
ORACLE (Org.). Clustering. Disponível em:
<http://www.oracle.com/technology/products/database/clustering/pdf/twp_rac10gr2.pdf>.
Acesso em: 02 abr. 2009.
53
ORACLE (Org.). Real Application Cluster. Disponível em: <http://www.oraclebase.com/articles/10g/OracleDB10gR2RACInstallationO.php>. Acesso em: 07 abr. 2009.
ORACLE (Org.). Clustering. Disponível em:
<http://www.oracle.com/technology/products/database/clustering/pdf/twpracwkldmgmt.pdf>.
Acesso em: 09 abr. 2009.
RACLE (Org.). Oracle. Disponível em:
<http://download.oracle.com/docs/pdf/B25801_01.pdf>. Acesso em: 03 abr. 2009.
ORACLE (Org.). Oracle. Disponível em:
<http://download.oracle.com/docs/pdf/B25784_01.pdf>. Acesso em: 20 abr. 2009.
ORACLE (Org.). Fail Safe. Disponível em:
<http://www.oracle.com/technology/software/tech/windows/failsafe/index.html>. Acesso em:
02 maio 2009.
ORACLE (Org.). Fail Safe. Disponível em:
<http://www.oracle.com/technology/documentation/failsafe.html>. Acesso em: 05 maio 2009.
ORACLE (Org.). Fail Safe. Disponível em:
<http://www.oracle.com/technology/tech/windows/failsafe/pdf/fscawp32.pdf>. Acesso em:
07 maio 2009.
CBLC. Tecnologia. Disponível em:
< http://www.cblc.com.br/cblc/ACBLC/Tecnologia.asp?tit=1>. Acesso em: 05 setembro
2009.