Olá pessoal,
Espero que estejam bem!
Estou trabalhando para um cliente que possui alguns bancos de dados Oracle para aplicações SAP.
Esses BD’s não estão usando RAC, sim, eu sei! 🙂
A SAP não suporta RAC na sua plenitude, e você não pode usar serviços com load balance, por exemplo. Se você quiser usar o RAC para o SAP, o serviço de BD precisa se conectar somente em 1 nó, os outros nós só podem ser usados para failover, mas o serviço só poderá ficar ativo em 1 nó por vez.
OK, como eu ia dizendo, esse cliente usa Veritas Cluster como solução de “alta disponibilidade”. Eles têm clusters de 2 nós onde o BD é armazenado num dNFS (NetApp), e os mount points NFS são montados em todos os nós do cluster Veritas. O Veritas vai então mover o listener e o BD para o nó sobrevivente em caso de falhas.
Na última noite eles tiveram alguns problemas com o primeiro nó e o Veritas tentou subir os serviços no segundo nó, mas a tentativa não foi bem sucedida.
Vamos tentar então subir os serviços manualmente.
Tentei realizar o startup (primeiro com a opção MOUNT) manualmente:
DBL01:db01 53> sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 17 05:12:05 2023 Version 19.17.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to an idle instance. SQL> SQL> SQL> startup mount ORACLE instance started. Total System Global Area 1.9931E+10 bytes Fixed Size 8906744 bytes Variable Size 7381975040 bytes Database Buffers 1.2482E+10 bytes Redo Buffers 58200064 bytes ORA-00205: error in identifying control file, check alert log for more info
Como vocês podem ver, está reclamando sobre o control file. Essa mensagem pode fazer você se desesperar! Afinal, aparentemente o control file não está acessível.
Vamos checar então o alert.log (o output foi truncado para facilitar a leitura):
2023-08-17T05:12:15.105485+00:00 ALTER DATABASE MOUNT 2023-08-17T05:12:15.205125+00:00 ORA-00210: cannot open the specified control file ORA-00202: control file: '/oracle/DBL01/origlogB/ctrl/control03.ctl' ORA-27086: unable to lock file - already in use Linux-x86_64 Error: 11: Resource temporarily unavailable Additional information: 8 Additional information: 4294967294
OK, a principal mensagem é:
ORA-27086: unable to lock file – already in use
Algumas vezes, se o DB não é baixado de maneira limpa (o que chamamos de clean shutdown), um arquivo de “lock” pode permanecer no $ORACLE_HOME/dbs. Vamos checar:
DBL01:db01 54> ls -ltr total 12168 -rw-r----- 1 db01 dba 2048 Oct 20 2021 orapwDBL01 drwx------ 3 db01 dba 4096 Oct 20 2021 wallet -rw-r----- 1 db01 dba 6656 Aug 17 00:13 spfileDBL01.ora -rw-r----- 1 db01 dba 12288 Aug 17 04:28 dr2DBL01.dat -rw-r----- 1 db01 dba 12288 Aug 17 04:29 dr1DBL01.dat -rw-rw---- 1 db01 dba 24 Aug 17 05:12 lkDBL01
Como podemos ver, o arquivo lkDBL01 está lá. Vamos removê-lo:
DBL01:db01 55> rm lkDBL01
Mesmo após removê-lo, continuamos tendo a mensagem “ORA-27086: unable to lock file – already in use”.
O que mais podemos fazer?
Bem, do nosso lado (BD), nada mais!
Então, qual é a razão para esse erro?
Isso acontece porque como os arquivos de banco de dados estavam abertos no node 1, um lock foi adquirido para cada arquivo na camada de storage, e esses locks não foram liberados após o crash do primeiro nó. A única solução aqui é solicitar ao time de storage para liberar (realizar o que chamamos de break) os locks:
O time do cliente não sabia como fazer isso, por sorte eu já havia passado por isso há uns bons anos e me lembrei e consegui ajudá-los!
Primeiro, da “console/prompt” de gerenciamento do NetApp, vamos executar o comando abaixo (output foi truncado para facilitar a leitura):
CA-NAS-CL01::*> vserver locks show -vserver PROD-SVM -volume *DBL01*
Notice: Using this command can impact system performance. It is recommended
that you specify both the vserver and the volume when issuing this command to
minimize the scope of the command's operation. To abort the command, press Ctrl-C.
Vserver: PROD-SVM
Volume Object Path LIF Protocol Lock Type Client
-------- ------------------------- ----------- --------- ----------- ----------
DBL01_db01_origlog_t110_vol /vol/DBL01_db01_origlog_t110_vol/DBL01_db01-origlogb-qt/ctrl/control01.ctl PROD-SVM-NFS_LIF3 nlm byte-range 10.222.133.141
Bytelock Offset(Length): 0 (18446744073709551615)
/vol/DBL01_db01_origlog_t110_vol/DBL01_db01-origloga-qt/ctrl/control02.ctl PROD-SVM-NFS_LIF3 nlm byte-range 10.222.133.141
DBL01_db01_sapdataa_t110_vol /vol/DBL01_db01_sapdataa_t110_vol/DBL01_db01-data1-qt/system01.dbf PROD-SVM-NFS_LIF4 nlm byte-range 10.222.133.141
Bytelock Offset(Length): 0 (18446744073709551615)
/vol/DBL01_db01_sapdataa_t110_vol/DBL01_db01-data3-qt/undotbs01.dbf PROD-SVM-NFS_LIF4 nlm byte-range 10.222.133.141
.
.
.
19 entries were displayed.
Como podemos ver, o comando “vserver locks show” vai mostrar as informações sobre os locks.
OK, agora estamos prontos para realizar a liberação (release/break) dos locks.
Atenção, tenha certeza que você não possui os arquivos abertos em nenhum outro servidor! Realizar o break dos locks para arquivos realmente abertos podem levar à corrupção dos mesmos!
CA-NAS-CL01::*> vserver locks break -vserver PROD-SVM -volume *DBL01* -path *
Notice: Using this command can impact system performance. It is recommended
that you specify both the vserver and the volume when issuing this command to
minimize the scope of the command's operation. To abort the command, press Ctrl-C.
Warning: Breaking file locks can cause applications to become unsynchronized and may lead to data corruption.
Do you want to continue? {y|n}: y
19 entries were acted on.
Ótimo, os locks foram quebrados.
Vamos checar novamente se temos locks:
CA-NAS-CL01::*> vserver locks show -vserver PROD-SVM -volume *DBL01* Notice: Using this command can impact system performance. It is recommended that you specify both the vserver and the volume when issuing this command to minimize the scope of the command's operation. To abort the command, press Ctrl-C. There are no entries matching your query. CA-NAS-CL01::*>
Perfeito! Nós não temos mais locks!
Vamos tentar agora montar (e abrir) o BD novamente:
DBL01:db01 59> sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 17 05:26:13 2023 Version 19.17.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to an idle instance. SQL> startup mount ORACLE instance started. Total System Global Area 1.9931E+10 bytes Fixed Size 8906744 bytes Variable Size 7381975040 bytes Database Buffers 1.2482E+10 bytes Redo Buffers 58200064 bytes Database mounted. SQL> alter database open; Database altered.
Ótimo! É isso!
Espero que seja útil!
Um abraço,
Vinicius
Notas de referência:
Essa nota do My Oracle Support tem alguns comandos velhos de NetApp que não funcionam nos mais recentes (?) ambientes (o comando mudou há alguns bons anos!).
