Oracle Cloud Infrastructure-Dokumentation

Fehlerbehebung bei Oracle Exadata Database Service on Cloud@Customer-Systemen

In diesen Themen werden einige allgemeine Probleme und ihre Behebung behandelt.

Übergeordnetes Thema: Referenzdokumentation zu Oracle Exadata Database Service on Cloud@Customer

Patching-Fehler auf Oracle Exadata Database Service on Cloud@Customer-Systemen

Bei Patching-Operationen können aus verschiedenen Gründen Fehler auftreten. In der Regel besteht der Grund für einen nicht erfolgreichen Vorgang darin, dass ein Datenbankknoten heruntergefahren ist, nicht ausreichend Speicherplatz im Dateisystem vorhanden ist oder die virtuelle Maschine nicht auf den Objektspeicher zugreifen kann.

  • Problem bestimmen
    In der Konsole können Sie einen nicht erfolgreichen Patching-Vorgang identifizieren, indem Sie die Patchhistorie eines Oracle Exadata Database Service on Cloud@Customer-Systems oder einer einzelnen Datenbank anzeigen.
  • Fehlerbehebung und Diagnose
    Hier finden Sie Informationen zum Diagnostizieren der häufigsten Probleme, die während des Patchings einer der Oracle Exadata Database Service on Cloud@Customer-Komponenten auftreten können.

Übergeordnetes Thema: Fehlerbehebung bei Oracle Exadata Database Service on Cloud@Customer-Systemen

Problem bestimmen

In der Konsole können Sie einen nicht erfolgreichen Patching-Vorgang identifizieren, indem Sie die Patchhistorie eines Oracle Exadata Database Service on Cloud@Customer-Systems oder einer einzelnen Datenbank anzeigen.

Ein nicht erfolgreich angewendeter Patch wird mit dem Status Nicht erfolgreich und einer kurzen Beschreibung des Fehlers angezeigt. 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.

Fehlerbehebung und Diagnose

Diagnostizieren Sie die häufigsten Probleme, die während des Patchings einer der Oracle Exadata Database Service on Cloud@Customer-Komponenten auftreten können

Übergeordnetes Thema: Patchfehler auf Oracle Exadata Database Service on Cloud@Customer-Systemen

VM-Probleme bei Datenbankservern

Eine oder mehrere der folgenden Bedingungen auf der Datenbankserver-VM können dazu führen, dass Patching-Vorgänge nicht erfolgreich ausgeführt werden.

Verbindungsprobleme bei der Datenbankserver-VMs

Cloud-Tooling erfordert die richtige Netzwerk- und Konnektivitätskonfiguration zwischen den virtuellen Maschinen eines bestimmten VM-Clusters. Wenn die Konfiguration nicht richtig festgelegt ist, kann dies zu Fehlern bei allen Vorgängen führen, die eine knotenübergreifende Verarbeitung erfordern. Beispiel: Die erforderlichen Dateien zum Einspielen eines bestimmten Patches können nicht heruntergeladen werden.

In diesem Fall haben Sie folgende Möglichkeiten:

  • Prüfen Sie, ob die DNS-Konfiguration korrekt ist, damit die relevanten Adressen der virtuellen Maschinen innerhalb des VM-Clusters aufgelöst werden können.
  • Weitere Informationen finden Sie in den relevanten Cloud-Tooling-Logs (siehe Abschnitt Weitere Unterstützung), oder wenden Sie sich an Oracle Support.

Übergeordnetes Thema: Fehlerbehebung und Diagnose

Probleme mit Oracle Grid Infrastructure

Eine oder mehrere der folgenden Bedingungen auf Oracle Grid Infrastructure können verhindern, dass Patching-Vorgänge erfolgreich ausgeführt werden.

Oracle Grid Infrastructure ist heruntergefahren

Mit Oracle Clusterware können Server miteinander kommunizieren und so zusammen als eine Einheit funktionieren. Das Clustersoftwareprogramm muss auf dem VM-Cluster hochgefahren und gestartet sein, damit Patching-Operationen abgeschlossen werden können. Gelegentlich müssen Sie Oracle Clusterware neu starten, um einen Patching-Fehler zu beheben.

Prüfen Sie in diesen Fällen den Status von Oracle Grid Infrastructure wie folgt:
./crsctl check cluster
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
Wenn Oracle Grid Infrastructure heruntergefahren ist, führen Sie mit den folgenden Befehlen einen Neustart aus:
crsctl start cluster -all
crsctl check cluster

Übergeordnetes Thema: Fehlerbehebung und Diagnose

Probleme mit Oracle-Datenbanken

Ein falscher Datenbankstatus kann zu Patching-Fehlern führen.

Oracle-Datenbank ist heruntergefahren

Die Datenbank muss aktiv sein und auf allen aktiven Knoten ausgeführt werden, damit die Patching-Vorgänge im gesamten Cluster erfolgreich abgeschlossen werden können.

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 Status der Datenbankinstanz zurück. Der Instanzstatus muss Offen lauten, damit der Patchvorgang 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

Übergeordnetes Thema: Fehlerbehebung und Diagnose

Weitere Unterstützung

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.

Verwandte Themen

Übergeordnetes Thema: Fehlerbehebung bei Oracle Exadata Database Service on Cloud@Customer-Systemen

Cloud-Tooling-Logs erfassen

Verwenden Sie die relevanten Logdateien, die Oracle Support bei der weiteren Untersuchung und Behebung eines gegebenen Problems unterstützen könnten.

DBAASCLI-Logs

/var/opt/oracle/log/dbaascli
  • dbaascli.log

Übergeordnetes Thema: Weitere Unterstützung

Oracle-Diagnosedaten erfassen

Um die relevanten Oracle-Diagnoseinformationen und -logs zu erfassen, führen Sie den Befehl dbaascli diag collect aus.

Weitere Informationen zur Verwendung dieses Utilitys finden Sie unter DBAAS-Tooling: Mit dbaascli Cloud-Tooling-Logs erfassen und Cloud-Tooling-Health Check durchführen.

VM-Betriebssystemupdate hängt beim Drain der Datenbankverbindung

Beschreibung: Dies ist ein vorübergehendes Problem. Während der Aktualisierung des Betriebssystems einer virtuellen Maschine mit 19c Grid Infrastructure und aktiven Datenbanken wartet dbnodeupdate.sh auf RHPhelper, um ein Drain der Verbindungen auszuführen. Der Vorgang wird aufgrund eines bekannten Bugs DBNODEUPDATE.SH HANGS IN RHPHELPER TO DRAIN SESSIONS AND SHUTDOWN INSTANCE nicht fortgesetzt.

Symptome: Aufgrund dieses Bugs sind zwei Ergebnisse möglich:
  1. VM-Betriebssystemupdate hängt in rhphelper
    • Automatisierung wird blockiert
    • Drain erfolgt für einige oder keine der Datenbankverbindungen, und einige oder alle Datenbankinstanzen werden weiterhin ausgeführt
  2. VM-Betriebssystemupdate führt kein Drain von Datenbankverbindungen aus, da rhphelper abgestürzt ist
    • Automatisierung wird nicht blockiert
    • Drain von einigen oder keinen der Datenbankverbindungen wird abgeschlossen

/var/log/cellos/dbnodeupdate.trc zeigt als letzte Zeile Folgendes an: 

(ACTION:) Executing RHPhelper to drain sessions and shutdown instances. 
(trace:/u01/app/grid/crsdata/scaqak04dv0201/rhp//executeRHPDrain.150721125206.trc)
Maßnahme:
  1. Führen Sie ein Upgrade von Grid Infrastructure auf Version 19.11 oder höher durch.

    (ODER)

    Deaktivieren Sie rhphelper vor der Aktualisierung, und aktivieren Sie es danach wieder.

    Deaktivieren, bevor die Aktualisierung gestartet wird:
    /u01/app/19.0.0.0/grid/srvm/admin/rhphelper /u01/app/19.0.0.0/grid 19.10.0.0.0 -setDrainAttributes ENABLE=false
    Nach Abschluss der Aktualisierung wieder aktivieren:
    /u01/app/19.0.0.0/grid/srvm/admin/rhphelper /u01/app/19.0.0.0/grid oracle-home-current-version -setDrainAttributes ENABLE=true

    Wenn Sie rhphelper deaktivieren, erfolgt kein Draining von Datenbankverbindungen, bevor Datenbankservices und -instanzen auf einem Knoten vor Aktualisierung des Betriebssystems heruntergefahren werden.

  2. Wenn Sie RHPhelper nicht deaktiviert haben und das Upgrade nicht fortschreitet und blockiert wird, wird beobachtet, dass das Draining von Services lange dauert:
    1. Prüfen Sie die Tracedatei /var/log/cellos/dbnodeupdate.trc, die einen Abschnitt wie den Folgenden enthält:
      (ACTION:) Executing RHPhelper to drain sessions and shutdown instances. 
(trace: /u01/app/grid/crsdata/<nodename>/rhp//executeRHPDrain.150721125206.trc)
    2. Öffnen Sie die Tracedatei /var/log/cellos/dbnodeupdate.trc.
      Wenn rhphelper nicht erfolgreich ausgeführt wird, enthält die Tracedatei folgende Meldung:
      "Failed execution of RHPhelper"
      Wenn rhphelper hängt, enthält die Tracedatei folgende Meldung:
      (ACTION:) Executing RHPhelper to drain sessions and shutdown instances.
    3. Identifizieren Sie die rhphelper-Prozesse, die auf Betriebssystemebene ausgeführt werden, und brechen Sie sie ab.

      Es gibt zwei Befehle, deren Namen die Zeichenfolge "rhphelper" enthalten: eine Bash-Shell und das zugrunde liegende Java-Programm, das rhphelper tatsächlich ausführt.

      rhphelper wird als root ausgeführt und muss daher als root (sudo von opc) abgebrochen werden.

      Beispiel:
      [opc@<HOST> ~] pgrep –lf rhphelper
191032 rhphelper
191038 java

      [opc@<HOST> ~] sudo kill –KILL 191032 191038
    4. Prüfen Sie, ob die Datei dbnodeupdate.trc fortschreitet und der Grid Infrastructure-Stack auf dem Knoten heruntergefahren ist.

    Weitere Informationen zu RHPhelper finden Sie unter Using RHPhelper to Minimize Downtime During Planned Maintenance on Exadata (Dok.-ID 2385790.1).

Hinzufügen einer VM zu einem VM-Cluster nicht erfolgreich

Beschreibung: Beim Hinzufügen einer VM zu einem VM-Cluster tritt möglicherweise das folgende Problem auf:
[FATAL] [INS-32156] Installer has detected that there are non-readable files in oracle home.
CAUSE: Following files are non-readable, due to insufficient permission oracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trc
ACTION: Ensure the above files are readable by grid.

Ursache: Das Installationsprogramm hat eine nicht lesbare Tracedatei oracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trc vorgefunden, die vom Autonomous Health Framework (AHF) im Oracle Home erstellt wurde und einen Fehler beim Hinzufügen einer Cluster-VM verursacht.

AHF wurde ausgeführt, als root eine trc-Datei mit Eigentümer root erstellte, die der grid-Benutzer nicht lesen kann.

Aktion: Stellen Sie sicher, dass die AHF-Tracedateien vom Benutzer grid gelesen werden können, bevor Sie VMs einem VM-Cluster hinzufügen. Um das Berechtigungsproblem zu beheben, führen Sie die folgenden Befehle als root auf allen vorhandenen VMs im VM-Cluster aus:
chown grid:oinstall /u01/app/19.0.0.0/grid/srvm/admin/logging.properties
chown -R grid:oinstall /u01/app/19.0.0.0/grid/oracle.ahf*
chown -R grid:oinstall /u01/app/grid/oracle.ahf*

Knotenliste wird für Datenbanken mit aktiviertem Data Guard nicht aktualisiert

Beschreibung: Das Hinzufügen einer VM zu einem VM-Cluster wird erfolgreich abgeschlossen. Bei Datenbanken mit aktiviertem Data Guard wird die neue VM jedoch nicht der Knotenliste in der Datei /var/opt/oracle/creg/<db>.ini hinzugefügt.

Ursache: Datenbanken mit aktiviertem Data Guard werden nicht auf die neu hinzugefügte VM erweitert. Daher wird die <db>.ini-Datei auch nicht aktualisiert, weil die Datenbankinstanz in der neuen VM nicht konfiguriert ist.

Aktion: Informationen zum Hinzufügen einer Instanz zu Primär- und Standbydatenbanken sowie zu den neuen VMs (Nicht-Data Guard) und zum Entfernen einer Instanz aus einer Data Guard-Umgebung finden Sie im My Oracle Support-Hinweis 2811352.1.

CPU-Offlineskalierung nicht erfolgreich

Beschreibung: Die Offlineskalierung der CPU ist nicht erfolgreich. Folgender Fehler wird gemeldet:
** CPU Scale Update **An error occurred during module execution. Please refer to the log file for more information

Ursache: Nach dem Provisioning eines VM-Clusters wird die Datei /var/opt/oracle/cprops/cprops.ini, die automatisch von Database-as-a-Service (DBaaS) generiert wird, nicht mit den Parametern common_dcs_agent_bindHost und common_dcs_agent_port aktualisiert. Dadurch verläuft die CPU-Offlineskalierung nicht erfolgreich.

Aktion: Fügen Sie als Benutzer root die folgenden Einträge manuell in die Datei /var/opt/oracle/cprops/cprops.ini ein.
common_dcs_agent_bindHost=<IP_Address>
common_dcs_agent_port=7070
Hinweis

Der Wert common_dcs_agent_port lautet immer 7070.
Führen Sie den folgenden Befehl aus, um die IP-Adresse abzurufen:
netstat -tunlp | grep 7070
Beispiel:
netstat -tunlp | grep 7070
tcp 0 0 <IP address 1>:7070 0.0.0.0:* LISTEN 42092/java
tcp 0 0 <IP address 2>:7070 0.0.0.0:* LISTEN 42092/java

Sie können eine der beiden IP-Adressen <IP address 1> oder <IP address 2> für den Parameter common_dcs_agent_bindHost angeben.

Standbydatenbank kann nach dem Switchover im Oracle Database 11g Oracle Data Guard-Setup nicht neu gestartet werden

Beschreibung: Nach dem Switchover bleibt die neue Standbydatenbank (alte Primärdatenbank) heruntergefahren und kann nicht neu gestartet werden.

Aktion: Führen Sie nach dem Switchover die folgenden Schritte aus:

  1. Starten Sie die Standbydatenbank mit dem Befehl srvctl start database -db <standby dbname> neu.
  2. Laden Sie den Listener als Benutzer grid auf allen Primär- und Standbyclusterknoten neu.
    • Um den Listener mit High Availability neu zu laden, laden Sie den Patch 25075940 herunter, und spielen Sie ihn in das Grid Home ein. Führen Sie dann lsnrctl reload -with_ha aus.
    • Um den Listener neu zu laden, führen Sie lsrnctl reload aus.

Prüfen Sie nach dem erneuten Laden des Listeners mit dem Befehl lsnrctl status, ob die <dbname>_DGMGRL-Services in den Listener geladen werden.

So laden Sie Patch 25075940 herunter:

  1. Melden Sie sich bei My Oracle Support an.
  2. Klicken Sie auf Patches und Updates.
  3. Wählen Sie Bugnummer aus der Dropdown-Liste Nummer/Name oder Bugnummer (Einfach) aus.
  4. Geben Sie die Bugnummer 34741066 ein, und klicken Sie dann auf Suchen.
  5. Klicken Sie in den Suchergebnissen auf den Namen des neuesten Patches.

    Sie werden zur Seite Patch 34741066: LSNRCTL RELOAD -WITH_HA FAILED TO READ THE STATIC ENTRY IN LISTENER.ORA umgeleitet.

  6. Klicken Sie auf Herunterladen.

Die Verwendung eines benutzerdefinierten SCAN-Listener-Ports mit Data Guard im Disaster-Recovery-Netzwerk führt zu Verifizierungsfehlern bei der Data Guard-Verknüpfung

Beschreibung: Wenn der SCAN-Listener-Port für das Clientnetzwerk und das Disaster Recovery-Netzwerk (DR-Netzwerk) unterschiedlich ist, verläuft die Data Guard-(DG-)Konfiguration während der Verifizierungsphase der Create Data Guard-Verknüpfung nicht erfolgreich.

Aktion: Verwenden Sie dieselben SCAN-Listener-Ports (oder Standardport) in allen Netzwerken. Um den Listener-Port zu korrigieren, nachdem das Cluster konfiguriert wurde, führen Sie den Befehl GI home/bin/srvctl modify listener -listener listener_name -endpoints endpoints aus. Weitere Informationen finden Sie im srvctl modify listener im Oracle Real Application Clusters Administration and Deployment Guide.

PDB-Erstellung nicht erfolgreich, nachdem Datenbank in ein neues DB-Home verschoben wurde (23ai)

Beschreibung: Nach dem Umspeichern einer Datenbank in ein anderes DB-Home kann keine neue integrierbare Datenbank (PDB) erstellt werden. Der PDB-Service kann nicht gestartet werden, was zu folgendem Fehler führt:
[FATAL] [DBAAS-60022] Command '/u02/app/oracle/product/23.0.0.0/dbhome_3/bin/srvctl 'start' 'service' '-db' 'db23ano' '-service' 'db23ano_PDBJULY242.paas.oracle.com'' has failed on nodes [localnode].

Aktion: Wenn die Grid Infrastructure-Version 23.4.0.24.05 ist, führen Sie ein Upgrade auf Version 23.5.0.24.07 aus, um dieses Problem zu beheben.

Intermittierender Fehler bei der PDB-Erstellung, wenn mehrere PDBs parallel erstellt werden

Beschreibung: Die PDB kann für eine Teilmenge von PDBs nicht erstellt werden, wenn mehrere PDBs parallel erstellt werden.

Ursache: Die PDB-Erstellung kann den folgenden Fehler gelegentlich bemerken.
ORA-03113: end-of-file on communication channel

Aktion: Wiederholen Sie die nicht erfolgreiche PDB-Erstellung.