Artigos Banco de Dados Artigo SQL Magazine 69 - Administração do Oracle RAC
Por que eu devo ler este artigo:Administração de um banco de dados em Cluster simulado, baseado na arquitetura Oracle RAC. Este artigo é o terceiro de uma série sobre RAC. Para disponibilizar o acesso a um único banco de dados a partir de várias instâncias acomodadas em computadores diferentes.

Em casos onde a disponibilidade e o poder de processamento são características fundamentais do ambiente. Nas duas edições anteriores, instalamos um Cluster (Nota 1) simulado, em Oracle RAC 10gR2, utilizando Linux CentOS e ASM, rodando sobre VMware Server. Nesta terceira parte da série de artigos sobre Oracle RAC, iremos demonstrar como funciona a administração do Oracle RAC, e como a administração de um banco de dados em Cluster difere de uma instalação Single Instance.

Cluster:

Um Cluster, ou aglomerado de computadores, é formado por um conjunto de computadores que utiliza um tipo especial de sistema operacional classificado como sistema distribuído.

Muitas vezes é construído a partir de computadores convencionais (personal computers), os quais são ligados em rede e comunicam-se através do sistema, trabalhando como se fossem uma única máquina de grande porte.

Daemons e Logs

Para começar a conhecer como funciona o Oracle RAC e como administrá-lo, precisaremos primeiramente conhecer mais sobre os daemons (Nota 2) que compõe o Clusterware.

Daemon:

No Unix e outros sistemas operacionais computacionais multi-tarefa, um daemon é um programa de computador que roda em segundo plano, ao invés de rodar sob o comando direto de um usuário. Eles são usualmente iniciados como processos de segundo plano. Tipicamente daemons terminam com a letra “d”, por exemplo, syslogd, o daemon que gerencia o log do sistema, ou sshd, que manuseia a entrada de conexões SSH.

O serviço Clusterware é mantido por três daemons:

  • crsd: É o Cluster Ready Services, ou CRS;
  • cssd: Cluster Syncronization Services, ou CSS;
  • evmd: Event Manager, ou EVM.

O bom funcionamento do Cluster depende do bom funcionamento destes três daemons. E a primeira coisa que o DBA precisa aprender sobre estes daemons é onde ficam os logs de cada um, para que possa procurar informações quando se deparar com algum problema.

Os logs do Clusterware possuem as seguintes localizações:

  • Alert Log geral do Clusterware: $CRS_HOME/log//alert_.log
  • Log do CRS – Cluster Ready Services (crsd): $CRS_HOME/log//crsd
  • Log do CSS – Cluster Syncronization Services (cssd): $CRS_HOME/log//cssd
  • Log do EVM – Event Manager (evmd): $CRS_HOME/log//evmd
  • Log do VIP e ONS – Virtual IP e Oracle Notification Services: $CRS_HOME/log//racg
  • Log de OCR Applications: $CRS_HOME/log//client

Onde está , deve ser colocado o nome do nó, por exemplo, rac1.

Para iniciar a administração do Oracle RAC, recomendo ao leitor que abra cada um destes logs (com um editor do Linux, como o vi, ou para visualização apenas, com o comando cat), e observe as informações dele para se familiarizar com os aspectos internos do Clusterware. Por exemplo, veja o comando da Listagem 1 para verificar o log geral do Clusterware do nó rac1 (Listagem 2). Para melhor demonstrar o conteúdo do log, simulei uma ejeção do nó rac2, desligando-o.


vi /u01/app/oracle/product/10.2.0/crs/log/rac1/alertrac1.log
Listagem 1. Comando para verificar o conteúdo do log geral do Clusterware do nó RAC1

[cssd(8078)]CRS-1610:node rac2 (2) at 90% heartbeat fatal, 
eviction in 4.010 seconds
2009-07-14 13:40:06.076
[cssd(8078)]CRS-1610:node rac2 (2) at 90% heartbeat fatal, 
eviction in 3.020 seconds
2009-07-14 13:40:07.079
[cssd(8078)]CRS-1610:node rac2 (2) at 90% heartbeat fatal, 
eviction in 2.020 seconds
2009-07-14 13:40:08.080
[cssd(8078)]CRS-1610:node rac2 (2) at 90% heartbeat fatal, 
eviction in 1.020 seconds
2009-07-14 13:40:09.083
[cssd(8078)]CRS-1610:node rac2 (2) at 90% heartbeat fatal, 
eviction in 0.010 seconds
2009-07-14 13:41:45.286
[cssd(8078)]CRS-1607:CSSD evicting node rac2. 
Details in /u01/app/oracle/product/10.2.0/crs/log/rac1/cssd/ocssd.log.
[cssd(8078)]CRS-1601:CSSD Reconfiguration complete. Active nodes are rac1 .
2009-07-14 13:41:45.550
[crsd(7401)]CRS-1005:The OCR upgrade was completed. 
Version has changed from 169870336 to 169870336. 
Details in /u01/app/oracle/product/10.2.0/crs/log/rac1/crsd/crsd.log.
2009-07-14 13:42:07.193
[crsd(7401)]CRS-1204:Recovering CRS resources for node rac2.
[cssd(8078)]CRS-1601:CSSD Reconfiguration complete. 
Active nodes are rac1 rac2 .
2009-07-14 17:34:47.164
[cssd(7883)]CRS-1605:CSSD voting file is online: 
/dev/raw/raw2. Details in 
/u01/app/oracle/product/10.2.0/crs/log/rac1/cssd/ocssd.log.
[cssd(7883)]CRS-1601:CSSD Reconfiguration complete. 
Active nodes are rac1 .
2009-07-14 17:38:08.255
[evmd(7184)]CRS-1401:EVMD started on node rac1.
2009-07-14 17:38:08.408
[crsd(7338)]CRS-1005:The OCR upgrade was completed. 
Version has changed from 169870336 to 169870336. 
Details in /u01/app/oracle/product/10.2.0/crs/log/rac1/crsd/crsd.log.
2009-07-14 17:38:08.411
[crsd(7338)]CRS-1012:The OCR service started on node rac1.
2009-07-14 17:38:10.042
[crsd(7338)]CRS-1201:CRSD started on node rac1.
2009-07-14 17:38:21.425
Listagem 2. Conteúdo do log geral do Clusterware do nó rac1

Iniciando o Oracle RAC

O Clusterware, e os serviços gerenciados por ele - por exemplo, o próprio banco de dados – iniciam-se automaticamente no Linux na configuração padrão.

Para iniciar o Oracle RAC, basta iniciar as máquinas virtuais instaladas. Para verificar se os serviços foram iniciados corretamente, é utilizado o comando crs_stat do Clusterware. Este comando pode ser utilizado tanto com o usuário oracle, ou com o usuário root do Linux.

O comando crs_stat, embora seja apenas para mostrar informações, é de suma importância para se conhecer o funcionamento do Oracle RAC, e essencial para verificação de problemas. Por isso, iremos explicá-lo detalhadamente em primeiro lugar.

...

Quer ler esse conteúdo completo? Tenha acesso completo