Bei Datenbankbackups können während der RMAN-Konfigurationsphase oder während der Ausführung eines RMAN-Backupjobs Fehler auftreten. RMAN-Konfigurationsaufgaben umfassen das Validieren der Backupzielkonnektivität, die Installation des Backupmoduls und RMAN-Konfigurationsänderungen. Welche Logdateien von Ihnen untersucht werden, hängt davon ab, in welcher Phase der Fehler auftritt.

1. Melden Sie sich beim Host als Benutzer oracle an.
2. Prüfen Sie die entsprechende Logdatei:
   • Um die Job-ID eines automatisierten Backups zu identifizieren, verwenden Sie den Befehl dbaascli database backup --dbname <dbname> --showHistory. Dadurch wird die Historie aller Backupjobs angezeigt, einschließlich der entsprechenden Job-IDs.
   • Joblogs sind unter /var/opt/oracle/log/dtrs/jobs/ mit dem Namen <job_id>.log verfügbar. Wenn ein Job nicht erfolgreich verläuft, wird auch ein entsprechendes Debuglog <job_id>.debug an demselben Speicherort generiert.
   • Sie finden die entsprechenden Ausführungslogs des Befehls RMAN für Backup-, Recovery- und Konfigurationsvorgänge im Verzeichnis /var/opt/oracle/log/<dbname>/dtrs/rman/bkup.

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

   systemctl status dbcsagent.service

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

   systemctl start dbcsagent.service

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

   systemctl status dbcsagent.service

1. Erstellen Sie einen Swift-Benutzer in Ihrem Mandanten. Siehe Mit Authentifizierungstoken arbeiten.
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>

   Weitere Informationen zur richtigen Region finden Sie unter Object Storage - Häufig gestellte Fragen. Informationen zu Ihrem Object Storage-Namespace finden Sie unter Object Storage-Namespaces.
3. Wenn Sie keine Verbindung zum Objektspeicher herstellen können, erhalten Sie unter Anforderungen für Backups in Exadata Cloud Service weitere Informationen zum Konfigurieren der Objektspeicherkonnektivität.

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.

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.

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-Patch aktualisieren.

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

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

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.

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).

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

Wenn sich der Instanzstatus nicht ändert, nachdem Sie das zugrunde liegende Problem mit vollen oder nicht verfügbaren Geräten oder Ressourcen gelöst haben, versuchen Sie, die Datenbank mit dem Befehl srvctl neu zu starten, um den Status der Datenbank in der Clusterware zu aktualisieren.

Die Bearbeitung bestimmter RMAN-Konfigurationsparameter kann zu Backupfehlern in Oracle Cloud Infrastructure 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 Oracle Cloud Infrastructure nicht geändert werden dürfen, finden Sie in der folgenden Parameterliste.

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;

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.

Datenbankbackups sind nicht erfolgreich, wenn das TDE-Wallet nicht den richtigen Status aufweist. Die folgenden Szenarios können zu diesem Problem führen:

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

srvctl start database -d <db_unique_name>

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. Bei Oracle 18c-Datenbanken wird dieser Verschlüsselungsschlüssel in einem zentralen Keystore gespeichert, der von allen Containern verwendet wird. (Oracle Database 19c unterstützt keinen Keystore auf PDB-Ebene.) 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:

   
   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. Stellen Sie sicher, dass sich die PDB im geöffneten READ WRITE-Modus befindet und nicht eingeschränkt ist, wie im folgenden Beispiel gezeigt:

   
   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

   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 beheben Sie das Problem, bevor Sie fortfahren. Weitere Informationen zur View PDB_PLUG_IN_VIOLATIONS und zum eingeschränkten Status finden Sie in der Dokumentation für Administratoren mehrmandantenfähiger Oracle-Systeme zur integrierbaren Datenbank für Ihre Oracle Database-Version.

3. Erstellen und aktivieren Sie einen Masterverschlüsselungsschlüssel für die PDB:

   • Setzen Sie den Container auf die PDB:

     ALTER SESSION SET CONTAINER = <pdb>;

   • Erstellen und aktivieren Sie einen Masterverschlüsselungsschlüssel in der PDB, indem Sie den folgenden Befehl ausführen:

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

   Beachten Sie Folgendes:

   • Die Klausel USING TAG ist optional und kann verwendet werden, um ein Tag mit dem neuen Masterverschlüsselungsschlüssel zu verknüpfen.

   • Die Klausel WITH BACKUP ist optional und kann verwendet werden, um ein Backup des Keystores zu erstellen, bevor der neue Masterverschlüsselungsschlüssel erstellt wird.

   Sie können auch die dbaascli-Befehle dbaascli tde status und dbaascli tde rotate masterkey verwenden, um Schlüssel zu untersuchen und zu verwalten.

4. Stellen Sie sicher, dass der Status des Wallets von OPEN_NO_MASTER_KEY zu OPEN gewechselt hat, indem Sie die View v$encryption_wallet wie in Schritt 1 dargestellt abfragen.

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

# 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

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

# 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

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

Erfassen Sie auf jedem mit der Data Guard-Konfiguration verknüpften Compute Node Logdateien, die sich auf das aufgetretene Problem beziehen.

• Logdateien der Aktivierungsphase (z.B. solche zur Dokumentation des Vorgangs " Standbydatenbank erstellen") und die Logs für das entsprechende Primär- oder Standbysystem.
• Logdateien der Aktivierungsjob-ID. Beispiel: 23.
• Speicherort der Logdateien nach Aktivierungsphase und Exadata-System (Primär oder Standby).
• Logdateien für Datenbanknamen (db_name oder db_unique_name, je nach Dateipfad).

Data Guard Deployer (DGdeployer) ist der Prozess, der die Konfiguration ausführt. Bei der Konfiguration der Primärdatenbank wird die Datei /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log erstellt.

Dieses Log sollte die Ursache eines Fehlers bei der Konfiguration der Primärdatenbank enthalten.

• Die primäre Logdatei des Befehlszeilenutilitys dbaasapi ist: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Suchen Sie nach Einträgen, die dg_api enthalten.
• Eine Standbylogdatei des Befehlszeilenutilitys dbaasapi ist: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Suchen Sie in diesem Log nach Einträgen, die dg_api enthalten.
• Die andere Standbylogdatei ist: /var/opt/oracle/log/<dbname>/dgcc/dgcc.log. Dies ist das Data Guard-Konfigurationslog.

• Die Oracle Cloud Deployment Engine (ODCE) erstellt die Datei /var/opt/oracle/log/<dbname>/ocde/ocde.log. Dieses Log sollte die Ursache für einen Fehler beim Erstellen der Standbydatenbank enthalten.
• Das Befehlszeilenutility dbaasapi erstellt die Datei var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Suchen Sie nach Einträgen, die dg_api enthalten.
• Die Data Guard-Konfigurationslogdatei ist /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

• DGdeployer ist der Prozess, der die Konfiguration ausführt. Er erstellt die folgende Datei: /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Dieses Log sollte die Ursache eines Fehlers bei der Konfiguration der Standbydatenbank enthalten.
• Das Befehlszeilenutility dbaasapi erstellt die Datei var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Suchen Sie nach Einträgen, die dg_api enthalten.
• Das Data Guard-Konfigurationslog ist /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

DGdeployer ist der Prozess, der die Konfiguration ausführt. Bei der Konfiguration von Data Guard wird die Datei /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log erstellt. Dieses Log sollte die Ursache eines Fehlers bei der Konfiguration der Primärdatenbank enthalten.

Erfassen Sie auf jedem Knoten der Primär- und Standbysites Logdateien für den zugehörigen Datenbanknamen (db_name).

• Datenbankalertlog: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/alert_<dbinstance>.log
• Data Guard-Brokerlog: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/drc<dbinstance>.log
• Cloud-Tooling-Logdatei für Data Guard: /var/opt/oracle/log/<dbname>/odg/odg.log

Das zum Aktivieren von Data Guard eingegebene Kennwort stimmte nicht mit dem primären Admin-Kennwort für den SYS-Benutzer überein. Dieser Fehler tritt während der Aktivierungsphase "Primärdatenbank validieren" auf.

Die Datenbank wird möglicherweise nicht ausgeführt. Dieser Fehler tritt während der Aktivierungsphase "Primärdatenbank validieren" auf. Prüfen Sie mit srvctl und sql auf dem Host, ob die Datenbank auf allen Knoten hochgefahren und gestartet ist.

Die Primärdatenbank konnte nicht konfiguriert werden. Dieser Fehler kann durch ungültige Data Guard-Befehle oder eine nicht erfolgreiche Listener-Neukonfiguration verursacht werden.

Das TDE- Wallet konnte nicht erstellt werden. Die Oracle TDE-Keystore-(Wallet-)Dateien konnten nicht für den Transport zur Standbysite vorbereitet werden. Dieser Fehler tritt während der Aktivierungsphase "TDE-Wallet erstellen" auf. Eines der folgenden Elemente kann zu einem Fehler in dieser Phase führen:

• Auf die TDE-Wallet-Dateien konnte nicht zugegriffen werden
• Die Aktivierungsbefehle konnten kein Archiv mit den Wallet-Dateien erstellen

Prozedur zur Fehlerbehebung:

1. Stellen Sie sicher, dass auf das Cluster zugegriffen werden kann. Um den Status eines Clusters zu prüfen, führen Sie den folgenden Befehl aus:

   crsctl check cluster -all

2. Wenn das Cluster heruntergefahren ist, führen Sie den folgenden Befehl aus, um es neu zu starten:

   crsctl start crs -wait

3. Wenn dieser Fehler auftritt, obwohl auf das Cluster zugegriffen werden kann, prüfen Sie die Logs für die Aktivierungsphase "TDE-Wallet erstellen", um Ursache und Lösung für den Fehler zu bestimmen.

Das Archiv mit dem TDE-Wallet wurde wahrscheinlich nicht an die Standbysite übertragen. Das Problem kann in der Regel durch Wiederholen behoben werden.

• Primär- und Standbysite können möglicherweise nicht miteinander kommunizieren, um die Standbydatenbank zu konfigurieren. Diese Fehler treten während der Aktivierungsphase "Standbydatenbank konfigurieren" auf. In dieser Phase werden Konfigurationen an der Standbydatenbank vorgenommen, einschließlich des RMAN-Duplikates der Primärdatenbank. So beheben Sie dieses Problem:
  1. Prüfen Sie den Konnektivitätsstatus für Primär- und Standbysite.
  2. Stellen Sie sicher, dass der Host über Port 1521 mit allen Ports kommunizieren kann. Prüfen Sie das Netzwerksetup, einschließlich Netzwerksicherheitsgruppen (NSGs), Netzwerksicherheitslisten und gegebenenfalls das Remote-VCN-Peering-Setup. Die beste Möglichkeit zum Testen der Kommunikation zwischen Host und anderen Knoten besteht darin, über SQL*Plus von der Primär- auf die Standbydatenbank und von der Standby- auf die Primärdatenbank zuzugreifen.
• Die SCAN-VIPs oder Listener werden möglicherweise nicht ausgeführt. Verwenden Sie den obigen Test, um das Problem zu ermitteln.

Mögliche Ursachen:

• Die SCAN-VIPs oder Listener werden möglicherweise nicht ausgeführt. Sie können das Vorliegen dieses Problems mit den folgenden Befehlen auf einem beliebigen Clusterknoten bestätigen.

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

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

• Die Datenbanken sind möglicherweise nicht erreichbar. Sie können das Vorliegen dieses Problems bestätigen, indem Sie versuchen, mit einem vorhandenen Oracle Net-Alias eine Verbindung herzustellen.

Prozedur zur Fehlerbehebung:

1. Prüfen Sie als Betriebssystembenutzer oracle, ob ein Oracle Net-Alias für die Containerdatenbank (CDB) vorhanden sind. Nach einem Alias in der Datei $ORACLE_HOME/network/admin/<dbname>/tnsnames.ora suchen.

   Das folgende Beispiel zeigt einen Eintrag für eine Containerdatenbank namens 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. Prüfen Sie, ob Sie mit dem Alias eine Verbindung zu der Datenbank herstellen können. Beispiel: Geben Sie als sysdba den folgenden Befehl an:

   sqlplus sys@db12c

Mögliche Ursache: Die Kennwörter der Oracle Database-Benutzer sys oder system für die Datenbank und das TDE-Wallet sind möglicherweise nicht identisch. So vergleichen Sie die Kennwörter:

1. Melden Sie sich als Benutzer sys bei der Datenbank an, und prüfen Sie den TDE-Status in V$ENCRYPTION_WALLET.
2. Stellen sie als system-Benutzer eine Verbindung zur Datenbank her, und prüfen Sie den TDE-Status in V$ENCRYPTION_WALLET.
3. Aktualisieren Sie die entsprechenden Kennwörter so, dass sie übereinstimmen. Melden Sie sich als opc-Benutzer beim Systemhost an, und führen Sie die folgenden Befehle durch:
   1. So ändern Sie das SYS-Kennwort:

      sudo dbaascli database changepassword --dbname <database_name>

   2. So ändern Sie das TDE- Wallet-Kennwort:

      sudo dbaascli tde changepassword --dbname <database_name>

Mögliche Ursachen und Lösungen für TDE-Wallet-Probleme finden Sie unter TDE-Wallet- und Backupfehler.

Wenn die Befehle für Switchover, Failover und Neuinstanziierung ausgeführt werden, können mehrere Fehlermeldungen auftreten. Diese Fehlermeldungen finden Sie in der Oracle Database-Dokumentation.

1. Stellen Sie als Benutzer oracle mit dgmgrl eine Verbindung zur Primär- oder Standbydatenbank her, und prüfen Sie die Konfiguration und die Datenbank:

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

2. Schlagen Sie die entsprechende Fehlermeldung in der Oracle Database-Dokumentation nach. Beispiel:
   • ORA-16766: Redo Apply ist gestoppt.
   • ORA-16853: Apply Lag hat den angegebenen Schwellenwert überschritten.
   • ORA-16664: Ergebnis kann nicht von einem Member empfangen werden (Standbydatenbank).
   • ORA-12541: TNS: Kein Listener (Primärdatenbank)

Ursache und Lösung zu den jeweiligen Fehlern finden Sie unter Datenbankfehlermeldungen.

DBAASCLI-Logs