As operações de aplicação de patch podem falhar por diversos motivos. Geralmente, uma operação falha porque um nó de banco de dados está inativo, não há espaço suficiente no sistema de arquivos ou a máquina virtual não pode acessar o armazenamento de objetos.

• Determinando o Problema
  Na Console, você pode identificar uma operação de patch com falha, exibindo o histórico de patches de um sistema Oracle Exadata Database Service on Cloud@Customer ou de um banco de dados individual.
• Solução de Problemas e Diagnóstico
  Diagnostique os problemas mais comuns que podem ocorrer durante o processo de aplicação de patch de qualquer componente do Oracle Exadata Database Service on Cloud@Customer.

Se não foi possível resolver o problema usando as informações deste tópico, execute os procedimentos a seguir para coletar informações relevantes sobre o banco de dados e de diagnóstico. Depois de obter essas informações, entre em contato com o Suporte Técnico da Oracle.

• Coletando Logs do Conjunto de Ferramentas da Nuvem
  Use os arquivos de log relevantes que possam ajudar o Suporte Técnico da Oracle a investigar e resolver melhor um determinado problema.
• Coletando Diagnósticos da Oracle
  

Descrição: Esse é um problema intermitente. Durante a atualização do sistema operacional da máquina virtual com o Grid Infrastructure 19c e os bancos de dados em execução, dbnodeupdate.sh aguarda que RHPhelper drene as conexões, que não terão andamento por causa de um bug conhecido "DBNODEUPDATE.SH HANGS IN RHPHELPER TO DRAIN SESSIONS AND SHUTDOWN INSTANCE".

/var/log/cellos/dbnodeupdate.trc mostrará isso como última linha:

(ACTION:) Executing RHPhelper to drain sessions and shutdown instances. 
(trace:/u01/app/grid/crsdata/scaqak04dv0201/rhp//executeRHPDrain.150721125206.trc)

[FATAL] [INS-32156] Installer has detected that there are non-readable files in oracle home.
CAUSE: Following files are non-readable, due to insufficient permission oracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trc
ACTION: Ensure the above files are readable by grid.

Causa: O instalador detectou um arquivo de rastreamento ilegível, oracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trc criado pelo Autonomous Health Framework (AHF) no Oracle home que causa a falha na adição de uma VM no cluster.

O AHF foi executado como root criou um arquivo trc com propriedade root, que o usuário grid não pode ler.

chown grid:oinstall /u01/app/19.0.0.0/grid/srvm/admin/logging.properties

chown -R grid:oinstall /u01/app/19.0.0.0/grid/oracle.ahf*

chown -R grid:oinstall /u01/app/grid/oracle.ahf*

Descrição: A adição de uma VM a um cluster de VMs é concluída com sucesso; no entanto, para bancos de dados ativados pelo Data Guard, a nova VM não é adicionada à lista de nós no arquivo /var/opt/oracle/creg/<db>.ini.

Causa: Os bancos de dados ativados pelo Data Guard não serão estendidos para a VM recém-adicionada. Portanto, o arquivo <db>.ini também não será atualizado porque a instância do banco de dados não está configurada na nova VM.

Ação: Para adicionar uma instância aos bancos de dados principal e stand-by e às novas VMs (não relacionadas ao Data Guard) e para remover uma instância de um ambiente do Data Guard, consulte a Nota 2811352.1 do My Oracle Support.

** CPU Scale Update **An error occurred during module execution. Please refer to the log file for more information

Causa: Após o provisionamento de um cluster de VMs, o arquivo /var/opt/oracle/cprops/cprops.ini, que é gerado automaticamente pelo banco de dados como serviço (DBaaS) não é atualizado com os parâmetros common_dcs_agent_bindHost e common_dcs_agent_port e isso faz com que o dimensionamento off-line de CPU falhe.

common_dcs_agent_bindHost=<IP_Address>
common_dcs_agent_port=7070

netstat -tunlp | grep 7070

netstat -tunlp | grep 7070
tcp 0 0 <IP address 1>:7070 0.0.0.0:* LISTEN 42092/java
tcp 0 0 <IP address 2>:7070 0.0.0.0:* LISTEN 42092/java

Você pode especificar um dos dois endereços IP, <IP address 1> ou <IP address 2>, para o parâmetro common_dcs_agent_bindHost.

Descrição: Após a execução do switchover, o novo banco de dados stand-by (antigo principal) permanece encerrado e falha ao ser reiniciado.

Ação: Depois de executar o switchover, faça o seguinte:

1. Reinicie o banco de dados stand-by usando o comando srvctl start database -db <standby dbname>.
2. Recarregue o listener como usuário grid em todos os nós de cluster principal e stand-by.
   • Para recarregar o listener usando alta disponibilidade, faça download do patch 25075940 e aplique-o ao Grid home e, em seguida, execute lsnrctl reload -with_ha.
   • Para recarregar o listener, execute lsrnctl reload.

Após recarregar o listener, verifique se os serviços <dbname>_DGMGRL foram carregados no listener usando o comando lsnrctl status.

Descrição: Se a porta do listener SCAN para a rede do cliente e a rede de recuperação de desastres (rede de DR) forem diferentes, a configuração do Data Guard (DG) falhará durante a fase de verificação da associação de criação do data guard.

Ação: Use as mesmas portas de listener SCAN (ou porta padrão) em todas as redes. Para corrigir a porta do listener após a configuração do cluster, execute o comando GI home/bin/srvctl modify listener -listener listener_name -endpoints endpoints. Para obter mais informações, consulte srvctl modify listener no Oracle Real Application Clusters Administration and Deployment Guide.

[FATAL] [DBAAS-60022] Command '/u02/app/oracle/product/23.0.0.0/dbhome_3/bin/srvctl 'start' 'service' '-db' 'db23ano' '-service' 'db23ano_PDBJULY242.paas.oracle.com'' has failed on nodes [localnode].

Ação: Se a versão do Grid Infrastructure for 23.4.0.24.05, faça upgrade para a versão 23.5.0.24.07 para resolver esse problema.

Descrição: A criação do PDB pode falhar para o subconjunto de PDBs quando vários PDBs estão sendo criados em paralelo.

ORA-03113: end-of-file on communication channel

Ação: Repita a criação do PDB com falha.