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 Especialista em Banco de Dados e Business Intelligence (eduamaral.ferreira@gmail.com). 2 Mestre em Informática e professor do Centro Universitário Newton Paiva (iremar.prof@uol.com.br).

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, aumentando-

se 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 receber- informaçõ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-rac-em-linux-com-vmware-parte-i/> Acesso: 22 junho 2009. VALLATH, Murali. Oracle 10g RAC Grid, Services e Clustering. Elsevier Digital Press, 2006, 670p.