Backupfehler beheben

Bei Datenbankbackups können aus verschiedenen Gründen Fehler auftreten. Backupfehler treten in der Regel auf, weil der Datenbankhost nicht auf den Objektspeicher zugreifen kann oder wenn Probleme auf dem Host oder mit der Datenbankkonfiguration aufgetreten sind.

Dieser Artikel enthält Informationen, die bei der Ermittlung von Fehlerursachen und bei der Problembehebung helfen sollen. Diese Informationen sind nach Art der Fehlerbedingung in verschiedene Abschnitte geordnet.

Wenn Sie die Ursache bereits kennen, können Sie mit dem Thema mit der vorgeschlagenen Lösung fortfahren. Andernfalls können Sie mit dem Thema Fehlerursache identifizieren beginnen.

In diesem Artikel werden die folgenden Themen behandelt:

Tipp:

Sie können auch serielle Konsolenverbindungen erstellen, um Systemfehler im Einzelbenutzermodus zu beheben. Informationen zum Erstellen einer seriellen Konsolenverbindung in der OCI-Konsole finden Sie unter Serielle Konsolenverbindung zum DB-System verwalten.

Verwandte Themen

Fehlerursache identifizieren

In der OCI-Konsole wird bei einem nicht erfolgreichen Datenbankbackup entweder der Status Nicht erfolgreich angezeigt, oder das Backup hängt mit dem Status Backup wird erstellt oder Wird erstellt. Wenn die Fehlermeldung nicht genügend Informationen enthält, um auf eine Lösung zu verweisen, können Sie mit der CLI und Logdateien der Datenbank mehr Daten sammeln. Lesen Sie dann den Abschnitt zur entsprechenden Lösung in diesem Thema.

Die folgenden Themen werden behandelt:

Ursache von Backupfehlern identifizieren

  1. Melden Sie sich als Root-Benutzer beim Host an, und navigieren Sie zum Verzeichnis /opt/oracle/dcs/bin/.

  2. Bestimmen Sie die Sequenz von Vorgängen, die mit der Datenbank ausgeführt wurden.

    dbcli list-jobs | grep -i <dbname>

    Notieren Sie die letzte aufgelistete Job-ID mit einem anderen Status als Erfolgreich.

  3. Verwenden Sie den folgenden Befehl mit der im vorherigen Schritt notierten Job-ID, um die Details dieses Jobs zu prüfen:

    dbcli describe-job -i <job_ID> -j

    In der Regel ist die Ausführung dieses Befehls ausreichend, um die Ursache des Fehlers zu ermitteln.

  4. Wenn Sie mehr Informationen benötigen, prüfen Sie die Datei /opt/oracle/dcs/log/dcs-agent.log.

    Sie können die Job-ID in dieser Datei anhand des vom Jobbericht in Schritt 2 zurückgegebenen Zeitstempels finden.

  5. Wenn die Fehlerdetails auf einen RMAN-Fehler verweisen, prüfen Sie die RMAN-Logs im folgenden Verzeichnis.

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

Hinweis:

Wenn der Datenbankfehler bei einer RAC-Datenbank mit 2 Knoten aufgetreten ist, führen Sie die Schritte 3 und 4 auf beiden Knoten aus.

Probleme beim Datenbankservice-Agent

Ihre OCI-Datenbank nutzt ein Agent Framework, um Ihnen die Verwaltung der Datenbank über die Cloud-Plattform zu ermöglichen. Gelegentlich müssen Sie das Programm "dcsagent" neu starten, wenn es sich im Status stop/waiting befindet, um einen Backupfehler zu beheben.

Die folgenden Themen werden behandelt:

Datenbankservice-Agent neu starten

Hinweis:

Verwenden Sie initctl anstelle von systemctl, wenn Sie OL6 verwenden.

  1. Prüfen Sie über eine Eingabeaufforderung den Status des Agent:

    systemctl status initdcsagent

  2. Wenn sich der Agent im Status stop/waiting befindet, starten Sie den Agent neu: 

    systemctl start initdcsagent

  3. Prüfen Sie den Status des Agent erneut, um sicherzustellen, dass der Status start/running lautet: 

    systemctl status initdcsagent

Probleme mit Oracle Clusterware

Mit Oracle Clusterware können Server miteinander kommunizieren und so zusammen als eine Einheit funktionieren. Gelegentlich müssen Sie das Clusterware-Programm neu starten, um einen Backupfehler zu beheben.

Eine oder mehrere der folgenden Bedingungen auf dem Datenbankhost können zu Backupfehlern führen:

Oracle Clusterware neu starten

  1. Prüfen Sie über die Eingabeaufforderung den Status von Oracle Clusterware:

    crsctl check crs
    crsctl stat res -t

  2. Wenn Oracle Clusterware nicht online ist, starten Sie das Programm neu:

    crsctl start crs

  3. Prüfen Sie den Status von Oracle Clusterware, um sicherzustellen, dass das Programm online ist:

    crsctl check crs

Probleme mit der Objektspeicherkonnektivität

Für das Backup einer Datenbank in OCI Object Storage muss der Host eine Verbindung zum entsprechenden Swift-Endpunkt herstellen können. Sie können diese Verbindung mit einem Swift-Benutzer testen.

Die folgenden Themen werden behandelt:

Stellen Sie sicher, dass der Datenbankhost eine Verbindung zum Objektspeicher herstellen kann

  1. Erstellen Sie einen Swift-Benutzer in Ihrem Mandanten. Weitere Informationen finden Sie unter Mit Authentifizierungstoken arbeiten in Benutzerzugangsdaten verwalten.

  2. Nachdem der Benutzer im vorherigen Schritt erstellt wurde, können Sie mit dem folgenden Befehl prüfen, ob der Host auf den Objektspeicher zugreifen kann.

    curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
  3. Wenn Sie keine Verbindung zum Objektspeicher herstellen können, lesen Sie unter Datenbank mit der Konsole sichern nach, wie Sie die Objektspeicherverbindung konfigurieren.

Hostprobleme

Die folgenden Themen werden behandelt:

Eine oder mehrere der folgenden Bedingungen auf dem Datenbankhost können zu Backupfehlern führen:

Interaktive Befehle im Oracle-Profil

Wenn ein interaktiver Befehl wie oraenv oder ein Befehl, der möglicherweise eine Fehler- oder Warnmeldung zurückgibt, der .bash_profile-Datei für den Benutzer "grid" oder "oracle" hinzugefügt wurde, können Datenbankservicevorgänge wie automatische Backups unterbrochen werden, was ihren Abschluss verhindert. Prüfen Sie die .bash_profile-Datei auf diese Befehle, und entfernen Sie sie.

Das Dateisystem ist voll

Für Backupvorgänge ist im Verzeichnis /u01 des Hostdateisystems Speicherplatz erforderlich. Verwenden Sie den Befehl df -h auf dem Host, um den für Backups verfügbaren Speicherplatz zu prüfen. Wenn nicht genügend Speicherplatz im Dateisystem vorhanden ist, können Sie alte Log- oder Tracedateien entfernen, um Speicherplatz freizugeben.

Falsche Version des Oracle Database Cloud-Backupmoduls

Ihr System verfügt möglicherweise nicht über die erforderliche Version des Backupmoduls (opc_installer.jar). Einzelheiten zu diesem bekannten Problem finden Sie unter In Ihrem DB-System können keine verwalteten Backups verwendet werden. Um das Problem zu beheben, können Sie die Prozedur in diesem Abschnitt ausführen oder das DB-System und die Datenbank einfach mit dem neuesten Bundle-Update aktualisieren.

Änderungen an der Siteprofildatei (glogin.sql)

Eine Anpassung der Siteprofildatei ($ORACLE_HOME/sqlplus/admin/glogin.sql) kann dazu führen, dass verwaltete Backups in OCI nicht erfolgreich verlaufen. Siehe SQL*Plus-Konfiguration. Insbesondere können interaktive Befehle zu Backupfehlern führen. Oracle empfiehlt, dass Sie diese Datei für Datenbanken, die in OCI gehostet sind, nicht ändern.

Datenbankprobleme

Ein falscher Datenbankstatus oder eine fehlerhafte Konfiguration kann zu Backupfehlern führen.

Die folgenden Themen werden behandelt:

Datenbank wird während des Backups nicht ausgeführt

Die Datenbank muss aktiv und gestartet sein (idealerweise auf allen Knoten), während das Backup ausgeführt wird.

Prüfen, ob die Datenbank hochgefahren und gestartet ist.

Verwenden Sie den folgenden Befehl, um den Status der Datenbank zu prüfen, und stellen Sie sicher, dass Probleme, die den falschen Datenbankstatus verursacht haben, behoben werden:

srvctl status database -d <db_unique_name> -verbose

Das System gibt eine Meldung mit dem Instanzstatus der Datenbank zurück. Der Instanzstatus muss Offen lauten, damit das Backup erfolgreich verläuft. Wenn die Datenbank nicht ausgeführt wird, starten Sie sie mit dem folgenden Befehl: 

srvctl start database -d <db_unique_name> -o open

Wenn die Datenbank gemountet ist, aber nicht den Status Offen hat, verwenden Sie die folgenden Befehle, um auf die SQL*Plus-Eingabeaufforderung zuzugreifen und den Status auf Offen zu setzen: 

sqlplus / as sysdba
alter database open;

Archivierungsmodus auf NOARCHIVELOG gesetzt

Wenn Sie eine neue Datenbank bereitstellen, ist der Archivierungsmodus standardmäßig auf ARCHIVELOG gesetzt. Das ist der für Backupvorgänge erforderliche Archivierungsmodus. Prüfen Sie die Einstellung des Archivierungsmodus für die Datenbank, und ändern Sie sie gegebenenfalls in ARCHIVELOG.

Archivierungsmodus prüfen und festlegen

Öffnen Sie eine SQL*Plus-Eingabeaufforderung, und geben Sie den folgenden Befehl ein:

select log_mode from v$database;

Wenn Sie den Archivierungsmodus auf ARCHIVELOG setzen müssen, starten Sie die Datenbank im Status Mount (und nicht im Status Offen), und geben Sie an der SQL*Plus-Eingabeaufforderung den folgenden Befehl ein: 

alter database archivelog;

Stellen Sie sicher, dass der Parameter db_recovery_file_dest auf +RECO verweist und dass der Parameter log_archive_dest_1 auf USE_DB_RECOVERY_FILE_DEST gesetzt ist.

Bei RAC-Datenbanken muss eine Instanz den StatusMountaufweisen, wenn der Archivelog-Modus aktiviert wird. So aktivieren Sie den Archivelog-Modus für eine RAC-Datenbank:

  1. Fahren Sie alle Datenbankinstanzen herunter.

    srvctl stop database -d

  2. Starten Sie eine der Datenbankinstanzen im Mount-Status.

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

  3. Rufen Sie die SQL*Plus-Eingabeaufforderung auf.

    sqlplus / as sysdba

  4. Aktivieren Sie den Archive-Logmodus, und beenden Sie den Vorgang.

    alter database archivelog;
    exit;

  5. Stoppen Sie die Datenbank.

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

  6. Starten Sie alle Datenbankinstanzen neu.

    srvctl start database -d <db_unqiue_name>

  7. Prüfen Sie über die SQL*Plus-Eingabeaufforderung, dass der Archivierungsmodus auf ARCHIVELOG gesetzt ist. 

    select log_mode from v$database;

Datenbank-Archiver-Prozess hängt und Backupfehler

Backups können nicht erfolgreich ausgeführt werden, wenn der Archiver-Prozess einer Datenbankinstanz hängt. Das kann beispielsweise dann geschehen, wenn der Flash-Recovery-Bereich (FRA) voll ist. Sie können diese Bedingung mit dem folgenden Befehl prüfen.

srvctl status database -db <db_unique_name> -v

Wenn der Befehl die folgende Ausgabe zurückgibt, müssen Sie das Problem mit dem hängenden Archiver-Prozess beheben, bevor Backups erfolgreich verlaufen können:

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

Weitere Informationen zum Beheben eines hängenden Archiver-Prozesses finden Sie unter ORA-00257: Archiver Error (Dok.-ID 2014425.1).

Nach dem Beheben des hängenden Prozesses sollte der Befehl folgende Ausgabe zurückgeben:

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

Wenn sich der Instanzstatus nicht ändert, nachdem Sie das zugrunde liegende Problem (Gerät oder Ressource voll oder nicht verfügbar) gelöst haben, führen Sie einen der folgenden Workarounds aus:

  • Datenbank mit dem Befehl srvctl neu starten, um ihren Status in der Clusterware zu aktualisieren
  • Datenbank auf die neuesten Patchsetebenen aktualisieren

Fehler beim Temporary Tablespace

Wenn die festen Tabellenstatistiken in der Datenbank nicht aktuell sind, können bei Backups Fehler auftreten, die den Temporary Tablespace referenzieren, der in der Datei dcs-agent.log vorhanden ist. Beispiel: 

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

Ausgabe:

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

Erfassen Sie die festen Tabellenstatistiken wie folgt, um dieses Problem zu lösen.

conn / as sysdba
exec dbms_stats.gather_fixed_objects_stats();

RMAN-Konfiguration und Backupfehler

Die Bearbeitung bestimmter RMAN-Konfigurationsparameter kann zu Backupfehlern in OCI führen. Um die RMAN-Konfiguration zu prüfen, geben Sie in der RMAN-Befehlszeile den Befehl show all ein.

Einzelheiten zu den Konfigurationseinstellungen, die für Datenbanken in OCI nicht geändert werden dürfen, finden Sie in der folgenden Parameterliste.

RMAN-Konfigurationseinstellungen, die nicht geändert werden dürfen

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;

RMAN-Aufbewahrungs-Policy und Backupfehler

Die Konfiguration der RMAN-Aufbewahrungs-Policy kann Backupfehler verursachen. Die Konfiguration mit der Aufbewahrungs-Policy REDUNDANCY anstelle der Policy RECOVERY WINDOW kann zu Backupfehlern führen. Stellen Sie sicher, dass Sie die Konfiguration RECOVERY WINDOW OF 30 DAYS verwenden.

Einstellung der RMAN-Aufbewahrungs-Policy konfigurieren

  1. Suchen Sie die Datenbank-ID mit dem folgenden Befehl:

    dbcli list-databases

  2. Suchen Sie den Wert BackupConfigId für die Datenbank mit dem folgenden Befehl: 

    dbcli describe-database -i <database_id>

  3. Aktualisieren Sie die Konfiguration der Aufbewahrungs-Policy auf RECOVERY WINDOW OF 30 DAYS: 

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

Verlust von Objektspeicher-Wallet-Datei und Backupfehler

RMAN-Backups verlaufen nicht erfolgreich, wenn keine Objektspeicher-Wallet-Datei vorhanden ist. Die Wallet-Datei ist erforderlich, um die Konnektivität mit dem Objektspeicher zu ermöglichen.

Prüfen, ob die Objektspeicher-Wallet-Datei vorhanden ist und die richtigen Berechtigungen aufweist

  1. Suchen Sie die Datenbank-ID mit dem folgenden Befehl:

    dbcli list-databases

  2. Suchen Sie den Wert BackupConfigId für die Datenbank mit dem folgenden Befehl: 

    dbcli describe-database -i <database_id>

  3. Suchen Sie den Wert von BackupLocation für die Datenbank mit dem folgenden Befehl: 

    dbcli describe-backupconfig <backup_config_id>

  4. Suchen Sie den Dateipfad der Backup-Konfigurationsparameterdatei (opc_<backup_location_value>_BC.ora) mit dem folgenden Befehl: 

    locate opc_<backup_location_value>_BC.ora

    Beispiel:

    locate opc_b9naijWMAXzi9example_BC.ora

    Ausgabe:

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

  5. Suchen Sie den Dateipfad zur Wallet-Datei in der Parameterdatei zur Backupkonfiguration, indem Sie den im Parameter OPC_WALLET gespeicherten Wert prüfen. Navigieren Sie dazu zum Verzeichnis mit der Parameterdatei zur Backupkonfiguration, und verwenden Sie den folgenden cat-Befehl: 

    cat <backup_config_parameter_file>

    Beispiel:

    cat opc_b9naijWMAXzi9example_BC.ora

    Ausgabe:

    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. Prüfen Sie, ob die Datei cwallet.sso in dem Verzeichnis vorhanden ist, das im Parameter OPC_WALLET angegeben ist, und ob sie die richtigen Berechtigungen aufweist. Die Dateiberechtigungen müssen den Oktalwert "600" (-rw-------) haben. Verwenden Sie den folgenden Befehl: 

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

    Beispiel:

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

    Ausgabe:

    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

TDE-Wallet-Probleme

Die folgenden Themen werden behandelt:

Falsche Angabe des TDE-Wallet-Speicherorts

Damit Backupvorgänge ausgeführt werden können, muss die Datei $ORACLE_HOME/network/admin/sqlnet.ora den Parameter ENCRYPTION_WALLET_LOCATION genau im folgenden Format enthalten: 

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

Hinweis:

In diesem Eintrag für den Wallet-Verzeichnis ist $ORACLE_UNQNAME eine Umgebungsvariable, die nicht durch einen tatsächlichen Wert ersetzt werden darf.

Angabe des TDE-Wallet-Speicherorts prüfen

Verwenden Sie den Befehl cat, um die Angabe des TDE-Wallet-Speicherorts zu prüfen. Beispiel: 

cat $ORACLE_HOME/network/admin/sqlnet.ora

Ausgabe:

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

Die Umgebungsvariable ORACLE_UNQNAME wurde beim Starten der Datenbank mit SQL*Plus nicht festgelegt

Wenn die Datenbank mit SQL*Plus gestartet wurde und die Umgebungsvariable ORACLE_UNQNAME nicht festgelegt ist, wird das Wallet nicht richtig geöffnet.

Um das Problem zu beheben, starten Sie die Datenbank mit dem Utility srvctl: 

srvctl start database -d <db_unique_name>

Integrierbare Datenbank wurde mit falsch konfiguriertem Masterverschlüsselungsschlüssel hinzugefügt

In einer mehrmandantenfähigen Umgebung für Oracle Database-Versionen, die Keystores auf PDB-Ebene unterstützen, verfügt jede PDB über einen eigenen Masterverschlüsselungsschlüssel. Dieser Verschlüsselungsschlüssel wird in einem zentralen Keystore gespeichert, der von allen Containern verwendet wird. Nachdem Sie eine neue PDB erstellt oder integriert haben, müssen Sie einen Masterverschlüsselungsschlüssel dafür erstellen und aktivieren. Andernfalls wird in der Spalte STATUS in der View v$encryption_wallet der Wert OPEN_NO_MASTER_KEY angezeigt.

So prüfen Sie den Status des Masterverschlüsselungsschlüssels und erstellen einen Masterschlüssel:

  1. Prüfen Sie die Spalte STATUS in der View v$encryption_wallet, wie im folgenden Beispiel dargestellt: 

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

    Ausgabe:

    WRL_TYPE  WRL_PARAMETER                                           STATUS             WALLET_TYPE
--------- ------------------------------------------------------- ------------------ -----------
FILE      /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ OPEN_NO_MASTER_KEY AUTOLOGIN

  2. Stellen Sie sicher, dass sich die PDB im geöffneten READ WRITE-Modus befindet und nicht eingeschränkt ist, wie im folgenden Beispiel gezeigt:

    show pdbs

    Ausgabe:

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

    Die PDB darf nicht im eingeschränkten Modus geöffnet sein (in der Spalte RESTRICTED muss NO angezeigt werden). Wenn sich die PDB im eingeschränkten Modus befindet, prüfen Sie die Informationen in der View PDB_PLUG_IN_VIOLATIONS, und lösen Sie das Problem, bevor Sie fortfahren. Weitere Informationen zur View PDB_PLUG_IN_VIOLATIONS und zum eingeschränkten Status finden Sie in der Dokumentation zu integrierbaren Datenbanken für Ihre Oracle-Datenbankversion.

  3. Um den Status auf OPEN zu setzen, führen Sie die folgenden DBCLI-Befehle aus: 

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

    Mit dem angezeigten Befehl update-tdekey werden Sie zur Eingabe des Admin-Kennworts aufgefordert.

  4. Stellen Sie sicher, dass der Status des Wallets von OPEN_NO_MASTER_KEY in OPEN geändert wurde, indem Sie die View v$encryption_wallet wie in Schritt 1 dargestellt abfragen.

Konfiguration für TDE-Wallet prüfen

Verschiedene Konfigurationsparameter für das TDE-Wallet können zu Backupfehlern führen.

  1. Prüfen Sie mit dem folgenden Befehl, ob der Parameter für den eindeutigen Datenbanknamen der Umgebung (ORACLE_UNQNAME) korrekt festgelegt ist:

    srvctl getenv database -d <db_unique_name>

    Beispiel:

    srvctl getenv database -d orclbkp_iadxyz

    Ausgabe:

    orclbkp_iadxyz:
ORACLE_UNQNAME=orclbkp_iadxyz
TZ=UTC

  2. Prüfen Sie in den sqlnet.ora-Einstellungen, ob die Datei einen ENCRYPTION_WALLET_LOCATION-Parameter mit dem korrekten DIRECTORY-Wert enthält. Verwenden Sie den folgenden Befehl: 

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Beispiel:

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Ausgabe:

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

  3. Stellen Sie in der View v$encryption_wallet sicher, dass der Wallet-Status openund der Wallet-Typ auto login lautet. Beispiel: 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Ausgabe:

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

    Bei integrierbaren Datenbanken (PDBs) müssen Sie zum entsprechenden Container wechseln, bevor Sie die View v$encryption_wallet abfragen. Beispiel: 

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

    Ausgabe:

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

Fehlende TDE- Wallet-Datei

Die TDE-Wallet-Datei (ewallet.p12) kann Backupfehler verursachen, wenn sie fehlt oder inkompatible Dateisystemberechtigungen oder Eigentümer hat. Prüfen Sie die Datei, wie im folgenden Beispiel gezeigt: 

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

Ausgabe:

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

Die TDE-Wallet-Datei muss über Dateiberechtigungen mit dem Oktalwert "700" (-rwx------) verfügen, und der Eigentümer dieser Datei muss zur Betriebssystemgruppe oinstall gehören.

Wallet-Datei für automatische Anmeldung fehlt

Die Wallet-Datei zur automatischen Anmeldung (cwallet.sso) kann Backupfehler verursachen, wenn sie fehlt oder inkompatible Dateisystemberechtigungen oder Eigentümer hat. Prüfen Sie die Datei, wie im folgenden Beispiel gezeigt: 

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

Ausgabe:

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

Die Wallet-Datei für die automatische Anmeldung muss über Dateiberechtigungen mit dem Oktalwert "700" (-rwx------) verfügen, und der Eigentümer dieser Datei muss zur Betriebssystemgruppe oinstall gehören.

Sonstige Ursachen von Backupfehlern

Die folgenden Themen werden behandelt:

Nicht gemounteter Commonstore Mount Point

Der Mount Point /opt/oracle/dcs/commonstore muss gemountet sein, andernfalls treten Backupfehler auf.

Commonstore Mount Point prüfen

Vergewissern Sie sich, dass der Mount Point /opt/oracle/dcs/commonstore gemountet ist, wie im folgenden Beispiel dargestellt: 

srvctl config filesystem -volume commonstore -diskgroup data

Ausgabe:

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

Vergewissern Sie sich, dass ora.data.commonstore.acfs online ist

  1. Der Status für ora.data.commonstore.acfs muss "online" lauten, andernfalls verlaufen Backups nicht erfolgreich. Prüfen Sie dies, wie im folgenden Beispiel gezeigt: 

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

    Ausgabe:

    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. Listen Sie den Inhalt des Verzeichnisses commonstore auf, um sich zu vergewissern, dass er gemountet wurde 

    ls -ltr /opt/oracle/dcs/commonstore

  3. Wenn der Wert von STATE_DETAILS unmounted lautet, mounten Sie das Dateisystem wie im folgenden Beispiel gezeigt: 

    srvctl start filesystem -volume commonstore -diskgroup data

  4. Prüfen Sie, ob die Änderung erfolgreich war, wie im folgenden Beispiel gezeigt:

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

    Ausgabe:

    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. Listen Sie den Inhalt des Verzeichnisses commonstore auf, um sich zu vergewissern, dass er gemountet wurde, wie im folgenden Beispiel gezeigt: 

    ls -ltr /opt/oracle/dcs/commonstore

    Ausgabe:

    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

Datenbank ist nicht ordnungsgemäß registriert

Datenbankbackups sind nicht erfolgreich, wenn die Datenbank nicht bei dcs-agent registriert ist. Dieses Szenario kann eintreten, wenn Sie die Datenbank manuell zu OCI migrieren und den Befehl dbcli register-database nicht ausführen.

Um herauszufinden, ob die Datenbank ordnungsgemäß registriert ist, prüfen Sie die Informationen, die von den Befehlen srvctl config database und dbcli list-databases zurückgegeben werden. Wenn einer der Befehle keinen Datensatz für die Datenbank zurückgibt, wenden Sie sich an Oracle Support Services.

Anweisungen zum Registrieren der Datenbank finden Sie in den folgenden Themen:

Weitere Hilfe suchen

Wenn Sie das Problem anhand der Informationen in diesem Thema nicht lösen können, gehen Sie wie folgt vor, um relevante Datenbank- und Diagnoseinformationen zu sammeln. Nachdem Sie diese Informationen erfasst haben, wenden Sie sich an Oracle Support.

Die folgenden Themen werden behandelt:

Datenbankinformationen zur Verwendung in Problemberichten erfassen

Mit den folgenden Befehlen können Sie Details zu Ihrer Datenbank erfassen. Notieren Sie die Ausgabe jedes Befehls zur Referenz:

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

Diagnosedaten zu nicht erfolgreichen Jobs erfassen

  1. Melden Sie sich als Root-Benutzer beim Host an, und navigieren Sie zum Verzeichnis /opt/oracle/dcs/bin/.

  2. Führen Sie die folgenden beiden Befehle aus, um Informationen zu dem nicht erfolgreichen Job zu erhalten:

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

    Die <job_ID> im zweiten Befehl muss die ID des letzten nicht erfolgreichen Jobs sein, der vom ersten Befehl gemeldet wurde.

  3. Führen Sie das Diagnose-Collector-Skript aus, um eine ZIP-Datei mit den Diagnoseinformationen für Oracle Support Services zu erstellen.

    diagcollector.py

    Dieser Befehl erstellt eine Datei mit dem Namen diagLogs -<timestamp>.zip im Verzeichnis /tmp.

DCS-Agent-Logdateien erfassen

Gehen Sie wie folgt vor, um DCS-Agent-Logdateien zu erfassen:

  1. Melden Sie sich als Benutzer opc an.

  2. Führen Sie den folgenden Befehl aus:

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

    Das System gibt eine Meldung zurück, dass Agent-Logs in einer ZIP-Datei in einem angegebenen Verzeichnis verfügbar sind. Beispiel:

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

TDE-Konfigurationsdetails erfassen

  1. Führen Sie den Befehl srvctl getenv database -d <db_unique_name> aus, und notieren Sie die Ausgabe zur Referenz.

  2. Notieren Sie die Ausgabe der View v$encryption_wallet. Beispiel: 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Ausgabe:

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

  3. Notieren Sie die Ausgabe des Befehls ls -ltr <wrl_parameter> Beispiel: 

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

    Ausgabe:

    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

RMAN-Backupberichtsdatei erfassen

Generieren Sie die RMAN-Backupberichtsdatei mit dem folgenden Befehl: 

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

Beispiel:

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

Suchen Sie die Berichtsdatei mit dem Befehl dbcli describe-rmanbackupreport -in <report_name>. Der Speicherort des Berichts wird in der Ausgabe angegeben. Beispiel: 

dbcli describe-rmanbackupreport -in bkpreport1

Ausgabe:

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