Guia de bolso para operar o cluster de laboratório da SourceTec. A atividade fica à esquerda, o comando exato à direita, pronto para copiar. Os exemplos usam o cluster real: rac10 e rac11.
AtençãoAmbiente de laboratório. Em produção, antes de qualquer parada: janela aprovada, Zabbix em manutenção e blackout no EM 24ai — ver Antes de parar. Comando com moldura vermelha pode derrubar serviço ou mudar estado.
Nósrac10 · rac11Oracle Linux, VMs KVM no T410
Grid Infrastructure 19c/u01/app/19.3.0/19c27usuário grid · raiz ohasd como root
Troque um valor aqui e todos os comandos da página mudam na hora. Os padrões são os do cluster rac10/rac11; o que está sublinhado nos comandos é o que vem destes campos. Ao trocar NODE para rac11, a instância, o SID do ASM e o nó vizinho acompanham (a menos que você já os tenha editado).
home do Grid (usuário grid)
home do banco (usuário oracle)
db_unique_name
instância do nó em que você está
nó em que você está
PDB de exemplo
serviço da aplicação
diskgroup do ASM
o nó vizinho; muda junto com NODE
instância do nó vizinho; muda junto com NODE
+ASM1 em rac10, +ASM2 em rac11; muda junto com NODE
base do oracle: alert do banco em diag/rdbms
base do grid: alert do Clusterware em diag/crs, adrci
nome do SCAN: nslookup, tnsping, EZConnect
porta do listener e do SCAN
PDB a criar, clonar ou apagar (seção 6)
admin da PDB nova; a senha vem do cofre, nunca daqui
serviço da aplicação amarrado à PDB (seção 6)
discos do ASM no SO (ou /dev/sd*)
root@rac10 # como rootgrid@rac10 $ como grid (dono do Grid e do ASM)oracle@rac10 $ como oracle (dono do banco)SQL> dentro do sqlplusoms $ na máquina do Enterprise Manager (emcli)parada interrompe algo: só com janelaPode prejudicar derruba serviço ou muda estado: leia a moldura antes de rodar
Ambiente das sessões
Sessão do gridAntes de crsctl, srvctl do Grid, asmcmd e lsnrctl. O SID do ASM é +ASM1 em rac10 e +ASM2 em rac11 (campo ASM_SID).
Árvore de componentes: quem é quem, com que usuário, e como parar, ver e subir.
De fora para dentro: o sistema operacional sustenta o Grid; o Grid sustenta ASM, rede e o banco; o banco tem uma instância por nó; a CDB contém as PDBs. Parar é de dentro para fora; subir é de fora para dentro.
Linux (Oracle Linux)
root
Sistema operacional dos nós rac10 e rac11. O daemon ohasd (unidade oracle-ohasd) é a raiz de tudo: sobe no boot e puxa o resto do Grid.
Status do serviço raiz do GridSe o ohasd não está ativo, nada do cluster existe neste nó.
root@rac10 #systemctl status oracle-ohasd
Processos do cluster vivosohasd, crsd, ocssd e evmd precisam aparecer.
Reiniciar o nó paradaSó depois de parar a instância e o Grid (seção 2). Reboot a seco deixa o banco se recuperar sozinho, mas custa tempo e risco.
Pode prejudicarroot@rac10 #systemctl rebootDerruba: tudo o que roda neste nó: instância, ASM, listener e VIP. Antes: serviços relocados, instância e Grid parados (seção 2). Zabbix e EM 24ai em manutenção.
Espaço e cargaO /u01 cheio trava alert, trace e patch.
root@rac10 #df -h /u01root@rac10 #uptime
Relógio sincronizado entre os nósDiferença de relógio entre rac10 e rac11 causa node eviction pelo CSSD/CTSSD. Olhe System time offset e Leap status; os dois nós no mesmo servidor NTP.
root@rac10 #chronyc tracking
Memória, swap e HugePagesSGA em swap ou HugePages sem uso (HugePages_Free igual ao Total) degradam o nó inteiro; HugePages_Total tem de cobrir a SGA.
root@rac10 #free -h && grep -i huge /proc/meminfo
Permissão dos discos do ASMNove em dez diskgroups que não montam depois do reboot são permissão grid:asmadmin 660 perdida na regra do udev ou do oracleasm. Conferir aqui antes de investigar o ASM.
root@rac10 #ls -la /dev/oracleasm/disks/*
Grid Infrastructure 19c
gridroot para parar/subir o stack
Clusterware + ASM. Ferramentas: crsctl (o stack), srvctl (os recursos), olsnodes (os nós) e cluvfy (verificação). Home: /u01/app/19.3.0/19c27.
Saúde do stack neste nóPrimeira pergunta de qualquer atendimento: CRS, CSS e EVM em linha.
grid@rac10 $crsctl check crs
Todos os recursos, em tabelaONLINE/OFFLINE de cada recurso em cada nó. É a visão que se cola no chamado.
grid@rac10 $crsctl stat res -t
Nós do clusterNúmero, VIP público (-i; mostra <none> quando o VIP não está ativo), status e tipo de cada nó. O IP privado do interconnect vem do oifcfg, logo abaixo.
A pilha nos dois nós de uma vezcrsctl check crs é só local; com cluster -all cada nó responde CRS, CSS e EVM.
grid@rac10 $crsctl check cluster -all
Integridade do OCREspelhos e consistência do registro do cluster no +OCR. Como root mostra tudo; como grid só o resumo.
root@rac10 #/u01/app/19.3.0/19c27/bin/ocrcheck
Quórum: voting disksVoting disk inacessível é risco de split-brain e de reboot de nó. Todos ONLINE, no diskgroup OCR.
grid@rac10 $crsctl query css votedisk
Versão ativa e patch levelNível de patch e modo rolling do cluster (ex.: 19.27). Crítico antes e depois de uma manutenção rolling: os dois nós têm de bater.
grid@rac10 $crsctl query crs activeversion -f
Parar o stack neste nó paradaDerruba instância, ASM, listener e VIP do nó. Pare a instância do banco antes (seção 2).
Pode prejudicarroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl stop crsDerruba: instância, ASM, listener e VIP deste nó; o outro nó segue sozinho. Antes: serviços relocados e instância do banco parada neste nó. Zabbix e EM 24ai em manutenção.
Subir o stack neste nóCom -wait o comando mostra o progresso em vez de devolver o prompt na hora.
LISTENER (1521) em cada nó, três LISTENER_SCAN atrás de rac10-scan.sourcetec.vm, e um VIP por nó (ora.rac10.vip, ora.rac11.vip) que migra quando o nó cai.
Listeners locaisUm por nó, no home do Grid.
grid@rac10 $srvctl status listener
Listeners do SCANOs três devem estar ON, distribuídos entre os nós.
grid@rac10 $srvctl status scan_listener
VIP de um nóSe o VIP de rac10 está em rac11, o nó rac10 caiu ou foi parado.
grid@rac10 $srvctl status vip -n rac10
Nodeapps e SCAN como estão registradosIPs e sub-rede reais do VIP, da rede e do SCAN; é o que vale quando olsnodes -i devolve <none>.
O RDBMS, registrado no Grid como recurso ora.cdb.db. Opera-se por srvctl (database, instance, service) e, por dentro, por sqlplus. Home: /u01/app/oracle/product/19.3.0/19c27EE.
Status do banco e dos serviçosInstância por nó e serviços ativos (-v).
oracle@rac10 $srvctl status database -d CDB -v
Parar o banco inteiro paradaTodas as instâncias e serviços, em todos os nós.
Pode prejudicaroracle@rac10 $srvctl stop database -d CDB -o immediateDerruba: todas as instâncias e serviços nos dois nós: toda aplicação cai. Antes: janela aprovada, RMAN, Data Guard e Scheduler avisados. Zabbix e EM 24ai em manutenção.
Subir o banco inteiroAbre as instâncias e os serviços nos nós preferidos.
oracle@rac10 $srvctl start database -d CDB
Entrar no sqlplus como SYSDBASempre com ORACLE_SID da instância deste nó.
oracle@rac10 $export ORACLE_SID=CDB1oracle@rac10 $sqlplus / as sysdba
Como o banco está registrado no GridSPFILE no ASM, ORACLE_HOME, política de start (AUTOMATIC ou MANUAL), diskgroups de que depende, instâncias e serviços.
oracle@rac10 $srvctl config database -d CDB
Nós: rac10 e rac11
oraclegrid para o VIP
Cada nó tem a sua instância (CDB1 em rac10, CDB2 em rac11), a sua instância ASM e o seu VIP. A operação por nó é o que permite manutenção sem derrubar o serviço.
Instância deste nóRunning ou not running.
oracle@rac10 $srvctl status instance -d CDB -i CDB1
Parar só a instância deste nó paradaO outro nó continua atendendo; os serviços preferidos daqui migram se tiverem -available.
Pode prejudicaroracle@rac10 $srvctl stop instance -d CDB -i CDB1 -o immediateDerruba: a instância deste nó; as sessões nela caem, o outro nó segue atendendo. Antes: relocar os serviços que têm esta instância como preferida. Zabbix e EM 24ai em manutenção.
Subir a instância deste nóDepois, conferir com o status do banco.
O container raiz. db_unique_name CDB, duas instâncias, uma por nó. Comandos de SQL valem para o cluster quando levam sid='*' ou instances=all.
Onde cada instância está e como estágv$ enxerga as duas instâncias de uma vez. Normal: OPEN, ACTIVE e logins ALLOWED nas duas.
SQL>select inst_id, instance_name, host_name, status, database_status, logins from gv$instance order by inst_id;
Em que container estou?CDB$ROOT ou o nome da PDB.
SQL>show con_name
FRA: limite e usoFRA cheia trava o banco (ORA-00257). Compare usado_gb com limite_gb antes que o archive pare.
SQL>select name, round(space_limit/1024/1024/1024,2) limite_gb, round(space_used/1024/1024/1024,2) usado_gb, number_of_files from v$recovery_file_dest;
PDB (exemplo: PDB1)
oracle · sqlplus
Hoje só existe PDB$SEED; PDB1 é a PDB de exemplo. Num RAC, abrir ou fechar sem instances=all age só na instância em que você está.
Listar as PDBsNome, modo (READ WRITE, MOUNTED…) e restrição.
SQL>show pdbs
Abrir a PDB nas duas instânciasDepois, save state para ela reabrir sozinha no próximo start.
Pode prejudicarSQL>alter pluggable database PDB1 open instances=all;Altera: o estado da PDB nas duas instâncias (passa a aceitar conexão). Antes: conferir em gv$pdbs em que modo ela está. Zabbix e EM 24ai em manutenção.
Fechar a PDB nas duas instâncias paradaSessões da PDB são derrubadas (immediate).
Pode prejudicarSQL>alter pluggable database PDB1 close immediate instances=all;Derruba: as sessões da PDB nas duas instâncias. Antes: avisar a aplicação; a PDB fica MOUNTED até reabrir. Zabbix e EM 24ai em manutenção.
Modo da PDB em cada instânciaEm RAC a PDB pode estar READ WRITE num nó e MOUNTED no outro; só gv$pdbs mostra isso.
SQL>select inst_id, name, open_mode, restricted from gv$pdbs order by name, inst_id;
Guardar o estado para o próximo startSem SAVE STATE a PDB não abre sozinha depois de um reboot ou de um restart da instância.
Pode prejudicarSQL>alter pluggable database PDB1 save state instances=all;Altera: o que a PDB faz no próximo start, nas duas instâncias. Antes: conferir open_mode em gv$pdbs e deixar a PDB no modo que deve ser guardado. Zabbix e EM 24ai em manutenção.
Criar uma PDB nova a partir do seedO CDB é OMF: o Oracle nomeia e posiciona os datafiles no +DATA, sem FILE_NAME_CONVERT. Serviço, clone, unplug/plug e drop na seção 6.
SQL>create pluggable database PDB2 admin user pdbadmin identified by senha roles=(dba);a senha vem do cofre; nunca fica nesta página
Guia básico
As operações do dia a dia, na ordem em que acontecem.
Cada seção começa com o contexto (por quê, risco, usuário) e segue com as linhas atividade | comando. Tudo é sintaxe documentada do 19c; nada foi inventado.
Antes de parar qualquer camadaRegistro de manutenção. Vale para nó, Grid, ASM, listener, SCAN, VIP, banco, instância, PDB e serviço.
Manutenção nos monitores. Zabbix: host ou serviço em manutenção, com período, no modo “sem coleta” ou “com coleta, sem alerta”. EM 24ai: blackout nos targets cluster, ASM, listeners, banco e instâncias, por emcli create_blackout ou pela console.
Avisar quem depende. Aplicações que entram pelos serviços do SCAN; backups RMAN agendados; replicação ou Data Guard, se houver; jobs do Scheduler.
Registrar. Chamado e janela: início, fim, o que para e quem autorizou.
Depois de subir
Tirar a manutenção no Zabbix e o blackout no EM 24ai (emcli stop_blackout).
Conferir no Zabbix e no EM que os targets voltaram: sem problema aberto, coleta ativa, status Up.
Registrar o resultado no chamado: o que parou, por quanto tempo, o que ficou pendente.
AtividadeComando
Blackout no EM 24aiAlvos no formato nome:tipo separados por ponto e vírgula (rac_database, cluster, osm_cluster, oracle_listener, host). Pela console: Enterprise, Monitoring, Blackouts.
Encerrar o blackoutDepois que tudo estiver ONLINE; aí os alertas voltam a valer.
oms $emcli stop_blackout -name="CDB_janela"
01
Status do cluster
Por quê: todo atendimento começa fotografando o estado. Risco: nenhum, são todos comandos de leitura. Usuário: grid para o Grid, oracle para o banco. Cole a saída de crsctl stat res -t no chamado antes de mexer em qualquer coisa.
AtividadeComando
Foto completa dos recursosTabela com cada recurso, em cada nó, ONLINE ou OFFLINE.
grid@rac10 $crsctl stat res -t
Saúde do stack neste nóCRS-4638/4537/4529/4533 = tudo online.
grid@rac10 $crsctl check crs
Saúde do stack em todos os nósUma linha por nó: CRS, CSS e EVM.
grid@rac10 $crsctl check cluster -all
Recursos de base (ohasd)Os recursos locais que sustentam o stack: cssd, ctssd, asm, crsd, evmd, crf…
grid@rac10 $crsctl stat res -t -init
Nós do clusterNúmero, VIP público (-i), status e tipo (pinned/unpinned). O IP privado do interconnect é o oifcfg.
Banco: instâncias e serviçosEsperado: CDB1 em rac10 e CDB2 em rac11, ambas running.
oracle@rac10 $srvctl status database -d CDB -v
ASM+ASM1 e +ASM2 running.
grid@rac10 $srvctl status asm
SCAN e listenersTrês listeners do SCAN, mais o LISTENER de cada nó.
grid@rac10 $srvctl status scan_listenergrid@rac10 $srvctl status listener
Nodeapps (VIP, rede, ONS)VIP e ONS de cada nó; VIP em nó errado denuncia failover.
grid@rac10 $srvctl status nodeapps
02
Um nó: parar e subir com segurança
Por quê: patch de SO, troca de hardware virtual, reboot. Risco: parar de qualquer jeito deixa sessões caindo e recovery de instância no outro nó. Ordem: de dentro para fora para parar (serviço, instância, Grid, SO) e de fora para dentro para subir. Usuário: oracle para a instância, root para o Grid e o reboot.
AtividadeComando
Tirar os serviços deste nóLeva o serviço da instância local para a outra; a aplicação reconecta pelo SCAN.
Pode prejudicaroracle@rac10 $srvctl relocate service -d CDB -s app_svc -oldinst CDB1 -newinst CDB2Altera: a instância que atende o serviço; sessões na instância antiga podem ser desconectadas. Antes: conferir com status -v e avisar a aplicação. Zabbix e EM 24ai em manutenção.
Parar a instância local paradaO outro nó segue atendendo.
Pode prejudicaroracle@rac10 $srvctl stop instance -d CDB -i CDB1 -o immediateDerruba: a instância deste nó; as sessões nela caem, o outro nó segue atendendo. Antes: relocar os serviços que têm esta instância como preferida. Zabbix e EM 24ai em manutenção.
Parar o Grid neste nó paradaSe algum recurso não parar, repita com -f (força).
Pode prejudicarroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl stop crsse travar: crsctl stop crs -fDerruba: instância, ASM, listener e VIP deste nó; o outro nó segue sozinho. Antes: serviços relocados e instância do banco parada neste nó. Zabbix e EM 24ai em manutenção.
Reiniciar o nó paradaCom o Grid parado o reboot é limpo.
Pode prejudicarroot@rac10 #systemctl rebootDerruba: tudo o que roda neste nó: instância, ASM, listener e VIP. Antes: serviços relocados, instância e Grid parados (seção 2). Zabbix e EM 24ai em manutenção.
Subir o GridSe o autostart está habilitado, o boot já sobe; confira antes de mandar subir.
Trazer os serviços de voltaDevolve o serviço à instância preferida.
Pode prejudicaroracle@rac10 $srvctl relocate service -d CDB -s app_svc -oldinst CDB2 -newinst CDB1Altera: a instância que atende o serviço; sessões na instância antiga podem ser desconectadas. Antes: conferir com status -v e avisar a aplicação. Zabbix e EM 24ai em manutenção.
ConferirStack online e as duas instâncias running.
grid@rac10 $crsctl check crsoracle@rac10 $srvctl status database -d CDB -v
03
Cluster inteiro
Por quê: parada total do storage, do T410 ou manutenção que não pode ser rolling. Risco: indisponibilidade total do banco. Usuário: root. -all ou -n:crsctl stop cluster para o stack (mantém o ohasd) e aceita -all para todos os nós ou -n rac11 para um nó remoto, a partir de qualquer nó; crsctl stop crs para tudo, inclusive o ohasd, e só vale para o nó local.
AtividadeComando
Parar o stack em todos os nós paradaBanco, ASM, listeners e VIPs caem nos dois nós; o ohasd fica vivo.
Pode prejudicarroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl stop cluster -allse algum recurso não parar: acrescente -fDerruba: o banco inteiro nos dois nós; o ohasd fica vivo. Antes: janela aprovada, aplicações, RMAN, Data Guard e Scheduler avisados. Zabbix e EM 24ai em manutenção.
Subir o stack em todos os nósDepois, crsctl stat res -t até tudo ficar ONLINE.
Parar ou subir o stack de um nó remoto paradaAge sobre o outro nó a partir deste, sem entrar nele.
Pode prejudicarroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl stop cluster -n rac11root@rac10 #/u01/app/19.3.0/19c27/bin/crsctl start cluster -n rac11Derruba: instância, ASM, listener e VIP do outro nó. Antes: serviços relocados para cá e instância de lá parada. Zabbix e EM 24ai em manutenção.
Impedir que o Grid suba no bootPara manutenção longa do nó. Vale só para o nó em que se roda; não esqueça de reabilitar.
Pode prejudicarroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl disable crsAltera: o boot: este nó não sobe o Grid sozinho no próximo reinício. Antes: anotar no chamado para reabilitar no fim da manutenção. Zabbix e EM 24ai em manutenção.
Voltar a subir o Grid no bootConfira com crsctl config crs.
Por quê: o banco se opera pelo srvctl, que fala com o Grid; assim o Grid sabe que a parada foi intencional e os serviços seguem a política. Risco:shutdown pelo sqlplus funciona, mas o Grid passa a tratar a instância como parada de propósito e não a religa; é exceção, não rotina. Usuário: oracle.
AtividadeComando
Ver como o banco está registradoHome, spfile, diskgroups, instâncias, serviços e política de start.
oracle@rac10 $srvctl config database -d CDB
StatusInstâncias e, com -v, os serviços.
oracle@rac10 $srvctl status database -d CDB -v
Parar o banco inteiro parada-o immediate desconecta as sessões e faz rollback do que estava aberto.
Pode prejudicaroracle@rac10 $srvctl stop database -d CDB -o immediateDerruba: todas as instâncias e serviços nos dois nós: toda aplicação cai. Antes: janela aprovada, RMAN, Data Guard e Scheduler avisados. Zabbix e EM 24ai em manutenção.
Subir o banco inteiroAbre as duas instâncias e os serviços.
oracle@rac10 $srvctl start database -d CDB
Subir só até MOUNTPara RMAN, troca de parâmetro ou abertura controlada.
oracle@rac10 $srvctl start database -d CDB -o mount
Parar e subir uma instânciaA operação de rotina em RAC: um nó por vez.
Pode prejudicaroracle@rac10 $srvctl stop instance -d CDB -i CDB1 -o immediateoracle@rac10 $srvctl start instance -d CDB -i CDB1Derruba: a instância deste nó; as sessões nela caem, o outro nó segue atendendo. Antes: relocar os serviços que têm esta instância como preferida. Zabbix e EM 24ai em manutenção.
Mover um serviço de instância-oldinst é de onde sai, -newinst é para onde vai.
Pode prejudicaroracle@rac10 $srvctl relocate service -d CDB -s app_svc -oldinst CDB1 -newinst CDB2Altera: a instância que atende o serviço; sessões na instância antiga podem ser desconectadas. Antes: conferir com status -v e avisar a aplicação. Zabbix e EM 24ai em manutenção.
Entrar como SYSDBASempre na instância local do nó.
oracle@rac10 $export ORACLE_SID=CDB1oracle@rac10 $sqlplus / as sysdba
Ver as instâncias por dentroStatus, host, logins e tempo de vida de cada uma. Normal: OPEN, ACTIVE, ALLOWED.
SQL>select inst_id, instance_name, host_name, status, database_status, logins, startup_time from gv$instance order by inst_id;
Mudar um parâmetro nas duas instânciasEm RAC, sid='*' grava para todas; scope=both aplica agora e no spfile.
Pode prejudicarSQL>alter system set open_cursors=500 scope=both sid='*';Altera: o parâmetro nas duas instâncias, agora e no spfile. Antes: conferir o valor atual com show parameter e anotar no chamado. Zabbix e EM 24ai em manutenção.
Parar pelo sqlplus (só exceção) paradaPara só a instância em que você está. O Grid entende como parada intencional; depois, suba pelo srvctl.
Pode prejudicarSQL>shutdown immediateDerruba: esta instância; o Grid trata como parada intencional e não a religa. Antes: relocar os serviços preferidos daqui; depois subir pelo srvctl. Zabbix e EM 24ai em manutenção.
FRA: limite e usoFRA cheia trava o banco (ORA-00257). Olhe usado_gb contra limite_gb.
SQL>select name, round(space_limit/1024/1024/1024,2) limite_gb, round(space_used/1024/1024/1024,2) usado_gb, number_of_files from v$recovery_file_dest;
Derrubar uma sessãosid, serial# e inst_id vêm de gv$session; em RAC o @inst_id diz em que instância a sessão está.
Pode prejudicarSQL>select inst_id, sid, serial#, username, status, program from gv$session where username is not null;SQL>alter system kill session 'sid,serial#,@inst_id' immediate;Derruba: a sessão escolhida; a transação dela sofre rollback. Antes: confirmar sid, serial# e inst_id com o dono da aplicação. Zabbix e EM 24ai em manutenção.
05
PDB
Por quê: a aplicação mora na PDB; abrir, fechar e deixar em read only são as operações do dia. Risco: num RAC, sem instances=all o comando age só na instância em que você está, e a PDB fica aberta num nó e fechada no outro. Usuário: oracle, no sqlplus como SYSDBA conectado ao CDB$ROOT. Hoje só existe PDB$SEED; PDB1 é o exemplo.
AtividadeComando
Listar as PDBs e o modo de cada umashow pdbs mostra a instância local; a consulta em gv$ mostra as duas.
SQL>show pdbsSQL>select inst_id, name, open_mode, restricted from gv$pdbs order by name, inst_id;
Abrir a PDB nas duas instânciasREAD WRITE.
Pode prejudicarSQL>alter pluggable database PDB1 open instances=all;Altera: o estado da PDB nas duas instâncias (passa a aceitar conexão). Antes: conferir em gv$pdbs em que modo ela está. Zabbix e EM 24ai em manutenção.
Abrir em somente leituraPara relatório, auditoria ou proteção durante uma manutenção.
Pode prejudicarSQL>alter pluggable database PDB1 open read only instances=all;Altera: a PDB para somente leitura: toda gravação da aplicação falha. Antes: avisar a aplicação e os jobs do Scheduler. Zabbix e EM 24ai em manutenção.
Fechar a PDB paradaimmediate derruba as sessões da PDB; sem ele, espera as sessões saírem.
Pode prejudicarSQL>alter pluggable database PDB1 close immediate instances=all;Derruba: as sessões da PDB nas duas instâncias. Antes: avisar a aplicação; a PDB fica MOUNTED até reabrir. Zabbix e EM 24ai em manutenção.
Guardar o estado para o próximo startSem isto, depois de um restart a PDB volta MOUNTED (fechada).
Pode prejudicarSQL>alter pluggable database PDB1 save state instances=all;Altera: o que a PDB faz no próximo start, nas duas instâncias. Antes: conferir open_mode em gv$pdbs e deixar a PDB no modo que deve ser guardado. Zabbix e EM 24ai em manutenção.
Entrar na PDB e voltar ao rootPara operar objetos de dentro.
SQL>alter session set container=PDB1;SQL>alter session set container=CDB$ROOT;
Pelo Grid: serviço amarrado à PDBAo subir um serviço com -pdb, o Grid abre a PDB na instância do serviço. Veja a seção 7.
oracle@rac10 $srvctl config service -d CDB -s app_svcoracle@rac10 $srvctl start service -d CDB -s app_svc
06
PDBs no CDB com OMF: criar, servir, clonar, plugar e apagar
Por quê: o CDB do laboratório é OMF (Oracle Managed Files): db_create_file_dest=+DATA e db_recovery_file_dest=+FRA. O Oracle nomeia e posiciona cada datafile sozinho, na árvore +DATA/{db_unique_name}/{GUID da PDB}/DATAFILE/. Por isso nenhum comando desta seção leva FILE_NAME_CONVERT; o dbca usa o mesmo OMF do CDB. Risco: criar, servir e clonar são seguros; unplug fecha a PDB e drop apaga dados. Usuário: oracle, no sqlplus como SYSDBA conectado ao CDB$ROOT; dbca também como oracle. A senha do admin vem do cofre e nunca desta página.
AtividadeComando
O CDB é OMF?Esperado: +DATA para datafiles e +FRA para recovery; o srvctl mostra os diskgroups de que o banco depende. Com isso, nada de FILE_NAME_CONVERT.
SQL>show parameter db_create_file_destSQL>show parameter db_recovery_file_destSQL>select name, value from v$parameter where name in ('db_create_file_dest','db_recovery_file_dest','db_create_online_log_dest_1');oracle@rac10 $srvctl config database -d CDB
Criar a PDB a partir do seed (SQL)Com OMF basta isto: o Oracle copia o seed para +DATA sob o GUID da PDB nova. ROLES=(DBA) dá ao admin o papel de DBA local da PDB.
SQL>create pluggable database PDB2 admin user pdbadmin identified by senha roles=(dba);a senha vem do cofre; troque senha na hora de rodar
Abrir nas duas instâncias e guardar o estadoSem instances=all a PDB abre só onde você está; sem save state ela volta MOUNTED no próximo start.
Pode prejudicarSQL>alter pluggable database PDB2 open instances=all;SQL>alter pluggable database PDB2 save state instances=all;Altera: o estado da PDB nas duas instâncias e o que ela faz no próximo start. Antes: conferir em gv$pdbs em que modo ela está. Zabbix e EM 24ai em manutenção.
Criar a PDB pelo dbca (silencioso)Mesmo resultado por fora do sqlplus: o dbca cria a partir do seed, abre nas instâncias e usa o OMF do CDB (não pede caminho). A senha aparece no ps enquanto roda: prefira o SQL ou rode numa sessão só sua.
oracle@rac10 $dbca -silent -createPluggableDatabase -sourceDB CDB -pdbName PDB2 -createPDBFrom DEFAULT -pdbAdminUserName pdbadmin -pdbAdminPassword senhadepois, conferir o save state (abaixo em Verificar)
Serviço da aplicação para a PDBEm RAC a aplicação entra pelo serviço, nunca pela instância. -pdb amarra o serviço à PDB (o Grid a abre onde o serviço sobe); preferido em uma instância, disponível na outra; -failovertype SELECT -failovermethod BASIC é o TAF, que religa a sessão no outro nó.
oracle@rac10 $srvctl add service -d CDB -s pdb1_srv -pdb PDB2 -preferred CDB1 -available CDB2 -failovertype SELECT -failovermethod BASICoracle@rac10 $srvctl start service -d CDB -s pdb1_srvoracle@rac10 $srvctl status service -d CDB -s pdb1_srv -v
Testar pelo SCAN, como a aplicaçãotnsping prova listener e serviço; o sqlplus pelo EZConnect prova o caminho inteiro até a PDB.
Clonar uma PDB (cópia local)Cria a PDB nova como cópia da existente, nos mesmos diskgroups, sob um GUID novo. Em 19c a origem pode ficar aberta (local undo + archivelog); se não, abra-a read only antes. Depois, abrir e guardar o estado como acima.
Pode prejudicarSQL>create pluggable database PDB2 from PDB1;SQL>alter pluggable database PDB2 open instances=all;SQL>alter pluggable database PDB2 save state instances=all;Altera: o estado da PDB nova nas duas instâncias; o clone consome espaço no +DATA igual ao da origem. Antes: conferir o livre em asmcmd lsdg. Zabbix e EM 24ai em manutenção.
Unplug: desconectar a PDB paradaFecha a PDB nas duas instâncias e gera o manifesto xml; os datafiles ficam no +DATA. O xml fica no filesystem deste nó: plugue a partir dele.
Pode prejudicarSQL>alter pluggable database PDB2 close immediate instances=all;SQL>alter pluggable database PDB2 unplug into '/u01/app/oracle/admin/PDB2_unplug.xml';Derruba: as sessões da PDB nas duas instâncias; a PDB fica desconectada até ser plugada de novo. Antes: serviço parado (srvctl stop service), aplicação avisada e backup RMAN da PDB. Zabbix e EM 24ai em manutenção.
Plug: conectar a PDB pelo xmlCOPY copia os datafiles para a árvore OMF do CDB (GUID novo), sem FILE_NAME_CONVERT. Para plugar de volta no mesmo CDB com o mesmo nome, antes: drop pluggable database … keep datafiles.
Pode prejudicarSQL>create pluggable database PDB2 using '/u01/app/oracle/admin/PDB2_unplug.xml' copy;SQL>alter pluggable database PDB2 open instances=all;SQL>alter pluggable database PDB2 save state instances=all;Altera: o estado da PDB nas duas instâncias e o espaço no +DATA (cópia dos datafiles). Antes: conferir o livre em asmcmd lsdg e o xml no caminho. Zabbix e EM 24ai em manutenção.
Verificar: modo, estado guardado e arquivosopen_mode por instância; o que está guardado para o próximo start; os datafiles sob +DATA/{DBL}/{{GUID}}/DATAFILE/ (o GUID é o de v$pdbs). As consultas rodam no CDB$ROOT.
SQL>select inst_id, name, open_mode, restricted from gv$pdbs order by name, inst_id;SQL>select con_name, instance_name, state from dba_pdb_saved_states order by con_name, instance_name;SQL>select p.name pdb, p.guid, f.file_name from cdb_data_files f join v$pdbs p on p.con_id=f.con_id where p.name='PDB2' order by f.file_name;exemplo de caminho OMF: +DATA/cdb/8A1C…F2/DATAFILE/system.274.1183456789
Apagar a PDB paradaPrimeiro o serviço sai do Grid, depois a PDB fecha nas duas instâncias e o drop com INCLUDING DATAFILES apaga os datafiles do +DATA.
Pode prejudicaroracle@rac10 $srvctl stop service -d CDB -s pdb1_srvoracle@rac10 $srvctl remove service -d CDB -s pdb1_srvSQL>alter pluggable database PDB2 close immediate instances=all;SQL>drop pluggable database PDB2 including datafiles;Apaga: a PDB e todos os datafiles dela no +DATA; sem backup não volta. Antes: backup RMAN da PDB (backup pluggable database), aplicação avisada, serviço removido e aval por escrito do dono. Zabbix e EM 24ai em manutenção.
07
Serviços
Por quê: a aplicação nunca conecta na instância; conecta num serviço pelo SCAN. O serviço diz em que instância prefere rodar e para onde vai se ela cair. Risco: parar um serviço derruba a aplicação que o usa. Usuário: oracle para o serviço; grid para o lsnrctl.
AtividadeComando
Criar o serviço da aplicaçãoPreferido em CDB1, disponível em CDB2, amarrado à PDB1.
Subir o serviçoAbre a PDB se precisar e registra o serviço nos listeners.
oracle@rac10 $srvctl start service -d CDB -s app_svc
Status e configuraçãoEm que instância está, e como foi definido.
oracle@rac10 $srvctl status service -d CDB -s app_svcoracle@rac10 $srvctl config service -d CDB -s app_svc
Relocar o serviço sem derrubar a aplicaçãoAntes de parar a instância preferida: primeiro o status com -v, depois o relocate. A aplicação reconecta pelo SCAN.
Pode prejudicaroracle@rac10 $srvctl status service -d CDB -s app_svc -voracle@rac10 $srvctl relocate service -d CDB -s app_svc -oldinst CDB1 -newinst CDB2Altera: a instância que atende o serviço; sessões na instância antiga podem ser desconectadas. Antes: conferir com status -v e avisar a aplicação. Zabbix e EM 24ai em manutenção.
Parar o serviço paradaA aplicação perde a conexão.
Pode prejudicaroracle@rac10 $srvctl stop service -d CDB -s app_svcDerruba: a aplicação que usa o serviço: as conexões caem e não há para onde migrar. Antes: avisar a aplicação; se for só manutenção de nó, use relocate. Zabbix e EM 24ai em manutenção.
Ver o serviço registrado no listenerDeve aparecer na lista de serviços do LISTENER e dos SCAN.
grid@rac10 $lsnrctl status
Conectar pelo SCAN (como a aplicação)EZConnect; o sqlplus pede a senha. Se entrar, o caminho inteiro está bom.
Por quê: todo dado do banco está nos diskgroups DATA, FRA e OCR; OCR guarda também o registro do cluster e os voting disks. Risco: parar o ASM de um nó derruba a instância do banco daquele nó. Usuário: grid, com ORACLE_SID=+ASM1 em rac10 (+ASM2 em rac11).
AtividadeComando
Status e configuração do ASMEm qual nó cada instância está; home e spfile do ASM.
grid@rac10 $srvctl status asmgrid@rac10 $srvctl config asm
Diskgroups: estado e espaçoMOUNTED e o livre de cada um. Olhe o Usable_file_MB.
grid@rac10 $asmcmd lsdg
Discos de um diskgroupCaminho e estado de cada disco.
grid@rac10 $asmcmd lsdsk -k -G DATA
Rebalanceamento em curso?Nunca parar o ASM ou um nó durante um rebalance sem avaliar.
grid@rac10 $asmcmd lsop
Status de um diskgroup pelo GridMontado em quais nós.
grid@rac10 $srvctl status diskgroup -g DATA
Montar um diskgroupPelo Grid (neste nó) ou por dentro do ASM.
grid@rac10 $srvctl start diskgroup -g DATA -n rac10grid@rac10 $sqlplus / as sysasmSQL>alter diskgroup DATA mount;
Ver os diskgroups por dentroNome, estado, redundância e espaço.
SQL>select name, state, type, total_mb, free_mb from v$asm_diskgroup;
Mudar a força do rebalanceamento0 pausa; 1 a 1024 acelera e consome I/O do storage. Só com o lsop na mão.
Pode prejudicarSQL>alter diskgroup DATA rebalance power 4;Altera: o I/O do storage durante o rebalance; power alto degrada o banco. Antes: asmcmd lsop, janela e aval do DBA. Zabbix e EM 24ai em manutenção.
Parar o ASM de um nó paradaFalha se o banco estiver usando o ASM neste nó: pare a instância do banco antes.
Pode prejudicargrid@rac10 $srvctl stop asm -n rac10 -o immediateDerruba: os diskgroups neste nó; falha se a instância do banco ainda usa o ASM aqui. Antes: instância do banco parada neste nó. Zabbix e EM 24ai em manutenção.
Subir o ASM de um nóDepois, os diskgroups montam sozinhos.
grid@rac10 $srvctl start asm -n rac10
09
Listener, SCAN e VIP
Por quê: a aplicação chega pelo SCAN (rac10-scan.sourcetec.vm, três IPs), que a redireciona ao VIP do nó com o listener local. Risco: parar o listener de um nó corta as conexões novas naquele nó; parar o VIP exige o listener parado. Usuário: grid.
AtividadeComando
Como o SCAN, os listeners e os nodeapps estão configuradosNome, os três IPs e as três VIPs do SCAN; VIP, rede e ONS de cada nó com -a.
Status de SCAN, listeners e VIPsA foto da camada de rede do cluster.
grid@rac10 $srvctl status scangrid@rac10 $srvctl status scan_listenergrid@rac10 $srvctl status listenergrid@rac10 $srvctl status vip -n rac10
O DNS responde os três IPs do SCAN? O tnsping atravessa?Esperado: 10.10.5.47, .48 e .49, em ordem variável; o tnsping prova listener e serviço pela porta.
Listener local: parar e subir paradaConexões novas neste nó param; as existentes seguem.
Pode prejudicargrid@rac10 $srvctl stop listener -n rac10grid@rac10 $srvctl start listener -n rac10Derruba: as conexões novas neste nó; as existentes seguem. Antes: o outro nó com listener ONLINE e os SCAN apontando para ele. Zabbix e EM 24ai em manutenção.
Listener do SCAN: parar, subir, mover paradaUm de cada vez (-i 1, 2 ou 3); os outros dois continuam atendendo.
Pode prejudicargrid@rac10 $srvctl stop scan_listener -i 1grid@rac10 $srvctl start scan_listener -i 1grid@rac10 $srvctl relocate scan_listener -i 1 -n rac11Derruba: um dos três listeners do SCAN; a aplicação reconecta pelos outros dois. Antes: conferir os três ONLINE e parar um de cada vez. Zabbix e EM 24ai em manutenção.
VIP do nó: parar e subir paradaSó com o listener do nó parado; senão o srvctl recusa.
Pode prejudicargrid@rac10 $srvctl stop vip -n rac10grid@rac10 $srvctl start vip -n rac10Derruba: o VIP do nó: nada mais chega por ele. Antes: listener do nó parado (senão o srvctl recusa). Zabbix e EM 24ai em manutenção.
Serviços registrados num listenerO lsnrctl precisa do home do Grid no ambiente. ONLINE no Grid mas BLOCKED ou sem instância aqui = o serviço não entra.
grid@rac10 $lsnrctl status LISTENER_SCAN1grid@rac10 $lsnrctl status LISTENER
10
Logs e diagnóstico
Por quê: antes de reiniciar qualquer coisa, ler o alert. Onde: o alert do Grid fica sob GRID_BASE (/u01/app/grid) e o do banco sob ORACLE_BASE (/u01/app/oracle), ambos na árvore diag/; os dois vêm do bloco Personalize, e o nome do banco entra em minúsculas no caminho. Risco: nenhum; só leitura. Usuário: grid para o Grid, oracle para o banco, root para ocrcheck.
AtividadeComando
Alert do Grid deste nóQuem parou o quê, quando, e por quê. Se o caminho não existir, use o find.
Alert da instância do bancoPelo arquivo direto (acompanhando ao vivo) ou pelo adrci. O db_unique_name entra em minúsculas no caminho.
oracle@rac10 $tail -f /u01/app/oracle/diag/rdbms/cdb/CDB1/trace/alert_CDB1.logoracle@rac10 $adrci exec="set base /u01/app/oracle; set home diag/rdbms/cdb/CDB1; show alert -tail 100"
Alert do Grid pelo adrciCom a base do grid; o home do Clusterware é diag/crs/nó/crs.
grid@rac10 $adrci exec="set base /u01/app/grid; set home diag/crs/rac10/crs; show alert -tail 50"
Checar cada camada do stackCRS (tudo), CSS (membership) e EVM (eventos).
Detalhe de um recursoTodos os atributos (AUTO_START, política, dependências) de ora.cdb.db.
grid@rac10 $crsctl stat res ora.cdb.db -p
11
Manutenção de SO em rolling
Por quê: patch de SO sem parar o banco: um nó de cada vez, o outro atende. Risco: durante a janela o cluster roda com um nó só; qualquer falha nele é parada total. Usuário: oracle para serviços e instância, root para Grid, dnf e reboot. Feito rac10, repete-se tudo em rac11 trocando NODE e INSTANCE no bloco Personalize.
AtividadeComando
Abrir a janelaZabbix em manutenção, blackout no EM 24ai, RMAN, Data Guard e Scheduler avisados, chamado registrado (bloco Antes de parar).
oms $emcli create_blackout -name="CDB_rolling" -add_targets="CDB:rac_database" -reason="patch de SO em rolling" -schedule="frequency:once;duration:02:00"
Drenar os serviços do nóUm relocate por serviço que tem o nó como preferido.
Pode prejudicaroracle@rac10 $srvctl status database -d CDB -voracle@rac10 $srvctl relocate service -d CDB -s app_svc -oldinst CDB1 -newinst CDB2Altera: a instância que atende o serviço; sessões na instância antiga podem ser desconectadas. Antes: conferir com status -v e avisar a aplicação. Zabbix e EM 24ai em manutenção.
Parar a instância paradaNeste nó só.
Pode prejudicaroracle@rac10 $srvctl stop instance -d CDB -i CDB1 -o immediateDerruba: a instância deste nó; as sessões nela caem, o outro nó segue atendendo. Antes: relocar os serviços que têm esta instância como preferida. Zabbix e EM 24ai em manutenção.
Parar o Grid paradaCom tudo parado, o patch de kernel e de bibliotecas não pega nada aberto.
Pode prejudicarroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl stop crsDerruba: instância, ASM, listener e VIP deste nó; o outro nó segue sozinho. Antes: serviços relocados e instância do banco parada neste nó. Zabbix e EM 24ai em manutenção.
Atualizar o SOSó pacotes do sistema; o Oracle não se atualiza por dnf.
Pode prejudicarroot@rac10 #dnf -y updateAltera: o SO do nó; o kernel novo só entra com o reboot seguinte. Antes: Grid parado neste nó (passo anterior). Zabbix e EM 24ai em manutenção.
Reiniciar paradaKernel novo só entra com reboot.
Pode prejudicarroot@rac10 #systemctl rebootDerruba: tudo o que roda neste nó: instância, ASM, listener e VIP. Antes: serviços relocados, instância e Grid parados (seção 2). Zabbix e EM 24ai em manutenção.
Subir o Grid e esperarSe o autostart está habilitado, só conferir; se não, mandar subir.
Subir a instância e devolver os serviçosDe volta ao desenho original.
Pode prejudicaroracle@rac10 $srvctl start instance -d CDB -i CDB1oracle@rac10 $srvctl relocate service -d CDB -s app_svc -oldinst CDB2 -newinst CDB1Altera: a instância que atende o serviço; sessões na instância antiga podem ser desconectadas. Antes: conferir com status -v e avisar a aplicação. Zabbix e EM 24ai em manutenção.
Conferir e seguir para o outro nóTudo ONLINE nos dois nós antes de começar o rac11.
grid@rac10 $crsctl stat res -toracle@rac10 $srvctl status database -d CDB -v
Fechar a janelaTirar a manutenção no Zabbix, encerrar o blackout, conferir que os targets voltaram nos dois monitores e registrar o resultado no chamado.
oms $emcli stop_blackout -name="CDB_rolling"
12
AHF/TFA e CHM
Situação: o AHF/TFA (coleta de diagnóstico) e o CHM (Cluster Health Monitor, recurso ora.crf) estão desligados nos dois nós por decisão de 08/10/2026, para poupar CPU no laboratório. Risco: nenhum para o banco; só se perde coleta automática. Usuário: root para ligar e desligar, grid para ver.
AtividadeComando
Ver se o TFA está rodandoEsperado hoje: parado e desabilitado.
root@rac10 #/u01/app/19.3.0/19c27/bin/tfactl statusroot@rac10 #systemctl status oracle-tfa
Ver se o CHM está rodandoEsperado hoje: ora.crf OFFLINE e ENABLED=0.
grid@rac10 $crsctl stat res ora.crf -initgrid@rac10 $ps -ef | grep -E 'osysmond|ologgerd' | grep -v grep
Ligar o TFA de novoEm cada nó. Volta a coletar e a consumir CPU.
root@rac10 #systemctl enable --now oracle-tfa
Ligar o CHM de novoEm cada nó: habilita o recurso e sobe.
root@rac10 #/u01/app/19.3.0/19c27/bin/crsctl modify res ora.crf -attr ENABLED=1 -initroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl start res ora.crf -init
Desligar de novo (estado atual)O inverso, se ligou só para uma coleta.
root@rac10 #systemctl disable --now oracle-tfaroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl stop res ora.crf -initroot@rac10 #/u01/app/19.3.0/19c27/bin/crsctl modify res ora.crf -attr ENABLED=0 -init