Servicewartung für Autonomous Database on Dedicated Exadata Infrastructure
Oracle plant alle Patching- und anderen Wartungsvorgänge für alle Autonomous Database-Ressourcen auf einer dedizierten Exadata-Infrastruktur und führt sie aus. Gleichzeitig erhalten Sie verschiedene Optionen zur Anpassung, Anzeige und Neuplanung von Wartungsereignissen für die verschiedenen Infrastrukturressourcen.
Hinweis:
Wenn Database In-Memory aktiviert ist, kann es bei Patching-Aktivitäten, die zum Neustart der Datenbank führen, zu Performanceeinbußen kommen. Weitere Informationen zu Database In-Memory finden Sie unter Database In-Memory.
Verwandte Themen
Servicewartungstypen
Oracle plant und führt verschiedene Servicewartungsaktivitäten in Autonomous Database aus. Diese Wartungsereignisse variieren in Umfang und Häufigkeit des Patchings.
- Patches für die vierteljährliche Wartung: Im Allgemeinen plant Oracle die gesamte Flottenwartung und führt sie in jedem Quartal durch.
- Vierteljährliche Wartungspatches werden auf verschiedenen Ressourcenebenen eingespielt, wie Exadata-Infrastruktur, autonomes Exadata-VM-Cluster (AVMC) und autonome Containerdatenbank (ACD). Das vierteljährliche Wartungsfenster kann beim Erstellen dieser Infrastrukturressourcen festgelegt oder später geändert werden.
- Sie können die Wartungsplanung Oracle überlassen oder ein bestimmtes Wartungsfenster festlegen, in dem Oracle mit der Wartung beginnen kann.
- Standardmäßig spielt Oracle Releaseupdates (RUs) zusammen mit diesen vierteljährlichen Wartungspatches ein. Sie können die Aktualisierung von RU in einer Rolling- oder Non-Rolling-Verwaltungsmethode konfigurieren.
- Die Methode Rolling aktualisiert die ACD, jeweils einen Knoten, ohne Ausfallzeiten für die Autonomous Databases.
- Die Methode Nicht-Rolling wird heruntergefahren und aktualisiert die ACD parallel auf allen Knoten. Diese Methode minimiert die Wartungszeit, erfordert jedoch eine vollständige Ausfallzeit für die ACD und alle zugehörigen Autonomous Databases.
Hinweis:
In einer Autonomous Data Guard-Konfiguration führt die Nicht-Rolling-Wartungsmethode während des jeweiligen Wartungsfensters zu Ausfallzeiten für die primären und Standby-ACDs, bis das Patching abgeschlossen ist.
- Sie können auch die zu aktualisierende Zeitzonendatei zusammen mit der RU aufnehmen. Vierteljährliche Wartungspatches, die ein Update der Zeitzonendatei enthalten, erfordern eine vollständige Ausfallzeit für die ACD und die zugehörigen Autonomous Databases. Die Ausfallzeit hängt von der Datenmenge ab, die zeitzonenabhängig ist.
- Vierteljährliche Wartungspatches ohne Aktualisierung einer Zeitzonendatei können je nach Wartungskonfiguration der autonomen Containerdatenbank (ACD) in einer Rolling- oder Nicht-Rolling-Methode eingespielt werden.
- Monatliche Sicherheitspatches:
- Sicherheitspatches für Exadata-Infrastruktur: Oracle plant und führt neben der vierteljährlichen Wartung eine monatliche Wartung der Infrastruktursicherheit durch. Diese Sicherheitspatches werden jedoch nur in diesen Monaten mit kritischen Sicherheitsupdates eingespielt, einschließlich Fixes für Sicherheitslücken mit CVSS-Scores größer/gleich 7.
- Jede Exadata-Infrastruktur, die bereitgestellt wird, bevor Oracle die Sicherheitswartung plant, ist zur Sicherheitswartung berechtigt.
- Der monatliche Sicherheitswartungsprozess aktualisiert Datenbankserver, um kritische Sicherheitslücken und Produktprobleme zu beheben. Außerdem aktualisieren sie Speicherserver auf ein Exadata Storage Software-Image, das bekannte Sicherheitslücken und Produktprobleme löst.
- Sicherheitspatches für autonome VM-Cluster: Oracle führt zusätzlich zu den regulären vierteljährlichen Updates eine monatliche Sicherheitswartung für autonome VM-Cluster durch. Diese Patches sind nur für GOV-Regionen anwendbar.
- Monatliche Sicherheitspatches werden mit der Rolling-Methode eingespielt.
- Der erste Monat jedes Quartals umfasst vierteljährliche Patches; die folgenden zwei Monate umfassen monatliche Sicherheitspatches.
- Um sicherzustellen, dass Patches eingespielt werden, müssen Sie alle drei Monate des Quartals auswählen und eine Voreinstellung für Woche 3 und/oder Woche 4 angeben.
- Sicherheitspatches für Exadata-Infrastruktur: Oracle plant und führt neben der vierteljährlichen Wartung eine monatliche Wartung der Infrastruktursicherheit durch. Diese Sicherheitspatches werden jedoch nur in diesen Monaten mit kritischen Sicherheitsupdates eingespielt, einschließlich Fixes für Sicherheitslücken mit CVSS-Scores größer/gleich 7.
- One-off-Patches: Oracle generiert One-off-Patches für kritische Supportanfragen, die bei My Oracle Support eingereicht werden. Hilfe zum Einreichen einer Supportanfrage finden Sie unter Serviceanfrage in My Oracle Support erstellen .
- Wenn Sie und Oracle zustimmen, dass eine Serviceanfrage kritisch ist und einen One-off-Patch für die sofortige Lösung erfordert, generiert das Serviceteam einen One-off-Patch und stellt diesen zur Verfügung. One-off-Patches unterscheiden sich von geplanten Wartungspatches.
- Wenn Sie Oracle Cloud-Benachrichtigungen und -Ereignisse mit einer Regel aktivieren, um Benachrichtigungen über neue Updates zu erhalten, sendet Oracle eine Benachrichtigung mit der OCID des zu patchenden Produkts, wenn One-off-Patches verfügbar sind. Andernfalls finden Sie den Updateverfügbarkeitshinweis im My Oracle Support-Portal für die von Ihnen eingereichte Supportanfrage.
- Die One-off-Patches werden in das nächste Releaseupdate (RU) eingefügt, um Folgendes sicherzustellen:
- Ein einmaliger Fix für einen bestimmten Kunden ist für alle Kunden verfügbar.
- Die nachfolgenden Versionen müssen One-off-Patches dann nicht erneut einspielen.
- Mehrere One-off-Patches können in einem RU zusammengeführt werden. Ab dem aktuellen Release sind die One-off-Patches nicht kumulativ und müssen daher einzeln eingespielt werden. Wenn ein One-off-Patch zu nahe am nächsten RU liegt, wird für das nächste Quartal eine benutzerdefinierte Version des RU mit dem One-off-Fix erstellt.
- Angenommen, eine einmalige Korrektur, die nicht mit der letzten RU zusammengeführt wurde, ist geplant, und Sie wenden die nächste RU an. Dann bricht Oracle den geplanten One-off-Patch ab. Sie können die abgebrochenen Wartungsläufe in der Wartungshistorie anzeigen. Alle One-off-Patching-Details, die in der Wartungshistorie protokolliert werden, sind in Downloads sowie Audit- und Loggingservices verfügbar.
- Bei Bedarf kann ein One-off-Patch über eine Serviceanfrage zurückgesetzt werden.
- Die Anzahl der One-off-Patches, die für eine autonome Containerdatenbank verfügbar sind, wird auf der Seite Details angezeigt. Wenn Sie daneben auf den Link Kopieren klicken, werden alle One-off-Patchnummern kopiert.
Angeben, wann Wartung stattfinden kann
Im Allgemeinen plant und führt Oracle die gesamte Flottenwartung über jedes Quartal und monatliche Infrastruktur-Sicherheitsfixes für Sicherheitslücken mit CVSS-Scores größer oder gleich 7 aus. Sie können die Wartungsplanung Oracle überlassen oder ein bestimmtes Wartungsfenster festlegen, in dem Oracle mit der Wartung beginnen kann.
Vierteljährliche Wartung anpassen
Sie wählen entweder einen Zeitplan für die vierteljährliche automatische Wartung der Autonomous Database-Ressourcen aus, oder lassen Oracle die Updates automatisch planen. Im Voraus benachrichtigt Oracle Sie über Datum und Uhrzeit der bevorstehenden geplanten Wartung.
Sie können die folgenden Aktionen mit automatischer vierteljährlicher Wartung auf verschiedenen Ressourcenebenen ausführen, wie in der folgenden Tabelle aufgeführt:
- Passen Sie die Voreinstellungen und den Zeitplan für die automatische Wartung an. Sie können diese Voreinstellungen beim Provisioning der Autonomous Database-Ressourcen festlegen oder sie später ändern.
- Sie können den Zeitplan jederzeit vor Beginn der geplanten Wartung anzeigen und ändern. Änderungen an der geplanten Wartung für nachfolgende Quartale wirken sich nicht auf den Zeitplan für das aktuelle Quartal aus.
- Zeigen Sie die vergangenen Wartungsereignisse an.
| Infrastrukturressource | Notizen und weitere Referenz |
|---|---|
|
Exadata-Infrastruktur (EI) |
|
|
Autonomes Exadata-VM-Cluster (AVMC) |
Hinweis: AVMC-Ressourcen, die vor dem Start des Features für mehrere autonome VM-Datenbanken in den Exadata-Infrastrukturressourcen in Oracle Cloud bereitgestellt wurden, erben den Wartungsplan der verknüpften Exadata-Infrastruktur. |
|
Autonome Containerdatenbank (ACD) |
|
Tipp:
Oracle empfiehlt, dass Sie ein Wartungsfenster für alle oben aufgeführten Infrastrukturressourcen festlegen, um Folgendes zu ermöglichen:- Verhindern, dass Wartungsvorgänge zu ungünstigen Zeiten stattfinden und reguläre Datenbankvorgänge stören.
- Gestaffeltes Patchen Ihrer Infrastrukturressourcen. Die Staffelung der Wartungsereignisse für verschiedene Infrastrukturressourcen ist eine Best Practice, die es Ihnen ermöglicht, den Patch für eine Gruppe von Ressourcen zu prüfen, bevor Sie einen weiteren Patch einspielen. Beispiel: Wenn Sie verschiedene autonome Containerdatenbanken für Entwicklung und Tests verwenden und die Patches in Ihrer Entwicklungsumgebung prüfen möchten, bevor Sie sie auf die Produktion anwenden, können Sie ihre Wartungspläne so anpassen, dass alle Entwicklungs-ACDs vor den Produktions-ACDs gepatcht werden.
Anpassbare Einstellungen im Wartungsplan
Sie können die folgenden Details in der Oracle Cloud Infrastructure-Konsole auswählen, während Sie einen benutzerdefinierten Zeitplan für eine der oben genannten Infrastrukturressourcen definieren.
-
Zulässige Monate: Sie müssen mindestens einen Monat pro Quartal auswählen, und Sie können auch das Patching für ein Quartal überspringen. Patching kann für zwei aufeinanderfolgende Quartale nicht übersprungen werden.
Hinweis:
Wenn Sie überspringen, müssen Sie mindestens einen Monat aus diesem Quartal auswählen. Dies dient als Fallback, falls im vorherigen nicht übersprungenen Quartal keine Wartung stattgefunden hat. In diesem Szenario führt Oracle die Wartung automatisch im ausgewählten Monat aus, selbst wenn für dieses Quartal die Option "Überspringen" ausgewählt wird. -
Woche (oder Wochen) innerhalb der ausgewählten Monate: Wochen beginnen am 1., 8., 15. und 22. Tag des Monats und müssen jeweils 7 Tage dauern. Beginn und Ende einer Woche basieren auf Kalenderdaten und nicht auf Wochentagen. Die Wartung kann nicht für die fünfte Woche von Monaten mit mehr als 28 Tagen geplant werden. Wenn Sie keine Woche des Monats angeben, weist Oracle automatisch eine Woche zu.
-
Tag (oder Tage) der ausgewählten Woche:
Wenn Sie keinen Wochentag angeben, führt Oracle das Wartungsupdate an einem automatisch zugewiesenen Tag aus.
Da Wochenbeginn und -ende nicht auf Wochentagen basieren, sondern auf Kalenderdaten, müssen Sie bei der Auswahl der Tage besonders umsichtig sein, falls Sie beim Patching der Exadata-Infrastruktur (EI) eine bestimmte Abfolge sicherstellen möchten. Betrachten Sie z.B. die beiden folgenden Monate:
Beschreibung der Abbildung dayofweek2.pngIm September 2023 beginnt die 1. Woche an einem Freitag und endet an einem Donnerstag. Der erste Samstag liegt also einen Tag vor dem ersten Sonntag. Die 1. Woche im Oktober 2023 beginnt jedoch an einem Sonntag und endet an einem Samstag. Der erste Samstag liegt daher fünf Tage nach dem ersten Sonntag.
Angenommen, Sie möchten alle Exadata-Infrastrukturressourcen patchen, bevor Sie die autonomen Containerdatenbanken (ACDs) patchen, um bei der Wartung eine bestimmte Abfolge einzuhalten. Die Planung der Wartung der Exadata-Infrastrukturressource am Samstag der Woche 1 und der zugehörigen ACDs am Sonntag der Woche 1 unter der Annahme, dass der Sonntag der Woche 1 immer auf einen Tag nach dem Samstag der Woche 1 fällt, kann für einige Monate wie September 2023 funktionieren, nicht aber für andere Monate wie Oktober 2023. Wenn Sie eine bestimmte Abfolge für das Patching implementieren möchten, empfiehlt es sich, dabei einen Abstand von einer Woche einzufügen. In diesem Fall können Sie Ihre Exadata-Infrastrukturressource am Samstag der 1. Woche und die zugehörigen ACDs am Sonntag der 2. Woche einplanen. Dadurch wird stets sichergestellt, dass die Exadata-Infrastrukturressource vor den zugehörigen ACDs gepatcht wird.
-
4-stündiges Fenster, wenn Wartungsvorgänge beginnen können.
-
Pufferzeitraum zwischen Primär- und Standbywartung: Anzahl der Tage zwischen der Standby-ACD-Wartung und der primären ACD-Wartung, d.h. wie viele Tage vor der Wartung der Primärcontainerdatenbank die Wartung der Standbycontainerdatenbank ausgeführt werden soll. Sie können einen beliebigen Wert zwischen 1 und 7 Tagen auswählen.
Die Auswahl des Pufferzeitraums gilt nur für eine autonome Containerdatenbank, die in einer Autonomous Data Guard-Konfiguration die Primärdatenbank ist.
- Vorlaufzeit: Geben Sie an, dass Sie mindestens Wochen vor dem Wartungsereignis eine Benachrichtigung erhalten möchten. Die Angabe der Vorlaufzeit stellt sicher, dass neu freigegebene Wartungsupdates unter Berücksichtigung der erforderlichen Benachrichtigungsfrist eingeplant werden.
Die Vorlaufzeit gilt nicht für die Wartung von autonomen Containerdatenbankressourcen.
- Sie können die Änderungen auf die Standardeinstellungen zurücksetzen, indem Sie Auf Standardwert zurücksetzen auswählen.
Monatliche Infrastruktursicherheitswartung anpassen
Die monatliche Wartung der Infrastruktursicherheit ist bei Bedarf für die Anwendung in einem 21-tägigen Fenster geplant, das zwischen dem 18. und 21. jedes Monats beginnt und bis zum 9. bis zum 12. des folgenden Monats läuft. Sie erhalten mindestens 7 Tage vor Beginn des monatlichen Wartungsfensters eine Benachrichtigung über den vorgeschlagenen Zeitplan. Sie können die monatliche Wartung gegebenenfalls im Fenster auf ein anderes Datum neu planen.
Monatliche Sicherheitspatches können auf einen anderen Zeitpunkt innerhalb des Wartungszeitraums verschoben, aber nicht über das 21-Tage-Fenster hinaus übersprungen oder neu geplant werden. Sie können die monatliche Sicherheitswartung neu planen, wenn Sie die vierteljährliche Wartung neu planen, solange Sie sie im aktuellen Wartungsfenster beibehalten.
Es gibt keine Auswirkungen auf die Autonomous Databases oder Anwendungen, die während der monatlichen Infrastructure-Sicherheitspatching-Aktivität mit ihnen verbunden sind. Updates an Datenbankservern werden online über die Ksplice-Technologie eingespielt, und Storage Server-Updates werden rollierend eingespielt.
Beim Aktualisieren Ihrer Serviceinfrastruktur kann Oracle jedoch einige Vorgänge blockieren, einschließlich Skalierung von Arbeitsspeicher und Speicher, Patching von Betriebssystem und Grid Infrastructure (einschließlich Vorabprüfungen) und elastische Erweiterung von Compute- und Speicherservern. Verschieben Sie diese Vorgänge, bis die Updates abgeschlossen sind. Die Anwendung von Sicherheitsupdates dauert je nach I/O-Aktivität etwa 15 Minuten pro DB-Serverhost und 60 Minuten pro Speicherserver. Wird versucht, einen von den Updates betroffenen Vorgang auszuführen, werden Sie von der Konsole über die laufenden Sicherheitsupdates benachrichtigt. In den Gast-VMs wird keine Software aktualisiert.
One-off-Patches anpassen
In der Wartungsansicht der Oracle Cloud-Konsole können Sie die geplante Startzeit bearbeiten oder den One-off-Patch sofort installieren. Standardmäßig werden One-off-Patches von Oracle innerhalb von 72 Stunden nach Verfügbarkeit des Patches eingespielt. Wenn keine Aktion zum Ändern des Zeitplans ausgeführt wird, wird der Patch automatisch eingespielt. Sie können die One-off-Patches nur innerhalb des aktuellen Quartals neu planen. Ein One-off-Patch kann jedoch nicht vollständig übersprungen werden.
Angeben, welche Art von Patches eingespielt werden soll
Ein Standardwartungsvorgang besteht darin, Datenbanksoftwarepatches in die autonomen Containerdatenbanken und damit auch in die darin erstellten autonomen Datenbanken einzuspielen. Standardmäßig spielt Oracle Releaseupdates (RUs) ein. Sie können den Wartungstyp auf "Nächste RU" konfigurieren, um die autonome Containerdatenbank auf das nächste Releaseupdate zu aktualisieren, oder auf "Neueste RU", um die autonome Containerdatenbank im nächsten Wartungsfenster auf das neueste Releaseupdate zu aktualisieren. Dementsprechend verwendet Oracle einen Imagetyp, der Ihrer Voreinstellung entspricht, wenn verfügbar. Bei Bedarf können Sie einen bestimmten geplanten Patch jederzeit in eine andere Version ändern.
Weitere Informationen finden Sie unter Voreinstellungen für die Wartung autonomer Containerdatenbanken aktualisieren.
Bereits geplante Wartung anzeigen und verwalten
Sobald eine Wartungsaktivität auf Basis des festgelegten Wartungsfensters geplant ist, können Sie den tatsächlichen Zeitpunkt der Aktivität selbst bestimmen. Sie können dabei die Patchversion ändern, den Patch sofort einspielen oder die Aktivität überspringen.
Details der geplanten Wartung
- Status des Ereignisses
- Typ des Ereignisses: "Wöchentlich", "Vierteljährlich", "Monatlich" oder "Jährlich"
- OCID des Ereignisses
- Geplante Startzeit und Datum des Ereignisses
- Wartungsmethode des Ereignisses: "Rolling" oder "Nicht-Rolling-Modus". Dies wird nur für Exadata-Infrastrukturressourcen angezeigt.
- Patchversion, die in das Ereignis eingespielt werden soll. Dies wird nur für autonome Containerdatenbankressourcen angezeigt.
Verwaltungsvorgänge für eine geplante Wartung
- Startzeit und Datum des Ereignisses für einen späteren Zeitpunkt im Quartal neu planen. Geben Sie die neue Startzeit und das neue Datum im Fenster Startzeit der Wartung bearbeiten ein.
- Wartungsereignis sofort starten, indem Sie auf Jetzt patchen klicken.
Hinweis:
Jetzt patchen ist für eine Autonomous Database, die mit Autonomous Data Guard aktiviert ist, nicht verfügbar. Als Workaround können Sie die geplante Wartungszeit ändern, sodass sie im nächsten verfügbaren 4-Stunden-Zeitraum beginnt. Stellen Sie sicher, dass die Standbydatenbank vor der Primärdatenbank gepatcht wird, und zwar mit einem Pufferzeitraum von 1 bis 7 Tagen dazwischen. - Geplantes Wartungsereignis für eine Autonomous-Containerdatenbank überspringen.
Hinweis:
Sie können nicht zwei aufeinander folgende Wartungsereignisse überspringen. Nachdem Sie ein Wartungsereignis übersprungen haben, können Sie das nächste unmittelbar geplante Wartungsereignis nicht überspringen. Sie können Wartungsereignisse nur für zwei alternative Quartale in einem Jahr überspringen. - Eine andere Patchversion zum Einspielen auswählen. Beachten Sie Folgendes bei der Auswahl einer Version:
- Sie müssen eine Version auswählen, die nach der aktuellen Version der autonomen Containerdatenbank liegt.
- Die Liste der verfügbaren Versionen kann sowohl Releaseupdates (RUs) als auch Releaseupdaterevisionen (RURs) enthalten. Sie können unabhängig von dem für die autonome Containerdatenbank konfigurierten Wartungstyp einen beliebigen der beiden Typen auswählen. Wenn Sie einen anderen Typ in der Liste Version auswählen, ändert sich nicht der für die autonome Containerdatenbank konfigurierte Typ.
- Die Exadata-Infrastruktur-Verwaltungsmethode von Rolling in Non-Rolling und umgekehrt aktualisieren.
Automatisches Queuing von Wartungsereignissen
Vierteljährliche Wartungsereignisse verschiedener Autonomous Database-Ressourcen
Wenn Sie einen benutzerdefinierten Wartungsplan für Infrastrukturressourcen auswählen, berücksichtigt Oracle Ihre Präferenzen bei der Planung der Wartungsereignisse. Wenn Ihr benutzerdefinierter Zeitplan jedoch zu Überschneidungen mit anderen Infrastrukturressourcen führt, serialisiert Oracle die Ausführung der Wartungsereignisse automatisch wie folgt: Exadata-Infrastruktur, autonomes Exadata-VM-Cluster, autonome Containerdatenbank. Dabei wird zwischen Ereignissen jeweils eine Zeitlücke eingefügt.
Beispiel: Geben Sie an, dass ein Wartungsereignis für eine Exadata-Infrastrukturressource und ein Wartungsereignis für eine autonome Containerdatenbank planmäßig gleichzeitig gestartet werden sollen. In diesem Fall wird das Wartungsereignis für die Exadata-Infrastrukturressource gestartet. Das Wartungsereignis für die autonome Containerdatenbank wird in die Queue gestellt und unmittelbar nach Abschluss des Wartungsereignisses für die Exadata-Infrastrukturressource gestartet.
Vierteljährliche Wartungsereignisse und monatliche Infrastruktur-Sicherheitspatches
| Scenario | Queuing |
|---|---|
| Wenn eine vierteljährliche Wartungsaktivität innerhalb von 24hours eines monatlichen Infrastruktursicherheitspatches geplant ist. | Die geplante monatliche Wartung wird übersprungen und sofort nach der vierteljährlichen Wartung angewendet. |
| Wenn eine vierteljährliche Wartungsaktivität gleichzeitig mit einem monatlichen Infrastruktursicherheitspatch geplant wird. | Die vierteljährliche Wartung wird zuerst durchgeführt, und der monatliche Sicherheitspatch wird sofort nach Abschluss der vierteljährlichen Wartung eingespielt. |
| Ein monatlicher Infrastruktursicherheitspatch beginnt 0-24 Stunden vor der vierteljährlichen Wartung. |
Die geplante monatliche Wartung wartet und wird sofort nach der vierteljährlichen Wartung ausgeführt. Wird die vierteljährliche Wartung anschließend neu geplant, beginnt die monatliche Sicherheitswartung sofort. Oracle empfiehlt daher, die vierteljährliche und monatliche Wartung gleichzeitig zu planen. Wenn Sie also das vierteljährliche Wartungsereignis im letzten Moment neu planen, wird die monatliche Wartungsaktivität zum geplanten Zeitpunkt nach Bearbeitung des Zeitplans ausgeführt. |
| Wenn eine vierteljährliche Wartung außerhalb des 24-Stunden-Fensters der Sicherheitswartung in demselben Monat geplant wird. |
Sie benötigen ein Wartungsfenster für die vierteljährliche Wartung und ein Wartungsfenster für die Sicherheitswartung. Hinweis: Sie können die Wartung jederzeit vor der geplanten monatlichen Exadata-Infrastruktur neu planen.Die Storage Server werden nur einmal aktualisiert, wenn Sie die monatliche Sicherheitswartung mindestens 25 Stunden vor der vierteljährlichen Wartung in dem Monat planen, in dem sowohl die vierteljährliche als auch die monatliche Sicherheitswartung geplant wurde. |
Vergangene Wartungsereignisse anzeigen
Auf der Seite Details können Sie die vergangenen Wartungsarbeiten einer Exadata-Infrastruktur, eines autonomen Exadata-VM-Clusters oder einer autonomen Containerdatenbankressource anzeigen.
Servicewartungsereignisse überwachen
Sie können die Wartungsereignisse Ihrer Autonomous Database-Infrastrukturressourcen mit den Services Events und Notifications überwachen. Mit den Services Events und Notifications können Sie E-Mail-Benachrichtigungen erhalten, wenn Wartungsereignisse bei der Exadata-Infrastruktur, autonomen Exadata-VM-Clustern und autonomen Containerdatenbankressourcen auftreten.
- Wartung geplant
- Wartungserinnerung
Für die Ressourcen des autonomen Exadata-VM-Clusters (AVMC) und der autonomen Containerdatenbank (ACD) wird die Benachrichtigung zur Wartungserinnerung 1 Woche vor dem eigentlichen Wartungslauf gesendet. Bei Exadata-Infrastrukturressourcen wird die Erinnerungsbenachrichtigung je nach festgelegter Voreinstellung zwischen 1 und 4 Wochen vor dem Wartungslauf freigegeben.
- Wartung - Beginn
- Wartung - Ende
Eine vollständige Liste der Ereignisse, die für jede Infrastrukturressource generiert wurden, finden Sie unter Ereignisse für Autonomous Database on Dedicated Exadata Infrastructure.
- Erstellen Sie ein Notifications-Servicethema.
- Fügen Sie dem Thema ein E-Mail-Abonnement hinzu.
- Fügen Sie eine Ereignisserviceregel hinzu, um Wartungsereignisse an das Notifications-Servicethema zu senden.
Beispiel -: Benachrichtigungen: E-Mails für Wartungsereignisse
Eine Schritt-für-Schritt-Anleitung mit einem Beispiel finden Sie unter Beispiel für Benachrichtigungen: E-Mails für Wartungsereignisse.