funcionalidades do oracle rac - Blog da Newton
Propaganda
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.
