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
Olá. Tenho um ambiente de teste formado por um cluster de dois nós 10.2.0.3, usando OCFS2, e não ASM, em RedHat 4u5 64bit. Meu objetivo nesse ambiente é reaproveitar o database a partir de uma instância após ter a instalação do Clusterware detonada no primeiro nó(faltando arquivos) e com a outra instância irrecuperável (problema de hardware).
Tentei exportação de dados via datapump, mas ele passa pelo cluster manager. Não sei se há maneira de contornar…
A pergunta é: é possível reaproveitar a instância?
Agradeço antecipadamente.
Olá Vinicius
Volta e meia estou aqui fuçando no seu blog em busca de +info!! hehe
Fiquei com uma dúvida relendo este artigo, pois no caso de realocar o meu Rac para uma outra rede com mascara diferente, eu somente preciso executar o passo onde vc diz: “Alterar os VIP’s dos 2 nós no cluster novo” ??
Minha rede em casa é 10.1.1.X. A outra rede é 10.197.81.X.
Neste caso altero apenas a rede publica, ou Virtual IPs tbem?
Grande abraço.