I backup del database possono non riuscire durante la fase di configurazione RMAN o durante un job di backup RMAN in esecuzione. I task di configurazione RMAN includono la convalida della connettività di destinazione del backup, l'installazione del modulo di backup e le modifiche alla configurazione RMAN. I file di log esaminati dipendono dalla fase in cui si verifica l'errore.

1. Accedere all'host come utente oracle.
2. Controllare il file di log applicabile:
   • Per identificare l'ID job di un backup automatico, utilizzare il comando dbaascli database backup --dbname <dbname> --showHistory. Viene visualizzata la cronologia di tutti i job di backup, inclusi i relativi ID job corrispondenti.
   • I log dei job sono disponibili in /var/opt/oracle/log/dtrs/jobs/, denominati utilizzando il formato <job_id>.log. Se un job non riesce, nella stessa posizione viene generato anche un log di debug corrispondente <job_id>.debug.
   • È possibile trovare i log di esecuzione dei comandi RMAN corrispondenti per le operazioni di backup, recupero e configurazione nella directory /var/opt/oracle/log/<dbname>/dtrs/rman/bkup.

1. Da un prompt dei comandi, controllare lo stato dell'agente:

   systemctl status dbcsagent.service

2. Se l'agente si trova nello stato stop/waiting, provare a riavviare l'agente:

   systemctl start dbcsagent.service

3. Controllare di nuovo lo stato dell'agente per verificare che abbia lo stato stop/running:

   systemctl status dbcsagent.service

1. Creare un utente Swift nella tenancy. Vedere Utilizzo dei token di autenticazione.
2. Con l'utente creato nel passo precedente, utilizzare il comando seguente per verificare che l'host possa accedere all'area di memorizzazione degli oggetti.

   curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   Consulta le domande frequenti sullo storage degli oggetti per conoscere l'area corretta da utilizzare. Per informazioni sullo spazio di nomi dello storage degli oggetti, vedere Informazioni sugli spazi di nomi dello storage degli oggetti.
3. Se non è possibile connettersi all'area di memorizzazione degli oggetti, fare riferimento all'argomento Prerequisiti per i backup in Exadata Cloud Service per informazioni sulla configurazione della connettività dell'area di memorizzazione degli oggetti.

Se un comando interattivo come oraenv o qualsiasi comando che potrebbe restituire un messaggio di errore o di avvertenza è stato aggiunto al file .bash_profile per l'utente Grid o oracle, le operazioni del servizio di database, ad esempio i backup automatici, possono essere interrotte e non possono essere completate. Controllare la presenza di questi comandi nel file .bash_profile e rimuoverli.

Le operazioni di backup richiedono spazio nella directory /u01 del file system host. Utilizzare il comando df -h sull'host per controllare lo spazio disponibile per i backup. Se lo spazio disponibile nel file system è insufficiente, è possibile rimuovere i vecchi file di log o di trace per liberare spazio.

Il sistema potrebbe non avere la versione richiesta del modulo di backup (opc_installer.jar). Per i dettagli su questo problema noto, vedere Impossibile utilizzare i backup gestiti nel sistema DB. Per risolvere il problema, puoi seguire la procedura descritta in quella sezione o semplicemente aggiornare il sistema DB e il database con la patch bundle più recente.

La personalizzazione del file del profilo del sito ( $ORACLE_HOME/sqlplus/admin/glogin.sql ) può causare il guasto dei backup gestiti in Oracle Cloud Infrastructure. In particolare, i comandi interattivi possono causare errori di backup. Oracle consiglia di non modificare questo file per i database ospitati in Oracle Cloud Infrastructure.

Il database deve essere attivo e in esecuzione (idealmente su tutti i nodi) mentre il backup è in corso.

Quando si esegue il provisioning di un nuovo database, la modalità di archiviazione è impostata su ARCHIVELOG per impostazione predefinita. Questa è la modalità di archiviazione necessaria per le operazioni di backup. Controllare l'impostazione della modalità di archiviazione per il database e modificarla in ARCHIVELOG, se applicabile.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Stuck Archiver

Fare riferimento a ORA-00257: Errore dell'archivio (ID documento 2014425.1) per informazioni sulla risoluzione di un processo dell'archiviatore bloccato.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Open

Se lo stato dell'istanza non cambia dopo aver risolto il problema di base con il dispositivo o la risorsa piena o non disponibile, provare a riavviare il database utilizzando il comando srvctl per aggiornare lo stato del database nel clusterware.

La modifica di determinati parametri di configurazione RMAN può causare errori di backup in Oracle Cloud Infrastructure. Per controllare la configurazione RMAN, utilizzare il comando show all al prompt della riga di comando RMAN.

Per i dettagli su RMAN, vedere la lista di parametri riportata di seguito. Le impostazioni di configurazione non devono essere modificate per i database in Oracle Cloud Infrastructure.

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 5 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'SBT_LIBRARY=/var/opt/oracle/dbaas_acfs/<db_name>/opc/libopc.so, ENV=(OPC_PFILE=/var/opt/oracle/dbaas_acfs/<db_name>/opc/opc<db_name>.ora)';

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE ENCRYPTION FOR DATABASE ON;

I backup RMAN non riescono quando un file wallet dell'area di memorizzazione degli oggetti viene perso. Il file wallet è necessario per abilitare la connettività all'area di memorizzazione degli oggetti.

I backup del database non riescono se il wallet TDE non si trova nello stato corretto. Questo problema può essere causato dagli scenari riportati di seguito.

Se il database è stato avviato utilizzando SQL*Plus e la variabile di ambiente ORACLE_UNQNAME non è stata impostata, il wallet non viene aperto correttamente.

srvctl start database -d <db_unique_name>

In un ambiente multi-tenant per le versioni di Oracle Database che supportano il keystore a livello di PDB, ogni PDB dispone della propria chiave di cifratura master. Per i database Oracle 18c, questa chiave di cifratura viene memorizzata in un singolo keystore utilizzato da tutti i contenitori. Oracle Database 19c non supporta un keystore a livello di PDB. Dopo aver creato o collegato un nuovo PDB, è necessario creare e attivare una chiave di cifratura master. In caso contrario, la colonna STATUS nella vista v$encryption_wallet mostra il valore OPEN_NO_MASTER_KEY.

Per verificare lo stato della chiave di cifratura master e creare una chiave master, effettuare le operazioni riportate di seguito.

1. Rivedere la colonna STATUS nella vista v$encryption_wallet, come mostrato nell'esempio riportato di seguito.

   
   SQL> alter session set container=pdb2;
   Session altered.
   
   SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;
   
   WRL_TYPE   WRL_PARAMETER                                   STATUS             WALLET_TYPE
   ---------- ----------------------------------------------- ------------------ -----------
   FILE       /var/opt/oracle/dbaas_acfs/testdb30/tde_wallet/ OPEN_NO_MASTER_KEY AUTOLOGIN

2. Verificare che il PDB sia in modalità di apertura READ WRITE e che non sia limitato, come mostrato nell'esempio riportato di seguito.

   
   SQL> show pdbs
   
   CON_ID CON_NAME     OPEN MODE              RESTRICTED
   ------ ------------ ---------------------- ---------------
   2      PDB$SEED     READ ONLY              NO
   3      PDB1         READ WRITE             NO
   4      PDB2         READ WRITE             NO

   Impossibile aprire il PDB in modalità limitata (la colonna RESTRICTED deve mostrare NO). Se il PDB è attualmente in modalità limitata, rivedere le informazioni nella vista PDB_PLUG_IN_VIOLATIONS e risolvere il problema prima di continuare. Per ulteriori informazioni sulla vista PDB_PLUG_IN_VIOLATIONS e sullo stato limitato, consultare il manuale Oracle Multitenant Administrator's Guide su pluggable database per la versione di Oracle Database in uso.

3. Creare e attivare una chiave di cifratura master per il PDB:

   • Impostare il contenitore sul PDB:

     ALTER SESSION SET CONTAINER = <pdb>;

   • Creare e attivare una chiave di cifratura master nel PDB eseguendo il comando seguente:

     ADMINISTER KEY MANAGEMENT SET KEY USING TAG '<tag>' 
     FORCE KEYSTORE IDENTIFIED BY <keystore-password> WITH BACKUP USING '<backup_identifier>';

   Tenere presente quanto riportato di seguito.

   • La clausola USING TAG è facoltativa e può essere utilizzata per associare una tag alla nuova chiave di cifratura principale.

   • La clausola WITH BACKUP è facoltativa e può essere utilizzata per creare un backup del keystore prima di creare la nuova chiave di cifratura master.

   È anche possibile utilizzare i comandi dbaascli dbaascli tde status e dbaascli tde rotate masterkey per individuare e gestire le chiavi.

4. Verificare che lo stato del wallet sia stato modificato da OPEN_NO_MASTER_KEY in OPEN eseguendo una query sulla vista v$encryption_wallet come mostrato nel passo 1.

I parametri di configurazione correlati al wallet TDE possono causare l'errore dei backup.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/ewallet.p12
total 76
-rw------ 1 oracle oinstall 5467 Oct 1 20:17 ewallet.p12

Il file wallet TDE deve disporre delle autorizzazioni file con il valore ottale "600" (-rw-------) e il proprietario di questo file deve far parte del gruppo di sistemi operativi oinstall.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/cwallet.sso
total 76
-rw------ 1 oracle oinstall 5512 Oct 1 20:18 cwallet.sso

Il file wallet di login automatico deve disporre delle autorizzazioni file con il valore ottale "600" (-rw-------) e il proprietario di questo file deve far parte del gruppo di sistemi operativi oinstall.

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>

Per possibili cause e risoluzioni dei problemi del wallet TDE, vedere Errori di wallet e backup TDE.

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)

Per la causa e la risoluzione, esaminare gli errori in Messaggi di errore del database.

Log DBAASCLI