Informationen zur autonomen Containerdatenbank

Autonome Containerdatenbank (ACD) ist eine der vier Komponenten des Datenbankarchitekturmodells mit vier Ebenen, das die Grundlage für eine Autonomous Database on Dedicated Exadata Infrastructure ist. ACDs werden in einem autonomen Exadata-VM-Cluster (AVMC) bereitgestellt und dienen als Container für mindestens eine Autonomous Database-Instanz.

Sie können mehrere ACD-Ressourcen in einer AVMC-Ressource erstellen. Sie müssen jedoch mindestens eine solche Ressource erstellen, bevor Sie Autonomous Databases erstellen können. Um ein umfassendes Verständnis der vierschichtigen Architektur zu erhalten, die mit der Autonomous Database on Dedicated Exadata Infrastructure verwendet wird, und um die Positionierung von ACD innerhalb dieser Architektur zu verstehen, lesen Sie Komponenten von Autonomous Database on Dedicated Exadata Infrastructure.

ACDs bieten den Vorteil, isoliert voneinander zu arbeiten, sodass Sie Autonomous Databases nach ihrer beabsichtigten Verwendung trennen können. Beispiel: Sie können verschiedene ACDs für Zwecke wie Produktion und Tests erstellen oder sogar mehrere ACDs mit verschiedenen Datenbankversionen verwenden.

Obwohl Flottenadministratoren ACDs erstellen, überwachen und verwalten, verwenden Anwendungs-DBAs sie hauptsächlich zum Erstellen von Autonomous Databases. Weitere Informationen finden Sie unter Mit Autonomous Database on Dedicated Exadata Infrastructure verknüpfte Benutzerrollen.

Verwandte Themen

Anforderungen der autonomen Containerdatenbank

IAM-Policy-Anforderungen

Sie benötigen einen Oracle Cloud Infrastructure-Account mit Berechtigungen, die über die erforderlichen IAM-Policys erteilt werden. Die erforderlichen Policys hängen von dem Vorgang ab, den Sie ausführen. Eine Liste der IAM-Policys für autonome Containerdatenbanken finden Sie unter Policys zur Verwaltung autonomer Containerdatenbanken.

Mindestens erforderliche Ressourcen

Um eine autonome Containerdatenbank zu erstellen, benötigen Sie mindestens folgende Ressourcen:

8 ECPUs oder 2 OCPUs pro Knoten
50 GB lokaler Speicher pro Knoten

Versionsanforderungen der Oracle Database-Software

Um eine ACD mit der Oracle Database-Softwareversion als 23ai bereitzustellen, müssen Sie ein autonomes ECPU-basiertes Exadata-VM-Cluster (AVMC) auswählen, das mit dem Tag DatabaseVersion erstellt wurde, das auf 23ai gesetzt ist.
Um eine ACD mit der Oracle Database-Softwareversion 19c bereitzustellen, müssen Sie auch ein autonomes Exadata-VM-Cluster (AVMC) auswählen, dessen Tag DatabaseVersion nicht auf 23ai gesetzt ist.
Sie können nicht sowohl 19c- als auch 23ai-ACDs innerhalb desselben AVMC bereitstellen.

Hinweis:

Multicloud-Deployments erfordern kein spezielles Tag und unterstützen automatisch sowohl 19c- als auch 23ai-Datenbanken.

Von autonomer Containerdatenbank verwaltete Datenbankfeatures

Die folgenden Features von Autonomous Database können auf der Ebene der autonomen Containerdatenbank (ACD) definiert und verwaltet werden.

Autonomous Database-Feature	Hinweise:	Weitere Referenz
Oracle Database-Softwareversion Sie können die Softwareversion der Containerdatenbank beim Provisioning einer ACD festlegen.	Sie können die Oracle Database-Softwareversion entweder aus einer Basisimageversion oder einem Autonomous Database-Softwareimage auswählen, das aus einer anderen ACD erstellt wurde. Bei der Auswahl der Version aus dem Basisimage können Sie entweder die neueste Oracle Database-Softwareversion oder den unmittelbaren Vorgänger auswählen. Beispiel: Angenommen, die neueste von Autonomous Database unterstützte Oracle Database-Version ist 19.26.0.1.0. Anschließend werden in der Dropdown-Liste Basisbild auswählen 19.26.0.1.0 und 19.25.0.1.0 angezeigt, die Sie auswählen können. Autonome Containerdatenbanken (ACD) mit der Version der 23ai-Datenbanksoftware können nur auf autonomen ECPU-basierten Exadata-VM-Clustern (AVMC) bereitgestellt werden, die mit den entsprechenden Tags erstellt wurden. Weitere Informationen finden Sie unter Anforderungen für das 23ai Database Software Version Tag. Multicloud-Deployments erfordern kein spezielles Tag und unterstützen automatisch sowohl 19c- als auch 23ai-Datenbanken.	-
Autonomous Data Guard Mit der Konfiguration von Autonomous Data Guard können Sie Ihre kritischen Produktionsdatenbanken trotz Ausfällen für geschäftskritische Anwendungen verfügbar halten.	Sie können Autonomous Data Guard auf der Seite Details einer ACD aktivieren und bis zu zwei Standby-ACDs erstellen. Die zweite Standby-ACD muss sich jedoch im selben Mandanten wie die primäre ACD befinden. Die primären und sekundären ACDs können auch in verschiedenen Regionen (regionsübergreifend) bereitgestellt werden. In einem regionsübergreifenden Autonomous Data Guard-Setup mit vom Kunden verwalteten Schlüsseln oder KMS werden je nach Anzahl von Autonomous Databases in der primären ACD automatisch neue Schlüsselversionen für die Standbydatenbanken im regionsübergreifenden Vault generiert.	Kritische Datenbanken mit Autonomous Data Guard vor Fehlern und Katastrophen schützen
Wartungsplan 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.	Sie können zwischen Rolling- oder Non-Rolling-Wartungsmethoden für eine ACD wählen. Wenn Sie eine Nicht-Rolling-Wartungsmethode in einer Autonomous Data Guard-Konfiguration auswählen, kommt es zu einer Ausfallzeit für die ACD und alle zugehörigen Autonomous Databases, bis das Patching abgeschlossen ist. Optional können Sie auch "Zeitzonenaktualisierung aktivieren" wählen. Zeitzonendateien können nur mit der Nicht-Rolling-Konfigurationsmethode aktualisiert werden. Sie können die Wartungsplaneinstellungen für eine von Oracle zu verwaltende ACD definieren oder ändern oder einen benutzerdefinierten Wartungsplan festlegen. Während Sie den Wartungsplan einer ACD anpassen, können Sie das Patching für ein Quartal überspringen. Sie können das Patching jedoch nicht für zwei aufeinanderfolgende Quartale überspringen. Wenn Sie das Patching für ein Quartal überspringen möchten, 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. Sie können die Anzahl der One-off-Patches, die für eine ACD verfügbar sind, auf der Seite Details anzeigen. Wenn Sie daneben auf den Link Kopieren klicken, werden alle One-off-Patchnummern kopiert. Wenn Sie ein bereits geplantes ACD-Wartungsereignis neu planen, kann Oracle es in eine Queue stellen, sofern für die zugehörige Exadata-Infrastrukturressource oder die autonome Exadata-VM-Clusterressource Folgendes gilt: Wird bereits einem Wartungsupdate unterzogen oder Geplant für eine Wartungsaktivität gleichzeitig als ACD. Sie können eine On-Demand-Wartung zur Aktualisierung von RU (Releaseupdate) zusammen mit der Zeitzonendatei oder nur der Zeitzonendatei für eine ACD planen. Sie können die Aktualisierung auch mit einem vorhandenen benutzerdefinierten Datenbanksoftwareimage vornehmen. Je nach Konfiguration des Wartungsplans Ihrer ACD und der zugehörigen Autonomous Database-Instanzen kann es zu Ausfallzeiten kommen.	Servicewartung Vierteljährliches Wartungsupdate planen
Backup und Wiederherstellung Um High Availability zu unterstützen, sichert Autonomous Database die Datenbank automatisch für Sie. Der Aufbewahrungszeitraum für Backups beträgt bis zu 95 Tage, je nachdem, welche Backupaufbewahrungs-Policys/Periode für die ACD gewählt wurde. Sie können den Zustand der Datenbank zu einem beliebigen Zeitpunkt in diesem Aufbewahrungszeitraum wiederherstellen.	Nach der Aktivierung können automatische Backups für eine ACD nicht mehr deaktiviert werden. Wenn automatische Backups aktiviert sind, können Sie darüber hinaus regionsübergreifende Backups, langfristige Backups und manuelle Backups erstellen. Sie können die Backupaufbewahrungs-Policy/-periode beim Provisioning einer ACD definieren oder sie später auf der Detailseite in der Oracle Cloud Infrastructure-Konsole ändern. In Oracle Public Cloud- und Exadata Cloud@Customer-Deployments: Sie können die Backups einer beendeten ACD entweder bis zu 72 Stunden oder bis zum Ende des Backupaufbewahrungszeitraums aufbewahren. Sie können die Backupaufbewahrungssperre aktivieren, um ein unerwünschtes Löschen der ACD- und Autonomous Database-Backups vor dem Aufbewahrungszeitraum zu verhindern. Sie können die Aufbewahrungssperre entweder beim Provisioning der ACD oder später aktivieren. Nach der Aktivierung können Sie die Aufbewahrungssperre innerhalb von 14 Tagen deaktivieren. Danach wird die Einstellung dauerhaft. Sobald die Aufbewahrungssperre aktiviert ist, können Sie den Wert des Aufbewahrungszeitraums nur noch erhöhen und nicht reduzieren. Alle langfristigen Backups werden ebenfalls gesperrt und können nicht gelöscht werden, wenn die Aufbewahrungssperre aktiviert ist. Die langfristigen Backups werden nach Ablauf automatisch gelöscht. Wenn das Backupziel jedoch NFS ist, werden bei Exadata Cloud@Customer-Deployments keine der Backups automatisch gelöscht, wenn eine ACD beendet wird. Sie müssen alle automatischen, manuellen und langfristigen Backups manuell löschen, nachdem die ACD beendet und das Ablaufdatum verstrichen ist. Weitere Details zu den Werten der Backupaufbewahrungs-Policy für verschiedene Autonomous Database-Deployments finden Sie unter Backupaufbewahrungs-Policy.	Autonome Datenbanken sichern und wiederherstellen.
Backupziel Ein Backupziel definiert die Eigenschaften, die für die Verbindung mit einem Backupverzeichnis erforderlich sind. Jedes Backupziel muss über die VM-Clusterknoten in Ihrem Data Center zugänglich sein.	Die Möglichkeit, beim Provisioning einer ACD ein Backupziel auszuwählen, und die unterstützten Backupziele variieren je nach Deployment-Plattform. Weitere Informationen zu den verschiedenen Backupzieltypen finden Sie unter Backupziel.	Weitere Informationen zum Konfigurieren des NFS-Backupziels für Cloud@Customer finden Sie unter Voraussetzungen für Backupziele für Exadata Cloud@Customer. Anweisungen zum Ändern des Backupzieltyps nach dem Provisioning der ACD finden Sie unter Backupeinstellungen der autonomen Containerdatenbank bearbeiten.
NFS-Speicherauslastung	Gilt nur für: Exadata Cloud@Customer Wenn der aktuelle Backupzieltyp NFS ist, wird die aktuelle NFS-Speicherauslastung zusammen mit einem Statussymbol als Prozentsatz angezeigt.	Weitere Informationen finden Sie unter NFS-Speicherplatzauslastung anzeigen.
Resource Management-Attribute Attribute der Ressourcenverwaltung wirken sich darauf aus, wie Ressourcen verwaltet werden, um entweder mehr Datenbanken zu konsolidieren oder die höchste Datenbankverfügbarkeit zu haben.	Optional können Sie beim Provisioning einer ACD einen geeigneten Wert für die folgenden Ressourcenverwaltungsattribute definieren, der Ihren Anforderungen entspricht: Schwellenwert für Datenbankaufteilung (CPU): Der CPU-Wert, über den hinaus eine Autonomous Database auf mehreren Knoten geöffnet wird. Der Standardwert dieses Attributs ist 16 für OCPUs und 64 für ECPUs. Knoten-Failover-Reservierung (%): Bestimmt den Prozentsatz der CPUs, die über Knoten hinweg reserviert sind, um Knoten-Failover zu unterstützen. Zulässige Werte sind 0%, 25% und 50%, wobei 50% die Standardoption ist. Verteilungsaffinität: Bestimmt, ob eine Autonomous Database über einen Mindest- oder Höchstwert von Knoten geöffnet werden muss. Standardmäßig ist "Minimale Knoten" ausgewählt.	Weitere Informationen dazu, wie sich diese ACD-Attribute auf die Performance Ihrer Datenbanken auswirken, finden Sie unter CPU-Abrechnungsdetails.
Shared Server-Verbindungen Die Shared Server-Architektur ermöglicht es einem Datenbankserver, vielen Client-Prozessen zu erlauben, sehr wenige Server-Prozesse gemeinsam zu nutzen, so dass die Anzahl von Benutzern, die unterstützt werden können, erhöht wird.	Beim Provisioning einer ACD können Sie optional Shared Server-Verbindungen aktivieren. Sie können die Shared Server-Architektur nach dem Provisioning der ACD nicht deaktivieren.	Spezielle Verbindungsfeatures.
Verschlüsselungsschlüssel Standardmäßig erstellt und verwaltet Autonomous Database alle Masterverschlüsselungsschlüssel zum Schutz Ihrer Daten und speichert diese in einem sicheren PKCS 12-Keystore auf denselben Exadata-Systemen, auf denen die Datenbanken gespeichert sind. Wenn die Sicherheits-Policys Ihres Unternehmens dies erfordern, kann Autonomous Database stattdessen Schlüssel verwenden, die Sie erstellen und verwalten.	Beim Provisioning einer ACD können Sie optional die ACD so konfigurieren, dass vom Kunden verwaltete Verschlüsselungsschlüssel statt von Oracle verwalteter Verschlüsselungsschlüssel verwendet werden. Bei der Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln können Sie zwischen den folgenden Optionen wählen: OCI Vault-Service: Mit dieser Option wählen Sie einen Vault und einen Masterverschlüsselungsschlüssel aus. Diese Option ist nur in Oracle Public Cloud verfügbar. Oracle Key Vault: Sie wählen einen Keystore mit dieser Option aus, und geben Sie einen OKV-Endpunktgruppennamen ein. Sie können benutzerdefinierte Verschlüsselungsschlüssel mit Autonomous Data Guard-fähigen ACDs verwenden, wenn sich Primär- und Standbydatenbank in verschiedenen Availability-Domains innerhalb derselben Region befinden.	Masterverschlüsselungsschlüssel Bring Your Own Keys (BYOK) im Vault-Service verwenden Vom Kunden verwaltete Schlüssel in Oracle Key Vault verwenden Verschlüsselungsschlüssel einer autonomen Containerdatenbank rotieren.
Kontakt - E-Mail Sie können Kontakt-E-Mails bereitstellen, in denen Sie Betriebsbenachrichtigungen, Ankündigungen und ungeplante Wartungsbenachrichtigungen zu Ihrer autonomen Containerdatenbank erhalten können.	Oracle empfiehlt, nach Möglichkeit die E-Mail-Adresse einer Administratorgruppe und nicht die einer Person zu verwenden, um sicherzustellen, dass keine wichtigen Benachrichtigungen oder Ankündigungen übersehen werden.
Full Stack Disaster Recovery Full Stack DR ist ein Disaster-Recovery-Orchestrierungs- und -Managementservice von Oracle Cloud Infrastructure (OCI), der alle Layer eines Anwendungsstacks, einschließlich Infrastruktur, Middleware, Datenbank und Anwendung, umfasst.	Sie können das OCI Full Stack Disaster Recovery aktivieren und damit Switchover-/Failover-Vorgänge ausführen oder optional nur Autonomous Database-Switchover-/Failover-Vorgänge für Datenbanken ausführen.	OCI Full Stack Disaster Recovery in Autonomous Database on Dedicated Exadata Infrastructure verwenden
Regionsübergreifende Backupkopie Sie können eine sekundäre Region für eine Kopie Ihrer Backups auswählen. Bei einem Regionsfehler können Sie das Remotebackup der ACD klonen, um die Daten wiederherzustellen. Das Backup einer ACD kann nur in einem autonomen Exadata-VM-Cluster (AVMC) geklont werden, das sich von seinem Quell-AVMC unterscheidet.	Gilt nur für: Oracle Public Cloud Die regionsübergreifende Backupkopie kann beim Provisioning einer ACD oder auf der Detailseite einer vorhandenen ACD aktiviert werden. Sie können das regionsübergreifende Backup nicht aktivieren, wenn Autonomous Data Guard aktiviert ist.	Autonome Containerdatenbank auf dedizierter Exadata-Infrastruktur klonen Autonome Containerdatenbank klonen

Autonomous Database-Feature

Hinweise:

Weitere Referenz

Oracle Database-Softwareversion

Sie können die Softwareversion der Containerdatenbank beim Provisioning einer ACD festlegen.

Sie können die Oracle Database-Softwareversion entweder aus einer Basisimageversion oder einem Autonomous Database-Softwareimage auswählen, das aus einer anderen ACD erstellt wurde.

Bei der Auswahl der Version aus dem Basisimage können Sie entweder die neueste Oracle Database-Softwareversion oder den unmittelbaren Vorgänger auswählen. Beispiel: Angenommen, die neueste von Autonomous Database unterstützte Oracle Database-Version ist 19.26.0.1.0. Anschließend werden in der Dropdown-Liste Basisbild auswählen 19.26.0.1.0 und 19.25.0.1.0 angezeigt, die Sie auswählen können.

Autonome Containerdatenbanken (ACD) mit der Version der 23ai-Datenbanksoftware können nur auf autonomen ECPU-basierten Exadata-VM-Clustern (AVMC) bereitgestellt werden, die mit den entsprechenden Tags erstellt wurden. Weitere Informationen finden Sie unter Anforderungen für das 23ai Database Software Version Tag. Multicloud-Deployments erfordern kein spezielles Tag und unterstützen automatisch sowohl 19c- als auch 23ai-Datenbanken.

Autonomous Data Guard

Mit der Konfiguration von Autonomous Data Guard können Sie Ihre kritischen Produktionsdatenbanken trotz Ausfällen für geschäftskritische Anwendungen verfügbar halten.

Sie können Autonomous Data Guard auf der Seite Details einer ACD aktivieren und bis zu zwei Standby-ACDs erstellen. Die zweite Standby-ACD muss sich jedoch im selben Mandanten wie die primäre ACD befinden.

Die primären und sekundären ACDs können auch in verschiedenen Regionen (regionsübergreifend) bereitgestellt werden. In einem regionsübergreifenden Autonomous Data Guard-Setup mit vom Kunden verwalteten Schlüsseln oder KMS werden je nach Anzahl von Autonomous Databases in der primären ACD automatisch neue Schlüsselversionen für die Standbydatenbanken im regionsübergreifenden Vault generiert.

Kritische Datenbanken mit Autonomous Data Guard vor Fehlern und Katastrophen schützen

Wartungsplan

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.

Sie können zwischen Rolling- oder Non-Rolling-Wartungsmethoden für eine ACD wählen. Wenn Sie eine Nicht-Rolling-Wartungsmethode in einer Autonomous Data Guard-Konfiguration auswählen, kommt es zu einer Ausfallzeit für die ACD und alle zugehörigen Autonomous Databases, bis das Patching abgeschlossen ist. Optional können Sie auch "Zeitzonenaktualisierung aktivieren" wählen. Zeitzonendateien können nur mit der Nicht-Rolling-Konfigurationsmethode aktualisiert werden.

Sie können die Wartungsplaneinstellungen für eine von Oracle zu verwaltende ACD definieren oder ändern oder einen benutzerdefinierten Wartungsplan festlegen.

Während Sie den Wartungsplan einer ACD anpassen, können Sie das Patching für ein Quartal überspringen. Sie können das Patching jedoch nicht für zwei aufeinanderfolgende Quartale überspringen. Wenn Sie das Patching für ein Quartal überspringen möchten, 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.

Sie können die Anzahl der One-off-Patches, die für eine ACD verfügbar sind, auf der Seite Details anzeigen. Wenn Sie daneben auf den Link Kopieren klicken, werden alle One-off-Patchnummern kopiert.

Wenn Sie ein bereits geplantes ACD-Wartungsereignis neu planen, kann Oracle es in eine Queue stellen, sofern für die zugehörige Exadata-Infrastrukturressource oder die autonome Exadata-VM-Clusterressource Folgendes gilt:

Wird bereits einem Wartungsupdate unterzogen oder
Geplant für eine Wartungsaktivität gleichzeitig als ACD.

Sie können eine On-Demand-Wartung zur Aktualisierung von RU (Releaseupdate) zusammen mit der Zeitzonendatei oder nur der Zeitzonendatei für eine ACD planen. Sie können die Aktualisierung auch mit einem vorhandenen benutzerdefinierten Datenbanksoftwareimage vornehmen.

Je nach Konfiguration des Wartungsplans Ihrer ACD und der zugehörigen Autonomous Database-Instanzen kann es zu Ausfallzeiten kommen.

Servicewartung

Vierteljährliches Wartungsupdate planen

Backup und Wiederherstellung

Um High Availability zu unterstützen, sichert Autonomous Database die Datenbank automatisch für Sie. Der Aufbewahrungszeitraum für Backups beträgt bis zu 95 Tage, je nachdem, welche Backupaufbewahrungs-Policys/Periode für die ACD gewählt wurde. Sie können den Zustand der Datenbank zu einem beliebigen Zeitpunkt in diesem Aufbewahrungszeitraum wiederherstellen.

Nach der Aktivierung können automatische Backups für eine ACD nicht mehr deaktiviert werden. Wenn automatische Backups aktiviert sind, können Sie darüber hinaus regionsübergreifende Backups, langfristige Backups und manuelle Backups erstellen.

Sie können die Backupaufbewahrungs-Policy/-periode beim Provisioning einer ACD definieren oder sie später auf der Detailseite in der Oracle Cloud Infrastructure-Konsole ändern.

In Oracle Public Cloud- und Exadata Cloud@Customer-Deployments:

Sie können die Backups einer beendeten ACD entweder bis zu 72 Stunden oder bis zum Ende des Backupaufbewahrungszeitraums aufbewahren.
Sie können die Backupaufbewahrungssperre aktivieren, um ein unerwünschtes Löschen der ACD- und Autonomous Database-Backups vor dem Aufbewahrungszeitraum zu verhindern.
Sie können die Aufbewahrungssperre entweder beim Provisioning der ACD oder später aktivieren.
Nach der Aktivierung können Sie die Aufbewahrungssperre innerhalb von 14 Tagen deaktivieren. Danach wird die Einstellung dauerhaft.
Sobald die Aufbewahrungssperre aktiviert ist, können Sie den Wert des Aufbewahrungszeitraums nur noch erhöhen und nicht reduzieren.
Alle langfristigen Backups werden ebenfalls gesperrt und können nicht gelöscht werden, wenn die Aufbewahrungssperre aktiviert ist.

Die langfristigen Backups werden nach Ablauf automatisch gelöscht. Wenn das Backupziel jedoch NFS ist, werden bei Exadata Cloud@Customer-Deployments keine der Backups automatisch gelöscht, wenn eine ACD beendet wird. Sie müssen alle automatischen, manuellen und langfristigen Backups manuell löschen, nachdem die ACD beendet und das Ablaufdatum verstrichen ist.

Weitere Details zu den Werten der Backupaufbewahrungs-Policy für verschiedene Autonomous Database-Deployments finden Sie unter Backupaufbewahrungs-Policy.

Autonome Datenbanken sichern und wiederherstellen.

Backupziel

Ein Backupziel definiert die Eigenschaften, die für die Verbindung mit einem Backupverzeichnis erforderlich sind. Jedes Backupziel muss über die VM-Clusterknoten in Ihrem Data Center zugänglich sein.

Die Möglichkeit, beim Provisioning einer ACD ein Backupziel auszuwählen, und die unterstützten Backupziele variieren je nach Deployment-Plattform.

Weitere Informationen zu den verschiedenen Backupzieltypen finden Sie unter Backupziel.

Weitere Informationen zum Konfigurieren des NFS-Backupziels für Cloud@Customer finden Sie unter Voraussetzungen für Backupziele für Exadata Cloud@Customer.

Anweisungen zum Ändern des Backupzieltyps nach dem Provisioning der ACD finden Sie unter Backupeinstellungen der autonomen Containerdatenbank bearbeiten.

NFS-Speicherauslastung

Gilt nur für: Exadata Cloud@Customer

Wenn der aktuelle Backupzieltyp NFS ist, wird die aktuelle NFS-Speicherauslastung zusammen mit einem Statussymbol als Prozentsatz angezeigt.

Weitere Informationen finden Sie unter NFS-Speicherplatzauslastung anzeigen.

Resource Management-Attribute

Attribute der Ressourcenverwaltung wirken sich darauf aus, wie Ressourcen verwaltet werden, um entweder mehr Datenbanken zu konsolidieren oder die höchste Datenbankverfügbarkeit zu haben.

Optional können Sie beim Provisioning einer ACD einen geeigneten Wert für die folgenden Ressourcenverwaltungsattribute definieren, der Ihren Anforderungen entspricht:

Schwellenwert für Datenbankaufteilung (CPU): Der CPU-Wert, über den hinaus eine Autonomous Database auf mehreren Knoten geöffnet wird. Der Standardwert dieses Attributs ist 16 für OCPUs und 64 für ECPUs.
Knoten-Failover-Reservierung (%): Bestimmt den Prozentsatz der CPUs, die über Knoten hinweg reserviert sind, um Knoten-Failover zu unterstützen. Zulässige Werte sind 0%, 25% und 50%, wobei 50% die Standardoption ist.
Verteilungsaffinität: Bestimmt, ob eine Autonomous Database über einen Mindest- oder Höchstwert von Knoten geöffnet werden muss. Standardmäßig ist "Minimale Knoten" ausgewählt.

Weitere Informationen dazu, wie sich diese ACD-Attribute auf die Performance Ihrer Datenbanken auswirken, finden Sie unter CPU-Abrechnungsdetails.

Shared Server-Verbindungen

Die Shared Server-Architektur ermöglicht es einem Datenbankserver, vielen Client-Prozessen zu erlauben, sehr wenige Server-Prozesse gemeinsam zu nutzen, so dass die Anzahl von Benutzern, die unterstützt werden können, erhöht wird.

Beim Provisioning einer ACD können Sie optional Shared Server-Verbindungen aktivieren. Sie können die Shared Server-Architektur nach dem Provisioning der ACD nicht deaktivieren.

Spezielle Verbindungsfeatures.

Verschlüsselungsschlüssel

Standardmäßig erstellt und verwaltet Autonomous Database alle Masterverschlüsselungsschlüssel zum Schutz Ihrer Daten und speichert diese in einem sicheren PKCS 12-Keystore auf denselben Exadata-Systemen, auf denen die Datenbanken gespeichert sind.

Wenn die Sicherheits-Policys Ihres Unternehmens dies erfordern, kann Autonomous Database stattdessen Schlüssel verwenden, die Sie erstellen und verwalten.

Beim Provisioning einer ACD können Sie optional die ACD so konfigurieren, dass vom Kunden verwaltete Verschlüsselungsschlüssel statt von Oracle verwalteter Verschlüsselungsschlüssel verwendet werden.

Bei der Verwendung von vom Kunden verwalteten Verschlüsselungsschlüsseln können Sie zwischen den folgenden Optionen wählen:

OCI Vault-Service: Mit dieser Option wählen Sie einen Vault und einen Masterverschlüsselungsschlüssel aus. Diese Option ist nur in Oracle Public Cloud verfügbar.
Oracle Key Vault: Sie wählen einen Keystore mit dieser Option aus, und geben Sie einen OKV-Endpunktgruppennamen ein.

Sie können benutzerdefinierte Verschlüsselungsschlüssel mit Autonomous Data Guard-fähigen ACDs verwenden, wenn sich Primär- und Standbydatenbank in verschiedenen Availability-Domains innerhalb derselben Region befinden.

Masterverschlüsselungsschlüssel

Bring Your Own Keys (BYOK) im Vault-Service verwenden

Vom Kunden verwaltete Schlüssel in Oracle Key Vault verwenden

Verschlüsselungsschlüssel einer autonomen Containerdatenbank rotieren.

Kontakt - E-Mail

Sie können Kontakt-E-Mails bereitstellen, in denen Sie Betriebsbenachrichtigungen, Ankündigungen und ungeplante Wartungsbenachrichtigungen zu Ihrer autonomen Containerdatenbank erhalten können.

Oracle empfiehlt, nach Möglichkeit die E-Mail-Adresse einer Administratorgruppe und nicht die einer Person zu verwenden, um sicherzustellen, dass keine wichtigen Benachrichtigungen oder Ankündigungen übersehen werden.

Full Stack Disaster Recovery

Full Stack DR ist ein Disaster-Recovery-Orchestrierungs- und -Managementservice von Oracle Cloud Infrastructure (OCI), der alle Layer eines Anwendungsstacks, einschließlich Infrastruktur, Middleware, Datenbank und Anwendung, umfasst.

Sie können das OCI Full Stack Disaster Recovery aktivieren und damit Switchover-/Failover-Vorgänge ausführen oder optional nur Autonomous Database-Switchover-/Failover-Vorgänge für Datenbanken ausführen.

OCI Full Stack Disaster Recovery in Autonomous Database on Dedicated Exadata Infrastructure verwenden

Regionsübergreifende Backupkopie

Sie können eine sekundäre Region für eine Kopie Ihrer Backups auswählen. Bei einem Regionsfehler können Sie das Remotebackup der ACD klonen, um die Daten wiederherzustellen. Das Backup einer ACD kann nur in einem autonomen Exadata-VM-Cluster (AVMC) geklont werden, das sich von seinem Quell-AVMC unterscheidet.

Gilt nur für:

Oracle Public Cloud

Die regionsübergreifende Backupkopie kann beim Provisioning einer ACD oder auf der Detailseite einer vorhandenen ACD aktiviert werden.

Sie können das regionsübergreifende Backup nicht aktivieren, wenn Autonomous Data Guard aktiviert ist.

Autonome Containerdatenbank auf dedizierter Exadata-Infrastruktur klonen

Autonome Containerdatenbank klonen

Verwaltungsvorgänge für autonome Containerdatenbanken

Sie können die folgenden Verwaltungsvorgänge in einer autonomen Containerdatenbank ausführen.

Vorgang	Aufgabenanweisungen
Autonome Containerdatenbank erstellen	Autonome Containerdatenbank erstellen
Backupaufbewahrungs-Policy einer autonomen Containerdatenbank ändern	Einstellungen für das Backup der autonomen Containerdatenbank bearbeiten
Autonomous Database-Softwareimage erstellen	Autonomous Database-Softwareimage erstellen
Wartungsvoreinstellungen einer autonomen Containerdatenbank bearbeiten	Wartungseinstellungen für autonome Containerdatenbank aktualisieren
Autonomous Data Guard-Konfiguration ändern	Autonomous Data Guard-Konfiguration ändern
Autonome Containerdatenbank in ein anderes Compartment verschieben	Autonome Containerdatenbank in anderes Compartment verschieben
Verschlüsselungsschlüssel für autonome Containerdatenbank rotieren	Verschlüsselungsschlüssel einer autonomen Containerdatenbank rotieren
Autonome Containerdatenbank neu starten	Autonome Containerdatenbank neu starten
Autonome Containerdatenbank beenden	Autonome Containerdatenbank beenden
Kundenkontakte für eine autonome Containerdatenbank verwalten	Kundenkontakte für eine autonome Containerdatenbank verwalten
Liste der autonomen Containerdatenbanken anzeigen	Liste der autonomen Containerdatenbanken anzeigen
Details einer autonomen Containerdatenbank anzeigen	Details einer autonomen Containerdatenbank anzeigen
NFS-Speicherauslastung anzeigen	Gilt nur für: Exadata Cloud@Customer NFS-Speicherauslastung anzeigen

Die oben aufgeführten Vorgänge können auch mit API erreicht werden. Weitere Informationen finden Sie unter API zum Verwalten autonomer Containerdatenbanken.

Überwachen der autonomen Containerdatenbank

Mit dynamischen Performance-Views können Sie die autonome Containerdatenbank (ACD) wie folgt überwachen:

Echtzeitmetriken für verschiedene Wait-Ereignisse und Wait-Klassen anzeigen
Zeigen Sie historische Snapshots von Wait-Klassenmetriken an.
Zeigen Sie Echtzeit-, historische und zusammenfassende Performancemetrikdaten an.
Zeigen Sie die Ressourcenlimits und die aktuelle Nutzung an.

Ausführliche Informationen finden Sie unter Dynamische Performanceansichten.

Titel und Copyright-Informationen

Oracle und/oder verbundene Unternehmen.