Primär- und Standby-Datenbanken in einer Autonomous Data Guard-Konfiguration verwalten
Hier erfahren Sie, wie Sie Primär- und Standbydatenbanken in einer Autonomous Data Guard-Konfiguration verwalten.
Wenn Sie eine Autonomous Database in einer autonomen Containerdatenbank erstellen, für die Autonomous Data Guard aktiviert ist, werden zwei vollständig separate Kopien der Datenbank erstellt: eine in einer primären Containerdatenbank und eine synchronisierte Kopie in einer Standby-Containerdatenbank. Sollte die Primärcontainerdatenbank dann nicht mehr verfügbar sein, konvertiert Autonomous Data Guard die Standbycontainerdatenbank automatisch in die Primärcontainerdatenbank. Daher beginnt sie mit der Wartung von Anwendungsverbindungen zu Autonomous Database.
Hinweis:
Da bei Verwendung von Autonomous Data Guard zwei autonome Datenbanken erstellt werden, wird die doppelte Anzahl von CPU- und Speicherressourcen genutzt, die Hälfte für die Primärdatenbank und die andere 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 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 für autonome Datenbanken ausführen, in der Primär- und der Standbydatenbank in einer Autonomous Data Guard-Konfiguration anders als bei Standarddatenbanken. In der folgenden Liste werden diese Unterschiede beschrieben.
- Scale-up, Scale-down und Autoscaling
Die beiden Peerdatenbanken müssen dieselbe CPU-Anzahl, Speichergröße und Autoskalierungseinstellung aufweisen. 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.
- Clonen
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 Verbindung 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 können, stellen Clientanwendungen eine Verbindung zur Datenbank mit Datenbankservicenamen her, die "_RO" ("Read-Only" bzw. "schreibgeschützt") enthalten, wie unter Vordefinierte Datenbankservicenamen für autonome 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 nicht über ausreichende Kapazität für die von der Primärdatenbank eingehenden Redo-Datensätze verfügt. Um diese Situation zu beheben, skalieren Sie die CPUs der Datenbank, wie unter CPU- oder Speicherressourcen zu einer dedizierten Autonomous Database 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.