Risoluzione degli errori di backup

I backup del database possono non riuscire per vari motivi. In genere, un backup non riesce poiché l'host del database non può accedere all'area di memorizzazione degli oggetti oppure si verificano problemi sull'host o con la configurazione del database.

Questo articolo include informazioni utili per determinare la causa dell'errore e risolvere il problema. Le informazioni sono organizzate in diverse sezioni, in base alla condizione di errore.

Se si conosce già la causa, è possibile passare all'argomento con la soluzione suggerita. In caso contrario, utilizzare l'argomento Identifica la causa dell'errore per iniziare.

In questo articolo vengono trattati i seguenti argomenti:

Suggerimento

È anche possibile creare connessioni alla console seriale per risolvere i problemi del sistema in modalità monoutente. Per informazioni sulla creazione di una connessione console seriale nella console OCI, vedere Gestire la connessione della console seriale al sistema DB.

Argomenti correlati

Identificare la causa dell'errore

Nella console OCI, un backup del database non riuscito visualizza uno stato Non riuscito o si blocca nello stato Backup in corso o Creazione. Se il messaggio di errore non contiene informazioni sufficienti per indirizzare l'utente a una soluzione, è possibile utilizzare l'interfaccia CLI del database e i file di log per raccogliere più dati. Quindi, fare riferimento alla sezione applicabile in questo argomento per una soluzione.

Vengono trattati i seguenti argomenti:

Identificare la causa principale dell'errore di backup

  1. Accedere all'host come utente root e passare a /opt/oracle/dcs/bin/.

  2. Determinare la sequenza delle operazioni eseguite sul database.

    dbcli list-jobs | grep -i <dbname>

    Prendere nota dell'ultimo ID job elencato con uno stato diverso da Operazione riuscita.

  3. Con l'ID job indicato dal passo precedente, utilizzare il comando seguente per controllare i dettagli di tale job:

    dbcli describe-job -i <job_ID> -j

    In genere, l'esecuzione di questo comando è sufficiente per rivelare la causa principale dell'errore.

  4. Per ulteriori informazioni, vedere il file /opt/oracle/dcs/log/dcs-agent.log.

    È possibile trovare l'ID job in questo file utilizzando l'indicatore orario restituito dal report job nel passo 2.

  5. Se i dettagli del problema indicano un problema RMAN, esaminare i log RMAN nella directory seguente.

    /opt/oracle/dcs/log/<hostname>/rman/bkup/<db_unique_name>/rman_backup/<yyyy-mm-dd>

Nota

Se l'errore del database si trova su un database RAC a 2 nodi, eseguire i passi 3 e 4 su entrambi i nodi.

Problemi relativi all'agente del servizio di database

Il tuo database OCI utilizza un framework agente per consentirti di gestire il tuo database attraverso la piattaforma cloud. A volte potrebbe essere necessario riavviare il programma dcsagent se il relativo stato è stop/waiting per risolvere un errore di backup.

Vengono trattati i seguenti argomenti:

Riavviare l'agente del servizio di database

Nota

Utilizzare initctl anziché systemctl quando si utilizza OL6.

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

    systemctl status initdcsagent

  2. Se lo stato dell'agente è stop/waiting, provare a riavviare l'agente: 

    systemctl start initdcsagent

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

    systemctl status initdcsagent

Problemi con Oracle Clusterware

Oracle Clusterware consente ai server di comunicare tra loro in modo da poter funzionare come unità collettiva. A volte potrebbe essere necessario riavviare il programma Clusterware per risolvere un errore di backup.

Una o più delle seguenti condizioni nell'host del database possono causare l'errore dei backup:

Riavviare Oracle Clusterware

  1. Dal prompt dei comandi, controllare lo stato di Oracle Clusterware:

    crsctl check crs
    crsctl stat res -t

  2. Se Oracle Clusterware non è in linea, provare a riavviare il programma:

    crsctl start crs

  3. Controllare lo stato di Oracle Clusterware per verificare che sia online:

    crsctl check crs

Problemi di connettività dell'area di memorizzazione degli oggetti

Il backup del database nello storage degli oggetti OCI richiede che l'host possa connettersi all'endpoint Swift applicabile. È possibile testare questa connettività utilizzando un utente Swift.

Vengono trattati i seguenti argomenti:

Assicurarsi che l'host del database possa connettersi all'area di memorizzazione degli oggetti

  1. Creare un utente Swift nella tenancy. Per ulteriori informazioni, vedere Utilizzo dei token di autenticazione in Gestione delle credenziali utente.

  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>
  3. Se non è possibile connettersi all'area di memorizzazione degli oggetti, vedere Backup di un database mediante la console per informazioni su come configurare la connettività dell'area di memorizzazione degli oggetti.

Problemi dell'host

Vengono trattati i seguenti argomenti:

Una o più delle seguenti condizioni nell'host del database possono causare l'errore dei backup:

Comandi interattivi nel profilo Oracle

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.

Il file system è completo

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.

Versione errata del modulo di backup di Oracle Database Cloud

Il sistema potrebbe non avere la versione richiesta del modulo di backup (opc_installer.jar). Per informazioni 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 l'aggiornamento del bundle più recente.

Modifiche al file del profilo del sito (glogin.sql)

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

Problemi relativi al database

Uno stato o una configurazione del database errata può causare backup non riusciti.

Vengono trattati i seguenti argomenti:

Database non in esecuzione durante il backup

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

Verificare che il database sia attivo e in esecuzione

Utilizzare il seguente comando per controllare lo stato del database e assicurarsi che vengano risolti eventuali problemi che potrebbero aver messo il database in uno stato non corretto:

srvctl status database -d <db_unique_name> -verbose

Il sistema restituisce un messaggio che include lo stato dell'istanza del database. Affinché il backup riesca, lo stato dell'istanza deve essere Aperto. Se il database non è in esecuzione, utilizzare il seguente comando per avviarlo: 

srvctl start database -d <db_unique_name> -o open

Se il database è installato ma non ha lo stato Apri, utilizzare i seguenti comandi per accedere al prompt dei comandi di SQL*Plus e impostare lo stato su Apri: 

sqlplus / as sysdba
alter database open;

Modalità di archiviazione impostata su NOARCHIVELOG

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.

Controllare e impostare la modalità di archiviazione

Aprire un prompt dei comandi SQL*Plus e immettere il comando riportato di seguito.

select log_mode from v$database;

Se è necessario impostare la modalità di archiviazione su ARCHIVELOG, avviare il database in stato Attiva (e non Apri) e utilizzare il seguente comando al prompt dei comandi di SQL*Plus: 

alter database archivelog;

Verificare che il parametro db_recovery_file_dest punti a +RECO e che il parametro log_archive_dest_1 sia impostato su USE_DB_RECOVERY_FILE_DEST.

Per i database RAC, quando si abilita la modalità log di archiviazione, è necessario che un'istanza abbia lo stato Mount. Per abilitare la modalità log di archiviazione per un database RAC, attenersi alla procedura riportata di seguito.

  1. chiudere tutte le istanze di database.

    srvctl stop database -d

  2. Avviare una delle istanze di database in stato di accesso.

    srvctl start instance -d <db_unique_name> -i <instance_name> -o mount

  3. Accedere al prompt dei comandi di SQL*Plus.

    sqlplus / as sysdba

  4. Abilitare la modalità di log dell'archivio e uscire.

    alter database archivelog;
    exit;

  5. Arresta il database.

    srvctl stop instance -d <db_unique_name> -i <instance_name>

  6. Riavviare tutte le istanze di database.

    srvctl start database -d <db_unqiue_name>

  7. Al prompt dei comandi di SQL*Plus, confermare che la modalità di archiviazione sia impostata su ARCHIVELOG. 

    select log_mode from v$database;

Errori di processo e backup dell'archiviatore di database bloccati

I backup possono non riuscire quando l'istanza di database ha un processo di archiviazione bloccato. Ad esempio, ciò può verificarsi quando l'area di recupero flash (FRA) è piena. È possibile verificare la presenza di questa condizione utilizzando il comando seguente.

srvctl status database -db <db_unique_name> -v

Se il comando restituisce il seguente output, è necessario risolvere il problema del processo di archiviazione bloccato prima che i backup possano avere esito positivo:

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.

Dopo aver risolto il processo bloccato, il comando deve restituire il seguente output:

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 una delle soluzioni seguenti:

  • Riavviare il database utilizzando il comando srvctl per aggiornare lo stato del database nel clusterware
  • Aggiornare il database ai livelli più recenti del set di patch

Errori tablespace temporanea

Se le statistiche delle tabelle fisse non sono aggiornate nel database, i backup possono non riuscire con errori che fanno riferimento alla tablespace temporanea presente nel file dcs-agent.log. Ad esempio: 

select status from v$rman_status where COMMAND_ID=<backup_id>

Output:

ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

Raccogliere le statistiche della tabella fissa come indicato di seguito per risolvere il problema.

conn / as sysdba
exec dbms_stats.gather_fixed_objects_stats();

Errori di configurazione e backup RMAN

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

Per i dettagli sulle impostazioni di configurazione di RMAN che non devono essere modificate per i database in OCI, vedere la lista di parametri riportata di seguito.

Impostazioni di configurazione RMAN da non modificare

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' MAXPIECESIZE 2 G FORMAT   '%d_%I_%U_%T_%t' PARMS  
    'SBT_LIBRARY=/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/libopc.so 
    ENV=(OPC_PFILE=/opt/oracle/dcs/commonstore/objectstore/opc_pfile/1578318329/opc_tiger_iad3c8.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;

Errori dei criteri di conservazione e di backup RMAN

La configurazione dei criteri di conservazione RMAN può essere l'origine degli errori di backup. L'uso della configurazione del criterio di conservazione REDUNDANCY invece del criterio RECOVERY WINDOW può causare errori di backup. Assicurarsi di utilizzare la configurazione RECOVERY WINDOW OF 30 DAYS.

Configurare l'impostazione dei criteri di conservazione RMAN

  1. Trovare l'ID del database utilizzando il comando seguente:

    dbcli list-databases

  2. Trovare il valore BackupConfigId per il database utilizzando il comando seguente: 

    dbcli describe-database -i <database_id>

  3. Aggiornare la configurazione dei criteri di conservazione in RECOVERY WINDOW OF 30 DAYS: 

    dbcli update-backupconfig -i <backup_config_id> --recoverywindow 30

Perdita del file wallet dell'area di memorizzazione degli oggetti e errori di backup

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.

Confermare che il file wallet dell'area di memorizzazione degli oggetti esiste e dispone delle autorizzazioni corrette

  1. Trovare l'ID del database utilizzando il comando seguente:

    dbcli list-databases

  2. Trovare il valore BackupConfigId per il database utilizzando il comando seguente: 

    dbcli describe-database -i <database_id>

  3. Trovare il valore BackupLocation per il database utilizzando il comando seguente: 

    dbcli describe-backupconfig <backup_config_id>

  4. Trovare il percorso del file dei parametri di configurazione del backup (opc_<backup_location_value>_BC.ora) utilizzando il comando seguente: 

    locate opc_<backup_location_value>_BC.ora

    Ad esempio:

    locate opc_b9naijWMAXzi9example_BC.ora

    Output:

    /opt/oracle/dcs/commonstore/objectstore/opc_pfile/13aef284-9d6b-4eb6-8751-2988a9example/opc_b9naijWMAXzi9example_BC.ora

  5. Trovare il percorso del file wallet nel file dei parametri di configurazione del backup ispezionando il valore memorizzato nel parametro OPC_WALLET. A tale scopo, andare alla directory contenente il file dei parametri di configurazione di backup e utilizzare il comando cat seguente: 

    cat <backup_config_parameter_file>

    Ad esempio:

    cat opc_b9naijWMAXzi9example_BC.ora

    Output:

    OPC_HOST=https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/dbbackupiad
OPC_WALLET='LOCATION=file:/opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample CREDENTIAL_ALIAS=alias_opc'
OPC_CONTAINER=b9naijWMAXzi9example

  6. Verificare che il file cwallet.sso esista nella directory specificata nel parametro OPC_WALLET e verificare che il file disponga delle autorizzazioni corrette. Le autorizzazioni del file devono avere il valore ottale "600" (-rw-------). Utilizzare il seguente comando: 

    ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/<backup_config_id>

    Ad esempio:

    ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample

    Output:

    total 4
-rw------- 1 oracle oinstall    0 Apr 20 06:45 cwallet.sso.lck
-rw------- 1 oracle oinstall 1941 Apr 20 06:45 cwallet.sso

Problemi del wallet TDE

Vengono trattati i seguenti argomenti:

Specifica ubicazione wallet TDE errata

Per il funzionamento delle operazioni di backup, il file $ORACLE_HOME/network/admin/sqlnet.ora deve contenere il parametro ENCRYPTION_WALLET_LOCATION formattato nel modo seguente: 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

Nota

In questa voce di posizione del wallet, $ORACLE_UNQNAME è una variabile di ambiente e non deve essere sostituita con un valore effettivo.

Controllare la specifica dell'ubicazione del wallet TDE

Utilizzare il comando cat per controllare la specifica della posizione del wallet TDE. Ad esempio: 

cat $ORACLE_HOME/network/admin/sqlnet.ora

Output:

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

La variabile di ambiente ORACLE_UNQNAME non è stata impostata quando il database è stato avviato utilizzando SQL*Plus

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

Per risolvere il problema, avviare il database utilizzando la utility srvctl: 

srvctl start database -d <db_unique_name>

Il pluggable database è stato aggiunto con una chiave di cifratura master configurata in modo errato

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. Questa chiave di cifratura viene memorizzata in un singolo keystore utilizzato da tutti i contenitori. 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. 

    alter session set container=pdb2;
    select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

    Output:

    WRL_TYPE  WRL_PARAMETER                                           STATUS             WALLET_TYPE
--------- ------------------------------------------------------- ------------------ -----------
FILE      /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ 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.

    show pdbs

    Output:

    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 la documentazione relativa al pluggable database per la versione di Oracle Database in uso.

  3. Eseguire i seguenti comandi DBCLI per modificare lo stato in OPEN: 

    sudo su –
    dbcli list-database
    dbcli update-tdekey -i <database_ID> -n <PDB_name> -p

    Il comando update-tdekey visualizzato richiederà la password di amministrazione.

  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.

Verifica configurazione correlata al wallet TDE

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

  1. Verificare che il parametro del nome univoco del database dell'ambiente (ORACLE_UNQNAME) sia impostato correttamente utilizzando il comando seguente:

    srvctl getenv database -d <db_unique_name>

    Ad esempio:

    srvctl getenv database -d orclbkp_iadxyz

    Output:

    orclbkp_iadxyz:
ORACLE_UNQNAME=orclbkp_iadxyz
TZ=UTC

  2. Controllare le impostazioni sqlnet.ora per verificare che il file disponga di un parametro ENCRYPTION_WALLET_LOCATION con il valore DIRECTORY corretto. Utilizzare il seguente comando: 

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Ad esempio:

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Output:

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

  3. Verificare che lo stato del wallet sia open e che il tipo di wallet sia login automatico controllando la vista v$encryption_wallet. Ad esempio: 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Output:

    STATUS  WRL_PARAMETER                                            WALLET_TYPE
------- -------------------------------------------------------- ------------
OPEN    /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/  AUTOLOGIN

    Per i pluggable database (PDB), assicurarsi di passare al contenitore appropriato prima di eseguire una query sulla vista v$encryption_wallet. Ad esempio: 

    sqlplus / as sysdba
    alter session set container=pdb1;
    select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

    Output:

    WRL_TYPE  WRL_PARAMETER                                          STATUS  WALLET_TYPE
--------- ------------------------------------------------------ ------- ------------
FILE      /opt/oracle/dcs/commonstore/wallets/tde/tiger_iad3c8/  OPEN    AUTOLOGIN

File wallet TDE mancante

Il file wallet TDE (ewallet.p12) può causare il guasto dei backup in caso di mancanza oppure se dispone di autorizzazioni o proprietà del file system incompatibili. Controllare il file come mostrato nell'esempio riportato di seguito. 

ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/ewallet.p12

Output:

-rwx------ 1 oracle oinstall 5680 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxzy/ewallet.p12

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

File del wallet di login automatico mancante

Il file wallet di login automatico (cwallet.sso) può causare il guasto dei backup in caso di mancanza o se dispone di autorizzazioni o proprietà del file system incompatibili. Controllare il file come mostrato nell'esempio riportato di seguito. 

ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/cwallet.sso

Output:

-rwx------ 1 oracle oinstall 5725 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxyz/cwallet.sso

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

Altre cause di errori di backup

Vengono trattati i seguenti argomenti:

Punto di accesso Commonstore non installato

Il punto di attivazione /opt/oracle/dcs/commonstore deve essere attivato o i backup non riusciranno.

Controllare il punto di accesso Commonstore

Verificare che il punto di attivazione /opt/oracle/dcs/commonstore sia attivato, come mostrato nell'esempio riportato di seguito. 

srvctl config filesystem -volume commonstore -diskgroup data

Output:

Volume device: /dev/asm/commonstore-5
Diskgroup name: data
Volume name: commonstore
Canonical volume device: /dev/asm/commonstore-5
Accelerator volume devices:
Mountpoint path: /opt/oracle/dcs/commonstore
Mount point owner: oracle
Mount users:
Type: ACFS

Conferma che ora.data.commonstore.acfs è online

  1. Lo stato di ora.data.commonstore.acfs deve essere online, altrimenti i backup non riusciranno. Confermare come indicato nell'esempio seguente: 

    crsctl stat resource ora.data.commonstore.acfs -v

    Output:

    NAME=ora.data.commonstore.acfs
TYPE=ora.acfs.type
LAST_SERVER=orcl
STATE=OFFLINE
TARGET=OFFLINE
...
STATE_DETAILS=admin unmounted /opt/oracle/dcs/commonstore
...

  2. Elencare i contenuti della directory commonstore per confermare che è attivata 

    ls -ltr /opt/oracle/dcs/commonstore

  3. Se il valore STATE_DETAILS è unmounted, attivare il file system come mostrato nell'esempio riportato di seguito. 

    srvctl start filesystem -volume commonstore -diskgroup data

  4. Verificare che la modifica sia riuscita come mostrato nell'esempio riportato di seguito.

    crsctl stat resource ora.data.commonstore.acfs -v

    Output:

    NAME=ora.data.commonstore.acfs
TYPE=ora.acfs.type
LAST_SERVER=orcl
STATE=ONLINE on orcl
TARGET=ONLINE
CARDINALITY_ID=ONLINE
...
STATE_DETAILS=mounted on /opt/oracle/dcs/commonstore

  5. Elencare i contenuti della directory commonstore per confermare che è attivata, come mostrato nell'esempio seguente: 

    ls -ltr /opt/oracle/dcs/commonstore

    Output:

    total 220
drwx------ 2 root   root     65536 Apr 18 10:50 lost+found
drwx------ 3 oracle oinstall 20480 Apr 18 11:02 wallets
drwxr-xr-x 3 root   root     20480 Apr 20 06:41 pkgrepos
drwxr-xr-x 4 oracle oinstall 20480 Apr 20 06:41 objectstore

Il database non è registrato correttamente

I backup del database non riescono se il database non è registrato con dcs-agent. Questo scenario può verificarsi se si esegue manualmente la migrazione del database in OCI e non si esegue il comando dbcli register-database.

Per verificare se il database è registrato correttamente, esaminare le informazioni restituite eseguendo il comando srvctl config database e il comando dbcli list-databases. Se uno dei comandi non restituisce un record del database, contattare Oracle Support Services.

Per istruzioni su come registrare il database, fare riferimento agli argomenti riportati di seguito.

Guida aggiuntiva

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.

Vengono trattati i seguenti argomenti:

Raccogli informazioni database da utilizzare nei report dei problemi

Utilizzare i comandi seguenti per raccogliere i dettagli sul database. Registrare l'output di ciascun comando come riferimento:

dbcli list-databases
dbcli describe-database -i <database_id>
dbcli describe-component

Raccogliere informazioni di diagnostica sui job non riusciti

  1. Accedere all'host come utente root e passare alla directory /opt/oracle/dcs/bin/.

  2. Eseguire i due comandi seguenti per generare informazioni sul job non riuscito:

    dbcli list-jobs
    dbcli describe-job -i <job_ID> -j

    Il <job_ID> nel secondo comando deve essere l'ID dell'ultimo job non riuscito segnalato dal primo comando.

  3. Eseguire lo script di raccolta diagnostica per creare un file zip con le informazioni di diagnostica per Oracle Support Services.

    diagcollector.py

    Questo comando crea un file denominato diagLogs -<timestamp>.zip nella directory /tmp.

Raccogli file di log agente DCS

Per raccogliere i file di log dell'agente DCS, effettuare le operazioni riportate di seguito.

  1. Eseguire il login come utente opc.

  2. Eseguire il comando riportato di seguito:

    sudo /opt/oracle/dcs/bin/diagcollector.py

    Il sistema restituisce un messaggio che indica che i log dell'agente sono disponibili in un file zip in una directory specificata. Ad esempio:

    Logs are being collected to: /tmp/dcsdiag/diagLogs-1234567890.zip

Raccogli dettagli configurazione TDE

  1. Eseguire il comando srvctl getenv database -d <db_unique_name> e registrare l'output come riferimento.

  2. Registrare l'output della vista v$encryption_wallet. Ad esempio: 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Output:

    STATUS   WRL_PARAMETER                                           WALLET_TYPE
-------- ------------------------------------------------------- ---------
OPEN     /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ AUTOLOGIN

  3. Registrare l'output dell'esempio ls -ltr <wrl_parameter> command.For: 

    ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/

    Output:

    total 28
-rw----- 1 oracle asmadmin 2400 May  2 09:42 ewallet_2018050209420381_defaultTag.p12
-rw----- 1 oracle asmadmin 5680 May  2 09:42 ewallet.p12
-rw----- 1 oracle asmadmin 5723 May  2 09:42 cwallet.sso

Raccoglie il file di report di backup RMAN

Generare il file di report di backup RMAN utilizzando il comando seguente:

dbcli create-rmanbackupreport -i <db_id> -w detailed -rn <report_name>

Ad esempio:

dbcli create-rmanbackupreport -i 57fvwxyz-9dc4-45d3-876b-5f850example -w detailed -rn bkpreport1

Individuare il file di report utilizzando il comando dbcli describe-rmanbackupreport -in <report_name>. La posizione del report viene specificata nell'output. Ad esempio: 

dbcli describe-rmanbackupreport -in bkpreport1

Output:

Backup Report details                                           
----------------------------------------------------------------
ID: b55vwxyz-c49f-4af3-a956-acccdexample
Report Type: detailed
Location: Node patchtst: /opt/oracle/dcs/log/patchtst/rman/bkup/example_iadxyz/rman_list_backup_detail
    /2018-05-02/rman_list_backup_detail_2018-05-02_11-46-51.0359.log
Database ID: 57fvwxyz-9dc4-45d3-876b-5f850example
CreatedTime: May 2, 2018 11:46:38 AM UTC