Tag Archive: inicializar

Olá pessoal!

Hoje veremos como interromper e inicializar recursos individualmente utilizando outros binários: crs_start e crs_stop.

Características do crs_start e crs_stop:

  • Pode ser executado a partir de qualquer nó;
  • Deve ser executado com o usuário root;
  • Controla todos os nós;
  • Inicializa e interrompe individualmente os recursos gerenciados pelo Clusterware.

Alguns exemplos de uso:

Interrompendo o listener do nó MVRAC2 a partir do nó MVRAC1

[root@mvrac1 ~]# crs_stop ora.mvrac2.LISTENER_MVRAC2.lsnr
Attempting to stop `ora.mvrac2.LISTENER_MVRAC2.lsnr` on member `mvrac2`
Stop of `ora.mvrac2.LISTENER_MVRAC2.lsnr` on member `mvrac2` succeeded.

Verificando o status dos componentes:

[root@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                    OFFLINE    OFFLINE
ora.mvrac2.gsd                                     ONLINE     ONLINE on mvrac2
ora.mvrac2.ons                                     ONLINE     ONLINE on mvrac2
ora.mvrac2.vip                                     ONLINE     ONLINE on mvrac2

Inicializando o listener do nó MVRAC2 a partir do nó MVRAC1:

[root@mvrac1 ~]# crs_start ora.mvrac2.LISTENER_MVRAC2.lsnr
Attempting to start `ora.mvrac2.LISTENER_MVRAC2.lsnr` on member `mvrac2`
Start of `ora.mvrac2.LISTENER_MVRAC2.lsnr` on member `mvrac2` succeeded.

Verificando o status dos componentes:

[root@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

Vocês puderam observar que é necessário especificar o nome completo do recurso, diferentemente do srvctl onde especificamos os recursos através de flags (-n para nó, -d para database, -i para instancia, etc…).

Comparando o crs_start/crs_stop com o srvctl, podemos verificar que o controle de cada recurso individual é mais fino no crs_start/crs_stop, já que no srvctl temos o recurso NODEAPPS que controla os recursos listener, gds, ons e vip. Cada recurso desse pode ser controlado manualmente pelo crs_start/crs_stop.

Além de inicializar/interromper os recursos, ele também “atualiza” o status dos componentes no OCR. Isso pode ser necessários em determinadas ocasiões onde o recurso está OFFLINE mas o seu alvo consta como ONLINE (no caso de uma máquina que não foi inicializada), ou qualquer outra situação.

O recurso pode ser “forçado” a ficar em OFFLINE a partir do crs_stop com a opção -f (force):

[root@mvrac1 ~]# crs_stop ora.mvrac2.LISTENER_MVRAC2.lsnr -f

Bom, o uso do crs_start e crs_stop é bem limitado. Eu só utilizo* esses binários nestas situações específicas.

Também há o binário crs_relocate.

Ele é utilizado para reposicionar um recurso do Clusterware.

Reposicionando o VIP:

[root@mvrac1 ~]# crs_relocate ora.mvrac1.vip
mvrac2 : CRS-1022: Resource ora.mvrac1.LISTENER_MVRAC1.lsnr (application) is running on mvrac1

CRS-0223: Resource 'ora.mvrac1.vip' has placement error.

Se eu tentar fazer o relocate do VIP com o listener no ar, eu receberei esse erro acima, pois o listener é um recurso dependente do VIP.

Neste caso, eu interrompo primeiro o listener:

[root@mvrac1 ~]# crs_stop ora.mvrac1.LISTENER_MVRAC1.lsnr
Attempting to stop `ora.mvrac1.LISTENER_MVRAC1.lsnr` on member `mvrac1`
Stop of `ora.mvrac1.LISTENER_MVRAC1.lsnr` on member `mvrac1` succeeded.

Aí faço o relocate do VIP:

[root@mvrac1 ~]#  crs_relocate ora.mvrac1.vip
Attempting to stop `ora.mvrac1.vip` on member `mvrac1`
Stop of `ora.mvrac1.vip` on member `mvrac1` succeeded.
Attempting to start `ora.mvrac1.vip` on member `mvrac2`
Start of `ora.mvrac1.vip` on member `mvrac2` succeeded.

O relocate geralmente é utilizado quando um recurso (VIP) não foi inicializado no seu nó (por um problema de placa de rede, por exemplo).

Este artigo foi bem simples. No próximo, veremos sobre as ferramentas de gerenciamento do OCR.

Um abraço!

Vinicius

* Corrigido erro de digitação. Obrigado LRezende!

Share

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

Share