Tag Archive: administração

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

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

Share