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:

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:

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 des Typs CRITICAL wird erstellt, wenn 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 mit CSS-Voting-Disks und Member-Kill-Eskalationen. CSSDAGENT- oder CSSDMONITOR-Entfernungen können auf ein BS-Scheduler-Problem oder einen hängenden Thread innerhalb des CSS-Daemons zurückzuführen 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:

Blockbeschädigungen können auch in Interblockbeschädigungen und In-Blockbeschädigungen unterteilt werden:

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

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: RMAN kann 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:

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

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:

Für vom Kunden verwaltete Backups mit RMAN:

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 DB-System 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.