Korrektur für Ereignisse des Datenbankservice

In diesem Artikel werden die erforderlichen Fixes für Probleme beschrieben, die bei der Verwendung von Datenbankserviceereignissen auftreten.

Die folgenden Korrekturen sind verfügbar:

Verwandte Themen

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Ereignisname

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Ereignisbeschreibung

Dieses Ereignis wird gemeldet, wenn der freie Speicherplatz des VM-Gastdateisystems gemäß dem Befehl df(1) des Betriebssystems für die folgenden Dateisysteme unter 10% liegt:

  • /
  • /u01
  • /u02
  • /var
  • /tmp

Problembeschreibung

Der freie Speicherplatz von mindestens einem VM-Gastdateisystem liegt unter 10%.

Risiko

Nicht genügend freier Speicherplatz im VM-Gastdateisystem kann zu Fehlern bei der Zuweisung von Datenträgerspeicherplatz führen. Diese können wiederum weitreichende Fehler in der Oracle-Software (Datenbank, Clusterware, Cloud-Tooling) zur Folge haben.

Aktion/Reparatur

Oracle Cloud und der DCS-Agent werden automatisch ausgeführt, um alte vom Cloud-Tooling erstellte Logdateien und Tracedateien zu löschen und Speicherplatz im Dateisystem freizugeben.

Wenn die Utilitys zur automatischen Speicherplatzfreigabe im Dateisystem nicht genügend alte Dateien löschen können, um dieses Ereignis zu beheben, führen Sie die folgenden Aktionen aus:

  1. Entfernen Sie nicht erforderliche Dateien und/oder Verzeichnisse, die manuell oder von vom Kunden installierten Anwendungen oder Utilitys erstellt wurden. Dateien, die von der vom Kunden installierten Software erstellt wurden, fallen nicht in den Anwendungsbereich der automatischen Utilitys von Oracle für die Speicherplatzfreigabe in Dateisystemen. Der folgende Betriebssystembefehl, der als Benutzer root ausgeführt wird, eignet sich zum Ermitteln von Verzeichnissen, die übermäßig viel Speicherplatz belegen: 
    sudo du -hx <file system mount point> | sort -hr

    Entfernen Sie nur Dateien oder Verzeichnisse, von denen Sie wissen, dass sie sicher entfernt werden können.

  2. Legen Sie die Policy für das automatische Löschen mit Cloud-Tooling fest. Weitere Informationen finden Sie unter Autologcleanpolicy-Befehle.
  3. Öffnen Sie eine Serviceanfrage, um zusätzliche Anleitungen zur Reduzierung der Speicherplatzbelegung im Dateisystem zu erhalten.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Ereignisname

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Ereignisbeschreibung

Ein Ereignis des Typs CRITICAL wird erstellt, wenn der Cluster Ready Service (CRS) als heruntergefahren erkannt wird.

Problembeschreibung

Der Cluster Ready Stack befindet sich in einem Offlinestatus oder war nicht erfolgreich.

Risiko

Wenn der CRS auf einem Knoten offline ist, kann der Knoten keine Datenbankservices für die Anwendung bereitstellen.

Aktion/Reparatur

  1. Prüfen Sie, ob CRS vom Administrator als Teil eines geplanten Wartungsereignisses oder einer vertikalen Skalierung des lokalen Speichers gestoppt wurde
    1. Die folgenden Patching-Ereignisse stoppen CRS
      1. GRID-Aktualisierung
      2. Aktualisierung des Gasts
      3. Aktualisierung des Hosts
  2. Wenn CRS unerwartet gestoppt wurde, kann der aktuelle Status mit dem Befehl crsctl check crs geprüft werden.
    1. Wenn der Knoten nicht antwortet, wird der VM-Knoten möglicherweise neu gestartet. Warten Sie, bis der Neustart des Knotens abgeschlossen ist. CRS wird normalerweise über den Prozess init gestartet.
  3. Wenn CRS noch heruntergefahren ist, prüfen Sie die Fehlerursache im alert.log in /u01/app/grid/diag/crs/<node_name>/crs/trace. Prüfen Sie die Logeinträge, die dem Datum/der Uhrzeit des Ausfallereignisses entsprechen, und setzen Sie mögliche Korrekturen um.
  4. Starten Sie CRS mit dem Befehl crsctl start crs neu.
  5. Bei einem erfolgreichen Neustart von CRS wird das Behebungsereignis generiert: AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Löschereignis

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Löschereignisbeschreibung

Ein INFORMATION-Ereignis wird erstellt, sobald der CRS erfolgreich gestartet wurde.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Ereignisname

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Ereignisbeschreibung

Ein Ereignis vom Typ CRITICAL wird erstellt, wenn der Cluster Ready Service (CRS) einen Knoten aus dem Cluster entfernt. Die CRS-Datei alert.log wird auf den Fehler CRS-1632 geparst, der angibt, dass ein Knoten aus dem Cluster entfernt wird.

Problembeschreibung

Oracle Clusterware ist so konzipiert, dass eine Knotenentfernung durchgeführt wird, indem mindestens ein Knoten aus dem Cluster entfernt wird, wenn ein kritisches Problem erkannt wird. Ein kritisches Problem könnte sein, dass ein Knoten nicht über einen Netzwerk-Heartbeat antwortet, dass ein Knoten nicht über einen Datenträger-Heartbeat antwortet, ein hängender oder stark beeinträchtigter Rechner oder ein hängender ocssd.bin-Prozess. Der Zweck dieser Knotenentfernung besteht darin, den Gesamtzustand des Clusters aufrechtzuerhalten, indem fehlerhafte Mitglieder entfernt werden.

Risiko

Während des Neustarts des entfernten Knotens kann der Knoten keine Datenbankservices für die Anwendung bereitstellen.

Aktion/Reparatur

Eine CRS-Knotenentfernung könnte durch OCSSD- (auch CSS-Daemon), CSSDAGENT- oder CSSDMONITOR-Prozesse verursacht werden. Dazu müssen Sie bestimmen, welcher Prozess für die Knotenentfernung verantwortlich war, und die relevanten Logdateien prüfen. Häufige Ursachen für die OCSSD-Entfernung sind Netzwerkausfälle/-latenzen, I/O-Probleme bei CSS-Voting Disks, eine Mitgliederabbrucheskalation. CSSDAGENT- oder CSSDMONITOR-Entfernungen können ein BS-Scheduler-Problem oder ein hängender Thread innerhalb des CSS-Daemons sein. Zu den zu prüfenden Logdateien gehören Clusterware-Alert-Log, CSSDAGENT-Log, CSSDMONITOR-Log, OCSSD-Log, Lastgasp-Log, /var/log/messages, CHM/OS Watcher-Daten und opatch lsinventory-Details.

Weitere Informationen zum gemeinsamen Erfassen von Dateien finden Sie unter Autonomous Health Framework (AHF) Trace File Analyzer (TFA) und ORAchk/EXAchk. Weitere Informationen zur Fehlerbehebung bei der CRS-Knotenentfernung finden Sie unter Fehlerbehebung bei Clusterware-Knotenentfernungen (Neustarts).

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Ereignisname

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Ereignisbeschreibung

Ein DOWN-Ereignis wird erstellt, wenn ein SCAN-Listener heruntergefahren wird. Das Ereignis hat den Typ INFORMATION, wenn ein SCAN-Listener aufgrund einer Benutzeraktion heruntergefahren wird, z.B. mit den Befehlen für Server Control Utility (srvctl) oder Listener Control (lsnrctl) oder durch eine Oracle Cloud-Wartungsaktion, die diese Befehle verwendet, etwa ein Grid Infrastructure-Softwareupdate. Das Ereignis hat den Typ CRITICAL, wenn ein SCAN-Listener unerwartet heruntergefahren wird. Ein entsprechendes DOWN_CLEARED-Ereignis wird erstellt, wenn ein SCAN-Listener gestartet wird.

Es gibt drei SCAN-Listener pro Cluster mit dem Namen LISTENER_SCAN[1,2,3].

Problembeschreibung

Ein SCAN-Listener ist heruntergefahren und kann keine Anwendungsverbindungen akzeptieren.

Risiko

Wenn alle SCAN-Listener heruntergefahren sind, können keine Anwendungsverbindungen zur Datenbank über den SCAN-Listener hergestellt werden.

Aktion/Reparatur

Starten Sie den SCAN-Listener, um das Ereignis DOWN_CLEARED zu empfangen.

DOWN-Ereignis des Typs INFORMATION

  1. Wenn das Ereignis durch eine Oracle Cloud-Wartungsaktion wie das Ausführen eines Grid Infrastructure-Softwareupdates verursacht wurde, ist keine Aktion erforderlich. Der betroffene SCAN-Listener führt automatisch einen Failover auf eine verfügbare Instanz durch.
  2. Wenn das Ereignis durch eine Benutzeraktion verursacht wurde, starten Sie den SCAN-Listener bei der nächsten Gelegenheit.

DOWN-Ereignis des Typs CRITICAL

  1. Prüfen Sie den SCAN-Status, und starten Sie den SCAN-Listener neu
    • Melden Sie sich als Benutzer opc bei der VM an, und wechseln Sie mit sudo zum Benutzer grid: 
      [opc@vm ~] sudo su - grid
    • Prüfen Sie den SCAN-Listener-Status auf einem beliebigen Knoten:
      [grid@vm ~] srvctl status scan_listener
    • Starten Sie den SCAN-Listener.
      [grid@vm ~] srvctl start scan_listener
    • Prüfen Sie den SCAN-Listener-Status erneut auf einem beliebigen Knoten: Wenn scan_listener immer noch heruntergefahren ist, untersuchen Sie die Ursache des SCAN-Listener-Fehlers:
      1. Erfassen Sie die CRS- und BS-Logs 30 Minuten davor und 10 Minuten danach für den im Log angegebenen <hostName>. Beachten Sie, dass die Zeit in der Ereignis-Payload immer in UTC angegeben wird: Passen Sie die Zeit für die tfactl-Erfassung an die Zeitzone des VM-Clusters an. 
        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
    –from "<eventTime adjusted for local vm timezone> - 30 minute " 
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"
      2. SCAN-Listener-Probleme werden protokolliert:
        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Ereignisname

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Ereignisbeschreibung

Ein DOWN-Ereignis wird erstellt, wenn ein Client-Listener heruntergefahren wird. Das Ereignis hat den Typ INFORMATION, wenn ein Client-Listener aufgrund einer Benutzeraktion heruntergefahren wird, z.B. mit den Befehlen für Server Control Utility (srvctl) oder Listener Control (lsnrctl) oder durch eine Oracle Cloud-Wartungsaktion, die diese Befehle verwendet, etwa ein Grid Infrastructure-Softwareupdate. Das Ereignis hat den Typ CRITICAL, wenn ein Client-Listener unerwartet heruntergefahren wird. Ein entsprechendes DOWN_CLEARED-Ereignis wird erstellt, wenn ein Client-Listener gestartet wird.

Pro Knoten ist ein Client-Listener vorhanden, der jeweils als LISTENER bezeichnet wird.

Problembeschreibung

Ein Client-Listener ist heruntergefahren und kann keine Anwendungsverbindungen akzeptieren.

Risiko

Wenn der Client-Listener des Knotens heruntergefahren ist, können die Datenbankinstanzen auf dem Knoten keine Services für die Anwendung bereitstellen.

Wenn der Client-Listener auf allen Knoten heruntergefahren ist, können Anwendungen, die mit SCAN oder VIP eine Verbindung zu einer Datenbank herstellen, nicht erfolgreich ausgeführt werden.

Aktion/Reparatur

Starten Sie den Client-Listener, um das Ereignis DOWN_CLEARED zu empfangen.

DOWN-Ereignis des Typs INFORMATION

  1. Wenn das Ereignis durch eine Oracle Cloud-Wartungsaktion wie das Ausführen eines Grid Infrastructure-Softwareupdates verursacht wurde, ist keine Aktion erforderlich. Der betroffene Client-Listener wird automatisch neu gestartet, wenn die Wartung, die sich auf die Grid-Instanz auswirkt, abgeschlossen ist.
  2. Wenn das Ereignis durch eine Benutzeraktion verursacht wurde, starten Sie den Client-Listener bei der nächsten Gelegenheit.

DOWN-Ereignis des Typs CRITICAL

  1. Prüfen Sie den Client-Listener-Status, und starten Sie den Client-Listener dann neu.
    • Melden Sie sich als Benutzer opc bei der VM an, und wechseln Sie mit sudo zum Benutzer grid:
      [opc@vm ~] sudo su - grid
    • Prüfen Sie den Client-Listener-Status auf einem beliebigen Knoten:
      [grid@vm ~] srvctl status listener
    • Starten Sie den Client-Listener:
      [grid@vm ~] srvctl start listener
    • Prüfen Sie den Client-Listener-Status erneut auf einem beliebigen Knoten: Wenn der Client-Listener noch heruntergefahren ist, untersuchen Sie die Ursache des Client-Listener-Fehlers:
      1. Erfassen Sie mit tfactl die CRS- und BS-Logs 30 Minuten davor und 10 Minuten danach für den im Log angegebenen hostName. Beachten Sie, dass die Zeit in der Ereignis-Payload immer in UTC angegeben wird: Passen Sie die Zeit für die tfactl-Erfassung an die Zeitzone des VM-Clusters an.
        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
    –from "<eventTime adjusted for local vm timezone> - 30 minute " 
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"
      2. Prüfen Sie das Listener-Log unter:
        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Ereignisname

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Ereignisbeschreibung

Ein DOWN-Ereignis wird erstellt, wenn eine Datenbankinstanz heruntergefahren wird. Das Ereignis hat den Typ INFORMATION, wenn eine Datenbankinstanz aufgrund einer Benutzeraktion heruntergefahren wird, z.B. mit den Befehlen für SQL*Plus (sqlplus) oder Server Control Utility (srvctl) oder durch eine Oracle Cloud-Wartungsaktion, die diese Befehle verwendet, etwa ein Softwareupdate für das Datenbank-Home. Das Ereignis hat den Typ CRITICAL, wenn eine Datenbankinstanz unerwartet heruntergefahren wird. Ein entsprechendes DOWN_CLEARED-Ereignis wird erstellt, wenn eine Datenbankinstanz gestartet wird.

Problembeschreibung

Eine Datenbankinstanz wurde heruntergefahren.

Risiko

Eine Datenbankinstanz wurde heruntergefahren. Das kann zu einer verringerten Performance führen, wenn Datenbankinstanzen auf anderen Knoten im Cluster verfügbar sind, oder zu einem kompletten Ausfall, wenn die Datenbankinstanzen auf allen Knoten heruntergefahren sind.

Aktion/Reparatur

Starten Sie die Datenbankinstanz, um das Ereignis DOWN_CLEARED zu empfangen.

DOWN-Ereignis des Typs INFORMATION

  1. Wenn das Ereignis durch eine Oracle Cloud-Wartungsaktion verursacht wurde, wie das Ausführen eines Datenbank-Home-Softwareupdates, ist keine Aktion erforderlich. Die betroffene Datenbankinstanz wird automatisch neu gestartet, wenn die Wartung, die sich auf die Instanz auswirkt, abgeschlossen ist.
  2. Wenn das Ereignis durch eine Benutzeraktion verursacht wurde, starten Sie die betroffene Datenbankinstanz bei der nächsten Gelegenheit.

DOWN-Ereignis des Typs CRITICAL

  1. Prüfen Sie den Datenbankstatus, und starten Sie die heruntergefahrene Datenbankinstanz neu.
    1. Melden Sie sich als Benutzer oracle bei der VM an:
    2. Legen Sie die Umgebung fest:
      [oracle@vm ~] . <dbName>.env
    3. Prüfen Sie den Datenbankstatus:
      [oracle@vm ~] srvctl status database -db <dbName>
    4. Starten Sie die Datenbankinstanz:
      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>
  2. Untersuchen Sie die Ursache des Fehlers bei der Datenbankinstanz.
    1. Prüfen Sie die Trace File Analyzer-(TFA-)Ereignisse für die Datenbank:
      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>
    2. Prüfen Sie das Alertlog der Datenbank unter:
      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Ereignisname

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Ereignisbeschreibung

In der Primär- oder Standbydatenbank wurde eine Datenbankbeschädigung festgestellt. Die Datei alert.log der Datenbank wird auf bestimmte Fehler geparst, die auf physische Blockbeschädigungen, logische Blockbeschädigungen oder logische Blockbeschädigungen durch verlorene Schreibvorgänge hinweisen.

Problembeschreibung

Beschädigungen können zu Anwendungs- oder Datenbankfehlern führen und im schlimmsten Fall zu erheblichen Datenverlusten, wenn sie nicht umgehend behoben werden.

Ein beschädigter Block ist ein Block, der so geändert wurde, dass er nicht mehr den Erwartungen von Oracle Database entspricht. Blockbeschädigungen können als physisch oder logisch kategorisiert werden:

  • Bei einer physischen Blockbeschädigung, die auch als Medienbeschädigung bezeichnet wird, erkennt die Datenbank den Block nicht. Die Prüfsumme ist ungültig, oder der Block enthält nur Nullen. Ein Beispiel für eine komplexere Blockbeschädigung ist, wenn der Blockheader und -footer nicht übereinstimmen.
  • Bei einer logischen Blockbeschädigung ist der Inhalt des Blocks physisch unbeschädigt, und die physischen Blockprüfungen werden erfolgreich abgeschlossen. Der Block kann jedoch logisch inkonsistent sein. Beispiele für logische Blockbeschädigungen sind falsche Blocktypen, falsche Daten oder Redo-Blockfolgenummern, Beschädigung eines Row-Abschnitts oder Indexeintrags oder Data Dictionary-Beschädigungen.

Blockbeschädigungen können auch in Inter- und Intrablockbeschädigungen unterteilt werden:

  • Bei einer Intrablockbeschädigung tritt die Beschädigung im Block selbst auf. Dabei kann es sich um eine physische oder eine logische Blockbeschädigung handeln.
  • Bei einer Interblockbeschädigung tritt die Beschädigung zwischen Blöcken auf. Das kann nur eine logische Blockbeschädigung sein.

Oracle prüft die folgenden Fehler im alert.log:

  • ORA-01578
  • ORA-00752
  • ORA-00753
  • ORA-00600 [3020]
  • ORA-00600 [kdsgrp1]
  • ORA-00600 [kclchkblk_3]
  • ORA-00600 [13013]
  • ORA-00600 [5463]

Risiko

Ein Ausfall durch Datenbeschädigung tritt auf, wenn eine Hardware-, Software -oder Netzwerkkomponente das Lesen oder Schreiben fehlerhafter Daten verursacht. Die Auswirkungen eines Ausfalls durch Datenbeschädigung auf Serviceebene können von einem kleinen Teil der Anwendung oder Datenbank (eventuell nur einem Datenbankblock) bis zu einem großen Teil der Anwendung oder Datenbank reichen (wodurch diese im Wesentlichen unbrauchbar wird). Wenn die Korrekturmaßnahme nicht sofort ergriffen wird, steigt das Risiko potenzieller Ausfallzeiten und Datenverluste.

Aktion/Reparatur

Die Benachrichtigung über aktuelle Ereignisse wird gegenwärtig bei physischen Blockbeschädigungen (ORA-01578), verlorenen Schreibvorgängen (ORA-00752, ORA-00753 und ORA-00600 mit dem ersten Argument 3020) und logischen Beschädigungen (in der Regel ermittelt aus ORA-00600 mit dem ersten Argument kdsgrp1, kdsgrp1, kclchkblk_3, 13013 oder 5463) ausgelöst.

Empfohlene Schritte:

  1. Überprüfen Sie, ob diese Beschädigungen in der Tracedatei alert.log gemeldet wurden. Erstellen Sie eine Serviceanfrage mit dem neuesten EXAchk-Bericht, dem Auszug aus der Tracedatei alert.log, der die durch Beschädigung verursachten Fehler enthält, einer Historie der letzten Anwendungs-, Datenbank- oder Softwareänderungen, sofern vorhanden, sowie allen System-, Clusterware- und Datenbanklogs für den betreffenden Zeitraum. Für alle diese Fälle sollte eine TFA-Erfassung verfügbar sein und an die SA angehängt werden.
  2. Weitere Informationen zu Reparaturempfehlungen finden Sie unter Primärer Hinweis zur Behandlung von Oracle Database-Beschädigungsproblemen.

Bei physischen Beschädigungen oder ORA-1578-Fehlern sind die folgenden Hinweise hilfreich:

Hinweis:

Mit RMAN können Sie einen oder mehrere Datenblöcke wiederherstellen, die physisch beschädigt sind. Auch mit Active Data Guard im Echtzeit-Apply-Modus wäre die automatische Blockreparatur physischer Datenbeschädigungen automatisch erfolgt.

Logische Fehler, die durch verlorene Schreibvorgänge (ORA-00752, ORA-00753 und ORA-00600 mit dem ersten Argument 3020) in der Primär- oder der Standbydatenbank verursacht wurden, werden im Redo-Apply-Prozess der Primär- oder Standbydatenbank erkannt. Die folgenden Hinweise sind hilfreich:

Bei logischen Fehlern (in der Regel ermittelt aus ORA-00600 mit Argumenten von kdsgrp1, kclchkblk_3, 13013 oder 5463)

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Ereignisname

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Ereignisbeschreibung

Ein Ereignis des Typs CRITICAL wird erstellt, wenn eine Containerdatenbank (CDB) das aktive Online-Redo-Log entweder gar nicht oder nicht schnell genug in den Logarchivierungszielen archivieren kann.

Problembeschreibung

Die CDB-RAC-Instanz kann vorübergehend oder dauerhaft blockiert werden, weil der Log Writer (LGWR) die Logpuffer nicht in ein Online-Redo-Log schreiben kann. Dies liegt daran, dass alle Onlinelogs archiviert werden müssen. Sobald der Archiver (ARC) mindestens ein Online-Redo-Log archivieren kann, kann LGWR die Logpuffer wieder in Online-Redo-Logdateien schreiben, und die Auswirkungen auf Anwendungen werden verringert.

Risiko

Wenn der Archivierer vorübergehend nicht mehr reagiert, kann es bei Anwendungen zu einem kurzen Brownout oder Stillstand kommen, wenn versucht wird, Datenbankänderungen festzuschreiben. Wenn der Archivierer nicht wiederhergestellt wird, kann es bei den Anwendungsprozessen zu längeren Verzögerungen bei der Verarbeitung kommen.

Aktion/Reparatur

  • Informationen zum Festlegen der stündlichen Häufigkeit für jeden Thread/jede Instanz finden Sie unter Script To Find Redolog Switch History And Find Archivelog Size For Each Instances In RAC (Doc ID 2373477.1).
    • Wenn ein stündlicher Bucket größer als 12 ist, wird empfohlen, die Größe der Online-Redo-Logs zu ändern. Weitere Informationen zum Ändern der Größe finden Sie unter Punkt 2 weiter unten.
  • Wenn die Datenbank vorübergehend nicht mehr reagiert, kann der Archivierer möglicherweise nicht mit dem generierten Redo Log Schritt halten.
    • Prüfen Sie alert.log, $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log, auf "All online logs need archiving". Mehrere Ereignisse in kurzer Zeit können auf zwei mögliche Lösungen hinweisen.
      1. Wenn die Anzahl der Redo-Loggruppen pro Thread kleiner als 4 ist, sollten Sie weitere Loggruppen hinzufügen, um 4 zu erreichen. Das Verfahren zum Hinzufügen von Redo-Logs finden Sie unter Punkt 1 weiter unten.
      2. Die andere Möglichkeit besteht darin, die Größe der Redo-Logs zu ändern. Weitere Informationen zum Ändern der Größe finden Sie unter Punkt 2 weiter unten.
  • Die Größenrichtlinien für Data Guard und Nicht-Data Guard finden Sie unter Online-Redo-Logs richtig konfigurieren.
  • Fügen Sie für jeden Thread eine Redo-Loggruppe hinzu. Das zusätzliche Redo-Log muss gleich groß sein wie das aktuelle Log.
    1. Verwenden Sie die folgende Abfrage: 
      select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes
    2. Fügen Sie eine neue Gruppe pro Thread mit derselben Größe wie die aktuellen Redo-Logs hinzu.
      alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>
  • Ändern Sie die Größe der Online-Redo-Logs, indem Sie größere Redo-Logs hinzufügen und die aktuellen kleineren Redo-Logs löschen.
    1. Verwenden Sie die folgende Abfrage: 
      select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes
    2. Fügen Sie für jeden derzeit vorhandenen Thread number_of_groups_per_thread dieselbe Anzahl von Redo-Logs hinzu. Der Wert für new_redo_size_in_bytes muss auf Online-Redo-Logs richtig konfigurieren basieren. 
      1. alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>
      2. Die ursprünglichen kleineren Redo-Logs müssen gelöscht werden. Ein Redo-Log kann nur gelöscht werden, wenn es den Status "Inaktiv" hat. Um den Status von Redo-Logs zu bestimmen, führen Sie die folgende SELECT-Anweisung aus. 
        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        Löschen Sie die ursprünglichen kleineren Redo-Logs:

        alter database drop logfile <group#>;
  • Wenn die Datenbank nicht mehr reagiert, sind das primäre Logarchivziel und die Alternative möglicherweise voll.

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Ereignisname

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Ereignisbeschreibung

Ein Ereignis vom Typ CRITICAL wird erstellt, wenn ein Prozess oder eine Session in der Containerdatenbank (CDB) nicht mehr reagiert.

Problembeschreibung

Der Blocker-Resolver hat einen nicht reagierenden Prozess oder einen Block ermittelt und eine ORA-32701-Fehlermeldung generiert. Darüber hinaus kann dieses Ereignis ausgelöst werden, wenn der Diagnoseprozess (DIA0) feststellt, dass ein kritischer Datenbankprozess nicht mehr reagiert.

Risiko

Ein nicht reagierender Prozess oder ein Block kann auf Probleme mit der Ressourcen-, Betriebssystem- oder Anwendungscodierung hinweisen.

Aktion/Reparatur

Untersuchen Sie die Ursache des Sessionblocks.

  • Prüfen Sie die TFA-Ereignisse für die Datenbank auf die folgenden Meldungsmuster, die dem Datum/der Uhrzeit des Ereignisses entsprechen: ORA-32701, "DIA0 Critical Database Process Blocked", oder "DIA0 Critical Database Process As Root". 
    tfactl events -database <dbName> -instance <instanceName>
  • Prüfen Sie alert.log im folgenden Speicherort: 
    $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log
  • Für ORA-32701: Ein überlastetes System kann Verzögerungen bei der Folge verursachen, die als Block interpretiert werden können. Der Blocker-Resolver kann versuchen, den Block zu lösen, indem er den letzten Blocker-Prozess beendet.
  • Für DIA0-Meldungen zum kritischen Datenbankprozess: Prüfen Sie die zugehörigen Diagnosezeilen, die den Prozess und den Grund für den Block angeben.

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Ereignisname

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Ereignisbeschreibung

Ein Ereignis des Typs CRITICAL wird erstellt, wenn ein CDB-Backup mit dem Status FAILED in der Ansicht v$rman_status gemeldet wird.

Problembeschreibung

Ein tägliches inkrementelles Backup der CDB war nicht erfolgreich.

Risiko

Ein Fehler beim Backup kann dessen Verwendbarkeit für Wiederherstellung/Recovery der Datenbank beeinträchtigen. Er kann sich auf das Recovery Point Object (RPO) und das Recovery Time Object (RTO) auswirken.

Aktion/Reparatur

Prüfen Sie die RMAN-Logs, die dem Datum/der Uhrzeit des Ereignisses entsprechen. Beachten Sie, dass sich der Ereigniszeitstempel eventTime auf UTC bezieht, und passen Sie ihn gegebenenfalls an die Zeitzone der VM an.

Für von Oracle verwaltete Backups:

  • Die RMAN-Ausgabe finden Sie unter /opt/oracle/dcs/log/<hostname>/RMAN.
  • Prüfen Sie im Log, ob Fehler aufgetreten sind:
    • Wenn der Fehler auf ein externes Ereignis außerhalb von RMAN zurückzuführen ist, z.B. einen vollen Backupspeicherort oder ein Netzwerkproblem, beheben Sie das externe Problem.
    • Stellen Sie bei anderen RMAN-Skriptfehlern die Diagnoselogs zusammen, und öffnen Sie eine Serviceanfrage.
      dbcli collect-diagnostics -h
      Usage: collect-diagnostics [options]
  Options:
    --components, -c
       Supported components: [all, dcs, crs, acfs, asm, db]
       all -- Collects diagnosis for all supported components [all, dcs, crs, acfs, asm, db]
       dcs -- Collects diagnosis for dcs
       crs -- Collects diagnosis for crs
       acfs -- Collects diagnosis for acfs
       asm -- Collects diagnosis for asm.
       db -- Collects diagnosis for db.
       For multiple parameter values, follow the example as "-c c1 c2"
       Default: [dcs]
    --dbNames, -d
       Comma separated database names. Valid only if 'db' or 'all' specified in Components list.
    --endTime, -et
       End time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
    --help, -h
       get help
    --json, -j
       json output
    --objectstoreuri, -ou
       Pre Authenticated Request URI
    --redaction, -r
       Diagnostic logs redaction. Might take longer time with some components.
    --startTime, -st
    Start time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
  • Wenn das Problem vorübergehend ist oder behoben wurde, erstellen Sie ein neues inkrementelles Backup. Weitere Informationen finden Sie unter Datenbank mit der Konsole sichern.

Für vom Kunden verwaltete Backups mit RMAN:

  • Prüfen Sie die RMAN-Logs für das Backup.

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Ereignisname

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Ereignisbeschreibung

Ein Ereignis des Typs CRITICAL wird erstellt, wenn eine ASM-Datenträgergruppe eine Speicherplatzbelegung von 90% oder höher erreicht. Ein Ereignis des Typs INFORMATION wird erstellt, wenn die Speicherplatzbelegung der ASM-Datenträgergruppe unter 90% fällt.

Problembeschreibung

Die Speicherplatzbelegung der ASM-Datenträgergruppe beträgt mindestens 90%.

Risiko

Unzureichender Speicherplatz in ASM-Datenträgergruppen kann zu einem Fehler beim Erstellen von Datenbanken, Tablespaces und Datendateien, einem Fehler bei der automatischen Datendateierweiterung oder einem Fehler beim ASM-Rebalancing führen.

Aktion/Reparatur

Der belegte Speicherplatz in der ASM-Datenträgergruppe wird durch die Ausführung der folgenden Abfrage bei bestehender Verbindung zur ASM-Instanz bestimmt.

sudo su - grid
sqlplus / as sysasm
select 'ora.'||name||'.dg', total_mb, free_mb, 
    round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;
NAME             TOTAL_MB    FREE_MB   PCT_USED
---------------- ---------- ---------- ----------
ora.DATAC1.dg     75497472    7408292      90.19
ora.RECOC1.dg     18874368   17720208       6.11

Die Kapazität der ASM-Datenträgergruppen kann wie folgt erhöht werden:

  1. Skalieren Sie den VM-Clusterspeicher, um weitere ASM-Datenträgergruppenkapazität hinzuzufügen. Weitere Informationen finden Sie unter Speicher für ein VM-DB-System vertikal skalieren.

Die Speicherplatzbelegung von DATA-Datenträgergruppen wie folgt reduziert werden:

  1. Nicht verwendete Datendateien und temporäre Dateien aus Datenbanken löschen. Weitere Informationen finden Sie unter Datendateien löschen.

Die Speicherplatzbelegung von RECO-Datenträgergruppen kann wie folgt reduziert werden:

  1. Unnötige garantierte Restore Points löschen. Weitere Informationen finden Sie unter Normale und garantierte Restore Points verwenden.
  2. Archivierte Redo-Logs oder Datenbankbackups löschen, die bereits außerhalb des Flash Recovery-Bereichs (FRA) gesichert wurden. Weitere Informationen finden Sie unter Fast Recovery-Bereich verwalten.