Primär- und Standbydatenbanken in einer Autonomous Data Guard-Konfiguration
Hier erfahren Sie, wie Primär- und Standbydatenbanken in einer autonomen Data Guard-Konfiguration verwaltet werden.
Wenn Sie eine autonome KI-Datenbank in einer autonomen Containerdatenbank erstellen, für die Autonomous Data Guard aktiviert ist, werden zwei vollständig separate Kopien Ihrer Datenbank erstellt: eine in einer primären Containerdatenbank und eine (synchronisierte Kopie) in einer Standbycontainerdatenbank. Sollte die Primärcontainerdatenbank dann nicht mehr verfügbar sein, konvertiert Autonomous Data Guard die Standbycontainerdatenbank automatisch in die Primärcontainerdatenbank, und beginnt damit, Anwendungsverbindungen zu Ihrer autonomen KI-Datenbank zu warten.
Hinweis: Da bei der Verwendung von Autonomous Data Guard zwei autonome AI-Datenbanken erstellt werden, wird die doppelte Anzahl von CPU- und Speicherressourcen genutzt, die Hälfte für die Primärdatenbank und die Hälfte für die Standbydatenbank.
Diese beiden Datenbanken, die häufig als Peerdatenbanken bezeichnet werden, werden durch die Labels Primär und Standby in der Liste der autonomen KI-Datenbanken und auf der Seite "Details" für die Datenbank identifiziert.
Informationen dazu, wie Flottenadministratoren autonome Containerdatenbanken mit aktiviertem Autonomous Data Guard erstellen und verwalten, finden Sie unter Autonomous Data Guard verwalten.
Verwaltungsvorgänge für Primär- und Standbydatenbanken
Da die beiden Datenbanken verknüpft und synchronisiert sind, funktionieren einige der Verwaltungsvorgänge, die Sie in autonomen KI-Datenbanken ausführen, für die Primär- und die Standbydatenbank in einer Autonomous Data Guard-Konfiguration anders als bei Standarddatenbanken. In der folgenden Liste werden diese Unterschiede beschrieben.
-
Vertikale, horizontale Skalierung und Autoscaling
Die beiden Peerdatenbanken müssen dieselbe CPU-Anzahl, Speichergröße und Autoscaling-Einstellung haben. Daher können Sie die Datenbanken nur auf der Seite "Details" der Primärdatenbank vertikal oder horizontal skalieren bzw. nur dort Autoscaling-Einstellungen ändern. Die von Ihnen vorgenommenen Änderungen wirken sich sowohl auf die Primär- als auch auf die Standbydatenbank aus.
-
Stoppen, starten und neu starten
Der Lebenszyklusstatus der beiden Peerdatenbanken bleibt synchronisiert. Daher können Sie die Datenbank nur auf der Seite "Details" der Primärdatenbank stoppen, starten und neu starten. Der von Ihnen ausgeführte Vorgang wirkt sich sowohl auf die Primär- als auch auf die Standbydatenbank aus.
-
Manuell sichern
Sie können die Primär- und die Standbydatenbank separat und unabhängig voneinander sichern, genauso wie Standarddatenbanken.
-
Wiederherstellen
Sie können die Datenbank nur auf der Seite "Details" der Primärdatenbank wiederherstellen.
-
Klonen
Sie können die Datenbank nur auf der Seite "Details" der Primärdatenbank klonen.
-
Verschlüsselungsschlüssel rotieren
Sie können die Verschlüsselungsschlüssel der Primär- und Standbydatenbank separat und unabhängig rotieren, genauso wie bei Standarddatenbanken.
-
Zu einem anderen Compartment wechseln
Sie können die Primär- und die Standbydatenbank genauso wie Standarddatenbanken separat und unabhängig in andere Compartments verschieben.
-
Beenden
Sie können die Datenbank nur auf der Seite "Details" der Primärdatenbank beenden.
Aus Clientanwendungen auf Standbydatenbanken zugreifen
Bei Verwendung von Autonomous Data Guard stellen Clientanwendungen in der Regel eine Verbindung zur Primärdatenbank her und führen Vorgänge für diese Datenbank aus.
Neben dieser normalen Konnektivität bietet Ihnen Autonomous Data Guard die Möglichkeit, Clientanwendungen, die nur schreibgeschützte Vorgänge ausführen, mit der Standbydatenbank zu verbinden. Um diese Option nutzen zu kann, stellen Clientanwendungen eine Verbindung zur Datenbank mit Datenbankservicenamen bereit, die "_RO" (für "schreibgeschützt") enthalten, wie unter Vordefinierte Datenbankservicenamen für autonome KI-Datenbanken beschrieben.
Lag-Zeiten überwachen
Während die Datenbanken, die Autonomous Data Guard verwenden, ausgeführt werden, können Sie Transport- und Apply-Lagzeiten auf der Seite "Details" der Primär- oder Standbydatenbank überwachen, indem Sie auf Autonomous Data Guard klicken.
Sie sollten mit einer geringfügigen Fluktuation im Laufe der Zeit rechnen, während die Workloads in der Datenbank ab- und zunehmen. Wenn Sie jedoch einen anhaltenden Aufwärtstrend bei der Lag-Zeit feststellen, können Sie das Problem wie folgt beheben:
-
Aufwärtstrend bei Apply Lag. Ein anhaltender Aufwärtstrend beim Apply Lag weist darauf hin, dass die Standbydatenbank keine ausreichende Kapazität hat, um mit den von der Primärdatenbank eingehenden Redo-Datensätzen Schritt zu halten. Um diese Situation zu beheben, skalieren Sie die CPUs der Datenbank, wie unter CPU- oder Speicherressourcen zu einer dedizierten autonomen KI-Datenbank hinzufügen beschrieben.
-
Aufwärtstrend bei Transport-Lag. Ein anhaltender Aufwärtstrend beim Transport-Lag weist auf ein Problem mit der Netzwerkperformance hin. Das Oracle Cloud-Betriebspersonal überwacht konstant die Netzwerkperformance, sodass das Problem behoben werden sollte, ohne dass Sie Maßnahmen ergreifen müssen. Bei Bedarf können Sie das Problem jedoch dem Betriebspersonal melden, indem Sie eine Serviceanfrage stellen.