Risoluzione dei problemi relativi a Oracle Exadata Database Service su sistemi di infrastruttura Exascale

In ogni nodo di calcolo associato alla configurazione Data Guard, raccogliere i file di log relativi al problema riscontrato.

• I file di log dell'area intermedia di abilitazione (ad esempio quelli che documentano l'operazione Crea database in standby) e i log per il sistema primario o in standby corrispondente.
• File di log ID job di abilitazione. Esempio: 23.
• Posizioni dei file di log di abilitazione per fase di abilitazione e sistema Exadata (primario o in standby).
• File di log dei nomi del database (db_name o db_unique_name, a seconda del percorso del file).

Il programma di distribuzione Data Guard (DGdeployer) è il processo che esegue la configurazione. Quando si configura il database primario, viene creato il file /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log.

Questo log deve contenere la causa principale di un errore di configurazione del database primario.

• Il log principale della utility della riga di comando dbaasapi è: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Cercare le voci che contengono dg_api.
• Un log in standby della utility della riga di comando dbaasapi è: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. In questo log cercare le voci che contengono dg_api.
• L'altro log in standby è: /var/opt/oracle/log/<dbname>/dgcc/dgcc.log. Questo log è il log di configurazione di Data Guard.

• OCE (Oracle Cloud Deployment Engine) crea il file /var/opt/oracle/log/<dbname>/ocde/ocde.log. Questo log deve contenere la causa di un errore nella creazione del database di standby.
• L'utility della riga di comando dbaasapi crea il file var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Cercare le voci che contengono dg_api.
• Il file di log della configurazione Data Guard è /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

• DGdeployer è il processo che esegue la configurazione. Viene creato il file /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log seguente. Questo log deve contenere la causa principale di un errore nella configurazione del database in standby.
• L'utility della riga di comando dbaasapi crea il file /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Cercare le voci che contengono dg_api.
• Il log di configurazione Data Guard è /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

DGdeployer è il processo che esegue la configurazione. Durante la configurazione di Data Guard, crea il file /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Questo log deve contenere la causa principale di un errore di configurazione del database primario.

In ogni nodo dei siti primario e in standby, raccogliere i file di log per il nome del database correlato (db_name).

• Alert database: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/alert_<dbinstance>.log
• Log del broker Data Guard: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/drc<dbinstance>.log
• File di log degli strumenti cloud per Data Guard: /var/opt/oracle/log/<dbname>/odg/odg.log

La password immessa per l'abilitazione di Data Guard non corrisponde alla password amministratore primario per l'utente SYS. Questo errore si verifica durante la fase Convalida principale dell'abilitazione.

Impossibile eseguire il database. Questo errore si verifica durante la fase Convalida principale dell'abilitazione. Controllare con srvctl e sql sull'host per verificare che il database sia attivo e in esecuzione su tutti i nodi.

Impossibile configurare il database primario. Comandi Data Guard non validi o la riconfigurazione del listener non riuscita può causare questo errore.

Impossibile creare il wallet TDE. Impossibile preparare i file del keystore (wallet) TDE (Transparent Database Encryption) Oracle per il trasporto nel sito in standby. Questo errore si verifica durante la fase di abilitazione della creazione del wallet TDE. Uno dei seguenti elementi può causare errori in questa fase:

• Impossibile accedere ai file del wallet TDE
• I comandi di abilitazione non sono stati in grado di creare un archivio contenente i file wallet

Procedura di risoluzione dei problemi:

1. Assicurarsi che il cluster sia accessibile. Per controllare lo stato di un cluster, eseguire il comando riportato di seguito.

   crsctl check cluster -all

2. Se il cluster è inattivo, eseguire il comando seguente per riavviarlo:

   crsctl start crs -wait

3. Se questo errore si verifica quando il cluster è accessibile, controllare i log per creare il wallet TDE (fase di abilitazione) per determinare la causa e la risoluzione dell'errore.

È probabile che l'archivio contenente il wallet TDE non sia stato trasmesso al sito in standby. Ripetere di solito risolve il problema.

• I siti primario e in standby potrebbero non essere in grado di comunicare tra loro per configurare il database in standby. Questi errori si verificano durante la fase di configurazione del database in standby dell'abilitazione. In questa fase, le configurazioni vengono eseguite sul database di standby, incluso il duplicato rman del database primario. Per risolvere questo problema:
  1. Verificare lo stato di connettività per i siti primario e in standby.
  2. Accertarsi che l'host possa comunicare dalla porta 1521 a tutte le porte. Controllare l'impostazione della rete, inclusi i gruppi di sicurezza di rete (NSG), gli elenchi di sicurezza di rete e l'impostazione del peering VCN remoto (se applicabile). Il modo migliore per eseguire il test della comunicazione tra l'host e altri nodi è accedere ai database utilizzando SQL*PLUS dal database primario al database in standby e dal database in standby al database primario.
• È possibile che i VIP o i listener SCAN non siano in esecuzione. Utilizzare il test precedente per identificare il problema.

Cause possibili:

• È possibile che i VIP o i listener SCAN non siano in esecuzione. È possibile confermare questo problema utilizzando i comandi riportati di seguito su qualsiasi nodo cluster.

  • [grid@exa1-****** ~]$ srvctl status
                scan

  • [grid@exa1-****** ~]$ srvctl status
                  scan_listener

• I database potrebbero non essere raggiungibili. È possibile confermare questo problema tentando di connettersi utilizzando un alias Oracle Net esistente.

Procedura di risoluzione dei problemi:

1. In qualità di utente del sistema operativo oracle, verificare l'esistenza di un alias Oracle Net per il container database (CDB). Cercare un alias in $ORACLE_HOME/network/admin/<dbname>/tnsnames.ora.

   L'esempio seguente mostra una voce per un container database denominato db12c:

   cat $ORACLE_HOME/network/admin/db12c/tnsnames.ora 
   DB12C = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = exa1-*****-scan.********.******.******.com)(PORT = 1521)) 
   (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db12c.********.******.******.com) 
   (FAILOVER_MODE = (TYPE = select) (METHOD = basic))))

2. Verificare che sia possibile utilizzare l'alias per connettersi al database. Ad esempio, come sysdba, immettere il seguente comando:

   sqlplus sys@db12c

Una possibile causa di questo errore è che le password utente di sistema o di sistema di Oracle Database per il database e il wallet TDE potrebbero non essere uguali. Per confrontare le password:

1. Connettersi al database come utente SYS e controllare lo stato TDE in

   V$ENCRYPTION_WALLET

   .
2. Connettersi al database come utente di sistema e controllare lo stato TDE in

   V$ENCRYPTION_WALLET

   .
3. Aggiornare le password applicabili in modo che corrispondano. Accedere all'host del sistema come opc ed eseguire i comandi indicati di seguito.
   1. Per modificare la password SYS:

      sudo dbaascli database changepassword --dbname <database_name>

   2. Per modificare la password del wallet TDE:

      sudo dbaascli tde changepassword --dbname <database_name>

Quando vengono eseguiti i comandi di switchover, failover e reinstate, possono verificarsi più messaggi di errore. Per questi messaggi di errore, fare riferimento alla documentazione di Oracle Database.

Nota

Oracle consiglia di utilizzare l'interfaccia della riga di comando del broker Data Guard (dgmgrl) per convalidare le configurazioni.

1. In qualità di utente Oracle, connettersi al database primario o in standby con dgmgrl e verificare la configurazione e il database:

   dgmgrl sys/<pwd>@<database>
   DGMGRL> VALIDATE CONFIGURATION VERBOSE
   DGMGRL> VALIDATE DATABASE VERBOSE <PRIMARY>
   DGMGRL> VALIDATE DATABASE VERBOSE <STANDBY>

2. Consultare la documentazione di Oracle Database per verificare la presenza del rispettivo messaggio di errore. Ad esempio:
   • ORA-16766: l'applicazione dei redo è arrestata.
   • ORA-16853: il ritardo di applicazione ha superato la soglia.
   • ORA-16664: impossibile ricevere il risultato da un membro (sotto il database di standby).
   • ORA-12541: TNS: nessun listener (sotto il database primario)

Log DBAASCLI