Tag Archive: srvctl

Olá pessoal!

Hoje voltamos com a série de artigos que trata sobre as rotinas administrativas do Clusterware.

Hoje veremos com um pouco mais de detalhes o srvctl.

O srvctl, também é conhecido como service control.

Algumas características do srvctl:

  • Pode ser executado a partir de qualquer nó;
  • Deve ser executado com o usuário oracle;
  • Controla todos os nós;
  • Comando preferencial para interromper e iniciar recursos do cluster;
  • Administra nodeapps, listeners, ASM, instâncias, bancos de dados e serviços de banco de dados.

Alguns exemplos de uso:

Interromper o serviço producao do banco de dados mvdb:

srvctl stop service -d mvdb -s producao

Interromper a instância MVDB1 do banco de dados mvdb:

srvctl stop instance -d mvdb -i mvdb1

Interromper o ASM do nó mvrac1:

srvctl stop asm -n mvrac1

Interromper o listener do nó mvrac1:

srvctl stop listener -n mvrac1

Interromper os nodeapps do nó mvrac1:

srvctl stop nodeapps -n mvrac1

Interromper a instância mvdb1 do banco de dados mvdb com shutdown abort:

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

Iniciar os nodeapps do nó mvdb1:

srvctl start nodeapps -n mvrac1

O Listener é iniciado/interrompido junto com os nodeapps.

Iniciar o listener:

srvctl start listener -n mvrac1

Iniciar o ASM do nó mvrac1:

srvctl start asm -n mvrac1

Iniciar a instância mvdb1 do banco de dados mvdb:

srvctl start instance -d mvdb -i mvdb1

Iniciar o serviço producao do banco de dados mvdb:

srvctl start service -d mvdb -s producao

Interromper o banco de dados mvdb:

srvctl stop database -d mvdb

Iniciar o banco de dados mvdb:

srvctl start database -d mvdb

Observem que é muito prático interromper o banco de dados mvdb a partir de um único comando. Se o DBA quiser interromper o banco de dados através do SQL*Plus, o comando shutdown immediate será realizado somente na instância em que estiver conectado, ou seja, o banco de dados continuará em execução nas outras instâncias. Se o BD estivesse em execução em 6 instâncias/nós, e o DBA quisesse baixar o BD através do SQL*Plus, ele teria que emitir o comando shutdown immediate seis vezes. Já com o srvctl, apenas um comando é necessário.

Se o recurso a ser baixado é uma instância, o banco de dados também deverá ser especificado.

Se o recurso a ser baixado for listener/nodeapps/ASM, basta especificar o nó onde a ação deve ser realizada.

Vamos supor a seguinte situação:

Já temos nosso ambiente em Oracle RAC Standard Edition (máximo de 4 sockets de CPU por cluster), com 2 nós, na empresa onde trabalhamos.

Este ambiente é bem parecido com o ambiente que temos aqui no blog:

  • 2 nós;
  • 1 banco de dados;
    • 2 instâncias de BD.

Este ambiente já existe há 5 anos. E, por conta disso, a empresa decide comprar servidores novos, para obter ganho de processamento e, além disso, ter hardware novo nunca é ruim, não é mesmo?

Como serão adquiridos servidores novos, desejamos realizar instalações novas do Clusterware e Patchset, e trazer o banco de dados que roda nos “servidores antigos” para estes novos servidores.

Portanto, o primeiro passo é instalar o Clusterware nos novos servidores, com IP’s públicos e VIP’s diferentes do cluster atual, para não haver impacto para os usuários.

Com o Clusterware instalado nos novos servidores, faremos a instalação do ASM e criação dos respectivos DG’s (respeitando inclusive os nomes, de preferência). O próximo passo é migrar o banco de dados para o novo cluster.

Desde que os IP’s públicos e VIP’s do novo cluster não estejam registrados no OCR, podemos deixar os servidores com os mesmos hostnames do cluster antigo (mvrac1 e mvrac2, mvrac1-vip, mvrac2-vip, e assim por diante).

Podemos realizar estas tarefas com o ambiente antigo/atual de cluster em operação. Quando levarmos o backup do BD para o novo cluster, podemos deixar este BD montado e aplicando os archivelogs gerados no cluster antigo/atual, como se fosse um standby.

No entanto, esse banco de dados no novo cluster ainda não está registrado no OCR. Com isso, não é possível realizar as operações de load balance e failover. Além disso, os IP’s VIP que ainda rodam no cluster “antigo”, devem ir para o novo cluster.

Neste momento, devemos baixar BD e ASM do cluster antigo, além dos nodeapps.

Em seguida, faremos o OPEN do banco de dados no cluster novo.

Portanto, após subir o banco de dados Oracle RAC nos servidores novos, o seguinte passo deve ser feito:

Registrar o banco de dados no OCR:

srvctl add database -d mvdb -o /u01/app/oracle/product/10.2.0/db_1 -p +DG_DADOS/spfilemvdb.ora -s open -y automatic

Registrar as instâncias mvdb1 e mvdb2 no OCR:

srvtl add instance -d mvdb -i mvdb1 -n mvrac1
srvtl add instance -d mvdb -i mvdb2 -n mvrac2

Se o registro foi feito incorretamente, basta excluir e refazer.

Para remover o BD do OCR:

srvctl remove database -d mvdb

Para remover as instâncias do OCR:

srvctl remove instance -d mvdb -i mvdb1 -n mvrac1
srvctl remove instance -d mvdb -i mvdb2 -n mvrac2

Para deixar o recurso de startup automático do banco desabilitado:

srvctl modify database -d mvdb -y manual

Alterar os VIP’s dos 2 nós no cluster novo:

srvctl modify nodeapps -n mvrac1 -A 172.23.10.21/255.255.255.0/eth0
srvctl modify nodeapps -n mvrac2 -A 172.23.10.22/255.255.255.0/eth0

Alterar o arquivo /etc/hosts dos servidores do cluster novo para refletir a mudança do VIP realizada acima.

Subir os nodeapps no cluster novo.

Pronto! Neste momento o cluster novo já responde pelos mesmos nomes e IP’s do cluster antigo.

Caso queira deixar o ambiente de cluster do cluster antigo operacional, basta alterar os VIP’s através do srvctl, como realizado acima, só não esqueça de alterar o arquivo /etc/hosts após a mudança.

Neste artigo vimos como iniciar e interromper recursos no cluster. Além disso, vimos também como registrar, remover e modificar recursos no OCR.

Espero que este artigo seja útil!

Continuaremos com a continuação desta série em breve.

Um abraço!

Vinicius







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

Copyright:

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

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

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

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


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

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

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

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

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

Olá pessoal!

Depois de um longo tempo sem atualizar o blog, voltamos hoje com o início da série de artigos que tratará sobre as rotinas administrativas do Clusterware.

Esse primeiro artigo tratará sobre o start e stop do Clusterware.

Não explicarei em detalhes sobre os binários que utilizaremos para parar os recursos do cluster, pois isso será tratado nos artigos subsequentes. O objetivo deste artigo é deixar você preparado para inicializar e interromper os recursos individualmente ou globalmente.

Vamos lá?

Começaremos com a interrupção de todos os recursos do cluster num nó específico. Para isso, é necessário utilizar o binário crsctl que está em $ORA_CRS_HOME, a execução deste binário deve ser feita através do usuário root.

O atual status dos componentes 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

Podemos observar que todos os recursos do cluster estão ONLINE. Tanto no nó mvrac1 quanto no mvrac2.

Vamos supor que a equipe de infra-estrutura precisa realizar a atualização de um firmware de uma placa do servidor. Ou trocar um processador, ou aumentar memória, enfim, qualquer atividade que exija a interrupção do servidor.

Como utilizamos o Oracle RAC, o ambiente de Banco de Dados não ficará indisponível pois temos dois servidores que executam o banco de dados, desta forma, podemos interromper tranquilamente o servidor que passará pela manutenção, com a garantia que o ambiente de banco de dados continuará disponível aos usuários.

O servidor que passará pela manutenção é o mvrac1. Desta forma, com o usuário root, executaremos o binário crsctl da seguinte forma:

[root@mvrac1 ~]# /u01/app/oracle/product/10.2.0/crs/bin/crsctl stop crs
Stopping resources. This could take several minutes.
Successfully stopped CRS resources.
Stopping CSSD.
Shutting down CSS daemon.
Shutdown request successfully issued.

Vejam que a sintaxe é: crsctl stop crs.

Eu estou solicitando através do crsctl interromper todo o crs (cluster), mas o binário crsctl quando utilizado com as palavras-chave start ou stop, tratará apenas do nó onde é executado, ou seja, interromperá todos os recursos no nó onde o “crsctl stop crs” foi executado, neste caso, o nó mvrac1.

Vamos agora no servidor mvrac2 verificar o status dos recursos do cluster após a interrupção dos recursos no nó mvrac1.

[oracle@mvrac2 crsd]$ crsstat
HA Resource                                        Target     State
-----------                                        ------     -----
ora.mvdb.db                                        ONLINE     ONLINE on mvrac2
ora.mvdb.mvdb1.inst                                ONLINE     OFFLINE
ora.mvdb.mvdb2.inst                                ONLINE     ONLINE on mvrac2
ora.mvdb.producao.cs                               ONLINE     ONLINE on mvrac2
ora.mvdb.producao.mvdb1.srv                        ONLINE     OFFLINE
ora.mvdb.producao.mvdb2.srv                        ONLINE     ONLINE on mvrac2
ora.mvrac1.ASM1.asm                                ONLINE     OFFLINE
ora.mvrac1.LISTENER_MVRAC1.lsnr                    ONLINE     OFFLINE
ora.mvrac1.gsd                                     ONLINE     OFFLINE
ora.mvrac1.ons                                     ONLINE     OFFLINE
ora.mvrac1.vip                                     ONLINE     ONLINE on mvrac2
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

Observem que o recurso ora.mvrac1.vip que é o recurso que controla o VIP (IP Virtual) do nó mvrac1 está agora online no servidor mvrac2. Esse é o comportamento padrão do Clusterware. Quando os recursos são interrompidos através do crsctl, o IP virtual é remanejado para outro servidor que estiver ativo no cluster.

Os recursos são interrompidos na seguinte ordem:

1) Serviços de BD;

2) BD;

3) ASM;

4) Nodeapps (Listener, GSD, ONS e VIP).

Muito bem, para inicializar os recursos do cluster no nó mvrac1, basta utilizar o crsctl com a palavra-chave start, com o usuário root:

[root@mvrac1 ~]# /u01/app/oracle/product/10.2.0/crs/bin/crsctl start crs
Attempting to start CRS stack
The CRS stack will be started shortly

Após isso, vamos verificar o status dos recursos do cluster:

[oracle@mvrac1 ~]$ crsstat
HA Resource                                        Target     State
-----------                                        ------     -----
ora.mvdb.db                                        ONLINE     ONLINE on mvrac2
ora.mvdb.mvdb1.inst                                ONLINE     ONLINE on mvrac1
ora.mvdb.mvdb2.inst                                ONLINE     ONLINE on mvrac2
ora.mvdb.producao.cs                               ONLINE     ONLINE on mvrac2
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

Os recursos são inicializados na seguinte ordem:

1) Nodeapps (Listener, GSD, ONS e VIP);

2) ASM;

3) BD;

4) Serviços de BD.

Agora que já sabemos inicializar/interromper todos os recursos do cluster num nó, vamos ver como interrompemos serviços específicos do cluster num nó, ou então em todo o cluster.

Vamos supor que eu precise alterar um parâmetro somente numa instância, como por exemplo, a quantidade definida para a SGA. A instância que terá o parâmetro alterado é a instância mvdb1, que está em execução no servidor mvrac1:

SQL> alter system set sga_max_size=175m scope=spfile sid='mvdb1';

System altered.

SQL> alter system set sga_target=175m scope=spfile sid='mvdb1';

System altered.

Após alterar o parâmetro, é necessário reiniciar a instância.

Agora utilizaremos o binário srvctl, neste momento, verificaremos apenas as funções de start/stop deste binário. Ele é utilizado para interromper recursos específicos, em todo o cluster ou apenas em nós específicos.

  • Instância de BD:

Para interromper a instância mvdb1, basta executar o seguinte:

[oracle@mvrac1 ~]$ srvctl stop instance -d mvdb -i mvdb1

A sintaxe é: srvctl stop instance -d <DBNAME> -i <INSTANCE_NAME> -o <OPTION_SHUTDOWN>

Exemplos:

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

A opção default para o shutdown é a IMMEDIATE.

Para fazer o start o srvctl segue a mesma lógica:

[oracle@mvrac1 ~]$ srvctl start instance -d mvdb -i mvdb1

A sintaxe é: srvctl start instance -d <DBNAME> -i <INSTANCE_NAME> -o <OPTION_STARTUP>

Exemplos:

srvctl start instance -d mvdb -i mvdb1 -o nomount
srvctl start instance -d mvdb -i mvdb1 -o mount

A opção default para o shutdown é a OPEN.

  • Banco de Dados

Assim como baixamos apenas uma instância, podemos também realizar o stop/start de todo o banco de dados, ou seja, todas as instâncias associadas a este banco de dados:

[oracle@mvrac1 ~]$ srvctl stop database -d mvdb

Sua sintaxe é: srvctl stop database -d <DBNAME> -o <OPTION_SHUTDOWN>

Exemplos:

srvctl stop database -d mvdb -o abort
srvctl stop database -d mvdb -o transactional

A opção default para o shutdown é a IMMEDIATE.

Para fazer o startup do banco de dados:

[oracle@mvrac1 ~]$ srvctl start database -d mvdb

Sua sintaxe é: srvctl start database -d <DBNAME> -o <OPTION_STARTUP>

Exemplos:

srvctl start database -d mvdb -o nomount
srvctl start database -d mvdb -o mount

A opção default para o shutdown é a OPEN.

  • ASM

Para interromper o ASM:

[oracle@mvrac1 ~]$ srvctl stop asm -n mvrac1

A sintaxe deste comando é: srvctl stop asm -n <NODENAME>.

Como só há APENAS uma instância ASM por nó, é necessário especificar o nó quando a instância ASM for interrompida.

Para inicializar o ASM:

[oracle@mvrac1 ~]$ srvctl start asm -n mvrac1

A sintaxe deste comando é: srvctl start asm -n <NODENAME>.

Como só há APENAS uma instância ASM por nó, é necessário especificar o nó quando a instância ASM for inicializada.

  • Nodeapps

Para interromper os nodeapps:

[oracle@mvrac1 ~]$ srvctl stop nodeapps -n mvrac1

A sintaxe deste comando é: srvctl stop nodeapps -n <NODENAME> .

Para inicializar os nodeapps:

[oracle@mvrac1 ~]$ srvctl start nodeapps -n mvrac1

A sintaxe deste comando é: srvctl start nodeapps -n <NODENAME>.

  • Listener

Mesmo o Listener fazendo parte dos nodeapps, também é possível pará-lo individualmente com o srvctl.

Para interromper o Listener:

[oracle@mvrac1 ~]$ srvctl stop listener -n mvrac1

A sintaxe deste comando é: srvctl stop listener -n <NODENAME>.

Para inicializar o Listener:

[oracle@mvrac1 ~]$ srvctl start listener -n mvrac1

A sintaxe deste comando é: srvctl start listener -n <NODENAME>.

Bom, por hoje é só. No próximo artigo discutiremos com mais detalhes a utilização do crsctl (pois este não serve somente para interromper e inicializar os recursos do cluster).

Espero que este artigo seja útil.

Caso alguém tenha alguma dúvida, entre em contato através do comentário neste artigo ou então mande um e-mail para blog@viniciusdba.com.br.

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

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

Olá pessoal!

Nesse artigo instalaremos o Oracle Clusterware 10.2.0.1. Com isso, já subiremos no sistema operacional dos servidores mvrac1 e mvrac2 a camada de cluster necessária para a criação de um banco de dados Oracle RAC. Alguns pontos importantes:

  • A instalação do Oracle Home será local, ou seja, cada servidor terá uma cópia do Oracle Home;
  • Cada servidor precisa de pelo menos duas placas de rede:
    • Rede Pública: para subir o endereço IP Virtual, o chamado VIP;
    • Rede Privada: para subir o endereço IP da rede privada entre os nós, o chamado InterConnect.
  • Precisamos de discos compartilhados entre os servidores:
    • Armazenamento do OCR;
    • Armazenamento do Voting Disk;
    • Discos ASM.
  • Os usuários oracle de cada servidor precisarão ter equivalência de usuário entre si.

Bom, vamos lá?

Na tela da VMWare Server Console, deveremos clicar duas vezes no ícone do CD-ROM (identificado pela seta vermelha).

Eu fiz uma imagem ISO com alguns softwares Oracle, portanto, na tela acima, deveremos manter a opção “Use ISO image:” marcada, e clicar em Browse, para escolhermos a mídia do Oracle:

Basta selecionar a imagem ISO, e clicar em Open.

Agora, precisamos montar esse CD no servidor. Como root no servidor mvrac1:

[root@mvrac1 ~]# mount /dev/hdc /media
mount: block device /dev/hdc is write-protected, mounting read-only

Para verificar se o disco foi montado:

[root@mvrac1 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              11G  2.4G  7.8G  24% /
tmpfs                 252M     0  252M   0% /dev/shm
/dev/hdc              3.1G  3.1G     0 100% /media

Com o disco montado, precisamos acessá-lo:

[root@mvrac1 ~]# cd /media/Ora10.2.0.1

Vamos ver o conteúdo do disco:

[root@mvrac1 Ora10.2.0.1]# ls -l
total 8
dr-xr-xr-x 6 root root 2048 May 21  2008 client
dr-xr-xr-x 9 root root 2048 May 21  2008 clusterware
dr-xr-xr-x 6 root root 2048 May 21  2008 companion
dr-xr-xr-x 6 root root 2048 May 21  2008 database

Agora copiaremos o diretório clusterware para o diretório /home/oracle:

[root@mvrac1 Ora10.2.0.1]# cp -rp clusterware/ /home/oracle/

Agora precisamos acertar as permissões, pois o diretório foi copiado como root:

[root@mvrac1 ~]# chown -R oracle:oinstall /home/oracle/*

Agora, iniciaremos a instalação. Há algumas formas de realizar a instalação:

  • 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:

Bom, apenas para facilitar a instalação, vamos definir algumas variáveis de ambiente, já colocando-as no arquivo .bash_profile:

[oracle@mvrac1 ~]$ vi .bash_profile

O conteúdo do arquivo deverá ter o seguinte:

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

export ORACLE_BASE=/u01/app/oracle
export ORA_CRS_HOME=${ORACLE_BASE}/product/10.2.0/crs
export ORACLE_HOME=${ORACLE_BASE}/product/10.2.0/db_1
export PATH=${ORA_CRS_HOME}/bin:${ORACLE_HOME}/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/sbin

Com o arquivo configurado, devemos fechar o vi e salvá-lo.

Após isso, devemos carregar as variáveis de ambiente:

[oracle@mvrac1 ~]$ . .bash_profile

Para confirmar se as variáveis foram carregadas:

[oracle@mvrac1 ~]$ env |grep ORA
ORA_CRS_HOME=/u01/app/oracle/product/10.2.0/crs
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1

Pronto!

Vamos iniciar a instalação:

[oracle@mvrac1 ~]$ cd clusterware/
[oracle@mvrac1 clusterware]$ ls -l
total 36
dr-xr-xr-x 2 oracle oinstall 4096 May 21  2008 cluvfy
dr-xr-xr-x 6 oracle oinstall 4096 May 21  2008 doc
dr-xr-xr-x 4 oracle oinstall 4096 May 21  2008 install
dr-xr-xr-x 2 oracle oinstall 4096 May 21  2008 response
dr-xr-xr-x 2 oracle oinstall 4096 May 21  2008 rpm
-r-xr-xr-x 1 oracle oinstall 1328 Jul  2  2005 runInstaller
dr-xr-xr-x 9 oracle oinstall 4096 May 21  2008 stage
dr-xr-xr-x 2 oracle oinstall 4096 May 21  2008 upgrade
-r--r--r-- 1 oracle oinstall 3445 Jul  2  2005 welcome.html

Como estamos usando o RHEL5/OEL5, quando o produto 10.2.0.1 foi lançado, essa versão de sistema operacional ainda não estava disponível no mercado, precisaremos executar a instalação informando que a verificação de pré-requisitos deverá ser ignorada:

[oracle@mvrac1 clusterware]$ ./runInstaller -ignoreSysPreReqs

A tela acima é a tela inicial. Devemos clicar em Next:

A tela acima solicita definirmos a localização do inventário e qual será o grupo no sistema operacional que será o dono do inventário. Os valores sugeridos serão:

  • Para a localização do inventário: /u01/app/oracle/oraInventory;
  • Para o grupo do sistema operacional: oinstall.

Clicar em Next:

Na tela acima devemos especificar o nome do Oracle Home do Clusterware, assim como a sua localização. Os valores sugeridos são:

  • Para o nome do Oracle Home do Clusterware: OraCrs10g_home;
  • Para a localização do Oracle Home do Clusterware: /u01/app/oracle/product/10.2.0/crs.

Clicar em Next:

O OUI reclamará de pouca memória, bastará clicar na caixa de seleção onde está escrito “Warning” na coluna de Status:

Após ter clicado na caixa, observem que o status passará para o valor “User Verified”. Clicar em Next:

Na tela acima, devemos especificar a configuração do cluster. O campo “Cluster Name” deve ter valor único na rede corporativa. O nome default é “crs”. Eu alterei o valor para “crs_mv”. Observem que no campo “Cluster Nodes” as informações de “Public Node Name”,”Private Node Name” e “Virtual Host Name” já aparecerão para o host mvrac1, já que a instalação foi iniciada a partir desse host. Como o cluster terá 2 nós, precisamos adicionar mais um nó na configuração do cluster. Basta clicar no botão “Add”:

Deveremos preencher os campos “Public Node Name”, “Private Node Name” e “Virtual Host Name”. Os valores sugeridos são:

  • Para o “Public Node Name”: mvrac2.viniciusdba.com.br;
  • Para o “Private Node Name”: mvrac2-priv.viniciusdba.com.br;
  • Para o “Virtual Node Name”: mvrac2-vip.viniciusdba.com.br.

Clicar em OK:

Observem que agora na tela são exibidos os 2 nós. Ao clicar em Next, o OUI verificará 2 itens:

  • Se os hostnames informados existem no arquivo /etc/hosts;
  • Se há equivalência de usuário entre os nós especificados para o usuário oracle.

Apenas para lembrarmos do /etc/hosts:

# ============================================================
# 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

Clicar em Next:

Na tela acima serão exibidas TODAS as interfaces de rede existentes no servidor. A regra que utilizaremos será:

  • eth0: Pública;
  • eth1: Privada.

Mas, observem que as duas interfaces aparecem como Privadas. Nesse caso, deveremos selecionar a interface eth0 e clicar no botão Edit:

Basta clicar na opção “Option” e depois clicar em OK. Caso tivéssemos mais de duas placas de rede, deveríamos selecionar a placa que não seria usada no cluster, e selecionar a opção “Do not use”.

Após editarmos a placa de rede eth0, agora sim observaremos que as duas placas estão com as configurações adequadas. Clicar em Next:

Na tela acima, deveremos especificar o tipo de redundância para o OCR: normal (2 locais), externa (1 local). O tipo de redundância escolhido foi a normal. Após isso, deveremos especificar 2 locais para armazenar o OCR. Lembram que eu comentei que o OUI do Clusterware 10.2.0.1 não consegue determinar se os block devices estão compartilhados entre os nós do cluster? Pois bem, eu simulei o erro e especifiquei um local apontando para um block device, e outro apontando para um raw device:

  • OCR Location: /dev/ocr1 (block device);
  • OCR Mirror Location: /dev/raw/raw4 (raw device).

Clicar em Next:

A tela acima será exibida com a mensagem informando que a localização /dev/ocr1 não está compartilhada entre os nós do cluster. Isso é descrito na Nota do Metalink número 401132.1. Clicar em OK:

Devemos corrigir o valor para o campo “Specify OCR Location”. Os dois campos deverão estar preenchidos da seguinte forma:

  • OCR Location: /dev/raw/raw2;
  • OCR Mirror Location: /dev/raw/raw4.

Clicar em Next:

Na tela acima, deveremos especificar o tipo de redundância e localização do voting disk. O tipo de redundância escolhido foi o normal. A localização dos voting disks deverá ser o seguinte:

  • Voting Disk Location: /dev/raw/raw1;
  • Additional Voting Disk 1 Location: /dev/raw/raw3;
  • Additional Voting Disk 2 Location: /dev/raw/raw5.

Clicar em Next:

Um resumo sobre a instalação será exibido. Clicar em Install:

A janela com o progresso da instalação será exibida. Observem que há um item chamado “Remote operations pending”. É nesse item que o Oracle Home será copiado para o outro nó.

Uma janela aparecerá solicitando executarmos scripts como root nos 2 nós do cluster. Não podemos executar os scripts em paralelo!! Devemos executar os scripts no primeiro nó, e depois, no segundo nó.

Vamos à execução do script /u01/app/oracle/oraInventory/orainstRoot.sh no nó mvrac1:

[root@mvrac1 ~]# /u01/app/oracle/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oracle/oraInventory to 770.
Changing groupname of /u01/app/oracle/oraInventory to oinstall.
The execution of the script is complete

Agora, vamos executar o script /u01/app/oracle/product/10.2.0/crs/root.sh no nó mvrac1:

[root@mvrac1 ~]# /u01/app/oracle/product/10.2.0/crs/root.sh
WARNING: directory '/u01/app/oracle/product/10.2.0' is not owned by root
WARNING: directory '/u01/app/oracle/product' is not owned by root
WARNING: directory '/u01/app/oracle' is not owned by root
WARNING: directory '/u01/app' is not owned by root
WARNING: directory '/u01' is not owned by root
Checking to see if Oracle CRS stack is already configured
/etc/oracle does not exist. Creating it now.

Setting the permissions on OCR backup directory
Setting up NS directories
Oracle Cluster Registry configuration upgraded successfully
WARNING: directory '/u01/app/oracle/product/10.2.0' is not owned by root
WARNING: directory '/u01/app/oracle/product' is not owned by root
WARNING: directory '/u01/app/oracle' is not owned by root
WARNING: directory '/u01/app' is not owned by root
WARNING: directory '/u01' is not owned by root
assigning default hostname mvrac1 for node 1.
assigning default hostname mvrac2 for node 2.
Successfully accumulated necessary OCR keys.
Using ports: CSS=49895 CRS=49896 EVMC=49898 and EVMR=49897.
node : 

node 1: mvrac1 mvrac1-priv mvrac1
node 2: mvrac2 mvrac2-priv mvrac2
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Now formatting voting device: /dev/raw/raw1
Now formatting voting device: /dev/raw/raw3
Now formatting voting device: /dev/raw/raw5
Format of 3 voting devices complete.
Startup will be queued to init within 90 seconds.
Adding daemons to inittab
Expecting the CRS daemons to be up within 600 seconds.
CSS is active on these nodes.
	mvrac1
CSS is inactive on these nodes.
	mvrac2
Local node checking complete.
Run root.sh on remaining nodes to start CRS daemons.

Após a conclusão desse script, vamos executar o script /u01/app/oraInventory/orainstRoot.sh no nó mvrac2:

[root@mvrac2 ~]# /u01/app/oracle/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oracle/oraInventory to 770.
Changing groupname of /u01/app/oracle/oraInventory to oinstall.
The execution of the script is complete

Em seguida, devemos executar o script /u01/app/oracle/product/10.2.0/crs/root.sh no nó mvrac2:

[root@mvrac2 ~]# /u01/app/oracle/product/10.2.0/crs/root.sh
WARNING: directory '/u01/app/oracle/product/10.2.0' is not owned by root
WARNING: directory '/u01/app/oracle/product' is not owned by root
WARNING: directory '/u01/app/oracle' is not owned by root
WARNING: directory '/u01/app' is not owned by root
WARNING: directory '/u01' is not owned by root
Checking to see if Oracle CRS stack is already configured
/etc/oracle does not exist. Creating it now.

Setting the permissions on OCR backup directory
Setting up NS directories
Oracle Cluster Registry configuration upgraded successfully
WARNING: directory '/u01/app/oracle/product/10.2.0' is not owned by root
WARNING: directory '/u01/app/oracle/product' is not owned by root
WARNING: directory '/u01/app/oracle' is not owned by root
WARNING: directory '/u01/app' is not owned by root
WARNING: directory '/u01' is not owned by root
clscfg: EXISTING configuration version 3 detected.
clscfg: version 3 is 10G Release 2.
assigning default hostname mvrac1 for node 1.
assigning default hostname mvrac2 for node 2.
Successfully accumulated necessary OCR keys.
Using ports: CSS=49895 CRS=49896 EVMC=49898 and EVMR=49897.
node : 

node 1: mvrac1 mvrac1-priv mvrac1
node 2: mvrac2 mvrac2-priv mvrac2
clscfg: Arguments check out successfully.

NO KEYS WERE WRITTEN. Supply -force parameter to override.
-force is destructive and will destroy any previous cluster
configuration.
Oracle Cluster Registry for cluster has already been initialized
Startup will be queued to init within 90 seconds.
Adding daemons to inittab
Expecting the CRS daemons to be up within 600 seconds.
CSS is active on these nodes.
	mvrac1
	mvrac2
CSS is active on all nodes.
Waiting for the Oracle CRSD and EVMD to start
Waiting for the Oracle CRSD and EVMD to start
Waiting for the Oracle CRSD and EVMD to start
Oracle CRS stack installed and running under init(1M)
Running vipca(silent) for configuring nodeapps
/u01/app/oracle/product/10.2.0/crs/jdk/jre//bin/java: error while
loading shared libraries: libpthread.so.0: cannot open shared
object file: No such file or directory

Terminamos de executar o script, mas observem que pegamos um erro na execução do último script no nó mvrac2:

Running vipca(silent) for configuring nodeapps
/u01/app/oracle/product/10.2.0/crs/jdk/jre//bin/java: error while
loading shared libraries: libpthread.so.0: cannot open shared
object file: No such file or directory

Esse erro é normal no Red Hat Enterprise Linux 5 e sempre acontecerá nessa versão e é descrito pela Nota do Metalink número 414163.1. Deveremos editar 2 arquivos para corrigir esse problema. Primeiro, precisamos ir para ao diretório $ORA_CRS_HOME com o usuário oracle:

[oracle@mvrac1 clusterware]$ cd $ORA_CRS_HOME/bin

Em seguida, editaremos o arquivo srvctl:

[oracle@mvrac1 bin]$ vi srvctl

Aproximadamente da linha 166, haverá a seguinte string:

#Remove this workaround when the bug 3937317 is fixed
LD_ASSUME_KERNEL=2.4.19
export LD_ASSUME_KERNEL

Devemos acrescentar o seguinte conteúdo abaixo da última linha da string:

unset LD_ASSUME_KERNEL

Deverá ficar da seguinte forma:

#Remove this workaround when the bug 3937317 is fixed
LD_ASSUME_KERNEL=2.4.19
export LD_ASSUME_KERNEL
unset LD_ASSUME_KERNEL

Agora, editaremos o arquivo vipca:

[oracle@mvrac1 bin]$ vi vipca

Aproximadamente da linha 121, haverá a seguinte string:

#Remove this workaround when the bug 3937317 is fixed
       arch=`uname -m`
       if [ "$arch" = "i686" -o "$arch" = "ia64" ]
       then
            LD_ASSUME_KERNEL=2.4.19
            export LD_ASSUME_KERNEL
       fi
       #End workaround

Devemos acrescentar o seguinte conteúdo abaixo da linha que tenha a string “export LD_ASSUME_KERNEL”:

unset LD_ASSUME_KERNEL

Deverá ficar da seguinte forma:

#Remove this workaround when the bug 3937317 is fixed
       arch=`uname -m`
       if [ "$arch" = "i686" -o "$arch" = "ia64" ]
       then
            LD_ASSUME_KERNEL=2.4.19
            export LD_ASSUME_KERNEL
            unset LD_ASSUME_KERNEL
       fi
       #End workaround

Feito isso, deveremos copiar esses dois arquivos para o servidor mvrac2:

[oracle@mvrac1 bin]$ scp -rp srvctl mvrac2:`pwd`
srvctl                                             100% 5577     5.5KB/s   00:00
[oracle@mvrac1 bin]$ scp -rp vipca mvrac2:`pwd`
vipca                                              100% 5038     4.9KB/s   00:00

Podemos agora voltar para tela de instalação e clicar no botão OK:

Uma janela será exibida com a execução automática de assistentes de configuração:

No último assistente (Oracle Cluster Verification Utility), teremos um erro:

Erro erro é comum e não devemos nos preocupar. Clicar em OK:

Será exibido na janela que o último assistente falhou. Clicar em Next. Aparecerá uma mensagem informando que um assistente falhou:

Clicar em OK:

Clicar em Exit:

Clicar em Yes.

Estamos quase finalizando a instalação do Clusterware. Lembrem-se que na execução do último script no servidor mvrac2, obtivemos um erro:

Running vipca(silent) for configuring nodeapps
/u01/app/oracle/product/10.2.0/crs/jdk/jre//bin/java: error while
loading shared libraries: libpthread.so.0: cannot open shared
object file: No such file or directory

Pois bem, o assistente VIPCA, responsável por criar os recursos de IP virtuais (os VIP’s), nos servidores, falhou. Agora que corrigimos o problema editando os arquivos srvctl e vipca, agora precisamos executar o assistente vipca para criarmos os IP’s virtuais. No entanto, como se trata de iniciar um endereço IP no sistema operacional, só é possível executar o vipca com o usuário root (e com display gráfico):

vinicius@Viniciuss-MacBook:~$ ssh -X root@172.23.10.11
root@172.23.10.11's password:
Last login: Sun Feb 21 09:35:58 2010 from 172.23.10.100
[root@mvrac1 ~]# /u01/app/oracle/product/10.2.0/crs/bin/vipca

A tela inicial do VIPCA será exibida. Clicar em Next:

A interface de rede eth0 será exibida. Foi essa interface que definimos como interface de rede pública na instalação do Oracle Clusterware. Clicar em Next:

A janela acima será exibida. Precisamos definir o “IP Alias Name” para os servidores. Basta preencher o valor para o servidor mvrac1:

  • mvrac1-vip.viniciusdba.com.br

Pressionar [TAB] e o valor para o servidor mvrac2 será preenchido automaticamente, através da leitura do arquivo /etc/hosts:

Clicar em Next:

Um resumo sobre a configuração será exibido. Clicar em Finish.

Uma janela com o progresso da operação será exibido. Aguardar.

Quando o processo terminar, clicar no botão OK.

Uma janela com o resultado da configuração será exibido. Nesse momento, os endereços IP virtuais estarão online em cada servidor. Clicar em Exit.

Com o usuário oracle mesmo, podemos verificar quais são os endereços IP que estão online no servidor mvrac1:

[oracle@mvrac1 ~]$ ifconfig |grep inet | grep -v fe | grep -v 127.0. | grep -v ::1/128
          inet addr:172.23.10.11  Bcast:172.23.10.255  Mask:255.255.255.0
          inet addr:172.23.10.21  Bcast:172.23.10.255  Mask:255.255.255.0
          inet addr:10.0.0.11  Bcast:10.255.255.255  Mask:255.0.0.0

Ou seja:

  • 172.23.10.11: IP público físico;
  • 172.23.10.21: IP público virtual;
  • 10.0.0.11: IP privado físico, InterConnect.

Vamos ver agora no servidor mvrac2:

[oracle@mvrac2 ~]$ ifconfig |grep inet | grep -v fe | grep -v 127.0. | grep -v ::1/128
          inet addr:172.23.10.12  Bcast:172.23.10.255  Mask:255.255.255.0
          inet addr:172.23.10.22  Bcast:172.23.10.255  Mask:255.255.255.0
          inet addr:10.0.0.12  Bcast:10.255.255.255  Mask:255.0.0.0

Ou seja:

  • 172.23.10.12: IP público físico;
  • 172.23.10.22: IP público virtual;
  • 10.0.0.12: IP privado físico, InterConnect.

Caso o servidor mvrac1 sofra algum problema de hardware ou software e seja desligado, o seu IP virtual, 172.23.10.21 será transferido automaticamente para o servidor mvrac2.
Para verificarmos o status dos recursos do cluster, com o usuário oracle:

[oracle@mvrac1 ~]$ crs_stat -t
Name           Type           Target    State     Host
------------------------------------------------------------
ora.mvrac1.gsd application    ONLINE    ONLINE    mvrac1
ora.mvrac1.ons application    ONLINE    ONLINE    mvrac1
ora.mvrac1.vip application    ONLINE    ONLINE    mvrac1
ora.mvrac2.gsd application    ONLINE    ONLINE    mvrac2
ora.mvrac2.ons application    ONLINE    ONLINE    mvrac2
ora.mvrac2.vip application    ONLINE    ONLINE    mvrac2

Num artigo conveniente, veremos o que é cada um desses recursos. O que importa por enquanto, é que todos estão online.
Pessoal, por enquanto é isso!

No próximo artigo veremos como aplicar o patchset 10.2.0.4 no Clusterware, e também como migrar o OCR e Voting Disk para os block devices.

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