Tag Archive: ocr

Olá pessoal!

Hoje veremos mais detalhes sobre a ferramenta oifcfg.

Ela é utilizada para definir quais serão as interfaces de rede pública e privada no Clusterware. Além disso, ela é utilizada quando é necessário alterar a faixa de endereço IP e subnet de uma rede específica (necessário quando há mudança na faixa de IP’s utilizada pela corporação).

Características do oifcfg:

  • Pode ser utilizado com o usuário oracle;
  • A partir de qualquer nó, controla todos;
  • Ferramenta para administração das interfaces de rede utilizadas no Clusterware:
    • Pública (VIP);
    • Privada (InterConnect).
  • Caso uma interface de rede queime, essa ferramenta será utilizada para substituir a interface de rede no OCR;
  • Útil para alterar a Subnet de uma interface de rede.

Como citado, as alterações efetuadas através do oifcfg são armazenadas no OCR.

Para verificar quais são as interfaces de rede e seu devido uso no Clusterware:

[oracle@mvrac1 oracle]$ oifcfg getif
eth0  172.23.10.0  global  public
eth1  10.0.0.0  global  cluster_interconnect

Para reconfigurar uma placa de rede para outra faixa de IP, primeiro, é necessário excluir as configurações desta placa:

[oracle@mvrac1 oracle]$ oifcfg delif -global eth0

A opção -global significa que esta configuração deverá ser válida para todos os nós, ou seja, a placa eth0 deverá ser excluída da configuração do Clusterware em todos os nós. Esta opção é utilizada pois também pode ser feita a configuração de uma interface de rede em apenas um nó, com a opção…

Vamos supor que ambas as interfaces serão excluídas pois outras serão configuradas. Vamos agora excluir a configuração da placa eth1:

[oracle@mvrac1 oracle]$ oifcfg delif -global eth1

Agora devemos configurar as placas desejadas:

[oracle@mvrac1 oracle]$ oifcfg setif -global eth3/192.168.111.0:public
[oracle@mvrac1 oracle]$ oifcfg setif -global eth4/10.0.0.0:cluster_interconnect

Lembrando que para alterar o endereço de InterConnect também é necessário alterar a informação no arquivo /etc/hosts e no arquivo de configuração da placa de rede em /etc/sysconfig/network-scripts/ifcfg-ethX.

Para o VIP, além disso, também é necessário alterar o endereço IP no OCR através do srvctl, conforme citado no post Oracle Clusterware – Rotinas Administrativas – Parte 3 – srvctl.

Um abraço!

Vinicius







----------------------------------------------------------------------------

Copyright:

Este site e todo o conteúdo aqui publicado pertence ao Blog ViniciusDBA.com.br e possui seus respectivos direitos autorais.

O Conteúdo desde Blog não deve ser publicado, distribuído ou transmitido sem autorização prévia de seu autor.

Oracle e seus produtos são marcas registradas da Oracle Corporation® (http://www.oracle.com) Todo o material aqui encontrado é mantido sem ajuda financeira e mantém como propriedade de seu fundador/escritor.

Disclaimer:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
As opiniões publicadas neste blog (http://www.viniciusdba.com.br) são pessoais e não necessariamente representam a visão da Oracle.


Toda informação aqui encontrado é oferecida através do uso do bom senso e boa fé do seus leitores e não deve ser considerada como material oficial da Oracle Corporation (http://www.oracle.com).

O Autor (e contribuidores) não considera as informações aqui como oficiais e/ou permitidas para redistribuição. Ao utilizar o site http://www.viniciusdba.com.br o leitor deve entender e aceitar que as informações aqui encontradas são de direitos autorais do Autor e contribuidores.

O blog http://www.viniciusdba.com.br não faz revisão de conteúdo publicado por outros como comentários bem como posts em grupo de usuários ou portais.

Seus autores não necessariamente concordam ou apoiam opiniões de seus leitores.

ESTE É UM SITE INDEPENDENTE E NÃO REPRESENTA A ORACLE CORPORATION® (http://www.oracle.com) EM NENHUM SENTIDO. AS OPINIÕES E CONTEÚDOS AQUI ENCONTRADOS NÃO POSSUEM RELAÇÃO COM A VISÃO DA ORACLE CORPORATION®. ESTE SITE NÃO POSSUI NENHUM APOIO OU PATROCINIO DA ORACLE CORPORATION®.

Olá pessoal!

Hoje veremos sobre as ferramentas de gerenciamento do OCR.

Características do ocrcheck:

  • Pode ser executado com o usuário root ou oracle;
  • Exibe informações a respeito do OCR (tamanho, versão, status, localização;
  • Um log é gerado em $ORA_CRS_HOME/log/<hostname>/client/ocrcheck_<pid>.log

Exemplo de uso, ocrcheck:

[root@mvrac1 oracle]# ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          2
         Total space (kbytes)     :     256788
         Used space (kbytes)      :       4624
         Available space (kbytes) :     252164
         ID                       :  382969207
         Device/File Name         :  /dev/ocr1
                                    Device/File integrity check succeeded
         Device/File Name         :  /dev/ocr2
                                    Device/File integrity check succeeded

         Cluster registry integrity check succeeded

Como podem observar, o ocrcheck é utilizado para verificar a integridade do OCR.

Conteúdo do log gerado:

Oracle Database 10g CRS Release 10.2.0.4.0 Production Copyright 1996, 2008 Oracle.  All rights reserved.
2010-08-16 10:36:03.160: [OCRCHECK][6617296]ocrcheck starts...
2010-08-16 10:36:21.884: [OCRCHECK][6617296]protchcheck: OCR status : total = [256788], used = [4624], avail = [252164]

O ocrcheck pode ser utilizado caso haja algum problema no Clusterware para verificar a integridade do OCR.

Características do ocrdump:

  • Faz o dump do OCR;
  • Deve ser utilizado com o usuário root;
  • Usado para consultar sobre os registros do OCR em caso de perda e necessidade de novo registro (este, manual);
  • Suporte Oracle pode solicitar para tratar algum problema do Clusterware.

Exemplo de uso, ocrdump:

[root@mvrac1 oracle]# ocrdump /root/ocrdump.txt

Início do arquivo texto gerado:

08/17/2010 20:40:15
/u01/app/oracle/product/10.2.0/crs/bin/ocrdump.bin /root/ocrdump.txt

[SYSTEM]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : roo
t, GROUP_NAME : root}

[SYSTEM.css]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : roo
t, GROUP_NAME : root}

[SYSTEM.css.interfaces]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_CREATE_SUB_KEY, OTHER_PERMISSION : PROCR_READ, USER_
NAME : oracle, GROUP_NAME : oinstall}

[SYSTEM.css.interfaces.global]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_READ, USER_NAME
 : oracle, GROUP_NAME : oinstall}

Mais um trecho do arquivo gerado:

[DATABASE.DATABASES.mvdb.SPFILE]
ORATEXT : +DG_DADOS/mvdb/spfilemvdb.ora
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_WRITE, OTHER_PERMISSION : PROCR_READ, USER_NAME : oracle, GROUP_NAME : dba}

Características do ocrconfig:

  • Ferramenta de configuração do OCR;
  • Deve ser utilizado com o usuário root;
  • Permite realizar backup lógico do OCR (-export -s online);
  • Permite importar o backup lógico;
  • Permite fazer upgrade/downgrade do OCR;
  • Exibe qual é o diretório de backup automático do OCR e os últimos backups automáticos (-showbackup);
  • Altera o local de backup automático (-backuploc );
  • Substitui o local do OCR (-replace ocr | ocrmirror );
  • Sobrescreve a configuração do OCR (-overwrite);
  • Repara o OCR (-repair ocr | ocrmirror );
  • Um log é gerado em $ORA_CRS_HOME/log/<hostname>/client/ocrconfig_<pid>.log

O Clusterware gera um backup automático do OCR a cada 4 horas, conforme citado no post Oracle Clusterware – Arquitetura – Parte 2 – Principais Arquivos: Voting Disk e OCR.

Vamos exibir os backups automáticos:

[root@mvrac1 ~]# ocrconfig -showbackup

mvrac2     2010/08/16 08:16:47     /u01/app/oracle/product/10.2.0/crs/cdata/crs_mv

mvrac2     2010/08/16 02:53:24     /u01/app/oracle/product/10.2.0/crs/cdata/crs_mv

mvrac1     2010/08/11 23:11:57     /u01/app/oracle/product/10.2.0/crs/cdata/crs_mv

mvrac2     2010/08/16 02:53:24     /u01/app/oracle/product/10.2.0/crs/cdata/crs_mv

mvrac1     2010/08/08 02:24:35     /u01/app/oracle/product/10.2.0/crs/cdata/crs_mv

Como pudemos observar, os últimos backups estão no nó MVRAC2.

Verificando os arquivos de backup existentes no diretório:

[root@mvrac2 ~]# ls -ltr /u01/app/oracle/product/10.2.0/crs/cdata/crs_mv
total 28536
-rw-r--r-- 1 root root 4837376 Apr 26 00:19 week.ocr
-rw-r--r-- 1 root root 4861952 Jul 15 03:53 backup02.ocr
-rw-r--r-- 1 root root 4861952 Aug 16 02:53 backup01.ocr
-rw-r--r-- 1 root root 4861952 Aug 16 02:53 day.ocr
-rw-r--r-- 1 root root 4861952 Aug 16 08:16 week_.ocr
-rw-r--r-- 1 root root 4861952 Aug 16 08:16 backup00.ocr

Os backups estão ali.

Vamos fazer uma brincadeira?

Vamos corromper 1 OCR (como root):

[root@mvrac1 ~]# dd if=/dev/zero of=/dev/ocr1
dd: writing to `/dev/ocr1': No space left on device
514018+0 records in
514017+0 records out
263176704 bytes (263 MB) copied, 8.42927 seconds, 31.2 MB/s

Vamos agora verificar a integridade do OCR com o ocrcheck:

[root@mvrac1 ~]# ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          2
         Total space (kbytes)     :     256788
         Used space (kbytes)      :       4624
         Available space (kbytes) :     252164
         ID                       :  382969207
         Device/File Name         :  /dev/ocr1
                                    Device/File needs to be synchronized with the other device
         Device/File Name         :  /dev/ocr2
                                    Device/File integrity check succeeded

         Cluster registry integrity check succeeded

O device /dev/ocr1 não está mais íntegro.

Bom, vamos agora corromper o outro OCR:

[root@mvrac1 ~]# dd if=/dev/zero of=/dev/ocr2
dd: writing to `/dev/ocr1': No space left on device
514018+0 records in
514017+0 records out
263176704 bytes (263 MB) copied, 8.42927 seconds, 31.2 MB/s

Verificando novamente a integridade do OCR:

[root@mvrac1 ~]# ocrcheck
Segmentation fault

Verificando o status dos componentes do cluster:

[root@mvrac1 ~]# crsstat
HA Resource                                        Target     State
-----------                                        ------     -----
error connecting to CRSD at [(ADDRESS=(PROTOCOL=ipc)(KEY=ora_crsqs))] clsccon 184

Verificando o log $ORA_CRS_HOME/log/mvrac1/alertmvrac1.log:

2010-08-17 20:45:22.046
[client(9701)]CRS-1006:The OCR location /dev/ocr2 is inaccessible. Details in /u01/app/oracle/product/10.2.0/crs/log/mvrac1/client/ocrcheck_9701.log.
2010-08-17 20:45:22.037
[crsd(4403)]CRS-1006:The OCR location /dev/ocr2 is inaccessible. Details in /u01/app/oracle/product/10.2.0/crs/log/mvrac1/crsd/crsd.log.

Trecho do log $ORA_CRS_HOME/mvrac1/crsd/crsd.log:

2010-08-17 20:45:24.233: [  OCRRAW][3055160208]proprdc: backend_ctx->metactx=[0x932bbc8]
2010-08-17 20:45:24.233: [  OCRRAW][3055160208]proprdc: backend_ctx->prop_sctx=[0x9327600]
2010-08-17 20:45:24.233: [  OCRRAW][3055160208]proprdc: backend_ctx->prop_sltsmx=[0x0]
2010-08-17 20:45:24.234: [  OCRRAW][3055160208]proprdc: backend_ctx->prop_sclsctx=[0x9350004]
2010-08-17 20:45:24.234: [  OCRRAW][3055160208]proprdc: backend_ctx->prop_ctx_ocrctx=[0x9357f24]
[  OCRAPI][3055160208]procr_ctx_set_invalid_no_abort: ctx set to invalid
[  OCRAPI][3055160208]procr_ctx_set_invalid: aborting...

Fazendo o restore do OCR:

[root@mvrac2 oracle]# ocrconfig -restore /u01/app/oracle/product/10.2.0/crs/cdata/crs_mv/backup00.ocr

Verificando a integridade do OCR:

[root@mvrac2 oracle]# ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          2
         Total space (kbytes)     :     256788
         Used space (kbytes)      :       4624
         Available space (kbytes) :     252164
         ID                       :  382969207
         Device/File Name         :  /dev/ocr1
                                    Device/File integrity check succeeded
         Device/File Name         :  /dev/ocr2
                                    Device/File integrity check succeeded

         Cluster registry integrity check succeeded

Verificando o status dos recursos do Clusterware:

[root@mvrac1 crsd]# crsstat
HA Resource                                        Target     State
-----------                                        ------     -----
ora.mvdb.db                                        ONLINE     ONLINE on mvrac1
ora.mvdb.mvdb1.inst                                ONLINE     ONLINE on mvrac1
ora.mvdb.mvdb2.inst                                ONLINE     ONLINE on mvrac2
ora.mvdb.producao.cs                               ONLINE     ONLINE on mvrac1
ora.mvdb.producao.mvdb1.srv                        ONLINE     ONLINE on mvrac1
ora.mvdb.producao.mvdb2.srv                        ONLINE     ONLINE on mvrac2
ora.mvrac1.ASM1.asm                                ONLINE     ONLINE on mvrac1
ora.mvrac1.LISTENER_MVRAC1.lsnr                    ONLINE     ONLINE on mvrac1
ora.mvrac1.gsd                                     ONLINE     ONLINE on mvrac1
ora.mvrac1.ons                                     ONLINE     ONLINE on mvrac1
ora.mvrac1.vip                                     ONLINE     ONLINE on mvrac1
ora.mvrac2.ASM2.asm                                ONLINE     ONLINE on mvrac2
ora.mvrac2.LISTENER_MVRAC2.lsnr                    ONLINE     ONLINE on mvrac2
ora.mvrac2.gsd                                     ONLINE     ONLINE on mvrac2
ora.mvrac2.ons                                     ONLINE     ONLINE on mvrac2
ora.mvrac2.vip                                     ONLINE     ONLINE on mvrac2

Como puderam ver, desde que tenhamos os arquivos de backup do OCR disponíveis, é fácil recuperar o ambiente de Clusterware após um desastre.

No próximo, continuaremos com as rotinas administrativas do Clusterware.

Um abraço!

Vinicius







----------------------------------------------------------------------------

Copyright:

Este site e todo o conteúdo aqui publicado pertence ao Blog ViniciusDBA.com.br e possui seus respectivos direitos autorais.

O Conteúdo desde Blog não deve ser publicado, distribuído ou transmitido sem autorização prévia de seu autor.

Oracle e seus produtos são marcas registradas da Oracle Corporation® (http://www.oracle.com) Todo o material aqui encontrado é mantido sem ajuda financeira e mantém como propriedade de seu fundador/escritor.

Disclaimer:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
As opiniões publicadas neste blog (http://www.viniciusdba.com.br) são pessoais e não necessariamente representam a visão da Oracle.


Toda informação aqui encontrado é oferecida através do uso do bom senso e boa fé do seus leitores e não deve ser considerada como material oficial da Oracle Corporation (http://www.oracle.com).

O Autor (e contribuidores) não considera as informações aqui como oficiais e/ou permitidas para redistribuição. Ao utilizar o site http://www.viniciusdba.com.br o leitor deve entender e aceitar que as informações aqui encontradas são de direitos autorais do Autor e contribuidores.

O blog http://www.viniciusdba.com.br não faz revisão de conteúdo publicado por outros como comentários bem como posts em grupo de usuários ou portais.

Seus autores não necessariamente concordam ou apoiam opiniões de seus leitores.

ESTE É UM SITE INDEPENDENTE E NÃO REPRESENTA A ORACLE CORPORATION® (http://www.oracle.com) EM NENHUM SENTIDO. AS OPINIÕES E CONTEÚDOS AQUI ENCONTRADOS NÃO POSSUEM RELAÇÃO COM A VISÃO DA ORACLE CORPORATION®. ESTE SITE NÃO POSSUI NENHUM APOIO OU PATROCINIO DA ORACLE CORPORATION®.

Olá amigos!

Depois de uma longa pausa, continuamos hoje a série de artigos que aborda a arquitetura do Oracle Clusterware.

No post de hoje, veremos sobre as redes utilizadas no Oracle Clusterware: pública e privada.

  • Pública:
    • É nessa rede que o endereço IP virtual (VIP) será inicializado;
    • As conexões realizadas através de Oracle Net (Client Oracle) ou JDBC deverão apontar para os IP’s VIP, para que haja transparência no momento do failover;
    • Em caso de falha no nó 1, o VIP será inicializado no nó 2;
    • Enquanto houver pelo menos um servidor dentro do Cluster, todos os VIP’s estarão online neste servidor;
    • Quando o servidor que sofreu o problema inicializar a camada do Cluster, o CRS tentará subir o VIP nesse servidor, por 5 tentativas, e caso não consiga, outro servidor do Cluster ficará com esse VIP online;
    • Os IP’s VIP deverão ser registrados no DNS, pois os usuários devem se conectar o hostname do VIP ao invés do endereço IP. Isso é necessário pois quando ocorre o failover, o Listener do nó que permanecerá online, reencaminhará ao Client Oracle a string de conexão do nó 2 contendo a informação do hostname do VIP, e não do endereço IP, nesse momento, a estação de trabalho deverá ter a capacidade de resolver o nome no endereço IP. Seja através de DNS ou através do arquivo hosts na estação local.
  • Privada (InterConnect):
    • É a conexão privada entre os nós do cluster;
    • O uso de cabo cross-over é permitido tecnicamente, mas não suportado pela Oracle;
    • É a mídia do Cache-Fusion: global cache;
    • Deve ter baixa latência e alta largura de banda (gigabit ethernet é recomendado);
    • Deve ser utilizado em switchs gigabit;
    • Não deve estar no mesmo switch (ou VLAN) que a rede corporativa (pública);
    • Recomendado o uso de tecnologias para garantir maior disponibilidade. No Linux, há o bond networking, onde se utiliza 2 placas de rede físicas, com 2 switches, e é criada uma interface de rede virtual, para que a a rede InterConnect nunca fique indisponível, pois se ela ficar, o nó sofrerá reboot, já que ela faz parte da arquitetura do CSS. Essa tenologia de bonding networki é chamada de network teaming em outros sistemas operacionais.

Pessoal, essa foi a forma mais simples que eu tinha de explicar sobre as redes utilizadas no Clusterware. No próximo artigo, começaremos uma série que tratará sobre a administração do Clusterware.

Abraços!

Vinicius







----------------------------------------------------------------------------

Copyright:

Este site e todo o conteúdo aqui publicado pertence ao Blog ViniciusDBA.com.br e possui seus respectivos direitos autorais.

O Conteúdo desde Blog não deve ser publicado, distribuído ou transmitido sem autorização prévia de seu autor.

Oracle e seus produtos são marcas registradas da Oracle Corporation® (http://www.oracle.com) Todo o material aqui encontrado é mantido sem ajuda financeira e mantém como propriedade de seu fundador/escritor.

Disclaimer:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
As opiniões publicadas neste blog (http://www.viniciusdba.com.br) são pessoais e não necessariamente representam a visão da Oracle.


Toda informação aqui encontrado é oferecida através do uso do bom senso e boa fé do seus leitores e não deve ser considerada como material oficial da Oracle Corporation (http://www.oracle.com).

O Autor (e contribuidores) não considera as informações aqui como oficiais e/ou permitidas para redistribuição. Ao utilizar o site http://www.viniciusdba.com.br o leitor deve entender e aceitar que as informações aqui encontradas são de direitos autorais do Autor e contribuidores.

O blog http://www.viniciusdba.com.br não faz revisão de conteúdo publicado por outros como comentários bem como posts em grupo de usuários ou portais.

Seus autores não necessariamente concordam ou apoiam opiniões de seus leitores.

ESTE É UM SITE INDEPENDENTE E NÃO REPRESENTA A ORACLE CORPORATION® (http://www.oracle.com) EM NENHUM SENTIDO. AS OPINIÕES E CONTEÚDOS AQUI ENCONTRADOS NÃO POSSUEM RELAÇÃO COM A VISÃO DA ORACLE CORPORATION®. ESTE SITE NÃO POSSUI NENHUM APOIO OU PATROCINIO DA ORACLE CORPORATION®.

Olá amigos!

Continuamos hoje a série de artigos que aborda a arquitetura do Oracle Clusterware.

No post de hoje, veremos sobre os principais arquivos na arquitetura do Oracle Clusterware: Voting Disk e OCR.

  • Voting Disk
    • Deve estar em storage compartilhado entre os nós: raw devices (até o Kernel 2.5.x), block devices, ou um cluster file system suportado;
    • Ele também é chamado de Disco de Quórum (Quorum Disk);
    • Pode ou não ser multiplexado: 1, 2 ou 3 cópias (é possível colocar mais de 3 cópias);
    • Sua utilidade ocorre quando há falha na rede de InterConnect, onde, todos os nós do Cluster precisam “votar” num lugar acessível a todos os nós (storage), o nó que tiver o menor número de votos como disponível (available) é eleito a sair do cluster (node eviction), e o processo de CSS faz o restart abrupto do nó;
    • O backup deve ser executado manualmente com o usuário root (em sistemas Unix/Linux), o utilitário dd é utilizado. Veremos na série sobre Administração do Clusterware como realizar essa tarefa;
    • Sempre que houver adição ou remoção de nós no cluster, é recomendado fazer o backup. Isso significa que um backup pode ser armazenado por muitos meses, que mesmo assim, continuará válido;
    • Se um nó perder acesso aos Voting Disks (problemas na fibra, controladora, etc.), o nó será reiniciado imediatamente, pois faz parte da arquitetura do CSS, e, sendo assim, qualquer componente da arquitetura do CSS que falhar, o servidor será reiniciado imediatemente.
    • A figura abaixo exemplifica o funcionamento do Voting Disk:

Na figura acima, podemos observar que num cluster de 3 nós, todos os nós se enxergam através do que chamamos de heart-beat (batida de coração), que é feita pela rede InterConnect. Essa informação é registrada no Voting Disk informando que todos os nós estão ativos no cluster.

Na figura acima, observamos que o nó 3 sofreu algum problema de conexão com a rede privada (InterConnect). O CSS realiza a votação, e o nó 1 “diz” que enxerga os nós 1 e 2; o nó 2 “diz” que enxerga os nós 1 e 2; e o nó 3 “diz” que enxerga somente o nó 3. Dessa forma, o nó 1 tem 2 votos como disponível, o nó 2 tem 2 votos como disponível, e o nó 3 tem apenas 1 voto com disponível. Logo, o nó 3 será evitado e será reiniciado imediatamente.

OK, o funcionamento do Voting Disk é fácil de ser entendido com um cluster de 3 ou mais nós. Mas, aí vem a pergunta, e no caso de um cluster de 2 nós, onde o nó 2 sofrerá o problema de conexão com a rede InterConnect. Como ficarão os votos dentro do Voting Disk? Ficarão da seguinte forma: o nó 1 “diz” que enxerga somente o nó 1, e o nó 2 “diz” que enxerga somente o nó 2. E aí, quem deverá sair do cluster temporariamente?

De acordo com o Metalink Note (RAC: Frequently Asked Questions [ID 220970.1]), o nó que será o “sobrevivente” no cluster será aquele que entrou primeiro no cluster, isto é, supondo que o nó 2 tenha entrado no cluster no dia 05/05/2010 às 0:01 e o nó 1 tenha entrado no cluster no dia 05/05/2010 às 0:02, o nó 2 será o nó sobrevivente no cluster, e o nó 1 será reiniciado.

  • OCR (Oracle Cluster Registry)
    • Deve estar em storage compartilhado entre os nós: raw devices (até o Kernel 2.5.x), block devices, ou um cluster file system suportado;
    • Ele também é chamado arquivo de controle (control file) do Cluster, sendo o centro das informações no cluster;
    • Pode ou não ser multiplexado: 1 ou 2 cópias;
    • Ele armazena informações como:
      • Lista dos nós, bancos de dados, instâncias, listeners, ASM, etc -> todos esses componentes são chamados de recursos;
      • Status esperado de cada um dos recursos do cluster;
    • A perda implica em parada do ambiente;
    • Os backups são executados automaticamente a cada 4 horas, e tem a seguinte política de retenção:
      • Armazena 1 backup a cada 4 horas no dia, totalizando 6 backups num intervalo de 24 horas;
      • Armazena 1 backup diário (sempre 1 backup do dia anterior, mas nunca o backup de 2 dias anteriores ou mais);
      • Armazena 1 backup semanal;
    • Além do backup automático, também é possível realizar um backup lógico.

Bom pessoal, como vocês puderam ver, esses arquivos são a espinha dorsal do cluster. Sem eles, o cluster não entra em funcionamento. Também foi possível observar que para um DBA perder um backup do OCR, tem que estar muito desatento mesmo, pois com backup a cada 4 horas, é praticamente “impossível” perder um backup desses.

Novamente, espero que esse post seja útil!

No próximo artigo, da semana que vem, veremos sobre as redes utilizadas no cluster: pública e privada (InterConnect).

Um abraço!

Vinicius







----------------------------------------------------------------------------

Copyright:

Este site e todo o conteúdo aqui publicado pertence ao Blog ViniciusDBA.com.br e possui seus respectivos direitos autorais.

O Conteúdo desde Blog não deve ser publicado, distribuído ou transmitido sem autorização prévia de seu autor.

Oracle e seus produtos são marcas registradas da Oracle Corporation® (http://www.oracle.com) Todo o material aqui encontrado é mantido sem ajuda financeira e mantém como propriedade de seu fundador/escritor.

Disclaimer:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
As opiniões publicadas neste blog (http://www.viniciusdba.com.br) são pessoais e não necessariamente representam a visão da Oracle.


Toda informação aqui encontrado é oferecida através do uso do bom senso e boa fé do seus leitores e não deve ser considerada como material oficial da Oracle Corporation (http://www.oracle.com).

O Autor (e contribuidores) não considera as informações aqui como oficiais e/ou permitidas para redistribuição. Ao utilizar o site http://www.viniciusdba.com.br o leitor deve entender e aceitar que as informações aqui encontradas são de direitos autorais do Autor e contribuidores.

O blog http://www.viniciusdba.com.br não faz revisão de conteúdo publicado por outros como comentários bem como posts em grupo de usuários ou portais.

Seus autores não necessariamente concordam ou apoiam opiniões de seus leitores.

ESTE É UM SITE INDEPENDENTE E NÃO REPRESENTA A ORACLE CORPORATION® (http://www.oracle.com) EM NENHUM SENTIDO. AS OPINIÕES E CONTEÚDOS AQUI ENCONTRADOS NÃO POSSUEM RELAÇÃO COM A VISÃO DA ORACLE CORPORATION®. ESTE SITE NÃO POSSUI NENHUM APOIO OU PATROCINIO DA ORACLE CORPORATION®.