Tag Archive: crs

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!

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

O crsctl, também é conhecido como cluster control.

Algumas características do crsctl:

  • Pode ser executado a partir de qualquer nó;
  • Deve sempre ser executado com o usuário root;
  • Controla todos os nós (exceto o start/stop);
  • É a principal ferramenta de administração do Clusterware;
  • Utilizado para verificação e alteração de parâmetros (indicado somente sob a solicitação do Suporte Oracle);
  • Utilizado para debug do Clusterware;
  • Rotinas administrativas do Clusterware.

Alguns exemplos de uso:

Para verificar o status de TODOS os daemons do Clusterware:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl check crs

Para verificar o status do CRSD:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl check crsd

Para verificar o status do EVMD:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl check evmd

Para verificar o status do CSSD:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl check cssd

Para verificar as versões do Clusterware:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl query crs activeversion
/u01/app/oracle/product/10.2.0/crs/bin/crsctl query crs softwareversion

Para verificar (e alterar) parâmetros:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl get css misscount
/u01/app/oracle/product/10.2.0/crs/bin/crsctl get css disktimeout
/u01/app/oracle/product/10.2.0/crs/bin/crsctl set css misscount 3600
/u01/app/oracle/product/10.2.0/crs/bin/crsctl set css disktimeout 3600

Para Listar módulos do cluster

/u01/app/oracle/product/10.2.0/crs/bin/crsctl lsmodules crs
/u01/app/oracle/product/10.2.0/crs/bin/crsctl lsmodules css
/u01/app/oracle/product/10.2.0/crs/bin/crsctl lsmodules evm

Para habilitar o debug de um módulo e um recurso:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl debug log crs “CRSCOMM:3”  # Vai de 0 a 5
/u01/app/oracle/product/10.2.0/crs/bin/crsctl debug log res “ora.rac1.vip:5”

Para debugar todos os recursos:
Editar o script $ORA_CRS_HOME/bin/racgwrap e definir a variável _USR_ORA_DEBUG como 1

Para exibir os Voting Disks:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl query css votedisk

Para migrar os Voting Disks de raw devices para block devices (essa atividade foi feita também em outro post) – relembre aqui:

Como root, nos nós rac1 e rac2:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl stop crs

Como root, apenas em um nó. Como exemplo, no nó 1:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl add css votedisk /dev/voting1 -force
/u01/app/oracle/product/10.2.0/crs/bin/crsctl add css votedisk /dev/voting2 -force
/u01/app/oracle/product/10.2.0/crs/bin/crsctl add css votedisk /dev/voting3 -force
/u01/app/oracle/product/10.2.0/crs/bin/crsctl query css votedisk
/u01/app/oracle/product/10.2.0/crs/bin/crsctl delete css votedisk /dev/raw/raw1 -force
/u01/app/oracle/product/10.2.0/crs/bin/crsctl delete css votedisk /dev/raw/raw3 -force
/u01/app/oracle/product/10.2.0/crs/bin/crsctl delete css votedisk /dev/raw/raw5 -force
/u01/app/oracle/product/10.2.0/crs/bin/crsctl query css votedisk

Como root nos nós rac1 e rac2:

/u01/app/oracle/product/10.2.0/crs/bin/crsctl start crs

Como puderam ver, o crsctl é utilizado em muitos casos.

Geralmente habilitamos o debug ou alteramos parâmetros sob solicitação do Suporte Oracle mediante algum problema no ambiente.

O objetivo deste post, assim como todos os outros que eu coloco neste blog, não é preparar você para uma prova de certificação, mas, sim para prepará-lo para trabalhar no mundo real.

No próximo artigo, veremos como funciona o srvctl.

Um abraço!

Vinicius







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

Copyright:

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

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

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

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


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

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

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

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

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

Olá pessoal!

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

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

Olá pessoal!

Vimos no último artigo a aplicação do Patchset 10.2.0.4 no Oracle Database.

Veremos hoje como criar o Listener 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 Listener, o netca. 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 netca:

[oracle@mvrac1 ~]$ netca

O netca detectará que a pilha de cluster está em execução, e precisamos selecionar qual será o tipo de configuração que faremos:

  • Configuração de cluster;
  • Configuração de single node.

Manteremos a opção “Cluster configuration” selecionada. Clicar em Next:

Todos os nós estarão selecionados. Caso não estejam, devemos clicar no botão “Select all nodes”. Clicar em Next.

Como faremos a criação do Listener, devemos manter a opção “Listener configuration” selecionada.

Clicar em Next.

A única opção disponível é a “Add”. Clicar em Next.

O nome padrão do Listener é LISTENER. Manteremos esse nome, clicar em Next.

Na tela acima selecionamos quais protocolos o Listener utilizará. Nesse caso, só manteremos o protocolo TCP. Clicar em Next.

Na tela acima, precisamos especificar qual porta será utilizada pelo Listener. Manteremos a porta padrão (1521). Clicar em Next.

Não configuraremos outros Listeners. Manter a opção “No” selecionada e clicar em Next.

A tela acima indica que o Listener foi criado com sucesso. Clicar em Next.

Clicar em Finish.

O Listener foi criado. Como ele faz parte do cluster e foi cadastrado como recurso do mesmo, e o seu status também pode ser visto junto com o status dos outros recursos do cluster:

Name           Type           Target    State     Host
------------------------------------------------------------
ora....C1.lsnr application    ONLINE    ONLINE    mvrac1
ora.mvrac1.gsd application    ONLINE    ONLINE    mvrac1
ora.mvrac1.ons application    ONLINE    ONLINE    mvrac1
ora.mvrac1.vip application    ONLINE    ONLINE    mvrac1
ora....C2.lsnr application    ONLINE    ONLINE    mvrac2
ora.mvrac2.gsd application    ONLINE    ONLINE    mvrac2
ora.mvrac2.ons application    ONLINE    ONLINE    mvrac2
ora.mvrac2.vip application    ONLINE    ONLINE    mvrac2

Observem que temos os recursos lsnr, esses recursos são os Listeners, um em cada nó. No entanto, observem que a leitura da saída do comando crs_stat já não está tão prática, pois alguns recursos estão com o nome cortado.

Há um script criado pelo Jeffrey Hunter, guru em Oracle RAC, que formata a saída para melhor leitura:

Clique aqui para baixar esse script.

No servidor mvrac1, como root, criar o seguinte arquivo:

[root@mvrac1 ~]# cd /usr/local/bin
[root@mvrac1 bin]# vi crsstat
#!/bin/ksh

# +----------------------------------------------------------------------------+
# |                          Jeffrey M. Hunter                                 |
# |                      jhunter@idevelopment.info                             |
# |                         www.idevelopment.info                              |
# |----------------------------------------------------------------------------|
# |      Copyright (c) 1998-2009 Jeffrey M. Hunter. All rights reserved.       |
# |----------------------------------------------------------------------------|
# | DATABASE : Oracle                                                          |
# | FILE     : rac_crs_stat                                                    |
# | CLASS    : UNIX Shell Scripts                                              |
# | PURPOSE  : This KSH script will query all CRS resources using the crs_stat |
# |            script. The report will be a formatted version of the           |
# |            crs_stat -t command, but in tabular form with resource name     |
# |            and status. Filtering options are available by passing in a     |
# |            single string parameter to this script. This argument will be   |
# |            used to limit the output to HA resources whose names match      |
# |            that string.                                                    |
# | USAGE    : rac_crs_stat.ksh [RESOURCE_KEY]                                 |
# | NOTE     : This script requires the environment $ORA_CRS_HOME to be set to |
# |            your CRS installation.                                          |
# | NOTE     : As with any code, ensure to test this script in a development   |
# |            environment before attempting to run it in production.          |
# +----------------------------------------------------------------------------+

# +----------------------------------------------------------------------------+
# | GLOBAL VARIABLES                                                           |
# +----------------------------------------------------------------------------+

RSC_KEY=$1
QSTAT=-u
AWK=/usr/bin/awk
ORA_CRS_HOME=/u01/app/oracle/product/10.2.0/crs

# +----------------------------------------------------------------------------+
# | TABLE HEADER                                                               |
# +----------------------------------------------------------------------------+

$AWK \
  'BEGIN {printf "%-50s %-10s %-18s\n", "HA Resource", "Target", "State";
          printf "%-50s %-10s %-18s\n", "-----------", "------", "-----";}'

# +----------------------------------------------------------------------------+
# | TABLE BODY                                                                 |
# +----------------------------------------------------------------------------+

$ORA_CRS_HOME/bin/crs_stat $QSTAT | $AWK \
 'BEGIN { FS="="; state = 0; }
  $1~/NAME/ && $2~/'$RSC_KEY'/ {appname = $2; state=1};
  state == 0 {next;}
  $1~/TARGET/ && state == 1 {apptarget = $2; state=2;}
  $1~/STATE/ && state == 2 {appstate = $2; state=3;}
  state == 3 {printf "%-50s %-10s %-18s\n", appname, apptarget, appstate; state=0;}'

Observem que eu incluí a seguinte linha no script:

ORA_CRS_HOME=/u01/app/oracle/product/10.2.0/crs

Com isso, o script poderá ser executado com qualquer usuário no sistema operacional.

Após salvar o script, devemos definir suas permissões para execução:

[root@mvrac1 bin]# chmod 755 crsstat

E agora, devemos copiá-lo para o servidor mvrac2:

[root@mvrac1 bin]# scp -p crsstat mvrac2:`pwd`
root@mvrac2's password:
crsstat                               100% 3195     3.1KB/s   00:00

Vamos testar o script?

[oracle@mvrac1 ~]$ crsstat
HA Resource                                        Target     State
-----------                                        ------     -----
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.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 está mais legível do que com o comando “crs_stat -t”.

Pronto pessoal!

Criamos o Listener e configuramos um script para melhor leitura do comando “crs_stat -t”.

No próximo artigo veremos como criar e configurar a instância ASM no cluster.

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