Database não monta por não encontrar controlfile no ASM

Oracle Databases 10 minutos

Olá DBAs, a vida tá boa?

Estamos aqui, pós ressaca do GUOB Tech Day 2025 para finalmente um novo artigo. Agora quase que totalmente descansado do turbilhão que foi o evento, e do turbilhão que foi a semana da LAOUC tour (e olha que eu só palestrei em 2 países, fico imaginando uma galera mais top que palestrou em diversos países na mesma semana, como não foi puxado). Bom, de qualquer maneira, chega de GUOB por enquanto (pelo menos pra vocês, pois nós da organização pensamos nisso o ano todo), e vamos voltar a vida e eventos normalmente. E para celebrar isso, vamos de artigo técnico!!!

Estas andanças na vida de DBA como consultor sempre me surpreendem! Sério! Passei esses dias por um problema, que eu particularmente achei muito interessante, de certo modo até desafiador, e gostaria de compartilhar com vocês. Então, “simbora”, e como diz a Amanda Belniack (mina do agro que faz uns vídeos engraçados demais), “Chama na Cachangaaaaa”!!!!

  • só deixando claro que quando acima aqui digo que o banco não abre, eu sei que nesse ponto de leitura do controlfile ele tá tentando fazer o “mount”, mas estou falando do objetivo final de um startup que é abrir o banco, então nesse caso, se ele não monta, ele nem vai adiante para abrir. Em resumo, a porcaria do banco não abre 🙂

Só recapitulando, como todo DBA sabe, a abertura do banco de dados passa por 3 fases:

NOMOUNT ==> carrega parâmetros e inicia a instancia com estruturas de memória.
MOUNT ==> lê os controlfiles, conhece a estrutura física.
OPEN ==> abre datafiles e redo logs, torna o banco disponível para uso.

Tudo certo, todos se lembram? Show! Eu não duvidei de vocês nem por um segundo.

Então estava eu, tranquilo e sossegado, quando liguei meu notebook de manhã e vi meu teams pipocando mais que fogos do meio dia no 12 de Outubro. Cliente teve uma queda de energia no começo da madrugada, vários servers caíram, e ele informava que pra esse server em específico, o banco não subia, e segundo o cliente, eles já haviam “tentado de tudo durante a madrugada” (essa frase me preocupou…huahuahuauhauha).

Bom, por sorte eu não trabalho no esquema de plantão, então mesmo com esse fogo da madrugada deles, eu não fui acionado. Bom, por azar, só me chamam quando a coisa tá feia, então era hora de ativar o modo “DBA que resolve bucha braba” e começar a checar o que tava acontecendo.

Para ilustrar melhor o ambiente e deixar a mente de vocês mais informada, este cliente utiliza uma arquitetura onde ele tem um banco de dados principal, e outros 3 bancos de dados sendo replicados via GoldenGate. Este 3 replicados são utilizados para consulta no site, para ajudar a balancear a consulta no ambiente, mas quando o cliente coloca um item no carrinho, e vai para o pagamento, aí sim tudo se centraliza no banco principal. Um destes 3 servers estava problemático, mas ainda haviam outros dois funcionando, e o banco principal estava no ar, então pensando em criticidade, era crítico por ser ambiente produtivo, mas haviam redundâncias segurando a bronca, então por mais que eu precisasse atuar com certa urgencia, eu tinha tempo para pensar e pesquisar com uma certa tranquilidade.

Em um momento destes, é muito importante entender o cliente, entender sua necessidade, entender sua urgencia e sua dor. Mostrar empatia em relação ao nervosismo e apreensão do cliente. Só que mais importante ainda é saber e entender que as coisas não se resolvem em passe de mágica, e que você precisa olhar, analisar, entender, diagnosticar, conferir e só depois você pode resolver. Não adianta sair igual “vaca braba”. Mantenha a calma sempre, seja parceiro, mas mantenha uma certa distancia para que você não entre na pilha de nervosismo e com isso tenha sua análise comprometida.

Bom… vamos ao técnico!!! Primeiro passo, tentar subir a base e ver o que acontece (se já tá tudo quebrado, não tem como eu quebrar mais… huauhauhahua)

[oracle@copia01 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Wed Sep 10 08:38:27 2025

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 1.0048E+11 bytes
Fixed Size                  2264816 bytes
Variable Size            1.4496E+10 bytes
Database Buffers         8.5899E+10 bytes
Redo Buffers               86405120 bytes
ORA-00205: error in identifying control file, check alert log for more info
  • Sim, é 11.2.0.4, já expliquei em posts anteriores e volto a explicar: Tem sim muito cliente trabalhando com coisa velha, que não quer ir adiante ou por grana, ou por se sentir seguro, existem mil motivos. Como consultor a gente orienta e aconselha, mas não toma decisões.

Bom, como podemos ver, erro clássico de não achar o controlfile. Pensando nisso, já imaginei que não tivessem subido o ASM, decidi checar, e verfiquei que o ASM estava no ar, e pior, estava rodando corretamente.

[oracle@copia1 trace]$ crsctl status resource -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATAC1.dg
               ONLINE  ONLINE       copia1
ora.LISTENER.lsnr
               ONLINE  ONLINE       copia1
ora.asm
               ONLINE  ONLINE       copia1                    Started
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
      1        ONLINE  ONLINE       copia1
ora.evmd
      1        ONLINE  ONLINE       copia1
ora.DB_1.db
      1        ONLINE  OFFLINE                               Instance Shutdown
  • Single node beleza galera!

Checando o alert do ASM, tudo estava OK, ele subiu normalmente, e não havia nenhum problema. Sendo assim, porque o Controlfile não estava sendo encontrado pelo banco? Será que alguém apagou o controlfile? Será que por algum motivo ele sumiu? Será que houve algum crash no disco? Naquele bloco específico? Será… Será… Será???

Próximo passo, vamos checar o local do controlfile.

ASMCMD> ls -l
Type         Redund  Striped  Time             Sys  Name
CONTROLFILE  UNPROT  FINE     SEP 10 10:00:00  Y    Current.256.99999999
ASMCMD> pwd
+DATAC1/DB_1/CONTROLFILE

Ok! Controlfile no lugar, como deveria ser. Infelizmente não está multiplexado. Apesar de ser um ambiente produtivo, é um ambiente considerado pelo cliente meio como lado “B”, Não tem backup desse ambiente, não tem autobackup do controlfile. Vou analisar a multiplexação desse arquivo a partir de agora, pois caso o arquivo esteja corrompido, a multiplexação me salvaria nesse caso sem eu ter que recriar controlfile e etc..

Sendo assim, por ele não está lendo, será que está corrompido? Como validar? Simples, vou executar um backup do controlfile via RMAN com validate. Se este falhar, vai me mostrar se há corrupção.

RMAN> BACKUP VALIDATE CURRENT CONTROLFILE;

Starting backup at 10-SEP-25
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=9999 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
Control File OK     0              608
Finished backup at 10-SEP-25

Show de bola! Controlfile status ok! Zero blocos em situação de falha. Não corrompido. Validado.

Momento de alívio, afinal o controlfile está ok, mas também um momento onde tenho ainda mais dúvidas. Porque meu database não o está encontrando?

As vezes é preciso dar um passo para trás, para podermos dar dois passos a frente. Voltemos ao alertlog, para analisar com mais cuidado.

Errors in file /u01/app/oracle/diag/rdbms/DB_1/db_1/trace/db_1_asmb_22236.trc:
ORA-15055: unable to connect to ASM instance
ORA-27140: attach to post/wait facility failed
ORA-27300: OS system dependent operation:invalid_egid failed with status: 1
ORA-27301: OS failure message: Operation not permitted
ORA-27302: failure occurred at: skgpwinit6
ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1002 (dba)
...
ALTER DATABASE MOUNT /* db agent *//* {0:0:2} */
Starting background process ASMB
Wed Sep 10 10:22:54 2025
ASMB started with pid=23, OS id=22254
ORA-00210: cannot open the specified control file
ORA-00202: control file: '+DATAC1/db_1/controlfile/current.256.9999999'
ORA-17503: ksfdopn:2 Failed to open file +DATAC1/db_1/controlfile/current.256.99999999
ORA-15001: diskgroup "DATAC1" does not exist or is not mounted
ORA-15055: unable to connect to ASM instance
ORA-27140: attach to post/wait facility failed
ORA-27300: OS system dependent operation:invalid_egid failed with status: 1
ORA-27301: OS failure message: Operation not permitted
ORA-27302: failure occurred at: skgpwinit6
ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1002 (dba)

Algo nessa análise mais profunda me chamou atenção, mas primeiro, chequemos o arquivo de trace que foi gerado para o background process ASMB.

[oracle@copia1 ~]$ cat /u01/app/oracle/diag/rdbms/DB_1/db_1/trace/db_1_asmb_22236.trc
cat: /u01/app/oracle/diag/rdbms/DB_1/db_1/trace/db_1_asmb_22236.trc: No such file or directory

Ora, mas que estranho! O arquivo foi gerado agora há pouco, como ele não está lá? Deixe-me checar o diretório.

[oracle@copia1 trace]$ ls -ltrh | grep 22236
-rw-r----- 1 oracle dba        62 Sep 10 10:22 db_1_asmb_22236.trm
-rw-r----- 1 oracle dba      1.3K Sep 10 10:22 db_1_asmb_22236.trc

O arquivo está lá, mas algo me chamou atenção quando dei um “ls” completo no diretório

-rw-r----- 1 oracle oinstall 5.2K Sep  9 06:00 db_1_m001_16950.trc
-rw-r----- 1 oracle oinstall 2.2K Sep  9 08:05 db_1_ora_12302.trm
-rw-r----- 1 oracle oinstall 6.1K Sep  9 08:05 db_1_ora_12302.trc
-rw-r----- 1 oracle oinstall 1.4M Sep  9 13:30 db_1_mmon_740.trm
-rw-r----- 1 oracle oinstall  14M Sep  9 13:30 db_1_mmon_740.trc
-rw-r----- 1 oracle dba        84 Sep  9 17:15 db_1_ora_13199.trm
-rw-r----- 1 oracle dba      1.4K Sep  9 17:15 db_1_ora_13199.trc
-rw-r----- 1 oracle dba        89 Sep  9 17:15 db_1_vktm_13227.trm
-rw-r----- 1 oracle dba      1.3K Sep  9 17:15 db_1_vktm_13227.trc
-rw-r----- 1 oracle dba        62 Sep  9 17:15 db_1_asmb_13257.trm

Depois do horário do outage, os grupos dos arquivos no diretório de trace mudaram de “oinstall” para o grupo “dba”. Isso faz algum sentido com uma informação que encontrei no alert log que já havia chamado minha atenção.

ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1002 (dba)

Mas ora, os grupos dos arquivos mudaram, e o alert me diz que o processo de start do banco está neste momento com um group id diferente do que era esperado.

Checando o arquivo /etc/groups, o grupo “oinstall” está lá corretamente, então o que pode estar acontecendo? Vou checar o user oracle.

[oracle@copia1 trace]$ id oracle
uid=1001(oracle) gid=1001(oinstall) groups=1001(oinstall), 1002(dba)

O grupo padrão também está certo para o usuário. Porque cargas d´água ele está iniciando os processos com o grupo errado? Bom, se os arquivos do trace file estão com o grupo diferente, vamos checar os binários do Oracle, tanto para o DB quanto para o GRID, so pra ver se tá tudo certo.

[oracle@copia1 trace]$ ls -l $ORACLE_HOME/bin/oracle
-rwxr-s--x 1 oracle dba 227070714 Dec 10  2015 /u01/app/oracle/product/11.2.0/db_1/bin/oracle

Pro Oracle, tudo certo. Afinal, nos binários devemos ter esse configuração de permissão com o bit “s” para o setgid do grupo correto. Mas o grupo deveria ser o oinstall, e não o dba. 

chown oracle:oinstall $ORACLE_HOME/bin/oracle
chmod 6751 $ORACLE_HOME/bin/oracle

[oracle@copia1 trace]$ ls -l $ORACLE_HOME/bin/oracle
-rwxr-s--x 1 oracle oinstall 227070714 Dec 10  2015 /u01/app/oracle/product/11.2.0/db_1/bin/oracle

Então tudo perfeito. Vejamos o grid.

[oracle@copia1trace]$ ls -l $ORACLE_HOME/bin/oracle
-rwxrwxrwx 1 oracle oinstall 210047019 Dec 10  2015 /u01/app/grid/product/11.2.0/grid_1/bin/oracle

OOOOppppaaaaaaa!!! Isso aqui também não deveria estar assim. Isso automaticamente me remeteu a seguinte frase que escutei do cliente: “Nós já fizemos de tudo para tentar resolver e não conseguimos!”

Alguém deve ter achado estranho os bits de permissão com “s”, e meteu um 777 ali. Também deve ter achado estranho os binários do Oracle não serem do grupo dba, sei lá. Eu perguntei se alguém havia feito isso, e obviamente como fariam meus filhos se tivessem feito uma caquinha, me disseram que não, que ninguém no ambiente lá fez isso.

Bom, não adianta chorar o leite derramado. Vamos ver se a alteração das permissões para o que deveria estar correto ajuda.

chown oracle:oinstall $GRID_HOME/bin/oracle
chmod 6751 $GRID_HOME/bin/oracle

[oracle@rworacstrm01 trace]$ ls -l $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle oinstall 210047019 Dec 10  2015 /u01/app/grid/product/11.2.0/grid_1/bin/oracle

Prontinho! Permissões alteradas com sucesso. Agora vou fazer um shutdown limpo de tudo e vejamos o que acontece ao tentar subir.

[oracle@copia1 trace]$ crsctl stop has
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'copia1'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'copia1'
CRS-2673: Attempting to stop 'ora.DATAC1.dg' on 'copia1'
CRS-2677: Stop of 'ora.DATAC1.dg' on 'copia1' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'copia1'
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'copia1' succeeded
CRS-2677: Stop of 'ora.asm' on 'copia1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'copia1'
CRS-2677: Stop of 'ora.cssd' on 'copia1' succeeded
CRS-2673: Attempting to stop 'ora.evmd' on 'copia1'
CRS-2677: Stop of 'ora.evmd' on 'copia1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'copia1' has completed
CRS-4133: Oracle High Availability Services has been stopped.

[oracle@copia1 trace]$ crsctl start has
CRS-4123: Oracle High Availability Services has been started.

[oracle@copia1 trace]$ crsctl status resource -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATAC1.dg
               ONLINE  ONLINE       copia1
ora.LISTENER.lsnr
               ONLINE  ONLINE       copia1
ora.asm
               ONLINE  ONLINE       copia1             Started
ora.ons
               OFFLINE OFFLINE      copia1
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
      1        ONLINE  ONLINE       copia1
ora.diskmon
      1        OFFLINE OFFLINE
ora.evmd
      1        ONLINE  ONLINE       copia1
ora.search.db
      1        ONLINE  ONLINE       copia1             Open

E olha só quem conseguiu ler o controlfile e abrir banco corretamente? Que alegria!

Depois dessa, é quase certeza que os amiguinhos meteram a mão onde não deveriam, e é aí que entra o DBA pra dar aquela força, corrigir o que precisa e trazer de volta a paz e quietude ao universo.

Em resumo, as permissões de grupo não estavam deixando o banco encontrar o controlfile dentro do ASM, após essa correção, tudo de volta ao normal e funcionando!!!

Como sempre, Fiquem a vontade para fazer quaisquer pontuações caso já tenham vivenciado algo do tipo.

Essa é a dica 0800 pra vocês desta vez.

“Saber das coisas vale ouro. Compartilhar esse conhecimento não tem preço.”

Publicado por jvaldezio

Published

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *