Tag Archive: asm

 

Série de artigos sobre Instalação do Oracle RAC:

Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos
Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM
Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 4: Configuração do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 5: Clonagem da VM
Instalação do Oracle RAC 10g Release 2 – Parte 6: Pré-instalação do RAC
Instalação do Oracle RAC 10g Release 2 – Parte 7: Instalação do Oracle Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 8: Instalação do Patchset 10.2.0.4 no Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 9: Instalação do Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 10: Instalação do Patchset 10.2.0.4 no Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 11: Criação do Listener no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 12: Criação do ASM no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 13: Criação do Banco de Dados no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 14: Criação do Serviço para Load Balance e Failover

Conforme prometido, série de artigos para adição de um nó ao cluster:

Adição/Remoção de Nó – Parte 1: Pré-requisitos de software
Adição/Remoção de Nó – Parte 2: Criação da 3ª Máquina Virtual
Adição/Remoção de Nó – Parte 3: Instalação do Linux

Adição/Remoção de Nó – Parte 4: Configuração do Linux

===================================
Olá pessoal!
Falta pouco para que iniciemos de fato a adição do nó mvrac3 ao cluster!
Neste artigo de hoje, veremos os seguintes itens:

  • Criação de equivalência de usuários para acesso SSH entre os 3 nós;
  • Scan dos discos ASM no servidor mvrac3;
  • Criação de block devices no servidor mvrac3.

Vamos lá!

Com o servidor mvrac3 desligado, precisaremos pegar as referências dos discos attachados aos servidores mvrac1 e mvrac2 que desempenham o papel de disco do storage.

Pelo Windows Explorer, vá em G:\VMware\mvrac1.

Procure por um arquivo com a extensão VMX e abra-o num editor de textos, selecione e copie o seguinte trecho do arquivo:

scsi1.present = "TRUE"
scsi1:0.present = "TRUE"
scsi1:0.fileName = "G:\VMWARE\SharedDisks\sdisk01.vmdk"
scsi1:0.mode = "independent-persistent"
scsi1:1.present = "TRUE"
scsi1:1.fileName = "G:\VMWARE\SharedDisks\sdisk02.vmdk"
scsi1:1.mode = "independent-persistent"
scsi1:2.present = "TRUE"
scsi1:2.fileName = "G:\VMWARE\SharedDisks\sdisk03.vmdk"
scsi1:2.mode = "independent-persistent"
scsi1.virtualDev = "lsilogic"

Cole este trecho no final do arquivo com a extensão VMX no diretório G:\VMWare\mvrac3. Salve o arquivo e mande iniciar a máquina virtual.

Como já citado anteriormente, fizemos a instalação dos produtos em sistemas de arquivos (file systems) locais. Como havíamos criado chaves SSH para o usuário oracle dos nós mvrac1 e mvrac2, deixamos estabelecida a equivalência de usuário entre este usuário nos servidores já citados. A equivalência de usuário também é chamada de relação de confiança. Nesta relação de confiança, a comunicação entre os servidores ocorre sem a solicitação de senha, isto é um pré-requisito para ambientes em Cluster Oracle, pois o Oracle Universal Installer (OUI), dbca, netca, emca, OPatch, dentre outras ferramentas, sempre realizarão cópias de arquivos entre os nós do cluster. A equivalência de usuário poderá ocorrer através de duas maneiras:

  • rsh/rcp;
  • ssh/scp.

A configuração por rsh/rcp é mais simples de ser feita, no entanto, não é a recomendada, já que não é segura. Já no ssh/scp, os dados são enviados pela rede de forma criptografada, o que aumenta a segurança. Inclusive, em muitas empresas, as portas utilizadas em rsh/rcp nem são liberadas no firewall por motivos de segurança. A configuração do ssh/scp é um pouco mais chata, mas é a que veremos aqui por ser a mais segura.

Para realizar a configuração da equivalência de usuários para acesso via SSH, é necessário criar as chaves SSH de acesso ao usuário. Como a equivalência de usuários já existe entre os servidores mvrac1 e mvrac2 para o usuário oracle, os passos serão esses:

  • Criação das chaves do usuário oracle do servidor mvrac3;
  • Criação das chaves do usuário oracle do servidor mvrac2;
  • Append do arquivo de chaves autorizadas no servidor mvrac1, incluindo as chaves SSH do usuário oracle do servidor mvrac3. Inclusão do servidor mvrac3 num arquivo de hosts conhecidos para não mais confirmar o acesso via SSH e isso ser feito automaticamente entre os servidores.

Então, vamos para o primeiro passo, criar as chaves do usuário oracle no servidor mvrac3. Com o usuário oracle a partir do servidor mvrac3:

[oracle@mvrac3 ~]$ cd /home/oracle
[oracle@mvrac3 ~]$ mkdir .ssh
[oracle@mvrac3 ~]$ cd .ssh
[oracle@mvrac1 .ssh]$ ssh-keygen -t dsa

Pressionar [ENTER] até voltar para o shell.

[oracle@mvrac3 .ssh]$ ssh-keygen -t rsa

Pressionar [ENTER] até voltar para o shell.

Vamos verificar o tamanho do arquivo de chaves autorizadas. No servidor mvrac1:

[oracle@mvrac1 .ssh]$ ls -l authorized_keys
-rw-r--r-- 1 oracle oinstall 2072 Aug 16 19:43 authorized_keys

Observem que o arquivo authorized_keys tem 2072 bytes de tamanho, pois, por enquanto, só possui as chaves do servidor mvrac1 e mvrac2. Agora, colocaremos dentro desse mesmo arquivo, o conteúdo das chaves públicas do usuário oracle do servidor mvrac3:

[oracle@mvrac1 .ssh]$ ssh mvrac3 cat `pwd`/*.pub >> authorized_keys
The authenticity of host 'mvrac3 (172.23.10.13)' can't be established. RSA key fingerprint is ee:df:af:11:67:a9:b5:0a:e0:8f:3d:69:2a:3f:ef:6e. Are you sure you want to continue connecting (yes/no)? yes

Observem que eu tive que confirmar com yes e em seguida, terei que colocar a senha do usuário oracle do servidor mvrac3:

oracle@mvrac3's password:

Vamos verificar o tamanho do arquivo de chaves autorizadas após a inclusão das chaves do servidor mvrac3. No servidor mvrac1:

[oracle@mvrac1 .ssh]$ ls -l authorized_keys
-rw-r--r-- 1 oracle oinstall 3108 Sep 18 20:43 authorized_keys

Observem que o arquivo authorized_keys tem 3108 bytes de tamanho, e, desta forma, podemos concluir que o mesmo aumentou de tamanho. Logo, as chaves do servidor mvrac3 também estão no arquivo.

Esta versão de arquivo (com as chaves dos servidores mvrac1, mvrac2 e mvrac3 ainda existe somente no servidor mvrac1. Devemos copiá-lo para o servidor mvrac2 e também no servidor mvrac3, nesse mesmo diretório, /home/oracle/.ssh. Como este arquivo ainda não existe no servidor mvrac3, a senha para este servidor será solicitada:

[oracle@mvrac1 .ssh]$ scp -p authorized_keys mvrac2:`pwd`
authorized_keys         100% 3108     2.0KB/s   00:00
[oracle@mvrac1 .ssh]$ scp -p authorized_keys mvrac3:`pwd`
oracle@mvrac3's password:
authorized_keys         100% 3108     2.0KB/s   00:00

Bom, como no servidor mvrac1 eu estava no diretório /home/oracle/.ssh. E o arquivo authorized_keys tem que ir para o mesmo diretório no servidor mvrac2 e também no servidor mvrac3, observem que eu usei um comando do Linux dentro do comando scp. O comando foi o pwd. E sempre que quisermos usar um comando dentro de outro comando, deveremos colocá-lo entre crases: `pwd`. Dessa forma, ele executará o comando pwd no servidor mvrac1 e com base na saída do comando (/home/oracle/.ssh), jogará o arquivo dentro desse diretório no outro servidor. Se o diretório não existisse, teríamos um erro.

Vamos testar para ver se a equivalência de usuários está funcionando?

[oracle@mvrac1 .ssh]$ ssh mvrac3.viniciusdba.com.br date
The authenticity of host 'mvrac3.viniciusdba.com.br (172.23.10.13)' can't be established.
RSA key fingerprint is ee:df:af:11:67:a9:b5:0a:e0:8f:3d:69:2a:3f:ef:6e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mvrac3.viniciusdba.com.br' (RSA) to the list of known hosts.
Wed Sep 18 20:52:38 BRT 2012

Observem que eu tive que digitar yes. Mas não precisei mais digitar a senha. Porque?

Não precisei digitar mais a senha porque a equivalência de usuários funcionou. Mas, o host mvrac3.viniciusdba.com.br ainda não é um host conhecido para o SSH. Dessa forma, no servidor mvrac1, com o usuário oracle, deveremos fazer o seguinte:

ssh mvrac3 date
ssh mvrac3-priv date
ssh mvrac3.viniciusdba.com.br date
ssh mvrac3-priv.viniciusdba.com.br date

Em todos as saídas, deveremos sempre confirmar com yes:

Are you sure you want to continue connecting (yes/no)? yes

Quando executar as linhas acima, para confirmar se está tudo OK, basta refazer o comando incluindo todos os servidores:

ssh mvrac1 date
ssh mvrac1-priv date
ssh mvrac1.viniciusdba.com.br date
ssh mvrac1-priv.viniciusdba.com.br date
ssh mvrac2 date
ssh mvrac2-priv date
ssh mvrac2.viniciusdba.com.br date
ssh mvrac2-priv.viniciusdba.com.br date
ssh mvrac3 date
ssh mvrac3-priv date
ssh mvrac3.viniciusdba.com.br date
ssh mvrac3-priv.viniciusdba.com.br date

Ele não deverá mais pedir confirmação para nenhum host:

[oracle@mvrac1 .ssh]$ ssh mvrac3 date
Wed Sep 18 20:54:00 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac1-priv date
Wed Sep 18 20:54:00 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac1.viniciusdba.com.br date
Wed Feb 18 20:54:00 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac1-priv.viniciusdba.com.br date
Wed Feb 18 20:54:01 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac2 date
Wed Feb 18 20:54:01 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac2-priv date
Wed Feb 18 20:54:02 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac2.viniciusdba.com.br date
Wed Feb 18 20:54:02 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac2-priv.viniciusdba.com.br date
Wed Sep 18 20:54:03 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac3 date
Wed Feb 18 20:54:04 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac3-priv date
Wed Feb 18 20:54:05 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac3.viniciusdba.com.br date
Wed Feb 18 20:54:06 BRT 2012
[oracle@mvrac1 .ssh]$ ssh mvrac3-priv.viniciusdba.com.br date
Wed Sep 18 20:54:07 BRT 2012

Isso atualizará no servidor mvrac1, dentro do diretório corrente, /home/oracle/.ssh, o arquivo known_hosts (hosts conhecidos):

[oracle@mvrac1 .ssh]$ ls -l known_hosts
-rw-r--r-- 1 oracle oinstall 4869 Sep 20 20:54 known_hosts

Agora basta copiar esse arquivo para o outro servidor:

[oracle@mvrac1 .ssh]$ scp -p known_hosts mvrac2:`pwd`
known_hosts             100% 4869     3.2KB/s   00:00
[oracle@mvrac1 .ssh]$ scp -p known_hosts mvrac3:`pwd`
known_hosts             100% 4869     3.2KB/s   00:00

Pronto! Equivalência de usuários devidamente configurada!

Agora checar o particionamento de discos.

Como vocês se lembram, temos 4 discos disponibilizados:

  • 1 disco de 12GB (disco local);
  • 3 discos de 5GB (discos storage).

Não mexeremos nas partições do disco local, pois essas já foram configuradas durante a instalação do Linux.

Temos 3 discos de 5GB. Para instalarmos o Oracle RAC precisamos do seguinte:

  • 3 partições para armazenar Voting Disk;
  • 2 partições para armazenar OCR;
  • 3 partições que serão os discos ASM.

Vamos consultar os discos existentes no servidor mvrac3? Como root:

[root@mvrac3 ~]# fdisk -l

Disk /dev/sda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1435    11526606   83  Linux
/dev/sda2            1436        1566     1052257+  82  Linux swap / Solaris

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         652     5237158+   5  Extended
/dev/sdb5               1          32      256977   83  Linux
/dev/sdb6              33          64      257008+  83  Linux
/dev/sdb7              65          96      257008+  83  Linux
/dev/sdb8              97         128      257008+  83  Linux
/dev/sdb9             129         652     4208998+  83  Linux

Disk /dev/sdc: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         652     5237158+   5  Extended
/dev/sdc5               1          32      256977   83  Linux
/dev/sdc6              33          64      257008+  83  Linux
/dev/sdc7              65          96      257008+  83  Linux
/dev/sdc8              97         128      257008+  83  Linux
/dev/sdc9             129         652     4208998+  83  Linux

Disk /dev/sdd: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         652     5237158+   5  Extended
/dev/sdd5               1          32      256977   83  Linux
/dev/sdd6              33          64      257008+  83  Linux
/dev/sdd7              65         652     4723078+  83  Linux

As partições foram listadas!

Agora, faremos o SCAN dos discos ASM.

Para fazermos as partições dos discos ASM, basta usarmos a ASMLib com o usuário root:

[root@mvrac3 oracle]# /etc/init.d/oracleasm scandisks
Scanning the system for Oracle ASMLib disks:               [  OK  ]

Agora precisamos verificar se os discos foram realmente enxergados:

[root@mvrac3 oracle]# /etc/init.d/oracleasm listdisks
ASMDISK1
ASMDISK2
ASMDISK3

Pronto! Discos do ASM listados!

Agora falta apenas criar os block devices. Usaremos o utilitário chamado UDEV para isso. Para criarmos esses dispositivos, criaremos um arquivo com as regras necessárias no diretório /etc/udev/rules.d. O arquivo precisa ter a extensão .rules.

Agora criaremos o arquivo que criará os block devices:

[root@mvrac3 oracle]# vi 63-oracle-block.rules

O conteúdo do arquivo 63-oracle-block.rules será:

KERNEL=="sdb6", NAME="ocr1", OWNER="root", GROUP="dba", MODE="0640"
KERNEL=="sdb8", NAME="voting1", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="sdc6", NAME="ocr2", OWNER="root", GROUP="dba", MODE="0640"
KERNEL=="sdc8", NAME="voting2", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="sdd6", NAME="voting3",OWNER="oracle",GROUP="dba", MODE="0640"

Após isso, faremos o restart do serviço udev:

[root@mvrac3 rules.d]# start_udev
Starting udev:                                             [  OK  ]

Agora verificaremos se os devices foram criados:

[root@mvrac3 rules.d]# ls -l /dev/ocr* /dev/voting*
brw-r----- 1 oracle dba   8, 22 Sep 18 21:34 /dev/ocr1
brw-r----- 1 oracle dba   8, 38 Sep 18 21:35 /dev/ocr2
brw-r----- 1 root   dba   8, 24 Sep 18 21:34 /dev/voting1
brw-r----- 1 root   dba   8, 40 Sep 18 21:35 /dev/voting2
brw-r----- 1 oracle dba   8, 54 Sep 18 21:35 /dev/voting3

Os dispositivos foram criados!

Nesse momento estamos prontos para iniciar a adição do Nó ao Cluster!

Nos veremos no próximo post, semana que vem!

Um abraço!

Vinicius

——————————-

PS:

Observação:

Apenas para ficar claro, sobre as partições de discos, num ambiente corporativo eu costumo pedir o seguinte:

  • 1 disco (LUN) de 2GB para utilizar as partições raw devices (esse disco posteriormente será eliminado);
  • 2 discos (LUN’s) de 512MB para utilizar as partições block devices;
  • 1 disco (LUN) de 256MB para utilizar a partição block device;
  • Quantidade “X de discos para ASM, aí vai depender do tamanho do banco de dados.






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

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®.

Série de artigos sobre Instalação do Oracle RAC:

Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos
Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM
Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 4: Configuração do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 5: Clonagem da VM
Instalação do Oracle RAC 10g Release 2 – Parte 6: Pré-instalação do RAC
Instalação do Oracle RAC 10g Release 2 – Parte 7: Instalação do Oracle Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 8: Instalação do Patchset 10.2.0.4 no Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 9: Instalação do Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 10: Instalação do Patchset 10.2.0.4 no Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 11: Criação do Listener no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 12: Criação do ASM no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 13: Criação do Banco de Dados no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 14: Criação do Serviço para Load Balance e Failover

===================================

Olá pessoal, hoje chegamos ao último artigo sobre a série de Instalação do Oracle RAC 10g Release 2. É claro que na semana que vem, teremos um novo artigo, mas desta vez, começarei a abordar a administração do ambiente Oracle RAC. Portanto, essa série de 15 artigos se encerra aqui, e iniciaremos uma nova série de artigos.

Lembre-se, qualquer dúvida, poste seu comentário aqui, ou envie e-mail para blog@viniciusdba.com.br.

Para configurar o Enterprise Manager, precisamos ter alguns dados:

  • Nome global do banco de dados: mvdb;
  • Porta do Listener: 1521;
  • Nome do Cluster: crs_mv;
  • Senha do usuário SYS;
  • Senha do usuário DBSNMP;
  • Senha do usuário SYSMAN;
  • Endereço de e-mail para notificações (opcional);
  • Servidor SMTP para notificações (opcional);
  • Oracle Home do ASM;
  • Porta do ASM: 1521;
  • Role do ASM: SYSDBA;
  • Usuário do ASM: SYS;
  • Senha do usuário SYS do ASM.

Vamos fazer a configuração?

Com o usuário oracle no servidor mvrac1:

[oracle@mvrac1 ~]$ emca -config dbcontrol db -repos recreate -cluster

STARTED EMCA at Feb 25, 2010 2:22:59 AM
EM Configuration Assistant, Version 10.2.0.1.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:
Database unique name: mvdb
Listener port number: 1521
Cluster name: crs_mv
Password for SYS user:
Password for DBSNMP user:
Password for SYSMAN user:
Email address for notifications (optional):
Outgoing Mail (SMTP) server for notifications (optional):
ASM ORACLE_HOME [ /u01/app/oracle/product/10.2.0/db_1 ]:
ASM port [ 1521 ]:
ASM user role [ SYSDBA ]:
ASM username [ SYS ]:
ASM user password:
-----------------------------------------------------------------

You have specified the following settings

Database ORACLE_HOME ................ /u01/app/oracle/product/10.2.0/db_1

Database instance hostname ................ mvrac1.viniciusdba.com.br
Listener port number ................ 1521
Cluster name ................ crs_mv
Database unique name ................ mvdb
Email address for notifications ...............
Outgoing Mail (SMTP) server for notifications ...............
ASM ORACLE_HOME ................ /u01/app/oracle/product/10.2.0/db_1
ASM port ................ 1521
ASM user role ................ SYSDBA
ASM username ................ SYS

-----------------------------------------------------------------
Do you wish to continue? [yes(Y)/no(N)]: Y
Feb 25, 2010 2:23:45 AM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/emca/mvdb/emca_2010-02-25_02-22-59-AM.log.
Feb 25, 2010 2:23:50 AM oracle.sysman.emcp.EMReposConfig dropRepository
INFO: Dropping the EM repository (this may take a while) ...
Feb 25, 2010 2:28:10 AM oracle.sysman.emcp.EMReposConfig invoke
INFO: Repository successfully dropped
Feb 25, 2010 2:28:11 AM oracle.sysman.emcp.EMReposConfig createRepository
INFO: Creating the EM repository (this may take a while) ...
Feb 25, 2010 2:34:20 AM oracle.sysman.emcp.EMReposConfig invoke
INFO: Repository successfully created
Feb 25, 2010 2:34:43 AM oracle.sysman.emcp.EMDBCConfig instantiateOC4JConfigFiles
INFO: Propagating /u01/app/oracle/product/10.2.0/db_1/oc4j/j2ee/OC4J_DBConsole_mvrac1_mvdb1 to remote nodes ...
Feb 25, 2010 2:34:45 AM oracle.sysman.emcp.EMDBCConfig instantiateOC4JConfigFiles
INFO: Propagating /u01/app/oracle/product/10.2.0/db_1/oc4j/j2ee/OC4J_DBConsole_mvrac2_mvdb2 to remote nodes ...
Feb 25, 2010 2:34:46 AM oracle.sysman.emcp.EMDBCConfig copyAndPropagateOC4JDir
INFO: Propagating /u01/app/oracle/product/10.2.0/db_1/oc4j/j2ee/isqlplus_mvrac1.viniciusdba.com.br to remote nodes ...
Feb 25, 2010 2:34:48 AM oracle.sysman.emcp.EMDBCConfig copyAndPropagateOC4JDir
INFO: Propagating /u01/app/oracle/product/10.2.0/db_1/oc4j/j2ee/isqlplus_mvrac2.viniciusdba.com.br to remote nodes ...
Feb 25, 2010 2:34:59 AM oracle.sysman.emcp.EMAgentConfig deployStateDirs
INFO: Propagating /u01/app/oracle/product/10.2.0/db_1/mvrac1_mvdb1 to remote nodes ...
Feb 25, 2010 2:35:03 AM oracle.sysman.emcp.EMAgentConfig deployStateDirs
INFO: Propagating /u01/app/oracle/product/10.2.0/db_1/mvrac2_mvdb2 to remote nodes ...
Feb 25, 2010 2:35:04 AM oracle.sysman.emcp.util.DBControlUtil secureDBConsole
INFO: Securing Database Control (this may take a while) ...
Feb 25, 2010 2:36:34 AM oracle.sysman.emcp.util.DBControlUtil startOMS
INFO: Starting Database Control (this may take a while) ...
Feb 25, 2010 2:38:57 AM oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: Database Control started successfully
Feb 25, 2010 2:39:50 AM oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: >>>>>>>>>>> The Database Control URL is https://mvrac1.viniciusdba.com.br:1158/em <<<<<<<<<<<
Feb 25, 2010 2:40:40 AM oracle.sysman.emcp.EMDBPostConfig showClusterDBCAgentMessage
INFO:
****************  Current Configuration  ****************
 INSTANCE            NODE           DBCONTROL_UPLOAD_HOST
----------        ----------        ---------------------

mvdb1             mvrac1            mvrac1.viniciusdba.com.br
mvdb2             mvrac2            mvrac1.viniciusdba.com.br

Enterprise Manager configuration completed successfully
FINISHED EMCA at Feb 25, 2010 2:40:43 AM

Tela inicial do EM:

Finalizo aqui a série sobre a instalação do Oracle RAC 10 Release 2.

Semana que vem voltaremos, agora com a administração do ambiente, bem como os conceitos.

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®.

Série de artigos sobre Instalação do Oracle RAC:

Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos
Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM
Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 4: Configuração do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 5: Clonagem da VM
Instalação do Oracle RAC 10g Release 2 – Parte 6: Pré-instalação do RAC
Instalação do Oracle RAC 10g Release 2 – Parte 7: Instalação do Oracle Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 8: Instalação do Patchset 10.2.0.4 no Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 9: Instalação do Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 10: Instalação do Patchset 10.2.0.4 no Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 11: Criação do Listener no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 12: Criação do ASM no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 13: Criação do Banco de Dados no Cluster

===================================

Olá pessoal!

Vimos no último artigo a criação do Banco de Dados RAC.

Veremos hoje como criar o serviço responsável pelo load balance e principalmente, o failover. Vocês verão que é uma operação bem fácil de ser feita.

Agora, executaremos o assistente para criação do serviço, o dbca. Há algumas formas de executar esse assistente:

  • Localmente no servidor, através da VMWare Server Console;
  • Remotamente, através de um software que simule um X-Server (existem diversas opções gratuitas na Internet);
  • Remotamente, através de uma estação Linux/Unix/Mac que tenha a parte gráfica (X) habilitado.

Eu usarei a terceira opção, portanto, a partir da minha estação:

vinicius@Viniciuss-MacBook:~$ ssh -X oracle@172.23.10.11
oracle@172.23.10.11's password:
/usr/bin/xauth:  creating new authority file /home/oracle/.Xauthority

Testando para ver se a parte gráfica está funcionando:

[oracle@mvrac1 ~]$ xclock

O teste funcionou! Vejam:

Pronto!

Vamos executar o dbca:

[oracle@mvrac1 ~]$ dbca

O dbca detectará que a pilha de cluster está em execução, e precisamos selecionar qual será o tipo de ambiente que será configurado:

  • Oracle Real Application Clusters database;
  • Oracle single instance database.

Manteremos a opção Oracle Real Application Clusters database selecionada e clicaremos em Next.

Clicar no item “Services Management” e depois clicar em Next.

O DBCA exibirá a lista de bancos de dados existentes e ativos no cluster. Como só temos o banco de dados mvdb, ele será selecionado automaticamente. Clicar em Next.

dbca_create_service_blank

A janela acima será exibida. Essa janela também aparece na criação do banco de dados. Nela, criaremos no botão Add para criar um novo serviço.

Como exemplo, estou criando um serviço chamado producao. Clicar em OK.

No item “Details for producao”, temos 3 opções disponíveis para as instâncias de banco de dados:

  • Not used: o serviço nunca utilizará a instância de banco de dados, ou seja, nunca haverá conexões feitas àquela instância utilizando esse serviço de banco de dados;
  • Preferred: o serviço SEMPRE utilizará a instância de banco de dados, ou seja, no caso de um cluster de 2 nós, se as 2 instâncias estiverem como “Preferred”, haverá o Load Balance entre as 2 instâncias;
  • Available: o serviço SOMENTE utilizará a instância de banco dados em caso de falha na instância que estiver definida como PREFERRED. Ou seja, se a instância mvdb1 estiver como Preferred, e a instância mvdb2 estiver como Available, as conexões só serão feitas na instância mvdb2 se a instância mvdb1 estiver indisponível.

Como queremos que aconteça o Load Balance entre as 2 instâncias, as 2 instâncias deverão ser preenchidas como Preferred.

Agora configuraremos a parte do serviço responsável pelo failover. Chamamos isso de TAF (Transparent Application Failover).

No item “TAF Policy” temos 3 opções:

  • None: não haverá failover para o serviço.;
  • Basic: ocorrerá o failover básico para o serviço, ou seja, se o usuário estiver conectado na instância mvdb1 executando uma query e a instância ficar indisponível, o usuário será levado para a instância mvdb2;
  • Pre-connect: quando o usuário se conectar pelo serviço na instância mvdb1, automaticamente será criada uma conexão (pré-conexão) na instância mvdb2, isso torna o failover mais rápido, já que haverá uma conexão existente na segunda instância, no entanto, em contra-partida, essa sessão na segunda instância consumirá uma fatia da memória no servidor.

Utilizaremos a política “Basic”.

Clicar em Finish.

A janela acima solicitará confirmação para a criação do serviço no banco de dados mvdb. Clicar em OK.

Uma janela com o progresso da criação do serviço será exibida. Aguardar.

A janela acima será exibida questionando se o DBA deseja realizar mais alguma operação. Clicar em No.

Vamos verificar se os recursos do cluster foram alterados?

Para verificar o status dos recursos do cluster:

[oracle@mvrac1 ~]$ 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

Pronto!

Podemos ver que foi registrado no cluster uma serviço de banco de dados para cada nó, além de um recurso com o final .cs, representando o serviço clusterizado (cluster service).

Agora vamos realizar os testes com o serviço.

Porém, para que o failover aconteça com sucesso, a Oracle recomenda que os hostnames públicos, além dos hostnames referentes aos endereços VIP estejam registrados no DNS e/ou no arquivo hosts dos usuários. Como estou usando uma estação de trabalho baseada em Unix, o arquivo é o /etc/hosts, no caso do Windows, é C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS. As seguintes linhas precisam ser adicionadas:

172.23.10.21	mvrac1-vip	mvrac1-vip.viniciusdba.com.br
172.23.10.22	mvrac2-vip	mvrac2-vip.viniciusdba.com.br
172.23.10.11	mvrac1		mvrac1.viniciusdba.com.br
172.23.10.12	mvrac2		mvrac2.viniciusdba.com.br

Outro ponto importantíssimo para que o failover aconteça com sucesso, a entrada do TNSNAMES.ORA deve estar correta. Dentro do próprio servidor, há o TNSNAMES.ORA correto:

PRODUCAO =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mvrac1-vip.viniciusdba.com.br)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mvrac2-vip.viniciusdba.com.br)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = producao)
      (FAILOVER_MODE =
        (TYPE = SELECT)
        (METHOD = BASIC)
        (RETRIES = 180)
        (DELAY = 5)
      )
    )
  )

Observem que o TNSNAMES aponta para os 2 endereços VIP, ou seja, mesmo que um servidor fique indisponível, o IP VIP que estava nele, irá para o outro servidor.

Além disso, o ambiente pode retornar o erro ORA-12545 ao tentar se conectar pelo serviço criado recentemente.

A correção deste erro é definir o parâmetro LOCAL_LISTENER para que cada nó tenha somente o VIP local associado ao parâmetro. Vejamos:

SQL> alter system set local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=mvrac1-vip)(PORT=1521)))' scope=both sid='mvdb1';

System altered.

SQL> alter system set local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=mvrac2-vip)(PORT=1521)))' scope=both sid='mvdb2';

System altered.

Agora sim podemos testar:

sqlplus system/oracle@producao

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 25 00:06:27 2010

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Release 10.2.0.4.0 - Production
With the Real Application Clusters option

SQL> @taf    

 INST# INST_NAME  HOST			       USERNAME   TYPE	     METHOD	FAILED OVER
------ ---------- ---------------------------- ---------- ---------- ---------- -----------
     2 mvdb2	  mvrac2.viniciusdba.com.br    SYSTEM	  SELECT     BASIC	NO

O script taf.sql contém as seguintes linhas:

set linesize 100
col INST# format 99999
col INST_NAME format a10
col HOST format a28
col USERNAME format a10
col TYPE format a10
col METHOD format a10
col "FAILED OVER" format a11

select
  INSTANCE_NUMBER INST#,INSTANCE_NAME INST_NAME,HOST_NAME HOST,
  USERNAME, FAILOVER_TYPE TYPE, FAILOVER_METHOD METHOD,
  FAILED_OVER "FAILED OVER"
from
  V$SESSION a, V$INSTANCE b
where
  USERNAME = (select SYS_CONTEXT ('USERENV', 'SESSION_USER') from DUAL)
and
  SID = (select SYS_CONTEXT ('USERENV', 'SID') from DUAL)
;

De acordo com a saída do script, estamos na instância mvdb2, vamos fazer uma nova conexão para verificar o funcionamento do Load Balance:

SQL> connect system/oracle@producao
Connected.
SQL> @taf

 INST# INST_NAME  HOST			       USERNAME   TYPE	     METHOD	FAILED OVER
------ ---------- ---------------------------- ---------- ---------- ---------- -----------
     1 mvdb1	  mvrac1.viniciusdba.com.br    SYSTEM	  SELECT     BASIC	NO

Funcionou!

Agora, vamos fazer um teste de failover.

Vamos executar como teste, um script que traga muitas linhas como resultado, o script é o query.sql:

select a.*, b.*, c.*
from dba_objects a, dba_objects b, dba_objects c;

Como podem ver, faremos um produto cartesiano. Pois bem, a ideia é a seguinte:

  • Já estamos conectados na instância mvdb1;
  • Executaremos nessa instância, o script query.sql;
  • Enquanto a query é executada, baixaremos a instância mvdb1 com a opção abort;
  • A sessão do usuário SYSTEM deverá ser levada para o servidor mvdb2 e a query continuar o fetch do lugar onde parou, isso, sem o usuário perceber;
  • Executaremos o script taf.sql para verificar se ocorreu o failover.

Vamos lá?

Vamos deixar o comando do shutdown abort pronto para ser processado (vai faltar só pressionar [ENTER]). Com o usuário oracle, em qualquer servidor (mvrac1 ou mvrac2):

srvctl stop instance -d mvdb -i mvdb1 -o abort

Assim que a query voltar a processar, cancele o processamento. Se estiver usando o SQL*Plus no Windows, clique em Arquivo / Cancelar, e em seguida, execute o script taf.sql. Caso esteja usando o SQL*Plus em ambiente Unix/Linux, pressione [CTRL] + [C] e, em seguida, execute o script taf.sql. Vejam o resultado:

SQL> @taf

 INST# INST_NAME  HOST			       USERNAME   TYPE	     METHOD	FAILED OVER
------ ---------- ---------------------------- ---------- ---------- ---------- -----------
     2 mvdb2	  mvrac2.viniciusdba.com.br    SYSTEM	  SELECT     BASIC	YES

Observem que agora minha sessão está na instância mvdb2 e a coluna FAILED OVER foi alterada para YES.

Vamos ver um vídeo disso funcionando?

Para ver o vídeo, você precisa ter o Quicktime instalado no seu computador. Baixe ele aqui (é gratuito).

No próximo artigo veremos como configurar o Enterprise Manager.

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®.

Série de artigos sobre Instalação do Oracle RAC:

Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos
Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM
Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 4: Configuração do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 5: Clonagem da VM
Instalação do Oracle RAC 10g Release 2 – Parte 6: Pré-instalação do RAC
Instalação do Oracle RAC 10g Release 2 – Parte 7: Instalação do Oracle Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 8: Instalação do Patchset 10.2.0.4 no Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 9: Instalação do Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 10: Instalação do Patchset 10.2.0.4 no Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 11: Criação do Listener no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 12: Criação do ASM no Cluster

===================================

Olá pessoal!

Vimos no último artigo a criação do ASM no Cluster.

Veremos hoje como criar e configurar o Banco de Dados RAC. Vocês verão que é uma operação bem fácil de ser feita.

Agora, executaremos o assistente para criação do Banco de Dados, o dbca. Há algumas formas de executar esse assistente:

  • Localmente no servidor, através da VMWare Server Console;
  • Remotamente, através de um software que simule um X-Server (existem diversas opções gratuitas na Internet);
  • Remotamente, através de uma estação Linux/Unix/Mac que tenha a parte gráfica (X) habilitado.

Eu usarei a terceira opção, portanto, a partir da minha estação:

vinicius@Viniciuss-MacBook:~$ ssh -X oracle@172.23.10.11
oracle@172.23.10.11's password:
/usr/bin/xauth:  creating new authority file /home/oracle/.Xauthority

Testando para ver se a parte gráfica está funcionando:

[oracle@mvrac1 ~]$ xclock

O teste funcionou! Vejam:

Pronto!

Agora, vamos criar os diretórios de trace da instância de banco de dados nos servidores mvrac1 e mvrac2, com o usuário oracle.

mvrac1:

[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/adump
[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/bdump
[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/cdump
[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/udump
[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/pfile

mvrac2:

[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/adump
[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/bdump
[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/cdump
[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/udump
[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/mvdb/pfile

Vamos executar o dbca:

[oracle@mvrac1 ~]$ dbca

O dbca detectará que a pilha de cluster está em execução, e precisamos selecionar qual será o tipo de ambiente que será configurado:

  • Oracle Real Application Clusters database;
  • Oracle single instance database.

Manteremos a opção Oracle Real Application Clusters database selecionada e clicar em Next.

Manter a opção “Create a Database” e clicar em Next.

A tela acima será exibida, o DBCA solicita que escolhamos em quais nós o banco de dados RAC será criado. Clicar no botão Select All.

Agora, com todos os nós selecionados, clicar em Next.

Nos templates, como já temos o Patchset 10.2.0.4 aplicado, a única opção possível, é a “Custom Database”, onde os datafiles não estão incluídos. Isso porque os templates com os datafiles, nada mais são do que um backup RMAN que acompanha a mídia de instalação do Banco de Dados na versão 10.2.0.1. Portanto, se tentarmos criar o banco de dados usando um template que inclua os datafiles, teremos um erro no meio do processo informando que o banco de dados precisa ser iniciado com a opção “STARTUP UPGRADE”. Portanto, mantenha a opção “Custom Database” selecionada e clique em Next.

Na tela acima devemos especificar o nome global do banco de dados e o prefixo de SID.

Os valores serão iguais:

mvdb

Clicar em Next.

Por enquanto não configuraremos o Enterprise Manager, faremos isso depois. Clicar em Next.

Na tela acima, devemos especificar a senha. Como se trata de um ambiente de testes, mantive a opção “Use the Same Password for All Accounts”. A senha foi definida como oracle. Clicar em Next.

Como a edição utilizada é a Standard Edition, a única opção possível para armazenar o banco de dados é o Automatic Storage Management (ASM). Clicar em Next.

A tela acima exibirá os Disk Groups existentes no ASM. Nesse momento, se necessário, é possível criar outros Disk Groups, no entanto, não o faremos. Basta selecionar o Disk Group DG_DADOS como DG de destino do banco de dados e clicar em Next.

Na tela acima, o Disk Group DG_DADOS foi colocado como área onde o banco de dados será armazenado, clicar em Next.

Não habilitaremos a Flash Recovery Area e nem ativaremos o ArchiveLog Mode no banco de dados. Clicar em Next.

No nosso banco de dados de estudo, não precisamos de todos os componentes. Por isso, na tela acima, só deixei a opção “Enterprise Manager Repository” selecionada. Clicar em Next.

Na tela acima, nós podemos criar os serviços de load balance e failover. Faremos isso posteriormente (nosso próximo artigo). Clicar em Next.

A tela acima nos dará um alerta que precisamos de no mínimo 216MB para a memória disponível para o banco de dados. Esse alerta ocorreu pois a nossa máquina virtual tem apenas 512MB de RAM, não há problema no alerta. Clicar em OK.

Não alteraremos nenhum parâmetro nesse momento. Clicar em Next.

Na tela acima podemos criar mais tablespaces, multiplexar os control files e multiplexar os redo logs. Clicar em Next.

A tela acima é a última tela antes do início da criação do banco de dados. Eu sempre gosto de deixar os scripts de criação do banco de dados guardado. Portanto, clico na opção “Generate Database Creation Scripts”. Depois disso, clicar em Finish.

Uma tela com o resumo sobre a criação do banco de dados será exibida. Clicar em OK.

Uma tela com o progresso da geração dos scripts de criação do banco de dados será exibida. Aguardar.

A tela acima será exibida informando que os scripts foram gerados com sucesso. Clicar em OK.

Uma janela com o progresso da criação do banco de dados será exibida. Aguardar.

Quando o banco de dados for criado, a tela acima será exibida. Basta agora clicar em Exit.

O banco de dados RAC será iniciado. Aguardar. A tela do DBCA será fechada automaticamente.

Vamos verificar e ver se a instância ASM foi criada e se os recursos do cluster foram alterados?

mvrac1:

[oracle@mvrac1 ~]$ ps -ef |grep pmon | grep -v grep
oracle    5342     1  0 Feb22 ?        00:00:21 asm_pmon_+ASM1
oracle   28942     1  0 Feb23 ?        00:00:31 ora_pmon_mvdb1

mvrac2:

[oracle@mvrac2 ~]$ ps -ef |grep pmon | grep -v grep
oracle    5040     1  0 Feb22 ?        00:00:00 asm_pmon_+ASM2
oracle    5268     1  0 Feb23 ?        00:00:00 ora_pmon_mvdb2

Pudemos ver que o banco de dados está em execução nos 2 servidores através das instâncias mvdb1 e mvdb2 respectivamente.

Para verificar o status dos recursos do cluster:

[oracle@mvrac1 ~]$ 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.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

Pronto!

Pudemos ver que foi registrado no cluster uma instância de banco de dados para cada nó, além de um recurso com o final .db, representando o banco de dados.

No próximo artigo veremos como criar e configurar os serviços de failover e load balance, bem como simular uma situação de failover, além de configurar o Enterprise Manager.

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®.

Série de artigos sobre Instalação do Oracle RAC:

Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos
Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM
Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 4: Configuração do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 5: Clonagem da VM
Instalação do Oracle RAC 10g Release 2 – Parte 6: Pré-instalação do RAC
Instalação do Oracle RAC 10g Release 2 – Parte 7: Instalação do Oracle Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 8: Instalação do Patchset 10.2.0.4 no Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 9: Instalação do Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 10: Instalação do Patchset 10.2.0.4 no Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 11: Criação do Listener no Cluster

===================================

Olá pessoal!

Vimos no último artigo a criação do Listener no Cluster.

Veremos hoje como criar e configurar o ASM no ambiente clusterizado. Vocês verão que é uma operação bem fácil de ser feita.

Agora, executaremos o assistente para criação do ASM, o dbca. Há algumas formas de executar esse assistente:

  • Localmente no servidor, através da VMWare Server Console;
  • Remotamente, através de um software que simule um X-Server (existem diversas opções gratuitas na Internet);
  • Remotamente, através de uma estação Linux/Unix/Mac que tenha a parte gráfica (X) habilitado.

Eu usarei a terceira opção, portanto, a partir da minha estação:

vinicius@Viniciuss-MacBook:~$ ssh -X oracle@172.23.10.11
oracle@172.23.10.11's password:
/usr/bin/xauth:  creating new authority file /home/oracle/.Xauthority

Testando para ver se a parte gráfica está funcionando:

[oracle@mvrac1 ~]$ xclock

O teste funcionou! Vejam:

Pronto!

Agora, vamos criar os diretórios de trace da instância ASM nos servidores mvrac1 e mvrac2, com o usuário oracle.

mvrac1:

[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/bdump
[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/cdump
[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/hdump
[oracle@mvrac1 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/pfile

mvrac2:

[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/bdump
[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/cdump
[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/hdump
[oracle@mvrac2 ~]$ mkdir -p /u01/app/oracle/admin/+ASM/pfile

Vamos executar o dbca:

[oracle@mvrac1 ~]$ dbca

O dbca detectará que a pilha de cluster está em execução, e precisamos selecionar qual será o tipo de ambiente que será configurado:

  • Oracle Real Application Clusters database;
  • Oracle single instance database.

Manteremos a opção Oracle Real Application Clusters database selecionada e clicar em Next.

Clicar na opção “Configure Automatic Storage Management” e depois clicar em Next.

Somente o nó mvrac1 estará selecionado pois foi de onde partiu a execução do dbca. Clicar em “Select All”:

Clicar em Next.

Na tela acima deveremos especificar a senha do usuário SYS para a instância ASM. Como estamos utilizando o Standard Edition, não é possível utilizar um SPFILE para o ASM, já que a premissa é que não importa quantos nós (e consequentemente, quantas instâncias) teremos no cluster, quando se usa o SPFILE, esse arquivo deverá ficar armazenado num local compartilhado entre os nós do cluster. No nosso caso, usaremos o arquivo PFILE (init.ora). Portanto, clicar na opção “Create initialization parameter file (IFILE). Clicar em Next.

A janela acima será exibida informando que o DBCA irá criar a instância ASM, e que depois que a instância ASM for criada, poderemos criar os nossos disk groups. Clicar em OK.

A tela acima exibe que a instância ASM está sendo criada.

A tela acima será exibida. Precisamos criar um Disk Group para poder armazenar o banco de dados que criaremos brevemente. Para criar um novo disk group, basta clicar em “Create New”.

Na tela acima, deveremos definir os valores de alguns campos:

  • Disk Group Name: DG_DADOS;
  • Redundancy: External;
  • No campo Select Disk Members, devemos selecionar todos os discos.

Clicar em OK.

A tela acima exibe que o DG está sendo criado.

Podemos ver que o DG_DADOS foi criado e está montado nas duas instâncias ASM (uma em cada nó).

Clicar em Finish.

Clicar em Yes.

Vamos verificar e ver se a instância ASM foi criada e se os recursos do cluster foram alterados?

mvrac1:

[oracle@mvrac1 ~]$ ps -ef |grep pmon
oracle   14645     1  0 19:41 ?        00:00:00 asm_pmon_+ASM1

mvrac2:

[oracle@mvrac2 ~]$ ps -ef |grep pmon
oracle   26486     1  0 19:42 ?        00:00:00 asm_pmon_+ASM2

Pudemos ver que a instância ASM está em execução nos 2 servidores.

Para verificar o status dos recursos do cluster:

[oracle@mvrac1 ~]$ crsstat
HA Resource                                        Target     State
-----------                                        ------     -----
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

Pronto!

Pudemos ver que foi registrado no cluster uma instância ASM para cada nó!

No próximo artigo veremos como criar o banco de dados RAC.

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®.

Série de artigos sobre Instalação do Oracle RAC:

Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos

Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM

Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux

Instalação do Oracle RAC 10g Release 2 – Parte 4: Configuração do Linux

Instalação do Oracle RAC 10g Release 2 – Parte 5: Clonagem da VM

===================================

Olá pessoal!

Falta pouco para que iniciemos a instalação dos softwares Oracle que criarão o nosso ambiente Oracle RAC!

Neste artigo de hoje, veremos os seguintes itens:

  • Criação de equivalência de usuários para acesso SSH;
  • Particionamento dos discos do storage;
  • Marcação das partições dos discos do storage como discos ASM;
  • Criação de raw devices;
  • Criação de block devices.

Vamos lá!

Existem duas formas de se instalar o Oracle Clusterware e o Oracle Database num ambiente clusterizado:

  • Instalação dos binários (Oracle Home’s) em file system clusterizado;
  • Instalação dos binários (Oracle Home’s) em file system local.

Eu particularmente não gosto de instalar os Oracle Home’s em file system clusterizado. Isso porque para a aplicação de patches, incidência de bugs no produto de clusterização de file systems, ou qualquer problema que fuja às mãos do DBA, afeterá TODOS os nós do cluster, já que o Oracle Home enxergado por um nó será o mesmo enxergado pelos outros. Isso acontece porque fisicamente só há um Oracle Home, armazenado num file system clusterizado onde é permitido montar esse mesmo file system em diversos nós com estado de read/write.

Eu sempre faço a instalação dos Oracle Home’s em file systems locais. Motivo: a aplicação de patches se torna individualizada, se o patch for do tipo “rolling”, apenas um nó será interrompido na aplicação do patch, ou seja, o ambiente de banco de dados RAC continuará disponível para os usuários através dos outros nós. Mas não é só pela aplicação dos patches que eu escolho a instalação local. O principal motivo é que cada máquina terá sua cópia de Oracle Home, desta forma, se uma máquina sofrer algum tipo de problema de hardware ou software, o cluster continuará ativo com outros nós. Já que cada nó enxergará o seu Oracle Home.

Pois bem, no entanto, como é feita a instalação dos produtos em file systems locais?

É simples! A instalação dos produtos Oracle serão disparadas a partir de um único nó. O Oracle Universal Installer (OUI) criará o Oracle Home com seus arquivos e subdiretórios necessários, após o “relink” dos binários, o próprio OUI disparará uma cópia desse Oracle Home para os outros nós. Para que isso aconteça, é necessário que o usuário oracle do primeiro servidor, consiga copiar os arquivos para o segundo servidor sem a necessidade de informar senha (já que isso é feito automaticamente). Para que isso seja realizado, criamos o que chamamos de “equivalência de usuário”, onde, o usuário oracle do servidor mvrac1 poderá copiar qualquer arquivo para o servidor mvrac2, considerando que o usuário oracle no servidor mvrac2 tenha os privilégios necessários nos diretórios de destino da cópia, e vice-versa. Quando a equivalência de usuários está criada, qualquer ação de cópia ou login remoto, é feita sem a solicitação de senha pelo sistema operacional.

Bom, a equivalência de usuário poderá ocorrer através de duas maneiras:

  • rsh/rcp;
  • ssh/scp.

A configuração por rsh/rcp é mais simples de ser feita, no entanto, não é a recomendada, já que não é segura. Já no ssh/scp, os dados são enviados pela rede de forma criptografada, o que aumenta a segurança. Inclusive, em muitas empresas, as portas utilizadas em rsh/rcp nem são liberadas no firewall por motivos de segurança. A configuração do ssh/scp é um pouco mais chata, mas é a que veremos aqui por ser a mais segura.

Para realizar a configuração da equivalência de usuários para acesso via SSH, é necessário criar as chaves SSH de acesso ao usuário. Os passos são esses:

  • Criação das chaves do usuário oracle do servidor mvrac1;
  • Criação das chaves do usuário oracle do servidor mvrac2;
  • Criação de um arquivo de chaves autorizadas a acesso, contendo as chaves dos usuários oracle dos servidores mvrac1 e mvrac2. Esse arquivo será utilizado nos dois servidores;
  • Inclusão dos servidores mvrac1 e mvrac2 num arquivo de hosts conhecidos para não mais confirmar o acesso via SSH e isso ser feito automaticamente.

Então, vamos para o primeiro passo, criar as chaves do usuário oracle dos servidores mvrac1 e mvrac2. Com o usuário oracle a partir do servidor mvrac1:

[oracle@mvrac1 ~]$ cd /home/oracle
[oracle@mvrac1 ~]$ mkdir .ssh
[oracle@mvrac1 ~]$ cd .ssh
[oracle@mvrac1 .ssh]$ ssh-keygen -t dsa

Pressionar [ENTER] até voltar para o shell.

[oracle@mvrac1 .ssh]$ ssh-keygen -t rsa

Pressionar [ENTER] até voltar para o shell.

O mesmo precisa ser feito com o usuário oracle no servidor mvrac2:

[oracle@mvrac2 ~]$ cd /home/oracle
[oracle@mvrac2 ~]$ mkdir .ssh
[oracle@mvrac2 ~]$ cd .ssh
[oracle@mvrac2 .ssh]$ ssh-keygen -t dsa

Pressionar [ENTER] até voltar para o shell.

[oracle@mvrac2 .ssh]$ ssh-keygen -t rsa

Pressionar [ENTER] até voltar para o shell.

Agora vamos criar o arquivo com as chaves SSH autorizadas a acessar os servidores. Dentro desse arquivo, haverá o conteúdo das chaves públicas. Começando com o usuário oracle no servidor mvrac1:

[oracle@mvrac1 .ssh]$ cat *.pub >> authorized_keys
[oracle@mvrac1 .ssh]$ ls -l authorized_keys
-rw-r--r-- 1 oracle oinstall 1036 Feb 20 10:24 authorized_keys

Observem que o arquivo authorized_keys tem 1036 bytes de tamanho, e, por enquanto, só existe no servidor mvrac1. Agora, colocaremos dentro desse mesmo arquivo, o conteúdo das chaves públicas do usuário oracle do servidor mvrac2:

[oracle@mvrac1 .ssh]$ ssh mvrac2 cat /home/oracle/.ssh/*.pub >> authorized_keys
The authenticity of host 'mvrac2 (172.23.10.12)' can't be established.
RSA key fingerprint is ee:df:af:11:67:a9:b5:0a:e0:8f:3d:69:2a:3f:ef:6e.
Are you sure you want to continue connecting (yes/no)? yes

Observem que eu tive que confirmar com yes e em seguida, terei que colocar a senha do usuário oracle do servidor mvrac2:

oracle@mvrac2's password:

Vamos verificar o tamanho do arquivo?

[oracle@mvrac1 .ssh]$ ls -l authorized_keys
-rw-r--r-- 1 oracle oinstall 2072 Feb 20 10:26 authorized_keys

Ele agora tem 2072 bytes. Mas, ainda existe somente no servidor mvrac1. Devemos copiá-lo para o servidor mvrac2, nesse mesmo diretório, /home/oracle/.ssh, e, como a equivalência de usuários ainda não existe nos dois servidores (pela falta do arquivo authorized_keys no servidor mvrac2), terei que fornecer a senha do usuário oracle mais uma vez:

[oracle@mvrac1 .ssh]$ scp -p authorized_keys mvrac2:`pwd`
oracle@mvrac2's password:
authorized_keys                                                                                              100% 2072     2.0KB/s   00:00

Bom, como no servidor mvrac1 eu estava no diretório /home/oracle/.ssh. E o arquivo authorized_keys tem que ir para o mesmo diretório no servidor mvrac2, observem que eu usei um comando do Linux dentro do comando scp. O comando foi o pwd. E sempre que quisermos usar um comando dentro de outro comando, deveremos colocá-lo entre crases: `pwd`. Dessa forma, ele executará o comando pwd no servidor mvrac1 e com base na saída do comando (/home/oracle/.ssh), jogará o arquivo dentro desse diretório no outro servidor. Se o diretório não existisse, teríamos um erro.

Vamos testar para ver se a equivalência de usuários está funcionando?

The authenticity of host 'mvrac2.viniciusdba.com.br (172.23.10.12)' can't be established.
RSA key fingerprint is ee:df:af:11:67:a9:b5:0a:e0:8f:3d:69:2a:3f:ef:6e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mvrac2.viniciusdba.com.br' (RSA) to the list of known hosts.
Fri Feb 19 11:37:38 BRST 2010

Observem que eu tive que digitar yes. Mas não precisei mais digitar a senha. Porque?

Não precisei digitar mais a senha porque a equivalência de usuários funcionou. Mas, o host mvrac2.viniciusdba.com.br ainda não é um host conhecido para o SSH. Dessa forma, no servidor mvrac1, com o usuário oracle, deveremos fazer o seguinte:

ssh mvrac1 date
ssh mvrac1-priv date
ssh mvrac1.viniciusdba.com.br date
ssh mvrac1-priv.viniciusdba.com.br date
ssh mvrac2 date
ssh mvrac2-priv date
ssh mvrac2.viniciusdba.com.br date
ssh mvrac2-priv.viniciusdba.com.br date

Em todos as saídas, deveremos sempre confirmar com yes:

Are you sure you want to continue connecting (yes/no)? yes

Vocês viram que mesmo estando no servidor mvrac1, eu preciso fazer o ssh para ele mesmo. Isso é necessário porque quando o Oracle Universal Installer for confirmar se a equivalência de usuário está funcionando, ele fará isso também.

Quando fizer isso em todos os servidores, para confirmar se está tudo OK, basta refazer o comando:

ssh mvrac1 date
ssh mvrac1-priv date
ssh mvrac1.viniciusdba.com.br date
ssh mvrac1-priv.viniciusdba.com.br date
ssh mvrac2 date
ssh mvrac2-priv date
ssh mvrac2.viniciusdba.com.br date
ssh mvrac2-priv.viniciusdba.com.br date

Ele não deverá mais pedir confirmação para nenhum host:

[oracle@mvrac1 .ssh]$ ssh mvrac1 date
Sat Feb 20 11:38:59 BRST 2010
[oracle@mvrac1 .ssh]$ ssh mvrac1-priv date
Sat Feb 20 11:39:00 BRST 2010
[oracle@mvrac1 .ssh]$ ssh mvrac1.viniciusdba.com.br date
Sat Feb 20 11:39:00 BRST 2010
[oracle@mvrac1 .ssh]$ ssh mvrac1-priv.viniciusdba.com.br date
Sat Feb 20 11:39:01 BRST 2010
[oracle@mvrac1 .ssh]$ ssh mvrac2 date
Sat Feb 20 11:39:01 BRST 2010
[oracle@mvrac1 .ssh]$ ssh mvrac2-priv date
Sat Feb 20 11:39:02 BRST 2010
[oracle@mvrac1 .ssh]$ ssh mvrac2.viniciusdba.com.br date
Sat Feb 20 11:39:02 BRST 2010
[oracle@mvrac1 .ssh]$ ssh mvrac2-priv.viniciusdba.com.br date
Sat Feb 20 11:39:03 BRST 2010

Isso criará no servidor mvrac1, dentro do diretório corrente, /home/oracle/.ssh, o arquivo known_hosts (hosts conhecidos):

[oracle@mvrac1 .ssh]$ ls -l known_hosts
-rw-r--r-- 1 oracle oinstall 3246 Feb 20 10:33 known_hosts

Agora basta copiar esse arquivo para o outro servidor:

[oracle@mvrac1 .ssh]$ scp -p known_hosts mvrac2:`pwd`
known_hosts                                                                                                  100% 3246     3.2KB/s   00:00

Pronto! Equivalência de usuários devidamente configurada!

Agora iremos para o particionamento de discos.

Como vocês se lembram, temos 4 discos disponibilizados:

  • 1 disco de 12GB (disco local);
  • 3 discos de 5GB (discos storage).

Não mexeremos nas partições do disco local, pois essas já foram configuradas durante a instalação do Linux.

Temos 3 discos de 5GB. Para instalarmos o Oracle RAC precisamos do seguinte:

  • 3 partições para armazenar Voting Disk;
  • 2 partições para armazenar OCR;
  • 3 partições que serão os discos ASM.

Entrarei em mais detalhes sobre o Voting Disk e o OCR no artigo apropriado.

Até o Red Hat Enterprise Linux 4, geralmente se usava raw devices para o Voting Disk e o OCR. Os raw devices, são dispositivos brutos de caracter e não são buferizados. Porém, no kernel 2.6 o raw device foi depreciado, e no Red Hat Enterprise Linux 5 o serviço rawdevices nem existe mais. Por esse motivo, é necessário que o OCR e o Voting Disk deixem de usar raw devices e passem a usar block devices. Os block devices são dispositivos brutos de nível de acesso a blocos. Além disso, são buferizados. Porém, não há diferenças em desempenho (Metalink Note: 401132.1 – How to install Oracle Clusterware with shared storage on block devices).

Mas, o Oracle Universal Installer do Oracle Clusterware 10.2.0.1 não consegue determinar se os block devices estão compartilhados entre os nós (premissa para que se tenha um ambiente clusterizado), isso acontece porque quando o produto Clusterware 10.2.0.1 foi lançado, ainda não se usava block devices para esse fim. Sendo assim, a instalação precisa ser feita apontando para os dispositivos raw devices, e somente após a aplicação do patchset, que reaponteramos para os block devices. Mas, se eu comentei que os raw devices foram depreciados, como é que instalaremos utilizando esse tipo de dispositivo?

Usaremos um workaround para criar os dispositivos raw devices no RHEL5. Porém, como se trata de um workaround, devemos partir para a solução definitiva o quanto antes, a fim de evitar uma possível incidência de bugs envolvendo a utilização de raw devices. Até mesmo se encontrarmos algum bug envolvendo raw devices, tanto a Oracle quanto a Red Hat citarão que estamos utilizando um cenário que “não é mais certificado”, já que foi anunciada a depreciação desse tipo de dispositivo. Sendo assim, a tabela de partições será a seguinte:

  • 3 partições para armazenar Voting Disk em raw device de 256MB cada;
  • 3 partições para armazenar Voting Disk em block device de 256MB cada;
  • 2 partições para armazenar OCR em raw device de 256MB cada;
  • 2 partições para armazenar OCR em block device de 256MB cada;
  • 3 partições que serão os discos ASM (o restante livre dos discos).

Vamos consultar os discos existentes no servidor mvrac1? Como root:

[root@mvrac1 oracle]# fdisk -l

Disk /dev/sda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1435    11526606   83  Linux
/dev/sda2            1436        1566     1052257+  82  Linux swap / Solaris

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

Disk /dev/sdc: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

Disk /dev/sdd: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

O disco sda é o disco local do servidor mvrac1 (12GB). Já, os discos sdb, sdc e sdd são os discos do storage.

Vamos verificar se esses discos do storage também estão no servidor mvrac2?

[root@mvrac2 oracle]# fdisk -l

Disk /dev/sda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1435    11526606   83  Linux
/dev/sda2            1436        1566     1052257+  82  Linux swap / Solaris

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

Disk /dev/sdc: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

Disk /dev/sdd: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

Como eu preciso criar mais de 4 partições por disco, e no Linux só é possível criar 4 partições primárias, criaremos então uma partição estendida com o tamanho integral do disco, e depois criaremos as partições lógicas para atender as nossas necessidades. Vamos ver como será exatamente a tabela de partições?

Como estamos vendo na tabela de partições acima, os discos sdb e sdc terão 5 partições lógicas e 1 partição extendida. Apenas para manter o padrão de nomenclatura, o disco sdd também terá 1 partição extendida e 3 partições lógicas. Bom, sabendo qual será a tabela de partições, vamos particionar?

Vamos começar pelo disco sdb, como root no servidor mvrac1:

[root@mvrac1 oracle]# fdisk /dev/sdb

Será solicitado o comando: criaremos a partição, então digitaremos a tecla [n] de new partition e depois pressionaremos a tecla [ENTER]:

Command (m for help): n

Em seguida, deveremos especificar se será uma partição estendida [e] ou primária [p]. Nesse caso, criaremos uma partição estendida, portanto, digitaremos a tecla [e] e depois a tecla [ENTER]:

Command action
   e   extended
   p   primary partition (1-4)
e

Deveremos qual partição será (de 1 a 4), nesse caso, escolheremos a partição 1:

Partition number (1-4): 1

Em seguida, deveremos especificar o tamanho da partição, como é a partição estendida, pegará todo o tamanho do disco, basta pressionar [ENTER] para o primeiro cilindro, e [ENTER] para o último cilindro:

First cylinder (1-652, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-652, default 652):
Using default value 652

Maravilha! Agora precisamos criar as partições lógicas, automaticamente, serão atribuídos números a partir de 5. Criar a nova partição, pressionar a tecla [n] e pressionar [ENTER]:

Command (m for help): n

A partição agora será do tipo lógica, basta pressionar a tecla [l] e depois [ENTER]:

Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l

Essa partição terá o tamanho de 256MB, portanto, basta pressionar [ENTER] no primeiro cilindro e no último cilindro, digitar +256M e em seguida pressionar [ENTER]:

First cylinder (1-652, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-652, default 652): +256M

Precisamos criar mais 3 partições de 256MB (colocarei aqui todos os comandos num único bloco):

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (33-652, default 33):
Using default value 33
Last cylinder or +size or +sizeM or +sizeK (33-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (65-652, default 65):
Using default value 65
Last cylinder or +size or +sizeM or +sizeK (65-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (97-652, default 97):
Using default value 97
Last cylinder or +size or +sizeM or +sizeK (97-652, default 652): +256M

Agora precisamos criar a última partição lógica desse disco, basta pressionar [n], depois [ENTER], na hora de especificar o tamanho, basta pressionar [ENTER] para o cilindro inicial e o cilindro final:

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (129-652, default 129):
Using default value 129
Last cylinder or +size or +sizeM or +sizeK (129-652, default 652):
Using default value 652

Para saber se a tabela de partições está correta, basta pressionar [p] e depois [ENTER]:

Command (m for help): p

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         652     5237158+   5  Extended
/dev/sdb5               1          32      256977   83  Linux
/dev/sdb6              33          64      257008+  83  Linux
/dev/sdb7              65          96      257008+  83  Linux
/dev/sdb8              97         128      257008+  83  Linux
/dev/sdb9             129         652     4208998+  83  Linux

Como está correto, temos que gravar a tabela e partições, basta pressionar [w] e depois [ENTER]:

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Como se trata de um disco compartilhado entre os servidores, vamos ver se ele foi também particionado no servidor mvrac2? Como root no servidor mvrac2:

[root@mvrac2 oracle]# fdisk -l /dev/sdb

Disk /dev/sdb: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         652     5237158+   5  Extended
/dev/sdb5               1          32      256977   83  Linux
/dev/sdb6              33          64      257008+  83  Linux
/dev/sdb7              65          96      257008+  83  Linux
/dev/sdb8              97         128      257008+  83  Linux
/dev/sdb9             129         652     4208998+  83  Linux

As partições apareceram no servidor mvrac2! Mas, como o comando foi feito a partir do servidor mvrac1, os devices de cada partição ainda não foram criados no servidor mvrac2 (no diretório /dev/). Há duas formas de criarmos esses devices das partições no servidor mvrac2: reiniciando o servidor, ou, como root:

[root@mvrac2 oracle]# fdisk /dev/sdb

E gravar a tabela de partições, pressionando a tecla [w] e depois [ENTER]:

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Pronto! O disco /dev/sdb foi particionado com sucesso nos 2 servidores. O disco /dev/sdc terá a mesma estrutura de partições que o disco /dev/sdb, colocarei o comando num único bloco:

[root@mvrac1 oracle]# fdisk /dev/sdc

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
e
Partition number (1-4): 1
First cylinder (1-652, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-652, default 652):
Using default value 652

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (1-652, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (33-652, default 33):
Using default value 33
Last cylinder or +size or +sizeM or +sizeK (33-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (65-652, default 65):
Using default value 65
Last cylinder or +size or +sizeM or +sizeK (65-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (97-652, default 97):
Using default value 97
Last cylinder or +size or +sizeM or +sizeK (97-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (129-652, default 129):
Using default value 129
Last cylinder or +size or +sizeM or +sizeK (129-652, default 652):
Using default value 652

Command (m for help): p

Disk /dev/sdc: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         652     5237158+   5  Extended
/dev/sdc5               1          32      256977   83  Linux
/dev/sdc6              33          64      257008+  83  Linux
/dev/sdc7              65          96      257008+  83  Linux
/dev/sdc8              97         128      257008+  83  Linux
/dev/sdc9             129         652     4208998+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Lembrando que no servidor mvrac2 esse disco precisa ter os devices das partições criadas no diretório /dev:

[root@mvrac2 oracle]# fdisk /dev/sdc

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

O disco /dev/sdd terá 1 partição estendida com o tamanho total do disco, 2 partições de 256MB e 1 partição com o restante de espaço disponível no disco (4,5GB):

[root@mvrac1 oracle]# fdisk /dev/sdd

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
e
Partition number (1-4): 1
First cylinder (1-652, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-652, default 652):
Using default value 652

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (1-652, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (33-652, default 33):
Using default value 33
Last cylinder or +size or +sizeM or +sizeK (33-652, default 652): +256M

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (65-652, default 65):
Using default value 65
Last cylinder or +size or +sizeM or +sizeK (65-652, default 652):
Using default value 652

Command (m for help): p

Disk /dev/sdd: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         652     5237158+   5  Extended
/dev/sdd5               1          32      256977   83  Linux
/dev/sdd6              33          64      257008+  83  Linux
/dev/sdd7              65         652     4723078+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

No servidor mvrac2 esse disco precisa ter os devices das partições criadas no diretório /dev:

[root@mvrac2 oracle]# fdisk /dev/sdd

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

As partições foram criadas!

Agora, marcaremos como discos de ASM, as partições reservadas para o ASM. Lembrando que as partições reservadas para o ASM são:

  • /dev/sdb9: 4GB;
  • /dev/sdc9: 4GB;
  • /dev/sdd7: 4,5GB.

Para marcarmos as partições como discos ASM, basta usarmos a ASMLib. A nomenclatura padrão será: ASMDISKx. Como root, no servidor mvrac1:

[root@mvrac1 oracle]# /etc/init.d/oracleasm createdisk ASMDISK1 /dev/sdb9
Marking disk "ASMDISK1" as an ASM disk:                    [  OK  ]
[root@mvrac1 oracle]# /etc/init.d/oracleasm createdisk ASMDISK2 /dev/sdc9
Marking disk "ASMDISK2" as an ASM disk:                    [  OK  ]
[root@mvrac1 oracle]# /etc/init.d/oracleasm createdisk ASMDISK3 /dev/sdd7
Marking disk "ASMDISK3" as an ASM disk:                    [  OK  ]

Para verificar se os discos foram criados, ainda no servidor mvrac1:

[root@mvrac1 oracle]# /etc/init.d/oracleasm listdisks
ASMDISK1
ASMDISK2
ASMDISK3

Agora, precisamos verificar se o servidor mvrac2 enxergará os discos de ASM criados. Antes, precisamos fazer um scan dos discos, no momento do scan, a ASMLib lerá o cabeçalho de todas as partições de disco do servidor:

[root@mvrac2 oracle]# /etc/init.d/oracleasm scandisks
Scanning the system for Oracle ASMLib disks:               [  OK  ]

Agora precisamos verificar se os discos foram realmente enxergados:

[root@mvrac2 oracle]# /etc/init.d/oracleasm listdisks
ASMDISK1
ASMDISK2
ASMDISK3

Pronto! Discos do ASM criados!

Agora falta apenas criar os raw e block devices. Usaremos o utilitário chamado UDEV para isso. Para criarmos esses dispositivos, criaremos arquivos com as regras necessárias no diretório /etc/udev/rules.d. O arquivo precisa ter a extensão .rules.

Criaremos primeiro o arquivo que criará os raw devices:

[root@mvrac1 oracle]# cd /etc/udev/rules.d/
[root@mvrac1 oracle]# vi 62-oracle-raw.rules

O conteúdo do arquivo 62-oracle-raw.rules será:

ACTION=="add", KERNEL=="sdb5", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", KERNEL=="sdb7", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add", KERNEL=="sdc5", RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add", KERNEL=="sdc7", RUN+="/bin/raw /dev/raw/raw4 %N"
ACTION=="add", KERNEL=="sdd5", RUN+="/bin/raw /dev/raw/raw5 %N"
KERNEL=="raw[1-5]*", OWNER="oracle", GROUP="dba", MODE="640"

Agora criaremos o arquivo que criará os block devices:

[root@mvrac1 oracle]# vi 63-oracle-block.rules

O conteúdo do arquivo 63-oracle-block.rules será:

KERNEL=="sdb6", NAME="ocr1", OWNER="root", GROUP="dba", MODE="0640"
KERNEL=="sdb8", NAME="voting1", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="sdc6", NAME="ocr2", OWNER="root", GROUP="dba", MODE="0640"
KERNEL=="sdc8", NAME="voting2", OWNER="oracle", GROUP="dba", MODE="0640"
KERNEL=="sdd6", NAME="voting3",OWNER="oracle",GROUP="dba", MODE="0640"

Após isso, faremos o restart do serviço udev:

[root@mvrac1 rules.d]# start_udev
Starting udev:                                             [  OK  ]

Agora verificaremos se os devices foram criados:

[root@mvrac1 rules.d]# ls -l /dev/ocr* /dev/voting* /dev/raw/raw*
brw-r----- 1 oracle dba   8, 22 Feb 20 17:34 /dev/ocr1
brw-r----- 1 oracle dba   8, 38 Feb 20 17:35 /dev/ocr2
crw-r----- 1 oracle dba 162,  1 Feb 20 17:36 /dev/raw/raw1
crw-r----- 1 oracle dba 162,  2 Feb 20 17:36 /dev/raw/raw2
crw-r----- 1 oracle dba 162,  3 Feb 20 17:36 /dev/raw/raw3
crw-r----- 1 oracle dba 162,  4 Feb 20 17:36 /dev/raw/raw4
crw-r----- 1 oracle dba 162,  5 Feb 20 17:36 /dev/raw/raw5
brw-r----- 1 root   dba   8, 24 Feb 20 17:34 /dev/voting1
brw-r----- 1 root   dba   8, 40 Feb 20 17:35 /dev/voting2
brw-r----- 1 oracle dba   8, 54 Feb 20 17:35 /dev/voting3

Os dispositivos foram criados!

Agora precisamos copiar esses arquivos para o servidor mvrac2:

[root@mvrac1 rules.d]# scp -p *ora*.rules mvrac2:`pwd`
The authenticity of host 'mvrac2 (172.23.10.12)' can't be established.
RSA key fingerprint is ee:df:af:11:67:a9:b5:0a:e0:8f:3d:69:2a:3f:ef:6e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mvrac2,172.23.10.12' (RSA) to the list of known hosts.
root@mvrac2's password:
62-oracle-raw.rules                       100%  386     0.4KB/s   00:00
63-oracle-block.rules                     100%  359     0.4KB/s   00:00

Teremos que confirmar com yes, e depois digitar a senha do usuário root. Isso acontece porque criamos a equivalência de usuário para o usuário oracle. O root não precisa ter a equivalência de usuário criada.

Após copiar os arquivos para o servidor mvrac2, teremos que reiniciar o serviço udev no servidor mvrac2:

[root@mvrac2 rules.d]# start_udev
Starting udev:                                             [  OK  ]

Agora verificaremos se os devices foram criados:

Agora verificaremos se os devices foram criados:

[root@mvrac2 rules.d]# ls -l /dev/ocr* /dev/voting* /dev/raw/raw*
brw-r----- 1 oracle dba   8, 22 Feb 20 17:34 /dev/ocr1
brw-r----- 1 oracle dba   8, 38 Feb 20 17:35 /dev/ocr2
crw-r----- 1 oracle dba 162,  1 Feb 20 17:36 /dev/raw/raw1
crw-r----- 1 oracle dba 162,  2 Feb 20 17:36 /dev/raw/raw2
crw-r----- 1 oracle dba 162,  3 Feb 20 17:36 /dev/raw/raw3
crw-r----- 1 oracle dba 162,  4 Feb 20 17:36 /dev/raw/raw4
crw-r----- 1 oracle dba 162,  5 Feb 20 17:36 /dev/raw/raw5
brw-r----- 1 root   dba   8, 24 Feb 20 17:34 /dev/voting1
brw-r----- 1 root   dba   8, 40 Feb 20 17:35 /dev/voting2
brw-r----- 1 oracle dba   8, 54 Feb 20 17:35 /dev/voting3

Pronto! Devices criados!

Nesse momento estamos prontos para iniciar a instalação dos produtos Oracle!

Nos veremos no próximo post, semana que vem!

Um abraço!

Vinicius

——————————-

PS:

Observação:

Apenas para ficar claro, sobre as partições de discos, num ambiente corporativo eu costumo pedir o seguinte:

  • 1 disco (LUN) de 2GB para utilizar as partições raw devices (esse disco posteriormente será eliminado);
  • 2 discos (LUN’s) de 512MB para utilizar as partições block devices;
  • 1 disco (LUN) de 256MB para utilizar a partição block device;
  • Quantidade “X de discos para ASM, aí vai depender do tamanho do banco de dados.






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

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®.

Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos
Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM
Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux

===================================

Olá pessoal!

Vimos no último artigo como instalar o Linux.

Pois bem, agora precisamos configurar o nosso sistema operacional para atender os pré-requisitos necessários para instalar o software Oracle de banco de dados e clusterização.

Os pré-requisitos são citados na Documentação Oficial:

No entanto, quando o software de banco de dados 10g Release 2 foi lançado, ainda não estava disponível no mercado o Red Hat Enterprise Linux 5. Por esse motivo, nos documentos acima, essa versão de sistema operacional não é citada. Somente é possível encontrar esses pré-requisitos no Metalink (Oracle Support). Para acesso ao Metalink, é necessário ter um contrato de suporte junto à Oracle (CSI). No Metalink, é possível encontrar notas de suporte atualizadas para as versões de banco ainda suportadas pela Oracle.

A Nota 419646.1 cita os pré-requisitos necessários para instalar o Oracle 10g Release 2 no Red Hat Enterprise Linux 5 32bit.

Vamos lá, para os pacotes de sistema operacional (os RPM’s), a lista dos pré-requisitos é a seguinte:

  • binutils-2.17.50.0.6-2.el5;
  • compat-libstdc++-33-3.2.3-61;
  • elfutils-libelf-0.125-3.el5;
  • elfutils-libelf-devel-0.125;
  • gcc-4.1.1-52;
  • gcc-c++-4.1.1-52;
  • glibc-2.5-12;
  • glibc-common-2.5-12;
  • glibc-devel-2.5-12;
  • glibc-headers-2.5-12;
  • libaio-0.3.106;
  • libaio-devel-0.3.106;
  • libgcc-4.1.1-52;
  • libstdc++-4.1.1 ;
  • libstdc++-devel-4.1.1-52.e15;
  • make-3.81-1.1;
  • sysstat-7.0.0;
  • unixODBC-2.2.11;
  • unixODBC-devel-2.2.11.

Para pesquisar se temos os pacotes, uma das melhores maneiras é utilizando a seguinte sintaxe, com o binário rpm com o usuário root:

rpm -qa --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})\n" | grep package_name

Como exemplo, vou pesquisar o pacote binutils:

rpm -qa --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})\n" | grep binutils

A saída do comando será:

binutils-2.17.50.0.6.9.el5 (i386)

De acordo com a lista acima, e com a instalação do sistema operacional realizada, os únicos pacotes que ainda precisamos instalar são os seguintes:

elfutils-libelf-devel-0.125;
libaio-devel-0.3.106;
unixODBC-2.2.11;
unixODBC-devel-2.2.11.

Para instalar esses pacotes, primeiramente devemos apontar na Console da VMWare que essa máquina virtual utilizará a imagem ISO do Linux:

Após isso, deveremos montar o DVD no sistema operacional, acessar o DVD e instalar os pacotes restantes:

[root@mvrac1 ~]# mount /dev/hdc /media
mount: block device /dev/hdc is write-protected, mounting read-only
[root@mvrac1 ~]# cd /media/Server/
[root@mvrac1 Server]# rpm -ivh elfutils-libelf-devel*
warning: elfutils-libelf-devel-0.137-3.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ############################### [100%]
   1:elfutils-libelf-devel-s############################### [ 50%]
   2:elfutils-libelf-devel  ############################### [100%]
[root@mvrac1 Server]# rpm -ivh libaio-devel*
warning: libaio-devel-0.3.106-3.2.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ############################### [100%]
   1:libaio-devel           ############################### [100%]
[root@mvrac1 Server]# rpm -ivh unixODBC*
warning: unixODBC-2.2.11-7.1.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ############################### [100%]
   1:unixODBC               ############################### [ 33%]
   2:unixODBC-devel         ############################### [ 67%]
   3:unixODBC-kde           ############################### [100%]

Pronto! Uma parte dos pré-requisitos foi concluída!

O próximo passo serão os parâmetros de kernel.

Os seguintes parâmetros precisam ser adicionados ao arquivo de configuração /etc/sysctl.conf

kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 1048576
net.core.rmem_max = 1048576
net.core.wmem_default = 262144
net.core.wmem_max = 262144

Após colocar esses parâmetros no arquivo acima especificado, para efetivar os parâmetros no sistema operacional, o seguinte comando deverá ser executado como root:

sysctl -p

Agora, faremos a criação dos grupos e usuário no sistema operacional. Para o ambiente com Oracle RAC, a Oracle solicita que todos os usuários e grupos envolvidos na instalação do software Oracle, possuam os mesmos ID’s em todas as máquinas. Por isso, os grupos oinstall, dba e o usuário oracle serão criados da seguinte forma:

groupadd -g 1521 oinstall
groupadd -g 1522 dba
useradd -g oinstall -G dba -u 1521 oracle

A senha do usuário oracle deverá ser definida:

[root@mvrac1 Server]# passwd oracle
Changing password for user oracle.
New UNIX password:
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:
passwd: all authentication tokens updated successfully

Com os grupos e usuário criados, agora os diretórios deverão ser criados:

mkdir -p /u01/app/oracle/oraInventory
mkdir -p /u01/app/oracle/product/10.2.0/crs
mkdir -p /u01/app/oracle/product/10.2.0/db_1
chown -R oracle:oinstall /u01

Num ambiente corporativo, é recomendado instalar um Oracle Home para o ASM separadamente do Oracle Home do banco de dados. Como estamos num ambiente virtualizado, utilizarei o ASM e o banco de dados no mesmo Oracle Home.

Agora, o arquivo /etc/security/limits.conf deverá ser editado e as seguintes linhas deverão ser adicionadas:

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

O próximo arquivo a ser editado é o /etc/pam.d/login:

 session required pam_limits.so

O próximo arquivo a ser editado é o /etc/profile:

if [ $USER = "oracle" ]; then
	ulimit -u 16384
	ulimit -n 65536
fi

O módulo hangcheck-timer deverá ser carregado no kernel. Além disso, ele deverá ser carregado automaticamente quando o servidor for iniciado novamente. Num próximo artigo eu definirei em detalhes sobre o que é o hangcheck-timer. Editar o arquivo /etc/rc.d/rc.local e inserir a seguinte linha no final arquivo:

/sbin/insmod /lib/modules/2.6.18-128.el5/kernel/drivers/char/hangcheck-timer.ko hangcheck_tick=1 hangcheck_margin=10 hangcheck_reboot=1

Após isso, executar o arquivo e verificar se o módulo foi carregado:

[root@mvrac1 ~]# /etc/rc.d/rc.local
[root@mvrac1 ~]# lsmod |grep hangcheck
hangcheck_timer         8025  0

Outro ponto importante num ambiente clusterizado, é o horário dos servidores. Como os servidores vão “hospedar” o mesmo banco de dados, é importante que o horário desses servidores estejam sincronizados. Por este motivo, é recomendado utilizar um servidor NTP (Network Time Protocol). Muitas empresas têm servidores NTP internamente, na sua própria rede, e na grande maioria das vezes, esses servidores NTP apontam para um servidor NTP externo, muito preciso, brasileiro, que é o servidor da Rede Nacional de Ensino e Pesquisa (RNP).

Se a empresa não tiver um servidor NTP interno, e os servidores de banco de dados conseguirem acessar a Internet, basta colocar a seguinte informação na crontab do usuário root no servidor de banco de dados:

 * * * * * /usr/sbin/ntpdate ntp.cais.rnp.br >/dev/null 2>/dev/null

Com isso, o servidor sempre terá a hora sincronizada.

Para garantir que o serviço está OK, ou seja, que o servidor de banco de dados consegue utilizar o binário ntpdate para acessar o servidor da RNP, basta executar o seguinte comando como root:

[root@mvrac1 ~]# ntpdate ntp.cais.rnp.br
18 Feb 00:06:46 ntpdate[23646]: step time server 200.144.121.33 offset 90541.348582 sec

O próximo passo é configurar o arquivo /etc/hosts do servidor. Nesse arquivo, teremos a configuração de todos os servidores que farão parte do cluster:

# ========================================
# Arquivo /etc/hosts configurado para utilizacao do Oracle RAC
# Configurado por Marcus Vinicius
# 18/02/2010
# ========================================

# Localhost
127.0.0.1         localhost.localdomain      localhost

# Oracle RAC 10g
# -----------------

# Rede Publica
172.23.10.11   mvrac1.viniciusdba.com.br       mvrac1
172.23.10.12   mvrac2.viniciusdba.com.br       mvrac2

# InterConnect - Conexao Privada
10.0.0.11      mvrac1-priv.viniciusdba.com.br  mvrac1-priv
10.0.0.12      mvrac2-priv.viniciusdba.com.br  mvrac2-priv

# Virtual IP's
172.23.10.21   mvrac1-vip.viniciusdba.com.br   mvrac1-vip
172.23.10.22   mvrac2-vip.viniciusdba.com.br   mvrac2-vip

Por enquanto, para finalizarmos os pré-requisitos, falta instalarmos e configurarmos a ASMLib. Eu explicarei o porquê de utilizarmos essa LIB num artigo posterior.

Para baixarmos a ASMLib, precisamos acessar o seguinte link:

Oracle ASMLib Page / Downloads / Red Hat Enterprise Linux 5 AS*.

Deveremos encontrar a seção na página que trata da arquitetura 32bit:

Intel IA32 (x86) Architecture

Após encontrarmos, os dois primeiros arquivos deverão ser baixados:

Após baixar esses dois arquivos, procurar a versão correta da Lib para o Kernel utilizado no sistema operacional: 2.6.18-128.el5. Pode ser que você encontre variações como 2.6.18-128.1.1.el5 e assim por diante. Ignore essas versões, encontre a versão exata do Kernel:

Baixar os três arquivos, transferí-los via SCP/FTP para o servidor e instalá-los, com o usuário root:

[root@mvrac1 ~]# rpm -ivh oracleasm*
warning: oracleasm-2.6.18-128.el5-2.0.5-1.el5.i686.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ############################### [100%]
   1:oracleasm-support      ############################### [ 33%]
   2:oracleasm-2.6.18-128.el############################### [ 67%]
   3:oracleasmlib           ############################### [100%]

Após instalar os pacotes, deveremos configurar a ASMLib no sistema operacional:

[root@mvrac1 ~]# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting  without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface []: oracle
Default group to own the driver interface []: dba
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done
Initializing the Oracle ASMLib driver:                     [  OK  ]
Scanning the system for Oracle ASMLib disks:               [  OK  ]

Pronto! A primeira fase de pré-requisitos foi concluída! Falta agora particionar os discos e criar a equivalência de usuários entre os servidores que farão parte do cluster.
Como estamos num ambiente virtualizado, podemos agora baixar esse servidor, para clonar esse servidor para a nova máquina virtual (mvrac2).

Baixar o servidor:

 shutdown -h now

No próximo artigo veremos como clonar esse servidor para criar a nova máquina virtual.

Abraços!

Vinicius

 

———–

* Links do ASMLIb atualizados em 19/05/2011. Obrigado, Mônica!







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

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®.