Gibt eine Meldung aus, dass das Autonomous Database-ADMIN-Kennwort innerhalb von 30 Tagen abläuft oder bereits abgelaufen ist.

• Wenn das ADMIN-Kennwort innerhalb von 30 Tagen abläuft, erhalten Sie eine Warnung mit dem Datum, ab dem das ADMIN-Kennwort nicht mehr verwendet werden kann.

• Wenn das ADMIN-Kennwort abläuft und nicht mehr verwendet werden kann, meldet Autonomous Database ein Ereignis, das angibt, dass das ADMIN-Benutzerkennwort abgelaufen ist und zurückgesetzt werden muss.

Wenn ein automatischer Failover für Autonomous Database beginnt und die Datenbank nicht verfügbar ist, wird ein AutonomousDatabase-AutomaticFailoverBegin-Ereignis generiert.

Das Ereignis wird nur ausgelöst, wenn Sie Autonomous Data Guard verwenden.

Wenn ein automatisches Failover abgeschlossen ist und die Datenbank jetzt verfügbar ist, wird ein AutonomousDatabase-AutomaticFailoverEnd-Ereignis generiert.

Das Ereignis wird nur ausgelöst, wenn Sie Autonomous Data Guard verwenden.

Die Autonomous Database-Instanz kann nicht geöffnet werden, oder die Services wie High, Low, Medium, tp oder tpurgent sind nicht gestartet oder verfügbar.

Die folgenden Bedingungen lösen DatabaseDownBegin nicht aus:

• Vorgänge, die im Wartungsfenster ausgeführt werden

• Probleme im Zusammenhang mit Load Balancer, Netzwerk oder Backup

• Stoppen der Instanz durch einen Benutzer

Dieses Ereignis wird nicht ausgelöst, wenn Sie Autonomous Data Guard verwenden und die Standby-Datenbank aufgrund einer dieser Bedingungen nicht verfügbar ist.

Die Datenbank wird aus dem Status "Downloads" wiederhergestellt, d.h. die Autonomous Database-Instanz wird nach einem DatabaseDownBegin-Ereignis mit ihren Services geöffnet. DatabaseDownEnd wird nur ausgelöst, wenn zuvor ein DatabaseDownBegin-Ereignis aufgetreten ist.

Die folgenden Bedingungen lösen DatabaseDownEnd nicht aus:

• Vorgänge, die im Wartungsfenster ausgeführt werden

• Starten der Instanz durch einen Benutzer

Wenn Sie Autonomous Data Guard verwenden und die primäre Datenbank ausfällt, wird ein Ereignis DatabaseDownBegin ausgelöst. Beim Failover des Systems auf die Standbydatenbank wird ein Ereignis DatabaseDownEnd ausgelöst.

Auf die Autonomous Database-Instanz werden vom Kunden verwaltete Schlüssel verwendet, und auf die Datenbank kann nicht mehr zugegriffen werden (Status: Nicht zugänglich).

Die folgenden Bedingungen lösen DatabaseInaccessibleBegin aus:

• Oracle Cloud Infrastructure Vault-Master-Verschlüsselungsschlüssel wird gelöscht.

• Oracle Cloud Infrastructure Vault-Master-Verschlüsselungsschlüssel ist deaktiviert.

• Autonomous Database-Instanz kann Oracle Cloud Infrastructure Vault nicht erreichen.

Wenn die Autonomous Database-Instanz aus dem Status Nicht zugänglich wiederhergestellt wird und ein DatabaseInaccessibleBegin-Ereignis generiert wurde, wird bei Änderung des Datenbankstatus in Verfügbar ein DatabaseInaccessibleEnd-Ereignis ausgelöst.

Gibt eine Meldung an, dass das Autonomous Database-Benutzerkennwort innerhalb der angegebenen Verlängerungsfrist abläuft (Standard 30 Tage) oder bereits abgelaufen ist.

• Wenn das Kennwort eines Autonomous Database-Benutzers innerhalb der angegebenen Verlängerungsfrist liegt und nicht mehr verwendet werden kann, erhalten Sie eine Warnung, die das Datum angibt, an dem das Kennwort nicht mehr verwendet werden kann.

• Wenn ein Autonomous Database-Benutzerkennwort abläuft und nicht mehr verwendet werden kann, meldet Autonomous Database ein Ereignis, das angibt, dass das Kennwort abgelaufen ist und zurückgesetzt werden muss.

Das Ereignis DatabaseUserPasswordWarning wird einmal täglich generiert.

Wenn die Anzahl der nicht erfolgreichen Anmeldeversuche in den letzten drei (3) Stunden 3 * Anzahl der Benutzer insgesamt erreicht, löst die Datenbank ein FailedLoginWarning-Ereignis aus.

Fehlgeschlagene Anmeldeversuche können darauf zurückzuführen sein, dass ein Benutzer einen ungültigen Benutzernamen oder ein ungültiges Kennwort oder einen Verbindungstimeout eingegeben hat. Das Ereignis wird ausgelöst, wenn der Schwellenwert für nicht erfolgreiche Anmeldeversuche innerhalb des überwachten Zeitraums (der letzten drei Stunden) überschritten wird.

Wenn eine Autonomous Database aufgrund von Serverwartung, Hardwareaktualisierung, einem Hardwareproblem oder im Rahmen einer vertikalen Ressourcenskalierung in eine andere Exadata-Infrastruktur umgespeichert wird, wird das Ereignis InstanceRelocateBegin zu Beginn des Umspeicherungsprozesses ausgelöst.

Wenn eine Autonomous Database aufgrund von Serverwartung, Hardwareaktualisierung, einem Hardwareproblem oder im Rahmen einer vertikalen Ressourcenskalierung in eine andere Exadata-Infrastruktur umgespeichert wird, wird das Ereignis InstanceRelocateEnd am Ende des Umspeicherungsprozesses ausgelöst.

Dieses Ereignis wird generiert, wenn Autonomous Database feststellt, dass ein Wallet in weniger als sechs (6) Wochen abläuft. Dieses Ereignis wird höchstens einmal pro Woche gemeldet.

Dieses Ereignis wird ausgelöst, wenn eine Verbindung vorhanden ist, die das ablaufende Wallet verwendet.

AJDNonJsonStorageExceeded

Dieses Ereignis wird generiert, wenn eine autonome JSON-Datenbank das maximale Speicherlimit von 20 GB Daten überschritten hat, die außerhalb von SODA-Sammlungen gespeichert sind. Dieser Grenzwert gilt nicht für Daten, die in SODA-Collections gespeichert sind, oder für Objekte, die mit SODA-Collections verknüpft sind, wie Indizes oder Materialized Views.

Zusätzlich zu diesem Ereignis wird eine E-Mail an den Accountverantwortlichen gesendet. Sie müssen die Nutzung von Nicht-SODA-bezogenen Daten entweder auf weniger als 20 GB reduzieren oder die autonome JSON-Datenbank auf Autonomous Transaction Processing hochladen. Weitere Informationen finden Sie unter In Autonomous Transaction Processing hochstufen.

APEXUpgradeAvailable

Dieses Ereignis wird generiert, wenn Sie Oracle APEX verwenden und ein neues Release verfügbar wird.

APEXUpgradeBegin

Dieses Ereignis wird generiert, wenn Sie Oracle APEX verwenden und eine Autonomous Database-Instanz ein Upgrade auf ein neues Oracle APEX-Release startet oder ein Oracle APEX-Patchset-Bundle einspielt.

APEXUpgradeEnd

Dieses Ereignis wird generiert, wenn Sie Oracle APEX verwenden und eine Autonomous Database-Instanz ein Upgrade auf ein neues Oracle APEX-Release abgeschlossen oder die Installation eines Oracle APEX-Patchset-Bundles abgeschlossen wird.

AutomaticRefreshEnd

Dieses Ereignis wird generiert, wenn die geplante automatische Aktualisierung abgeschlossen ist.

Weitere Informationen finden Sie unter Policy für automatische Aktualisierung für aktualisierbaren Klon bearbeiten.

AutomaticRefreshFailed

Dieses Ereignis wird generiert, wenn die geplante automatische Aktualisierung nicht erfolgreich verläuft.

Weitere Informationen finden Sie unter Policy für automatische Aktualisierung für aktualisierbaren Klon bearbeiten.

DatabaseConnection

Dieses Ereignis wird generiert, wenn eine Verbindung zur Datenbank von einer neuen IP-Adresse (IP-Adresse, von der aus in den letzten 30 Tagen keine Verbindung hergestellt wurde) hergestellt wird.

InactiveConnectionsDetected

Dieses Ereignis wird generiert, wenn die Anzahl der erkannten inaktiven Datenbankverbindungen ein bestimmtes Verhältnis zu allen Datenbankverbindungen für die Autonomous Database-Instanz überschreitet. Wenn Sie dieses Ereignis abonnieren, können Sie ungenutzte Verbindungen im Auge behalten.

Dieses Ereignis wird einmal täglich generiert, wenn Folgendes zutrifft:

• Die Anzahl der inaktiven Verbindungen, bei denen die abgelaufene Zeit für die inaktive Verbindung mehr als 24 Stunden beträgt, ist größer als 10% der Gesamtzahl der Verbindungen in einem beliebigen Status.

  Bei dieser Berechnung sind inaktive Verbindungen Verbindungen Verbindungen, deren status "INACTIVE" ist.

Mit der folgenden Abfrage können Sie detaillierte Informationen zu Sessions erstellen, die länger als 24 Stunden inaktiv waren:

SELECT sid, serial#, last_call_et  FROM v$session
     WHERE status = 'INACTIVE' AND last_call_et > 60 * 60 *24;

Dieses Ereignis wird generiert, wenn eine Transaktion länger als 24 Stunden offen ist. Pro Transaktion wird nur ein Ereignis generiert. Das generierte Ereignis enthält die Transaktions-ID, die Adresse und die Sitzungsadresse.

MaintenanceBegin

Dieses Ereignis wird ausgelöst, wenn die Wartung gestartet wird. Sie geben den Startzeitstempel für die Wartung an (dieses Ereignis gibt nicht die geplante Startzeit an).

Dieses Ereignis wird auch ausgelöst, wenn die Wartung für eine lokale Autonomous Data Guard-Standbydatenbank gestartet wird.

MaintenanceEnd

Dieses Ereignis wird ausgelöst, wenn die Wartung endet, und stellt den Endzeitstempel für die Wartung bereit (dieses Ereignis gibt nicht die geplante Endzeit an).

Dieses Ereignis wird auch ausgelöst, wenn die Wartung für eine lokale Autonomous Data Guard-Standbydatenbank beendet wird.

NewMaintenanceSchedule

Dieses Ereignis wird generiert, wenn das Wartungsdatum aktualisiert wird und das neue Datum in der Oracle Cloud Infrastructure-Konsole angezeigt wird.

Dieses Ereignis wird auch ausgelöst, wenn das Wartungsdatum aktualisiert wird und das neue Datum für eine lokale Autonomous Data Guard-Standbydatenbank angezeigt wird.

Wenn die Java-Version aktualisiert wird, gibt das Feld description für das Ereignis Folgendes an: This maintenance involves Java version update, please expect down time of Java service during this maintenance window.

NetworkUsageInbound

Dieses Ereignis wird ausgelöst, wenn der durchschnittliche eingehende Netzwerktraffic zu Ihrer Autonomous Database für TCP- oder HTTP-Datenbankverbindungen in den letzten 24 Stunden 50% des durchschnittlichen eingehenden Traffics überschritten hat, der einen Tag zuvor beobachtet wurde.

Wenn die Triggerbedingungen für dieses Ereignis erfüllt sind, wird das Ereignis NetworkUsageInbound einmal pro Tag generiert.

NetworkUsageOutbound

Dieses Ereignis wird ausgelöst, wenn der durchschnittliche ausgehende Netzwerktraffic von Ihrer Autonomous Database für TCP- oder HTTP-Datenbankverbindungen in den letzten 24 Stunden 50% des durchschnittlichen ausgehenden Traffics überschritten hat, der einen Tag zuvor beobachtet wurde.

Wenn die Triggerbedingungen für dieses Ereignis erfüllt sind, wird das Ereignis NetworkUsageOutbound einmal pro Tag generiert.

Dieses Ereignis wird ausgelöst, wenn der Operatorzugriff für die Datenbank erkannt wird. Sie können die Zugriffsdetails in der View DBA_OPERATOR_ACCESS mit der in der Ereignisbeschreibung angegebenen Anforderungs-ID abfragen.

Das Ereignis OperatorAccess wird alle 24 Stunden generiert.

QueryPerformanceDegradationDetected

Dieses Ereignis wird ausgelöst, wenn die durchschnittliche verstrichene Zeit einer Abfrage das Zehnfache ihrer durchschnittlichen verstrichenen Zeit in den letzten sieben (7) Tagen überschritten hat.

Das Feld QueryPerformanceDegradationDetected-Ereignis description gibt die potenzielle Ursache einer Beeinträchtigung der Abfrageperformance an. Beispiel: Mit einer Nachricht wie:

Query performance slow down detected for SQL ID 9x25vyx9ujnn8. 
This could potentially be due to a recent compute scale down performed on this Autonomous Database. 
You might need to scale up your instance's compute allocation to address this performance degradation.

Wenn die Triggerbedingungen für dieses Ereignis erfüllt sind, wird das Ereignis QueryPerformanceDegradationDetected höchstens einmal pro Tag generiert.

ScheduledMaintenanceWarning

Dieses Ereignis wird generiert, wenn eine geplante Wartung in 24 Stunden ansteht, und erneut, wenn die geplante Wartung in 1 Stunde (60 Minuten) ansteht.

Dieses Ereignis wird auch ausgelöst, wenn eine lokale Autonomous Data Guard-Standbydatenbank 24 Stunden von einer geplanten Wartung entfernt ist und wenn die lokale Autonomous Data Guard-Standbydatenbank 1 Stunde (60 Minuten) von der geplanten Wartung entfernt ist.

Wenn die Java-Version aktualisiert wird, wird dies im Ereignisfeld description mit der folgenden Meldung angezeigt: This maintenance involves Java version update, please expect down time of Java service during this maintenance window.

SQLParseErrorWarning

Wenn ein SQL-Parse-Fehler mehrmals in einem bestimmten Zeitfenster auftritt, z.B. 200 Mal oder mehr in einer Stunde, generiert dies "Too Many Parse Errors"-Einträge im Alertlog. Das Ereignis SQLParseErrorWarning wird ausgelöst, wenn ein neuer Eintrag im Alertlog vorhanden ist, der angibt, dass eine SQL-Anweisung zu viele Parse-Fehler aufweist. Beispiel: Wenn eine ungültige Abfrage 200 Mal in weniger als einer Stunde ausgeführt wird, löst dies das Ereignis SQLParseErrorWarning aus.

Dieses Ereignis wird höchstens einmal pro Tag generiert. Dies bedeutet, dass es eine Verzögerung von bis zu 24 Stunden geben kann, bevor das Ereignis generiert wird.

Dieses Ereignis wird ausgelöst, wenn eine Workload-Erfassung initiiert wird.

Dieses Ereignis wird ausgelöst, wenn eine Workload-Erfassung erfolgreich abgeschlossen wird.

Dadurch wird eine vorab authentifizierte (PAR-)URL zum Herunterladen der Capture-Berichte generiert.

Diese URL ist im Feld captureDownloadURL des Ereignisses enthalten und 7 Tage ab dem Generierungsdatum gültig.

Dieses Ereignis wird ausgelöst, wenn eine Workload-Wiedergabe initiiert wird.

Dieses Ereignis wird ausgelöst, wenn eine Workload-Wiedergabe erfolgreich abgeschlossen wird.

Dadurch wird eine vorab authentifizierte (PAR-)URL zum Herunterladen der Wiedergabeberichte generiert.

Diese URL ist im Feld replayDownloadURL des Ereignisses enthalten und 7 Tage ab dem Generierungsdatum gültig.

Weitere Informationen finden Sie unter Kritische Ereignisse in Autonomous Database.

Dieses Ereignis wird 48 Stunden vor dem Stoppen der Datenbank ausgegeben.

Dieses Ereignis wird 48 Stunden vor der Beendigung der Datenbank ausgegeben.

Weitere Informationen finden Sie unter Informationsereignisse in Autonomous Database.

Dieses Ereignis wird ausgelöst, wenn ein langfristiges Backup abgeschlossen wird.

Dieses Ereignis wird ausgelöst, wenn ein langfristiger Backupzeitplan deaktiviert ist.

Dieses Ereignis wird ausgelöst, wenn ein langfristiger Backupzeitplan aktiviert oder aktualisiert wird.

Dieses Ereignis wird ausgelöst, wenn ein langfristiges Backup gestartet wird.

Dieses Ereignis wird ausgegeben, nachdem das Failover erfolgreich oder nicht erfolgreich abgeschlossen wurde.

Nicht erfolgreiche manuelle Failover-Vorgänge können zu Datenverlust führen. Weitere Informationen finden Sie auf der Autonomous Database-Detailseite in der Oracle Cloud Infrastructure-Konsole bei einem nicht erfolgreichen manuellen Failover.)

Die Ereignisse "Manuelle Aktualisierung" werden für aktualisierbare Klone von Autonomous Database verwendet.

Dieses Ereignis wird ausgegeben, nachdem das Switchover erfolgreich oder nicht erfolgreich abgeschlossen wurde.

Nicht erfolgreiche Switchover-Vorgänge können zu Datenverlust führen. Auf der Detailseite für Autonomous Database in der Oracle Cloud Infrastructure-Konsole finden Sie weitere Informationen, falls ein Switchover nicht erfolgreich war.