Le operazioni di applicazione delle patch possono non riuscire per vari motivi. In genere, un'operazione non riesce perché un nodo di database è inattivo, lo spazio disponibile nel file system è insufficiente oppure la virtual machine non è in grado di accedere all'area di memorizzazione degli oggetti.

• Determinazione del problema
  Nella console è possibile identificare un'operazione di applicazione delle patch non riuscita visualizzando la cronologia delle patch di un sistema Oracle Exadata Database Service on Cloud@Customer o di un singolo database.
• Risoluzione dei problemi e diagnosi
  Diagnosticare i problemi più comuni che possono verificarsi durante il processo di applicazione delle patch di qualsiasi componente di Oracle Exadata Database Service on Cloud@Customer.

Se non si è riusciti a risolvere il problema utilizzando le informazioni riportate in questo argomento, attenersi alle procedure riportate di seguito per raccogliere le informazioni relative al database e alla diagnostica. Dopo aver raccolto queste informazioni, contattare il Supporto Oracle.

• Raccolta dei log di Cloud Tooling
  Utilizzare i file di log pertinenti che potrebbero aiutare il Supporto Oracle a indagare e risolvere ulteriormente un determinato problema.
• Raccolta di Oracle Diagnostics
  

Descrizione: si tratta di un problema intermittente. Durante l'aggiornamento del sistema operativo della macchina virtuale con Grid Infrastructure 19c e i database IN esecuzione, dbnodeupdate.sh attende che RHPhelper scarichi le connessioni, che non progrediranno a causa di un bug noto "DBNODEUPDATE.SH HANGS IN RHPHELPER TO DRAIN SESSIONS AND SHUTDOWN INSTANCE".

/var/log/cellos/dbnodeupdate.trc mostrerà come ultima riga:

(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: l'Installer ha rilevato un file di trace non leggibile, oracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trc creato da Autonomous Health Framework (AHF) nella Oracle home che causa l'errore di aggiunta di una VM cluster.

AHF eseguito come root ha creato un file trc con proprietà root, che l'utente grid non è in grado di leggere.

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*

Descrizione: l'aggiunta di una VM a un cluster VM è stata completata. Tuttavia, per i database abilitati per Data Guard, la nuova VM non viene aggiunta alla lista di nodi nel file /var/opt/oracle/creg/<db>.ini.

Causa: i database abilitati per Data Guard non verranno estesi alla nuova VM aggiunta. Pertanto, anche il file <db>.ini non verrà aggiornato perché l'istanza di database non è configurata nella nuova VM.

Azione: per aggiungere un'istanza ai database primari e in standby e alle nuove VM (Non-Data Guard) e per rimuovere un'istanza da un ambiente Data Guard, vedere la nota di My Oracle Support 2811352.1.

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

Causa: dopo il provisioning di un cluster VM, il file /var/opt/oracle/cprops/cprops.ini generato automaticamente dal database as a service (DBaaS) non viene aggiornato con i parametri common_dcs_agent_bindHost e common_dcs_agent_port e pertanto la scalabilità non in linea della CPU non riesce.

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

È possibile specificare uno dei due indirizzi IP, <IP address 1> o <IP address 2>, per il parametro common_dcs_agent_bindHost.

Descrizione: dopo l'esecuzione dello switchover, il nuovo database di standby (vecchio database primario) rimane chiuso e non viene riavviato.

Azione: dopo aver eseguito lo switchover, effettuare le operazioni riportate di seguito.

1. Riavviare il database di standby utilizzando il comando srvctl start database -db <standby dbname>.
2. Ricaricare il listener come utente grid su tutti i nodi del cluster primario e in standby.
   • Per ricaricare il listener utilizzando High Availability, scaricare e applicare la patch 25075940 alla home Grid, quindi eseguire lsnrctl reload -with_ha.
   • Per ricaricare il listener, eseguire lsrnctl reload.

Dopo aver ricaricato il listener, verificare che i servizi <dbname>_DGMGRL vengano caricati nel listener utilizzando il comando lsnrctl status.

Descrizione: se la porta del listener SCAN per la rete client e la rete di recupero da errori irreversibili (rete DR) sono diverse, la configurazione Data Guard (DG) non riesce durante la fase di verifica della creazione dell'associazione Data Guard.

Azione: utilizzare le stesse porte del listener SCAN (o porta predefinita) su tutte le reti. Per correggere la porta del listener dopo la configurazione del cluster, eseguire il comando GI home/bin/srvctl modify listener -listener listener_name -endpoints endpoints. Per ulteriori informazioni, vedere srvctl modify listener nel manuale 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].

Azione: se la versione di Grid Infrastructure è la 23.4.0.24.05, eseguire l'upgrade alla versione 23.5.0.24.07 per risolvere il problema.

Descrizione: la creazione del PDB potrebbe non riuscire per il subset di PDB quando vengono creati più PDB in parallelo.

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

Azione: riprovare la creazione del PDB non riuscita.