BUG 23300142 – Redo Transport Slave Process

A semana começou com o filesystem /u01 alarmando ocupação elevada. Iniciei então uma investigação para encontrar o que estava ocupando o disco.

My week started with a filesystem high occupation alarm. I then started looking for what was going on.

Utilizei o comando find abaixo para buscar por arquivos grandes:

I usually use the find command bellow to search for huge files:

find / -type f -size +800M -exec ls -lh {} \; | awk '{ print $NF ": " $5 }'

Bingo! encontrei o arquivo de trace do processo TT01 (Redo Transport Slave Process) consumindo 6Gb !

Yes ! found a trace file from process TT01 (Redo Transport Slave Process) consuming 6 Gb!

Olhando o conteúdo do arquivo, a mensagem:

Looking at the contents of the trace file the messages:

Error in determining current logfile for thread 1
ASYNC ignored current log: KCCLENAL clear thread open

era repetida continuamente.

was happening on an on.

Uma pesquisa rápida no MOS e confirmado mais um BUG para coleção: Bug 23300142 – TT background process trace file message: async ignored current log: kcclenal clear thread open (Doc ID 23300142.8)

A quick search on MOS and I have hit another BUG for my collection: Bug 23300142 – TT background process trace file message: async ignored current log: kcclenal clear thread open (Doc ID 23300142.8)

A correção está disponível nos patches:

Bug fix is included on patches:

12.2.0.1.170919 (Sep 2017) Database Release Update (DB RU)
12.1.0.2.180116 (Jan 2018) Database Proactive Bundle Patch
12.2.0.1.171017 (Oct 2017) Bundle Patch for Windows Platforms

 

Falha ao aplicar o OJVM 12.1.0.2.180116

Ao aplicar o  patch 27001733 (Oracle JavaVM Component 12.1.0.2.180116 Database PSU), ocorreu uma falha que não havia ocorrido ao aplicar o patch de outubro e tão pouco ocorreu ao aplicar o OJVM de JAN2018 da versão 12.2.

I got an error applying patch 27001733 (Oracle JavaVM Component 12.1.0.2.180116 Database PSU) which hasn’t happen on ojvm patch from oct/2017 neither on ojvm from jan/2018 on 12.2.

Você encontrará o log do opatch no diretório $ORACLE_HOME/cfgtoollogs/opatch.

You will find opatch logs at $ORACLE_HOME/cfgtoollogs/opatch.

O erro reportado no log foi:

The error reported on log was:

[Feb 8, 2018 2:56:00 PM] [WARNING] OUI-67200:Make failed to invoke "/usr/bin/make -f ins_rdbms.mk javavm_refresh patchset_opt_all ioracle ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/db_1"....'make: perl: Command not found
 make: *** [javavm_refresh] Error 127
 '
[Feb 8, 2018 2:56:00 PM] [INFO] Re-link fails on target "javavm_refresh patchset_opt_all ioracle".
[Feb 8, 2018 2:56:00 PM] [INFO] --------------------------------------------------------------------------------
 Failed to run make commands. Please contact Oracle Support.
[Feb 8, 2018 2:56:00 PM] [SEVERE] OUI-67115:OPatch failed to restore OH '/u01/app/oracle/product/12.1.0.2/db_1'. Consult OPatch document to restore the home manually before proceeding.
[Feb 8, 2018 2:56:00 PM] [WARNING] OUI-67124:
 NApply was not able to restore the home. Please invoke the following scripts:
 - restore.[sh,bat]
 - make.txt (Unix only)
 to restore the ORACLE_HOME. They are located under
 "/u01/app/oracle/product/12.1.0.2/db_1/.patch_storage/NApply/2018-02-08_14-53-50PM"
[Feb 8, 2018 2:56:00 PM] [SEVERE] OUI-67073:UtilSession failed: Re-link fails on target "javavm_refresh patchset_opt_all ioracle".

A correção é simples, basta setar as variávies conforme abaixo:

To fix this issue you have to set those two variables below:

export PATH=$ORACLE_HOME/perl/bin:$PATH
export PERL5LIB = $ORACLE_HOME/perl/lib

e rodar novamente o opatch que agora a atualização será bem sucedida 🙂

and then opatch will run successfully.

 

DBCA /LISTENER

Essa semana encontrei um erro durante a criação de um banco RAC no Oracle Database Appliance.

A mensagem de erro era:

“ERROR : /bin/su oracle -c “/opt/oracle/oak/onecmd/tmp/dbca-PRTCORP.sh” did not complete successfully. Exit code 1 #Step -1# “

e o log do DBCA mostrava a mensagem:

“Default Listener “LISTENER” is not configured in the Grid Infrastructure home.”

O erro na verdade foi meu 😦  .. já que eu alterei um pouco demais o ambiente.

Por que ? Configuração de algumas redes (VLANs) no ambiente.

Segundo o MOS 1198973.1, o DBCA procura pelo listener default LISTENER rodando na porta 1521 para completar a criação da base em ambientes com GridInfrastructure.

A correção foi simples: removi um listener e o criei novamente com o nome padrão LISTENER.

 

This week I got an error running DBCA to create a RAC DB on my Oracle Database Appliance.

The error message was:

“ERROR : /bin/su oracle -c “/opt/oracle/oak/onecmd/tmp/dbca-PRTCORP.sh” did not complete successfully. Exit code 1 #Step -1# “

and in DBCA log was reported:

“Default Listener “LISTENER” is not configured in the Grid Infrastructure home.”

It was actually my mistake 😦 .. because I end up changing the environment too much.

But why so many changes ? Well, I had to set up a few networks (VLANs) on this GI.

As stated by MOS 1198973.1, the dbca utility searches for a default listener named LISTENER and running on port 1521 in order to complete the database creation running on GridInfrastructure home.

To fix this issue I had to remove one listener and create a new one with the default listener name LISTENER.