funcionalidades do oracle rac - Blog da Newton

FUNCIONALIDADES DO ORACLE RAC
Eduardo Amaral Ferreira 1
Iremar Nunes de Lima 2
Resumo: Diversas empresas têm como requisito fundamental do negócio que os seus
sistemas de informação fiquem disponíveis 24 horas durante todos os dias da semana.
Dentre as soluções de informática para alta disponibilidade disponíveis no Sistema
Gerenciador de Banco de Dados Oracle está a tecnologia Oracle RAC (Oracle Real
Application Cluster) que visa oferecer sistemas de bancos de dados 100% disponíveis e
escaláveis para grandes organizações. Este artigo descreve esta tecnologia e faz uma
análise das vantagens e desvantagens desta solução.
Palavras-chave: Informática, Banco de Dados, Disponibilidade, Oracle RAC.
1
2
Especialista em Banco de Dados e Business Intelligence ([email protected]).
Mestre em Informática e professor do Centro Universitário Newton Paiva ([email protected]).
2
1. INTRODUÇÃO
Hoje em dia, a evolução dos sistemas de informação, que estão cada vez
mais integrados, exige que eles estejam sempre disponíveis, ou seja, que possam ser
acessados 24 horas por dia, 7 dias por semana (24/7) de qualquer lugar.
Com este acelerado crescimento da integração de sistemas, quanto mais
crítico for o negócio ao qual o sistema se aplica, mais disponível ele deve ser. Junto da
integração de sistemas, tem-se a necessidade de oferecer e receber informações sempre,
com consistência, confiabilidade, rapidez e onde for preciso.
Para se ter sistemas disponíveis o máximo possível, é preciso que se tenham
bancos de dados 100% disponíveis, suportando o funcionamento dos sistemas que o
acessam.
Dentre as soluções de alta disponibilidade encontradas no Sistema
Gerenciador de Banco de Dados Oracle, temos o Oracle RAC (Oracle Real Application
Cluster) que visa oferecer sistemas de bancos de dados 100% disponíveis e escaláveis.
Este artigo tem foco na apresentação das vantagens e desvantagens do uso
desta ferramenta oferecida pelo SGBD Oracle, com intuito de se implantar e suportar
um ambiente de banco de dados sempre disponível. É objetivo deste artigo, também, a
apresentação das funcionalidades do Oracle RAC (Oracle Real Application Cluster).
O restante do artigo está organizado da seguinte forma: a seção 2 apresenta
e detalha o Oracle RAC, descrevendo suas funcionalidades e componentes. Na seção 3 é
tratado o funcionamento do Oracle RAC com um detalhamento das vantagens e
desvantagens de se usar um ambiente Oracle RAC e por fim, na seção 4 é feita a
conclusão do trabalho.
3
2. ORACLE RAC
2.1 Computação Distribuída (Grid Computing)
A alta disponibilidade na computação, através do Oracle RAC, tem sua
fundamentação na computação distribuída, que, por sua vez é fundamentada na
distribuição de energia elétrica.
A distribuição de energia é feita de forma transparente aos consumidores de
todo o mundo: por exemplo, ao comprar um aparelho de TV novo, você chega em casa
e o liga na tomada elétrica, que é um terminal de toda a malha elétrica da região ou país.
Não importa onde e como aquela energia elétrica foi gerada, o que importa é que ela
está chegando até sua casa. Outro exemplo: se um fio de energia elétrica de casa for
desencapado e a ele ligado outro para instalação de uma tomada, cria-se um novo
terminal de energia elétrica, que tem ligação com a malha de toda a região, aumentandose os terminais de distribuição de energia. Esta energia pode ter sido gerada, por
exemplo, na Hidrelétrica de Furnas ou em Foz do Iguaçu e chega nas casas de todas as
cidades através das redes de transmissão.
Assim acontece com a computação distribuída: por exemplo, uma aplicação
usa recurso computacional de um hardware sem se preocupar de onde e como vem
aquele recurso, quando esta aplicação e/ou este hardware estão hospedados em um
ambiente cluster, ou seja, um ambiente com diversos recursos, mas que representam
apenas um, de maneira transparente para o usuário. É como acontece em um ambiente
RAC: existe um cluster de bancos de dados, com duas ou mais instâncias,
compartilhando de uma única base de dados, porém, ao ser acessada por uma aplicação
ou usuário, parece ser um único serviço de banco de dados.
4
Figura: Distribuição de energia elétrica
Fonte: VALLATH, 2006
Conforme FARIA (2005),
"a idéia central do Grid Computing (computação em grade / distribuída) é
oferecer a computação como um serviço público. Não se deve ter
preocupação com o local onde os dados residam ou qual computador
processe a solicitação. O usuário deve ser capaz de solicitar - e receberinformações ou recurso de computação no volume e freqüência que desejar.
Pode-se fazer uma analogia com o modo como funcionam os serviços
públicos elétricos: você não sabe onde está o gerador, nem como é a rede
elétrica. O que se deseja é eletricidade. E a consegue. O objetivo é tornar a
computação um serviço público e onipresente."
2.2 Clusterização
Segundo (Loney, 2005) um banco de dados de um ambiente RAC, é
altamente disponível e escalonável. A falha de um dos nós no cluster não afeta as
sessões de cliente nem a disponibilidade do próprio cluster até o último nó do cluster
falhar. Tal característica é fundamental para o funcionamento dos sistemas de hoje em
dia, que exigem total disponibilidade. Mas o que vem a ser um cluster? E um nó deste
cluster, o que é?
5
O conceito de cluster está presente na maioria das áreas da informática: na
área de redes tem um foco com uma certa especificidade, na área aplicativos tem suas
particularidades e na área de banco de dados, também, com suas próprias características.
De acordo com o conceito comum entre as áreas, ressalvadas as particularidades,
“um cluster pode ser definido como um sistema onde dois ou mais
computadores trabalham de maneira conjunta para realizar processamento
pesado” (Alecrim, 2004).
Em outras palavras, os computadores dividem as tarefas de processamento,
e trabalham como se fossem um único computador. Enfim, um ambiente cluster é
composto de vários computadores e/ou servidores interligados entre si, mas que aos
olhos do usuário, ou de suas aplicações, parece apenas um único servidor.
Existem diversos tipos de cluster (Alecrim, 2004):
•
Cluster para alta disponibilidade: um ambiente com este objetivo visa
maximizar o tempo de disponibilidade e melhora das condições de uso.
Clusters deste tipo indicam sistemas de missão crítica e quase nunca
param de funcionar, característica preconizada pelo Oracle RAC. Em
ambientes como este, existem ferramentas para proteção, detecção e
correção de falhas;
•
Cluster para balanceamento de carga: compreende a distribuição de
processamento. Demanda monitoração constante e artifícios de
redundância, sob pena de parada de todo o cluster;
•
Cluster Combo: Combina os sistemas de alta disponibilidade e de
balanceamento de carga.
No Oracle RAC temos a implementação de um Cluster Combo, ou seja, a
combinação entre alta disponibilidade e balanceamento de carga.
Assim, a função do Oracle RAC, é fazer isto funcionar de forma
transparente para o usuário, ou seja, em um ambiente Oracle RAC, tem-se diversos
6
servidores de bancos de dados, que receberão os acessos dos usuários e suas aplicações,
de acordo com sua disponibilidade, porém acessando uma única base de dados. Há
ainda uma forte característica, que consiste em manter o serviço totalmente disponível
caso algum dos servidores se torne indisponível. O Oracle RAC, cuidará de transmitir
aos servidores sobreviventes as consultas que estavam “rodando” no servidor que
falhou. Assim, um servidor sobrevivente, receberá as requisições oriundas do servidor
falho, sem que o usuário perceba a troca de máquina que processava sua requisição.
2.3 - O SGBD Oracle
2.3.1 – Estrutura de um Servidor Oracle
O Oracle Real Application Cluster pode ser considerado como uma
extensão de uma instância simples de um banco de dados Oracle. Tal afirmativa é
verdade, pois um Oracle RAC, nada mais é do que várias instâncias Oracle
interconectadas em cluster, porém com alguns componentes a mais do que a instância
normal, para manter seu funcionamento, acessando uma base de dados compartilhada.
Um servidor Oracle é composto de dois principais componentes, ambos
presentes na configuração cluster: (ARQUITETURA, 2009)
• Instância Oracle: Conjunto da SGA e dos processos de background;
• Database Oracle: Conjunto de 3 (três) tipos de arquivos: Datafiles,
Control Files e arquivos de Redo On-Line.
SGA entende-se como a área de memória alocada pelo Oracle no sistema
operacional, comportando seus processos e sub-áreas, por exemplo: (ARQUITETURA,
2009):
• Shared Pool: sub-área da SGA que armazena os comandos SQL e
PL/SQL;
7
• Buffer Cache: Os dados lidos e manipulados pelo Oracle são acessados
através desta área ou de memória, garantia de desempenho, pois acesso em
disco é mais lento do que em memória;
• Log Buffer: Armazena as alterações feitas no banco de dados em
memória, para que tais alterações não tenham de ser feitas diretamente no
disco;
• Java Pool: Bloco de memória da SGA que permite a execução de
comandos Java dentro do banco de dados;
• Large Pool: Responsável por armazenar informações que são e serão
utilizadas por uma série de funcionalidades e utilitários do Oracle;
Além das áreas citadas anteriormente, temos os processos de background
que são abertos por um servidor Oracle: (ARQUITETURA, 2009)
• DBWn: processo responsável por escrever em disco os dados
manipulados que estão na buffer cache;
• CKPT (Checkpoint): processo responsável por sinalizar o disparo do
processo DBWn, ou seja, processo que roda e de tempos em tempos, e
quando acionado, que verifica a existência de blocos a serem gravados, que,
se houver, dispara o processo responsável pela escrita daqueles blocos em
disco;
• SMON (System Monitor): Responsável pela recuperação da instância
durante sua inicialização, “limpar” os segmentos temporários e aglutinação
de espaço livre em tablespaces gerenciados pelo dicionário de dados;
• PMON (Process Monitor): Faz a gerência dos processos dos usuários;
• LGWR (Log Writer): Responsável por escrever o conteúdo do Log
Buffer nos arquivos de Redo Log;
8
E outros processos, além dos citados, mas que fogem um pouco do contexto
deste trabalho.
Sobre os arquivos que compõem o Data Base Oracle, tem-se o seguinte:
• Data Files: Arquivos de dados, onde ficam efetivamente armazenados os
dados do banco;
• Control File: Arquivos de controle do banco de dados. Armazena todas
as informações possíveis sobre a instância Oracle, além dos dados sobre a
estrutura física do Data Base Oracle;
• Redo Log: Armazenam os dados recém alterados que estavam na área de
memória Log Buffer;
Todos os conceitos apresentados anteriormente, formam os principais
componentes de um servidor Oracle.
A figura 2.1, mostra a estrutura de um servidor Oracle, sob configuração de
uma única instância.
Figura: 2.1: Ambiente Oracle instância simples
Fonte: própria
9
Além dos itens mostrados sobre a estrutura de memória do servidor Oracle,
temos a PGA, que é também uma área de memória, que contém dados e informações
sobre uma sessão de um determinado usuário.
A figura 2.2, mostra a estrutura de um servidor Oracle RAC, sob a
configuração de quatro instâncias.
Em um Servidor Oracle, com implementação de RAC, tem-se todos os
componentes mostrados anteriormente, com a adição de alguns poucos componentes
que implementam o cluster e as características de alta disponibilidade e facilidade de
aumento de escalabilidade oferecidas pelo RAC.
Um banco de dados RAC, permite que múltiplas instâncias Oracle, cada
uma com uma estrutura como a mostrada anteriormente, residam em diferentes
servidores de um cluster, compartilhando os arquivos do banco de dados, em outras
palavras, quando há a configuração do RAC, temos várias instâncias Oracle
compartilhando do mesmo Database Oracle, ou seja, do mesmo conjunto de arquivos,
Data File, Control File e Redo Logfile.
10
Figura 2.2: Ambiente RAC com 4 instâncias.
Fonte: VALLATH (2006)
Existem duas formas de funcionamento do Oracle RAC: (FONSECA, 2008)
• Em uma delas existe uma camada de software de cluster que opera nos
nós do cluster. Cada nó (node) pode monitorar um ou mais nós do cluster
(através da interconexão de rede). Se a máquina monitorada falhar, a(s)
sobrevivente(s) pode(m) apropriar-se da memória (SGA e PGA) e restaurar
as aplicações que estavam sendo executadas na máquina que falhou. A
máquina corrompida pode permanecer fora de operação, e os usuários e
cliente da aplicação perceberiam somente uma breve interrupção do serviço,
pelo menos enquanto ocorre a transferência das estruturas de memória e
11
seus conteúdos para a máquina sobrevivente, fato que ocorre muito
rapidamente.
• Uma outra forma de cluster do Oracle RAC, é a operação em clusters
paralelos, onde são usadas versões especiais de software. Cada máquina
opera o Oracle, e uma camada de software conduz o acesso ao disco
compartilhado do banco de dados. Cada máquina tem acesso total a todos os
discos do banco de dados.
O banco de dados deve ser localizado em um grupo de disco compartilhado
onde todos os servidores do cluster possam acessar o banco de dados. Os servidores se
comunicam com os discos compartilhados via rede.
2.3.2 – Oracle Clusterware
O conjunto de software que faz o gerenciamento do cluster é chamado de
Oracle Clusterware. Oracle Clusterware, que no decorrer do texto será chamado de
OCR, é uma nova característica, que surgiu no Oracle 10g, que provê interface cluster
padrão em todas as plataformas, além de prover operações de alta disponibilidade que
não estavam disponíveis nas versões anteriores do Oracle. Existem diversos outros
softwares de gerência de cluster, mas o da Oracle é o mais indicado para RAC
(VALLATH, 2006).
Ele é o componente essencial para o funcionamento do Oracle RAC. Pode
trabalhar só, ou em conjunto com outros softwares deste tipo, de terceiros, como da HP
ou da Sun. Ele deve ser instalado em cada nó do cluster do ambiente RAC. A
combinação entre ele e o Oracle RAC contribui para o alto nível de disponibilidade e
flexibilidade. Ele deve ser o primeiro componente instalado quando se planeja
configurar um RAC.
12
O OCR é o responsável pelo processo de realocação dos componentes de
uma instância e pelo controle da reedição destes em uma nova instância, além de
recuperar parte das transações que falharam em algum nó (node).
O OCR, que também pode ser chamado de CRS (Cluster Ready Services) é
composto por 3 (três) principais componentes, que se manifestam como daemons
(processos) executados no inittab do linux ou como um serviço, em um ambiente
windows.(HART, 2004)
Os daemons componentes do Oracle Clusterware são: (HART, 2004):
• CSS – Cluster Synchronization Services: é o principal componente para
existência de disponibilidade de recursos no ambiente RAC. É base para
comunicação entre processos em um ambiente cluster (RAC). O CSS
também pode ser usado em instâncias simples de maneira a permitir a
interação entre instâncias ASM e o banco de dados. Ele provê uma série de
serviços, como informação em tempo real de cada nó (node) e instância que
compõem o RAC em um determinado momento, além de informações
estatísticas, como os nomes e números dos nós, que podem ser alterados
quando são removidos ou adicionados. O CSS também controla
funcionalidade de bloqueio, a nível de registro dentro do cluster. Este
daemon também é responsável pela checagem constante da permanência de
um nó em um cluster, além da monitoração do voting disk em busca de
falhas. Voting Disk, é um arquivo que contém e gerencia informações sobre
todos os nós membros de um RAC, além de gerenciar o cluster e manter o
RAC. É também um importante componente do OCR;
• CRS – Cluster Ready Services: Responsável por executar as operações
de recuperação de falhas e manter a disponibilidade dos recursos em um
ambiente RAC. É também responsável pela transferência de um serviço /
13
recurso de um nó para outro em caso de falha de um deles, além de registrar
os eventos ocorridos no ambiente no OCR Oracle Cluster Registry, arquivo
que contém os registros de todos os eventos e lista de nós em um cluster;
• EVM – Event Manager: Processo responsável por armazenar os logs
sobre cada evento dos daemons (processos) do RAC.
Um outro importante componente presente no OCR é o VIP: Virtual Ip
Address, que tem uma grande vantagem e importante característica do Oracle RAC, pois
proporciona um menor failover (tempo decorrido entre a detecção e correção de uma
falha) em eventos de falha de um nó do cluster.
Com o VIP, cada nó não terá apenas um endereço ip estático, mas terá
também um virtual que é associado a cada nó. A maneira de garantir este failover
menor é fazendo com que o listener de cada nó escute o VIP, pois tem uma resposta
muito mais rápida do que o ip normal, assim, ao tentar se conectar em um ip virtual
(VIP) onde o nó está inativo, a conexão já é transmitida para outro nó, e para outro, caso
o segundo esteja inativo, e assim por diante, caso não tenha resposta imediata.
Abaixo um exemplo de configuração de um arquivo tnsnames.ora, que
mostra uma lista de ip’s alternativos, possibilitando a busca por nós disponíveis.
GRID =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rmscvip1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rmscvip2)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = grid)
)
)
14
3. FUNCIONAMENTO DO ORACLE RAC
O Oracle Real Application Cluster (Oracle RAC) é uma option
(característica adicional) do SGBD Oracle que permite alta disponibilidade e
escalabilidade dos nós em um ambiente cluster. Trata-se de duas ou mais instâncias
Oracle compartilhando de uma única base de dados, em outras palavras, um banco de
dados clusterizado (ORACLE REAL APPLICATION CLUSTER – DATA SHEET,
2005).
No ambiente RAC, há a configuração de um cluster ativo / ativo, ou seja,
todos os nós do cluster acessam os mesmos dados simultaneamente. Existem, nesta
configuração, duas ou mais instâncias que respondem como um único serviço para as
aplicações e/ou usuários que a acessam. Quando uma aplicação ou usuário se conecta ao
banco de dados, existe uma camada de software (OCR) que envia sua sessão para a
instância mais disponível dentro do cluster, caracterizando o balanceamento de carga.
Esta sessão compartilha dos blocos “sujos” (blocos de dados alterados que
ainda não foram escritos em disco, ou seja, ainda estão na memória) do sistema através
do Cache Fusion, que mantém, através de uma interconexão privada, o
compartilhamento destes blocos entre as instâncias, evitando, assim, acesso a disco por
qualquer uma das instâncias. Em outras palavras, uma instância pode precisar acessar
um bloco que foi há poucos instantes alterado por outra instância, e este ainda está na
memória. Através do Cache Fusion esta instância acessará este bloco, com o valor atual,
ou seja, com a alteração feita pela outra instância. No RAC não existe fusão de SGA, ou
seja, cada instância tem sua própria SGA, porém com seus “blocos sujos” visíveis a
todas as instâncias, funcionalidade esta provida pelo Cache Fusion (FONSECA, 2008).
Caso alguma instância se torne inativa, os processos de background que
ficam “vigiando” todo o cluster, cuidarão de não enviar uma nova conexão para este nó
inativo e transferirá todas as sessões que residiam naquele para um ponto do cluster que
15
esteja ainda ativo. É muito importante ressaltar que os comandos e processos de uma
sessão que são transferidos são apenas de consultas, ou seja, transações que estejam
pendentes de commit (confirmação de gravação) lançarão mensagem de erro que deve
ser tratada, e sofrerá rollback (cancelamento de alteração).
Aquele nó que apresentou instabilidade pode sofrer manutenção e voltar à
ativa, passando a receber novas conexões a partir do momento que os processos
responsáveis por “vigiar” o ambiente o identificarem como ativo. Vale lembrar que as
sessões que estavam neste nó não voltam para ele, permanecem na instância para qual
foram transferidas, ele receberá apenas novas sessões, que provavelmente serão
direcionadas a ele, pois acabou de ingressar no cluster, logo está, teoricamente, mais
disponível que os demais nós do ambiente (DYKE, 2006).
Desta forma o Oracle RAC, garante baixo e transparente failover, pois as
sessões existentes em uma instância falha ressurgem em uma outra instância, podendo
acessar os mesmos dados que acessava na instância falha. Garante também capacidade
de escalabilidade, permitindo a adição e/ou remoção de nós no ambiente sem a parada
dos serviços.
Então, um DBA pode prestar manutenção em um ambiente de banco de
dados sem prejudicar o acesso aos dados, como por exemplo, aplicação de pacthes de
segurança e atualização, bem como no sistema operacional do nó hospedeiro de uma
instância.
Um fato importante de se ressaltar no Oracle RAC é as suas sutis diferenças
diante de um banco de dados de uma única instância. Em tese, um RAC, é um banco de
dados simples, porém com mais instâncias, e com alguns componentes a mais.
Componentes estes que merecem atenção são os processos de background específicos
de um ambiente RAC, que não existem em uma configuração simples, são eles
(FONSECA, 2008):
16
• LMS: Conhecido como Global Cache Service. O RAC pode ter até 10
processos deste, variando de acordo com a quantidade de mensagens que
trafegam entre os nós. As suas tarefas são: manusear as interrupções dos
blocos de dados de uma instância remota para o Global Cache Service
(Cache Fusion); controlar as requisições de recursos e as operações de
chamadas realizadas entre as instâncias RAC durante a utilização dos
recursos que são compartilhados; construção de uma lista de elementos que
são afetados pelo lock e validar estes elementos durante uma operação de
recuperação; manusear o mecanismo global de detecção de lock e deadlock
e monitorar a duração de um lock disparando o timeout quando necessário;
ele também controla a requisição dos dados que são acessados entre os nós
de um cluster. No ambiente RAC, cada bloco é associado a uma instância
específica. É este o processo que garante que cada instância irá fazer uma
leitura consistente dos blocos, e uma instância por vez;
• LMON: Sua função é monitorar todo o cluster, as filas globais de
requisição e o uso dos recursos da memória. O LMON controla as instâncias
e a expiração dos processos. Participa do processo de recuperação da
instância, em conjunto com o processo Global Cache Service. É ele que
controla o processo LMD e as regiões de memória usadas. É similar ao
processo PMON, em um banco de dados de única instância;
• LMD: É um processo agente de lock sobre os recursos que estão
armazenados na fila de requisição. Atende às solicitações do LMSn para
controlar o acesso global da instância na solicitação remota sobre a fila de
requisição. Também controla e detecta deadlock’s;
17
• LCK0: Executa o gerenciamento global da fila de requisição como
também da transmissão entre as instâncias. Ele manipula todos os recursos
de transferência que não requerem o uso do Cache Fusion;
• DIAG: É um processo daemon responsável por monitorar e fazer o
diagnóstico dos heartbeats (batimentos cardíacos) de cada instância,
verificando quais instâncias RAC estão rodando no momento. Ele também
captura os dados de um processo de uma instância falha. Existe um processo
deste em cada instância , e não pode desativado ou removido. Se por acaso o
processo DIAG da instância falhar, automaticamente outro é iniciado por
um outro processo de background.
3.1 Vantagens e desvantagens do Oracle RAC
Dentre as
vantagens
do
Oracle RAC
destacam-se as
seguintes
(VALLATH,2006):
• Alta disponibilidade: Na ocorrência de falha de um nó do cluster, os
outros nós podem continuar a operar e a disponibilidade do banco de dados
não será afetada;
• Confiabilidade: Devido ao uso de cluster no ambiente RAC, e com um
DBA bom prestando manutenção ao ambiente, tem-se confiabilidade, pois o
banco de dados se mantém funcionando até que caia o último nó do cluster,
e enquanto isso, o corpo técnico pode restabelecer o funcionamento daquele
que falhou;
• Recuperabilidade: Facilidade de recuperação em um nó falho, pois o
sistema não tem de parar para se restabelecer a atividade de um nó falho;
• Detecção de erros e manutenção facilitada: As bases de dados múltiplas
do legado podem ser consolidadas em uma única base de dados de RAC que
reduz a complexidade da gerência e que introduz economias de escala.
18
• Continuidade de operações: Garantida pela alta disponibilidade;
• Escalabilidade: Múltiplos nós permitem escalar bancos de dados
clusterizados além do limite de uma instância simples, ou seja, em um
ambiente RAC, pode aumentar e/ou diminuir o número de nós do cluster;
• Diminuição de TCO (Custo Total de Propriedade): Redução dos gastos
com compras de hardware, pois pode-se comprar n máquinas, de menor
porte, logo mais baratas. Além da redução do custo com manutenção e
suporte (PORTILHO, 2009);
Dentre as desvantagens têm-se as seguintes:
• Alto custo de licenciamento, pois para cada instância componente do
cluster é necessário uma licença para cada processador. Assim, se houver
um RAC com dois nós e cada nó deste tiver dois processadores, serão
necessárias 4 licenças de uso do SGBD (PORTILHO, 2009).
• Conhecimento, por parte do DBA, do ambiente de sistema operacional. O
DBA precisa ter um bom conhecimento de SO para facilitar a montagem e
manutenção do RAC.
Além de todas estas desvantagens, pode-se ter um grande problema de
desempenho em casos de catástrofe, ou seja, de acordo com o funcionamento do RAC,
quando um nó falha, uma instância sobrevivente recebe as sessões oriundas daquele e
outras novas. Caso os nós sobreviventes já estejam com uma carga um tanto alta, podem
não suportar a nova carga proveniente do nó inativo, e assim falhar também, daí suas
sessões, incluindo as sessões que herdou daquele nó, vão para um outro sobrevivente,
que teria de suportar sua carga de trabalho e a dos outros dois, causando um efeito
dominó, podendo chegar a inatividade de todo o cluster, caso não se restabeleça a
atividade dos dois primeiros. De acordo com (FONSECA, 2008) ao planejar um
ambiente Oracle RAC, deve-se estimar a utilização de CPU para consultas pesadas.
19
Durante o período de alta utilização de um servidor / instância do ambiente, a CPU não
deve passar de 70%. Deve-se atentar para o fato de se a instância sobrevivente tem
capacidade para suportar toda a carga de trabalho no caso de falha de uma determinada
instância do cluster.
3.2 Ferramentas para manutenção do RAC
Existem diversas ferramentas para o DBA administrar o Oracle RAC, dentre
elas destacam-se as seguintes:
• CVU (Cluster Verification Utility): Seu objetivo é verificar se o cluster
está configurado corretamente antes de se tentar instalar o Oracle
Clusterware ou o próprio software de gerência de banco de dados. Ele faz
uma leitura de checagem e relata dicas / conselhos se encontrar algum
problema. O DBA pode ou não seguir tais dicas, sob pena de encontrar
problemas na instalação de algum componente (DYKE, 2006). Com o CVU,
podem-se passar vários parâmetros para checagens diversas:
o
nodereach: verifica se toda a configuração de rede está correta e se todos
os nós podem ser alcançados via rede;
o nodecon: checa se a configuração de rede está correta, checa inclusive o
VIP (ip virtual);
o cfs: verifica a integridade do sistema de arquivos do cluster;
o ssa: checa se o storage compartilhado está acessível;
o space: verifica se o mínimo de espaço em disco requerido é atendido;
o sys: checa se os requisitos de sistema foram atingidos;
o clu: Verifica a integridade do cluster;
o clumgr: permite a verifica da integridade do gerenciador de cluster;
20
o ocr: analisa a integridade do OCR (Oracle Cluster Registry);
o crs: verificação de integridade do Oracle Clusterware;
o nodeapp: checa a existência de aplicação nos nós;
o admprv: verifica se os privilégios administrativos foram devidamente
delegados;
o peer: faz a verificação da configuração corrente de um nó com os
demais;
• CVUQDISK: Uma variação do CVU, que cuida de fazer uma checagem
dos discos que compõem o storage (área de armazenamento) do RAC.
Além das ferramentas de análise do cluster, que faz as verificações
necessárias após o processo de definição/instalação do cluster, existem as ferramentas
para gestão do RAC, incluindo a manutenção, inclusão ou remoção dos nós. É
importante ressaltar que para desativar uma instância no RAC, é essencial que existam
outras ativas e que o Oracle Clusterware esteja rodando nelas. Desligar um nó do RAC
não interfere no funcionamento do ambiente, o que pode ocorrer é um certo impacto nas
instâncias restantes, pois receberão o processamento que havia no nó ora desativado. As
ferramentas que proporcionam tais funcionalidades são:
• EM (Enterprise Manager): Nas versões superiores a 10.1 do Software de
banco de dados Oracle, o Enterprise Manager, que neste texto chamaremos
de EM, é uma ferramenta baseada na plataforma web. Existem duas versões
do EM nas edições 10.1 e superiores do Oracle: Database Control e Grid
Control. Com o Database Control pode-se gerenciar um único banco de
dados Oracle RAC com suas instâncias, listeners e nós. Já com o Grid
Control, consegue-se gerenciar vários bancos de dados Oracle RAC, bem
como suas instâncias, listeners, servidores de aplicação, servidores web, e
21
aplicações web. Com ele também é possível criar um banco de dados de
espera (stand by) Data Guard. (VALLATH, 2006)
• SRVCTL (Server Control Utility): É uma ferramenta de linha comando,
que executa muitas das tarefas feitas pelo EM. Nas versões superiores a 10.1
do Oracle, o SRVCTL armazena informações sobre configuração e status do
OCR (Oracle Cluster Registry), estas informações são utilizadas por outras
várias ferramentas Oracle, incluindo o EM. Pode-se usar o SRVCTL para
iniciar, parar e obter o status corrente de um banco de dados, de suas
instâncias e listeners. É usado também para adicionar e deletar informações
de instâncias e bancos de dados, além de mover uma instância de um nó
para outro por exemplo. Também é possível “setar” variáveis de ambiente,
seja no nível da instância ou do banco de dados. Através desta ferramenta é
possível controlar seis tipos de componentes: database, instância, serviços,
aplicações dos nós (que incluem: GSD – Global Services Daemon, Oracle
Notification Service – ONS, Virtual Ip – VIP , Oracle Net Listener, que
também pode ser administrado pela ferramenta LSNRCTL), ASM e listener.
Dentre as funções do SRVCTL, destacam-se as seguintes com relação a
gerência do banco de dados:
• Inicializar um banco de dados, parar um banco de dados; checar a
configuração de um banco de dados, checar o status de um banco de dados,
adição de configurações a um banco de dados, modificar as configurações
existentes de um banco de dados, habilitar e/ou desabilitar um banco de
dados, além de outras várias funcionalidades.
Com relação às funcionalidades do SRVCTL para gerência das instâncias de
um Oracle RAC, têm-se as seguintes:
22
• Iniciar ou parar uma instância, checar o status desta, adicionar uma nova,
modificar ou remover uma instância, desabilitar e/ou habilitar uma
instância. Abaixo alguns exemplos de comandos que podem ser utilizados
com o SRVCTl:
srvctl start instance -d RAC -i RAC1;
srvctl stop instance -d RAC -i RAC3;
srvctl status instance -d RAC -i RAC1;
Sobre as funções do SRVCTL para manutenção das aplicações nos nós, as
seguintes são as mais relevantes: Inicialização e paralização das aplicações nos nós,
checagem de status e configuração além de adição ou remoção destas.
Além das duas ferramentas para manutenção de um Oracle RAC descritas
anteriormente, tem uma terceira, que além de permitir a execução de várias tarefas
administrativas do ambiente RAC, permite a pesquisa e análise de estatísticas e
informações sobre todo o ambiente e, possibilita a alteração dos parâmetros de
inicialização de todas as instâncias do ambiente RAC, trata-se do SQLPLUS. Que
também a exemplo do SRVCTL, é uma ferramenta de linha de comando. (VALLATH,
2006). Através desta ferramenta, faz-se a gerência do ambiente RAC, incluindo a
alteração de parâmetros de inicialização do ambiente. É importante ressaltar que, ao
alterar algum parâmetro de inicialização, é preciso especificar qual será o escopo de
instância que aquele parâmetro terá validade, ou seja, além de especificar o escopo do
parâmetro, se memória, spfile ou ambos (both) é necessário de que se especifique a qual
SID (instância) o novo parâmetro passa a vigorar.
ALTER SYSTEM SET pga_aggregate_target = 200M SID = 'RACl';
Além das funcionalidades descritas anteriormente do SQLPLUS, pode-se
fazer uso das views dinâmicas de desempenho oferecidas pelo SGBD Oracle, que em
casos de um ambiente RAC, têm-se algumas que ajudam a analisar o desempenho e
23
configuração deste. A seguir alguns exemplos que mostram as informações sobre a
atividade balanceamento de carga no RAC:
• GV$SERVICES: Mostra dados sobre quais serviços de banco de dados
estão configurados atualmente;
• GV$ACTIVE_SERVICES: Exibe dados sobre quais serviços estão em
execução no momento;
• GV$SERVICE_WAIT_CLASS: Resume o tempo de espera por classe de
cada serviço do banco de dados;
Os próximos comandos e views, exemplificam a monitoração de
desempenho e informações sobre as configurações das instâncias e no RAC:
• GV$SYSTEM_EVENT,
• GV$SESSION_EVENT,
• GV$SESSION_WAIT,
• GV$SESSION,
• GV$LOCK,
• GV$SQL,
• GV$SQLTEXT,
• GV$SQLAREA.
Existe também uma ferramenta para administração do Clusterware que é a
CRSCTL (Cluster Ready Services Control). Ela provê a gerência do Oracle
Clusterware, permitindo a inicialização e paralização deste, bem como a administração
dos daemons CSS, CRSD e EVMD, já mencionados neste artigo.
4. CONCLUSÃO
O Oracle RAC, pode ser uma tecnologia complexa e custosa de se
implementar. Requer um bom conhecimento para planejar, instalar, configurar, fazer
24
ajustes de desempenho, suportar e manter. O custo das licenças necessárias para sua
implementação é significativamente maior que o custo para implantação de uma
instância simples.
A maioria das empresas que implantam o Oracle RAC, o fazem por precisar
e ter garantias de que alcançarão maior disponibilidade, escalabilidade ou a combinação
de ambos. Com o RAC têm-se ambientes mais disponíveis, com isso mais segurança.
Além disso, mais facilidade de administração das bases de dados da empresa e a
redução do custo de propriedade, ou seja, gasta-se menos dinheiro com equipamentos já
que se pode comprar mais máquinas, de menor poder de processamento e clusterizá-las
no ambiente RAC, perfazendo o balanceamento de carga, que pode ser configurado, por
exemplo, por requisição ou por disponibilidade, há uma série de configurações
possíveis.
Em síntese, para se decidir pelo RAC, é preciso analisar, além de toda a
viabilidade técnica, todo ambiente dos negócios da empresa, de maneira a identificar a
real necessidade de implantação de um ambiente com as características disponibilizadas
pelo Oracle RAC. Em termos de alta disponibilidade em banco de dados, e
principalmente com o Oracle, o mais falado hoje em dia nas grandes corporações é o
Oracle RAC, porém existem outras tecnologias, como Oracle Data Guard, o Oracle
FlashBack, e outras várias técnicas, cada uma com suas particularidades, desvantagens e
vantagens. Qual delas é a melhor, depende de um estudo no ambiente onde será
implantado, podendo inclusive implantar todas elas, garantindo um ambiente muito
seguro e com forte veio de disponibilidade, escalabilidade.
25
REFERÊNCIAS BIBLIOGRÁFICAS
ALECRIM, Emerson. Cluster: principais conceitos.
<http://www.infowester.com/cluster.php> Acesso em 20 junho 2009.
ARQUITETURA e Administração do BD Oracle. Synos Education Center. 2009.
DYKE, Julian; SHAW, Steve. Pro Oracle Database 10g RAC on Linux: Installation,
Administration, and Performance. Apress, 795p.
FARIA, Elizabeth. Grid e Oracle 10g. Oracle Corporation, 2005.
FONSECA, Luiz Cláudio. DBA RAC 11g Arquitetura: Instalação, Administração e
Performance. Ciência Moderna, 2008, 196p.
HART, Matthew; JESSE, Scott. High Availability with RAC, Flashback & Data
Guard. Oracle Press, 2004, 421p.
LONEY, Kevin; BRYLA, Bob. Oracle Data Base 10g – DBA Handbook. Oracle
Press, 2005, 757p.
LONEY, Kevin. Oracle Database 10g - The Complete Reference. Oracle Press, 2004,
1369p.
ORACLE REAL APPLICATION CLUSTER – DATA SHEET, 2005
<http://www.oracle.com/technology/products/database/clustering/index.html> Acesso:
20 junho 2009.
PORTILHO, Ricardo. Instalação de Oracle RAC em Linux com VMWare.
<http://profissionaloracle.com.br/blogs/portilho/2009/02/18/instalacao-de-oracle-racem-linux-com-vmware-parte-i/> Acesso: 22 junho 2009.
VALLATH, Murali. Oracle 10g RAC Grid, Services e Clustering. Elsevier Digital
Press, 2006, 670p.