Oracle Clusterware – Rotinas Administrativas – Parte 3 – 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