Fehlerbehebung bei Oracle Exadata Database Service auf Exascale-Infrastruktursystemen

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 bei der Fehlersuche:

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-Duplikats 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 bei der Fehlersuche:

1. Prüfen Sie als BS-Benutzer "oracle", ob ein Oracle Net-Alias für die Containerdatenbank (CDB) vorhanden ist. Suchen Sie nach einem Alias in der Datei $ORACLE_HOME/network/admin/<dbname>/tnsnames.ora.

   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 ein:

   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. Stellen Sie als Benutzer sys eine Verbindung zu der Datenbank her, und prüfen Sie den TDE-Status in

   V$ENCRYPTION_WALLET

   .
2. Stellen Sie als Benutzer system eine Verbindung zu der 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 Benutzer opc beim Systemhost an, und führen Sie die folgenden Befehle aus:
   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>

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.

Notiz

Oracle empfiehlt die Verwendung der Data Guard-Broker-Befehlszeilenschnittstelle (dgmgrl), um die Konfigurationen zu validieren.

1. Stellen Sie als Oracle-Benutzer 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)

DBAASCLI-Logs