Ereignisse des Database-Service

Durch Implementierung des Ereignisfeatures des Datenbankservice können Sie über Probleme mit dem Zustand Ihrer Oracle-Datenbanken oder anderer Komponenten auf dem DB-System benachrichtigt werden.

Möglicherweise ist Oracle Database oder Clusterware nicht fehlerfrei, oder verschiedene Systemkomponenten haben nicht genügend Speicherplatz auf dem DB-System. Kunden werden von dieser Situation nicht benachrichtigt. Durch die Implementierung des Ereignisfeatures des Database-Service werden Ereignisse für Data-Plane-Vorgänge und -Bedingungen sowie Benachrichtigungen für Kunden generiert. Dazu werden die vorhandenen OCI Events-Service- und Benachrichtigungsmechanismen in ihrem Mandanten genutzt. Kunden können dann Themen erstellen und diese Themen über E-Mail, Funktionen oder Streams abonnieren.

Hinweis:

Der Ereignisfluss im DB-System hängt von Oracle Trace File Analyzer-(TFA-) und vom Oracle Database Cloud Service-(DBCS-)Agent ab. Stellen Sie sicher, dass diese Komponenten hochgefahren und gestartet sind.

Verwandte Themen

Benachrichtigungen zu Ereignissen des Database-Service erhalten

Abonnieren Sie die Ereignisse des Database-Service, und lassen Sie sich benachrichtigen. Um Benachrichtigungen zu erhalten, abonnieren Sie die Ereignisse des Database Service. So erhalten Sie Benachrichtigungen über den Oracle Notifications-Service (siehe Überblick über Notifications). Weitere Informationen zu Oracle Cloud Infrastructure-Ereignissen finden Sie unter Überblick über Ereignisse.

Events-Service - Ereignistypen

Datenbank - Kritisch
DB-Knoten - Kritisch
DB-Knoten - Fehler
DB-Knoten - Warnung
DB-Knoten - Informationen
DB-System - Kritisch

Ereignistypen des Database-Service

In der folgenden Tabelle sind die Ereignistypen aufgeführt, die vom Datenbankservice ausgegeben werden.

Hinweis:

Kritische Ereignisse werden durch verschiedene kritische Bedingungen und Fehler ausgelöst, die die Datenbank oder andere wichtige Komponenten unterbrechen. Beispiel: Datenbankfehler und Verfügbarkeitsfehler für Datenbanken, Datenbankknoten und DB-Systeme geben an, wann eine Ressource nicht mehr verfügbar ist.
Informationsereignisse werden ausgelöst, wenn die Datenbank und andere kritische Komponenten wie erwartet funktionieren. Beispiel: Beim ordnungsgemäßen Herunterfahren von CRS, CDB, Client oder Scan-Listener oder beim Hochfahren dieser Komponenten wird ein Ereignis mit dem Schweregrad INFO erstellt.
Durch Schwellenwerte lässt sich die Anzahl der Benachrichtigungen reduzieren, die Kunden über derartige Vorfallereignisse erhalten. Gleichzeitig wird sichergestellt, dass sie die Vorfallereignisse erhalten und rechtzeitig benachrichtigt werden.

Ereignisse des Database-Service

Hinweis:

Neben den unten aufgeführten Ereignissen analysiert Oracle zusätzliche Ereignisse, um ein Höchstmaß an Servicevorgängen und Support für eine hohe Verfügbarkeit von Services bereitzustellen.

Tabelle -: Ereignisse des Database-Service

Anzeigename	Ereignisname	Beschreibung	Korrektur	Ereignistyp	Schwellenwert
Ressourcenauslastung - Datenträgerauslastung	`HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE`	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` (nur X8M und höher) `/tmp` (nur X8M und höher)	HEALTH-DB_GUEST-FILESYSTEM-FREE_SPACE	`com.oraclecloud.databaseservice.dbnode.critical`	Kritischer Schwellenwert: 90 %
CRS-Status Hochgefahren/Heruntergefahren	`AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN`.	Ein Ereignis des Typs CRITICAL wird erstellt, wenn der Cluster Ready Service (CRS) als heruntergefahren erkannt wird.	AVAILABILITY-DB_GUEST-CRS_INSTANCE.DOWN	`com.oraclecloud.databaseservice.dbnode.critical` (wenn .DOWN und nicht "user_action")	-
	`AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED`	Ein Ereignis des Typs INFORMATION wird erstellt, sobald festgestellt wird, dass das Ereignis für den heruntergefahrenen CRS behoben ist.	-	`com.oraclecloud.databaseservice.dbnode.information` (wenn .DOWN_CLEARED)	-
	`AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION`	Ein Ereignis des Typs CRITICAL wird erstellt.	AVAILABILITY-DB_GUEST-CRS_INSTANCE-EVICTION	`com.oraclecloud.databaseservice.dbnode.critical`	-
SCAN-Listener hoch-/heruntergefahren	`AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN`	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].	AVAILABILITY-DB_CLUSTER-SCAN_LISTENER-DOWN	`com.oraclecloud.databaseservice.dbnode.critical` (wenn .DOWN und nicht "user_action")	-
SCAN-Listener hoch-/heruntergefahren	`AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN_CLEARED`	Ein Ereignis des Typs INFORMATION wird erstellt, sobald festgestellt wird, dass das Ereignis für den heruntergefahrenen SCAN-Listener behoben ist.	-	`com.oraclecloud.databaseservice.dbnode.information` (wenn .DOWN_CLEARED)	-
Net-Listener hoch-/heruntergefahren	`AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN`	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.	AVAILABILITY-DB_GUEST-CLIENT_LISTENER.DOWN	`com.oraclecloud.databaseservice.database.critical` (wenn .DOWN und nicht "user_action")	-
Net-Listener hoch-/heruntergefahren	`AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN_CLEARED`	Ein Ereignis des Typs INFORMATION wird erstellt, sobald festgestellt wird, dass das Ereignis für den heruntergefahrenen Client-Listener behoben ist.	-	`com.oraclecloud.databaseservice.database.information` (wenn .DOWN_CLEARED)	-
CDB hoch-/heruntergefahren	`AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN`	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.	AVAILABILITY-DB_GUEST-CDB_INSTANCE-DOWN	`com.oraclecloud.databaseservice.database.critical` (wenn .DOWN und nicht "user_action")	-
CDB hoch-/heruntergefahren	`AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN_CLEARED`	Ein Ereignis des Typs INFORMATION wird erstellt, sobald festgestellt wird, dass das Ereignis für die heruntergefahrene CDB behoben ist.	-	`com.oraclecloud.databaseservice.database.information` (wenn .DOWN_CLEARED)	-
Kritische DB-Fehler	`HEALTH.DB_CLUSTER.CDB.CORRUPTION`	In der Primär- oder Standbydatenbank wurde eine Datenbankbeschädigung festgestellt. Das alert.log der Datenbank wird auf bestimmte Fehler analysiert, die auf physische Blockbeschädigungen, logische Blockbeschädigungen oder logische Blockbeschädigungen durch verlorene Schreibvorgänge hinweisen.	HEALTH-DB_CLUSTER-CDB-CORRUPTION	`com.oraclecloud.databaseservice.database.critical`	-
Andere DB-Fehler	`HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG`	Ein Ereignis des Typs CRITICAL wird erstellt, wenn eine CDB das aktive Online-Redo Log entweder gar nicht oder nicht schnell genug in den Logarchivierungszielen archivieren kann.	HEALTH-DB_CLUSTER-CDB-ARCHIVER_HANG	`com.oraclecloud.databaseservice.database.critical`	-
Andere DB-Fehler	`HEALTH.DB_CLUSTER.CDB.DATABASE_HANG`	Ein Ereignis vom Typ CRITICAL wird erstellt, wenn ein Prozess oder eine Session in der CDB nicht mehr reagiert.	HEALTH-DB_CLUSTER-CDB-DATABASE_HANG	`com.oraclecloud.databaseservice.database.critical`	-
Backupfehler	`HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE`	Ein Ereignis des Typs CRITICAL wird erstellt, wenn ein CDB-Backup mit dem Status FAILED in der Ansicht `v$rman_status` gemeldet wird.	HEALTH-DB_CLUSTER-CDB-BACKUP_FAILURE	`com.oraclecloud.databaseservice.database.critical`	-
Backupfehler	`HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE_CLEARED`	Ein Ereignis des Typs INFORMATION wird erstellt.	-	`com.oraclecloud.databaseservice.database.information`	-
Datenträgergruppenauslastung	`HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE`	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.	HEALTH-DB_CLUSTER-DISK_GROUP-FREE_SPACE	`com.oraclecloud.databaseservice.dbsystem.critical` `com.oraclecloud.databaseservice.dbsystem.information` (if < 90%)	Benachrichtigungen werden gesendet, wenn die Auslastung 70%, 80%, 90% und 100% mit dem entsprechenden Schweregrad 4, 3, 2 und 1 erreicht.

Automatische Diagnoseerfassung für bestimmte Ereignisse vorübergehend einschränken

Verwenden Sie den Befehl tfactl blackout, um die automatische Diagnoseerfassung vorübergehend zu unterdrücken.

Wenn Sie für ein Ziel ein Blackout festlegen, stoppt Oracle Trace File Analyzer die automatische Diagnoseerfassung, wenn beim Scannen Ereignisse in den Alertlogs für dieses Ziel gefunden werden. Standardmäßig ist das Blackout 24 Stunden lang gültig.

Sie können die automatische Diagnoseerfassung auch auf granularer Ebene einschränken, beispielsweise nur für ORA-00600 oder auch nur für ORA-00600 mit bestimmten Argumenten.

Syntax

tfactl blackout add|remove|print
    -targettype host|crs|asm|asmdg|database|dbbackup|db_dataguard|
        db_tablespace|pdb_tablespace|pdb|listener|service|os
    -target all|name
    [-container name]
    [-pdb pdb_name]
    -event all|"event_str1,event_str2"|availability
    [-timeout nm|nh|nd|none]
    [-c|-local|-nodes "node1,node2"]
    [-reason "reason for blackout"]
    [-docollection]

Parameter

Tabelle -: Parameter

Parameter	Beschreibung
`add`\|`remove`\|`print`\|	Fügt Blackout-Bedingungen hinzu, entfernt sie oder gibt sie aus.
`-targettype type` Zieltyp:`host`\|`crs`\|`asm`\|`asmdg`\|`database`\|`dbbackup`\|`db_dataguard`\| `db_tablespace`\|`pdb_tablespace`\|`pdb`\|`listener`\|`service`\|`os`	Begrenzt das Blackout auf den angegebenen Zieltyp. `host`: Der gesamte Knoten befindet sich im Blackout. Wenn ein Hostblackout vorliegt, wird für jedes Blackoutelement, das in der Telemetrie-JSON als "true" angezeigt wird, der Grund für das Blackout angegeben. `crs`: Blackout der Verfügbarkeit der Oracle Clusterware-Ressource oder -Ereignisse in den Oracle Clusterware-Logs. `ASM`: Blackout der Verfügbarkeit von Oracle Automatic Storage Management (Oracle ASM) auf diesem Rechner oder der Ereignisse in den Oracle ASM-Alertlogs. `asmdg`: Blackout einer Oracle ASM-Datenträgergruppe. `database`: Blackout der Verfügbarkeit einer Oracle-Datenbank, eines Backups einer Oracle-Datenbank, eines Tablespace usw. oder von Ereignissen in den Oracle Database-Alertlogs. `dbbackup`: Blackout von Oracle Database-Backupereignissen (wie CDB oder Archivbackups). `db_dataguard`: Blackout von Oracle Data Guard-Ereignissen. `db_tablespace`: Blackout von Oracle Database-Tablespace-Ereignissen (Containerdatenbank). `pdb_tablespace`: Blackout von Tablespace-Ereignissen integrierbarer Oracle-Datenbanken. `pdb`: Blackout von Ereignissen integrierbarer Oracle-Datenbanken. `listener`: Blackout der Verfügbarkeit eines Listeners. `service`: Blackout der Verfügbarkeit eines Service. `os`: Blackout eines oder mehrerer Betriebssystemdatensätze.
`-target all\|name`	Geben Sie das Ziel für das Blackout an. Sie können eine kommagetrennte Liste von Zielen angeben. Standardmäßig ist das Ziel auf `all` gesetzt.
`-container name`	Geben Sie den Namen des Datenbankcontainers (`db_unique_name`) an, in dem das Blackout wirksam wird (für PDB, DB_TABLESPACE und PDB_TABLESPACE).
`-pdb pdb_name`	Geben Sie die PDB an, in der das Blackout wirksam wird (nur für PDB_TABLESPACE).
`-events all\|"str1,str2"`	Begrenzt das Blackout auf Verfügbarkeitsereignisse oder Ereigniszeichenfolgen, die keine automatische Erfassung auslösen oder in Telemetrie-JSON als "Blackout" markiert werden sollen. `all`: Blackout für alles im angegebenen Ziel. string: Blackout für Vorfälle, bei denen ein Teil der Zeile die angegebenen Zeichenfolgen enthält. Geben Sie eine kommagetrennte Liste von Zeichenfolgen an.
`-timeout nh\|nd\|none`	Geben Sie die Dauer des Blackouts bis zum Timeout in Stunden oder Tagen an. Standardmäßig ist der Timeout auf 24 Stunden (24h) gesetzt.
`-c\|-local`	Geben Sie an, ob das Blackout clusterweit (`cluster-wide`) oder lokal (`local`) erfolgen soll. Standardmäßig ist "Blackout" auf `local` gesetzt.
`-reason comment`	Geben Sie eine Beschreibung des Grundes für das Blackout an.
`-docollection`	Verwenden Sie diese Option, um eine automatische Diagnoseerfassung auszuführen, auch wenn für dieses Ziel ein Blackout festgelegt ist.

Beispiele

Im Folgenden finden Sie Beispiele für die Verwendung des Befehls "tfactl blackout".

Blackout von event: ORA-00600 in targettype: database, target: mydb

tfactl blackout add -targettype database -target mydb -event "ORA-00600"

Blackout von event: ORA-04031 in targettype: database, target: all

tfactl blackout add -targettype database -target all -event "ORA-04031" -timeout 1h

Blackout von DB-Backupereignissen in targettype: dbbackup, target: mydb

tfactl blackout add -targettype dbbackup -target mydb

Blackout von DB-Data Guards-Ereignissen in targettype: db_dataguard, target: mydb

tfactl blackout add -targettype db_dataguard -target mydb -timeout 30m

Blackout von DB-Tablespace-Ereignissen in targettype: db_tablespace, target: system, container: mydb

tfactl blackout add -targettype db_tablespace -target system -container mydb -timeout 30m

Blackout von allen Ereignissen (ALL) in targettype: host, target: all

tfactl blackout add -targettype host -event all -target all -timeout 1h 
    -reason "Disabling all events during patching"

Blackoutdetails ausgeben:

tfactl blackout print

.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------.
|                                                                                myhostname                                                                                     |
+---------------+---------------------+-----------+------------------------------+------------------------------+--------+---------------+--------------------------------------+
| Target Type   | Target              | Events    | Start Time                   | End Time                     | Status | Do Collection | Reason                               |
+---------------+---------------------+-----------+------------------------------+------------------------------+--------+---------------+--------------------------------------+
| HOST          | ALL                 | ALL       | Thu Mar 24 16:48:39 UTC 2022 | Thu Mar 24 17:48:39 UTC 2022 | ACTIVE | false         | Disabling all events during patching |
| DATABASE      | MYDB                | ORA-00600 | Thu Mar 24 16:39:03 UTC 2022 | Fri Mar 25 16:39:03 UTC 2022 | ACTIVE | false         | NA                                   |
| DATABASE      | ALL                 | ORA-04031 | Thu Mar 24 16:39:54 UTC 2022 | Thu Mar 24 17:39:54 UTC 2022 | ACTIVE | false         | NA                                   |
| DB_DATAGUARD  | MYDB                | ALL       | Thu Mar 24 16:41:38 UTC 2022 | Thu Mar 24 17:11:38 UTC 2022 | ACTIVE | false         | NA                                   |
| DBBACKUP      | MYDB                | ALL       | Thu Mar 24 16:40:47 UTC 2022 | Fri Mar 25 16:40:47 UTC 2022 | ACTIVE | false         | NA                                   |
| DB_TABLESPACE | SYSTEM_CDBNAME_MYDB | ALL       | Thu Mar 24 16:45:56 UTC 2022 | Thu Mar 24 17:15:56 UTC 2022 | ACTIVE | false         | NA                                   |
'---------------+---------------------+-----------+------------------------------+------------------------------+--------+---------------+--------------------------------------'

Blackout entfernen für event: ORA-00600 in targettype: database, target: mydb

tfactl blackout remove -targettype database -event "ORA-00600" -target mydb

Blackout für DB-Backupereignisse entfernen in targettype: dbbackup, target: mydb

tfactl blackout remove -targettype dbbackup -target mydb

Blackout für DB-Tablespace-Ereignisse entfernen in targettype: db_tablespace, target: system, container: mydb

tfactl blackout remove -targettype db_tablespace -target system -container mydb

Blackout für Hostereignisse entfernen in targettype: all, target: all

tfactl blackout remove -targettype host -event all -target all

Oracle Trace File Analyzer verwalten

Um den Ausführungsstatus von Oracle Trace File Analyzer zu prüfen, führen Sie den Befehl tfactl status als root- oder als Nicht-Root-Benutzer aus:

tfactl status

.----------------------------------------------------------------------------------------------.
| Host  | Status of TFA | PID    | Port | Version    | Build ID             | Inventory Status |
+-------+---------------+--------+------+------------+----------------------+------------------+
| node1 | RUNNING       | 41312  | 5000 | 22.1.0.0.0 | 22100020220310214615 | COMPLETE         |
| node2 | RUNNING       | 272300 | 5000 | 22.1.0.0.0 | 22100020220310214615 | COMPLETE         |
'----------------------------------------------------------------------------------------------'

Um den Oracle Trace File Analyzer-Daemon auf dem lokalen Knoten zu starten, führen Sie den Befehl tfactl start als Benutzer root aus:

tfactl start

Starting TFA..
Waiting up to 100 seconds for TFA to be started..
. . . . .
Successfully started TFA Process..
. . . . .
TFA Started and listening for commands

Um den Oracle Trace File Analyzer-Daemon auf dem lokalen Knoten zu stoppen, führen Sie den Befehl tfactl stop als Benutzer root aus:

tfactl stop

Stopping TFA from the Command Line
Nothing to do !
Please wait while TFA stops
Please wait while TFA stops
TFA-00002 Oracle Trace File Analyzer (TFA) is not running
TFA Stopped Successfully
Successfully stopped TFA..

Datenbankservice-Agent verwalten

Informationen zum Ermitteln von Problemen mit dem Agent finden Sie in der Datei /opt/oracle/dcs/log/dcs-agent.log.

Um den Status des Datenbankservice-Agent zu prüfen, führen Sie den Befehl systemctl status aus:

systemctl status dbcsagent.service

dbcsagent.service
Loaded: loaded (/usr/lib/systemd/system/dbcsagent.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2022-04-01 13:40:19 UTC; 6min ago
Process: 9603 ExecStopPost=/bin/bash -c kill `ps -fu opc |grep "java.*dbcs-agent.*jar" |
    awk '{print $2}' ` (code=exited, status=0/SUCCESS)
Main PID: 10055 (sudo)
CGroup: /system.slice/dbcsagent.service
‣ 10055 sudo -u opc /bin/bash -c umask 077; /bin/java -Doracle.security.jps.config=/opt/oracle/...

Um den Agent zu starten, wenn er nicht ausgeführt wird, führen Sie den Befehl systemctl start als Benutzer root aus:

systemctl start dbcsagent.service

Titel und Copyright-Informationen

Oracle und/oder verbundene Unternehmen.