Autonomous Data Guard mit Autonomous Database on Exadata Cloud@Customer verwenden

Hier erfahren Sie, wie Sie eine Data Guard-Verknüpfung zwischen Datenbanken aktivieren, die Rolle einer Datenbank in einer Data Guard-Verknüpfung mit einem Switchover- oder Failover-Vorgang ändern und eine Datenbank nach Fehler neu instanziieren.

Autonomous Data Guard auf autonomer Containerdatenbank aktivieren

Wenn Sie Data Guard aktivieren, wird eine separate Data Guard-Verknüpfung für die Primär- und die Standbydatenbank erstellt.

Hinweis

Die Replikation von Daten erfolgt nur über das Clientnetzwerk.

Autonome Containerdatenbank mit aktiviertem Autonomous Data Guard erstellen

Führen Sie diese Schritte aus, um eine autonome Containerdatenbank mit aktiviertem Autonomous Data Guard auf einem Oracle Exadata Cloud@Customer-System zu erstellen.

Hinweis

Für eine bessere Verwaltung und gemeinsame Nutzung der zugrunde liegenden SGA-/Speicherressourcen empfiehlt Oracle, dass sich alle für In-Memory konfigurierten autonomen Datenbanken in derselben autonomen Containerdatenbank befinden.

Mindestens erforderliche Ressourcen

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

  • 2 OCPUs oder 8 ECPUs
  • 50 GB lokaler Speicher
  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie auf Autonome Containerdatenbank erstellen.
    Die Seite "Autonome Containerdatenbank erstellen" wird angezeigt.
  4. Geben Sie die folgenden grundlegenden Informationen ein:
    • Compartment: Wählen Sie das Compartment aus, in dem die autonome Containerdatenbank erstellt werden soll.
    • Anzeigename: Geben Sie eine benutzerfreundliche Beschreibung oder sonstige Informationen ein, anhand derer Sie die autonome Datenbank leicht identifizieren können. Der Anzeigename muss nicht eindeutig sein. Geben Sie dabei keine vertraulichen Informationen ein.
  5. Wählen Sie das autonome Exadata-VM-Cluster aus, das Sie zum Erstellen der autonomen Containerdatenbank verwenden möchten.
    Hinweis

    Wenn das ausgewählte autonome Exadata-VM-Cluster nicht über 2 verfügbare OCPUs oder 8 verfügbare ECPUs pro Knoten (Mindestanforderung für das Erstellen einer autonomen Containerdatenbank) verfügt, ist dieses Feld ausgegraut. Wählen Sie ein autonomes Exadata-VM-Cluster aus, das über genügend Ressourcen zum Erstellen einer autonomen Containerdatenbank verfügt.

  6. Wählen Sie die Softwareversion der Container-DB aus.
    • Version aus Basisimages auswählen: Erstellen Sie eine Datenbank mit der ausgewählten Oracle Database-Version.
      • Basisimage auswählen: Die neueste Version ist standardmäßig ausgewählt. Wählen Sie bei Bedarf eine Datenbankversion (N, N-1) aus.
  7. Aktivieren Sie unter Autonomous Data Guard konfigurieren das Kontrollkästchen Autonomous Data Guard aktivieren, und geben Sie die folgenden Details ein.
    • Compartment von autonomer Peerdatenbank: Wählen Sie das Compartment aus, in dem die autonome Standbydatenbank erstellt werden soll.
    • Anzeigename: Geben Sie eine benutzerfreundliche Beschreibung oder sonstige Informationen ein, anhand derer Sie die autonome Datenbank leicht identifizieren können. Der Anzeigename muss nicht eindeutig sein. Geben Sie dabei keine vertraulichen Informationen ein.
    • Autonomes Peer-Exadata-VM-Cluster auswählen: Geben Sie die folgenden Werte für die Standby-Datenbank ein:
      • Peerregion: Wählen Sie eine Peerregion aus.
      • Peer-Exadata: Wählen Sie die Exadata-Cloud@Customer-Infrastruktur aus, in der die Standby-Datenbank erstellt werden soll. Klicken Sie auf den Hyperlink Compartment ändern, um ein Compartment auszuwählen.
      • Autonomous-Peer-Exadata-VM-Cluster: Wählen Sie das autonome VM-Cluster aus, in dem die Standby-ACD erstellt werden muss. Klicken Sie auf den Hyperlink Compartment ändern, um ein Compartment auszuwählen.

        Die autonomen Primär- und Standbycontainerdatenbanken müssen sich auf zwei verschiedenen autonomen VM-Clustern auf derselben Exadata-Infrastruktur oder verschiedenen Exadata-Infrastrukturen befinden.

        Hinweis

        Wenn das ausgewählte autonome Exadata-VM-Cluster nicht über 2 verfügbare OCPUs pro Knoten (Mindestanforderung für das Erstellen einer autonomen Containerdatenbank) verfügt, ist dieses Feld ausgegraut. Wählen Sie ein autonomes Exadata-VM-Cluster aus, das über genügend Ressourcen zum Erstellen einer autonomen Containerdatenbank verfügt.
    • Datenschutzmodus: Geben Sie den Schutzmodus an, der für diese Data Guard-Verbindung verwendet wird.
      • Maximale Performance: Stellt den höchsten Grad des Datenschutzes bereit, der möglich ist, ohne die Verfügbarkeit einer Primärdatenbank zu beeinträchtigen.
      • Maximale Verfügbarkeit: Stellt den höchsten Grad des Datenschutzes bereit, der möglich ist, ohne die Performance einer Primärdatenbank zu beeinträchtigen. Dies ist der Standardschutzmodus.

        Weitere Informationen zu den Schutzmodi in Oracle Data Guard finden Sie unter Oracle Data Guard: Konzepte und Administration.

    • Automatischen Failover aktivieren: Aktivieren Sie dieses Kontrollkästchen, um den automatischen Failover zu aktivieren und den Lag-Grenzwert für FSFO festzulegen.

      Lag-Grenzwert für Fast-Start Failover (FSFO): Legen Sie den Lag-Grenzwert für Fast-Start Failover (FSFO) in 1er Schritten fest. Minimum: 5 und Maximum: 3600 Sekunden. Standardwert: 30 Sekunden.

      Hinweis

      Der Lag-Grenzwert für FSFO gilt nur für den Schutzmodus "Maximale Performance".
  8. Optional können Sie einen automatischen Wartungsplan konfigurieren.
    1. Klicken Sie auf Wartungsvoreinstellungen bearbeiten.
    2. Wartungsversion der Containerdatenbank konfigurieren
      • Nächstes Releaseupdate (RU): Führen Sie im nächsten Wartungszyklus eine Aktualisierung auf das nächste Releaseupdate durch.
      • Neuestes Releaseupdate (RU): Führen Sie im nächsten Wartungszyklus eine Aktualisierung auf das neueste Releaseupdate durch.

      Weitere Informationen finden Sie unter Verwaltungsvorgänge.

    3. Um den Wartungsplan zu konfigurieren, wählen Sie Zeitplan angeben.

      Wählen Sie einen bevorzugten Monat und Wochentag sowie die bevorzugte Woche und Startzeit für die Wartung der autonomen Containerdatenbank aus.

      • Geben Sie unter Woche des Monats an, in welcher Woche des Monats die Wartung stattfinden soll. Wochen beginnen jeweils am 1., 8., 15. und 22. Tag des Monats und dauern jeweils 7 Tage. 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.
      • Geben Sie unter Tag der Woche den Wochentag an, an dem die Wartung stattfinden soll.
      • Geben Sie unter Startstunde die Stunde an, in der der Wartungslauf beginnen soll.
    4. Klicken Sie auf Änderungen speichern.
  9. Automatische Backups aktivieren.

    Standardmäßig sind automatische Backups für eine ACD aktiviert. Optional können Sie sie deaktivieren, indem Sie das Kontrollkästchen "Automatische Backups aktivieren" deaktivieren.

    Beim Provisioning einer ACD mit Autonomous Data Guard können Sie die automatischen Backups nicht deaktivieren.

    Hinweis

    Wenn diese Option für eine ACD deaktiviert ist, können automatische Backups jederzeit später über die Oracle Cloud Infrastructure-(OCI-)Konsole aktiviert werden. Gehen Sie dazu wie unter Backupeinstellungen für autonome Containerdatenbank bearbeiten beschrieben vor. Nach der Aktivierung können Sie jedoch keine automatischen Backups für die ACD deaktivieren.

    Wenn die Aktivierung automatischer Backups aus irgendeinem Grund nicht erfolgreich verläuft, verläuft das ACD-Provisioning ebenfalls mit einer Fehlermeldung nicht erfolgreich. Als Workaround können Sie die ACD mit deaktivierten automatischen Backups bereitstellen und sie später auf der Seite "Details" der ACD aktivieren.

  10. Wählen Sie einen Backupzieltyp:
    Hinweis

    Der Backupzieltyp kann nur bei der Aktivierung automatischer Backups auf einer ACD festgelegt und später nicht mehr geändert werden.
    Folgende Optionen sind möglich:
    • Object Storage: Speichert Backups in einem von Oracle verwalteten Objektspeichercontainer in Oracle Cloud Infrastructure.

      Wenn Sie "Object Storage" als Typ auswählen, können Sie optional einen Internet-HTTP-Proxy angeben, der für die Verbindung zum Speichercontainer verwendet werden soll. Oracle empfiehlt, nach Möglichkeit einen Proxy für erweiterte Sicherheit zu verwenden.

    • Network File System (NFS): Speichert Backups an einem Network File System-(NFS-)Speicherort.

      Wenn Sie "Network File System (NFS)" als Typ auswählen, wählen Sie ein zuvor definiertes Backupziel aus, das Network File System-(NFS-)Speicher verwendet.

    • Recovery Appliance: Speichert Backups in einem der zuvor definierten Backupziele, die Oracle Zero Data Loss Recovery Appliance verwenden.

      Wenn Sie "Recovery Appliance" als Typ auswählen, wählen Sie ein zuvor definiertes Backupziel aus, das Oracle Zero Data Loss Recovery Appliance, DB_UNIQUE_NAME der autonomen Containerdatenbank sowie den VPC-Benutzernamen und das zugehörige Kennwort verwendet.

      Geben Sie die Verbindungszeichenfolge für die Verbindung zur Recovery Appliance im Oracle-Zeichenfolgenformat "easy connect" an, d.h. <host>:<port>/<service name>, wobei <host> der SCAN-Hostname der Zero Data Loss Recovery Appliance ist.

  11. Die folgenden erweiterten Optionen sind verfügbar:
    • Backupaufbewahrungszeitraum: Geben Sie einen Wert für den Backupaufbewahrungszeitraum an, der Ihren Anforderungen entspricht. Sie können einen beliebigen Wert zwischen 7 und 95 Tagen auswählen.

      Für die Backupzieltypen Object Storage und Network File System (NFS) wird der Wert der Backupaufbewahrungs-Policy standardmäßig auf 30 Tage gesetzt.

      Beim Backupzieltyp Recovery Appliance wird dieser Wert von der Schutz-Policy der Recovery Appliance gesteuert.

      Alle Backups werden nach dem Backupaufbewahrungszeitraum automatisch gelöscht.

    • Verschlüsselungsschlüssel: Wählen Sie eine Verschlüsselungsoption: Mit Oracle-verwalteten Schlüsseln verschlüsseln oder Mit vom Kunden verwalteten Schlüsseln verschlüsseln. Die Standardoption ist "Mit von Oracle verwalteten Schlüsseln".

      Um vom Kunden verwaltete Schlüssel zu verwenden, wählen Sie die Option Mit vom Kunden verwalteten Schlüsseln verschlüsseln, das Compartment, in dem Sie den Keystore erstellt haben, und dann den Keystore. Beim Erstellen der CDB wird ein neues Wallet für die CDB in Oracle Key Vault (OKV) erstellt. Außerdem wird ein TDE-Masterschlüssel für die CDB generiert und dem Wallet in OKV hinzugefügt.

      Hinweis

      • Autonome Containerdatenbanken und autonome Datenbanken unterstützen nur HSM-(Hardware Security Module-)Vault-Schlüssel mit 256 Bit.
      • OKV-Schlüsselverschlüsselung nach Neustart validieren: Der OKV-TDE-Masterschlüssel wird jedes Mal validiert, wenn Sie Ihre ACD starten oder neu starten. Der Start oder Neustart ist nicht erfolgreich, wenn der Schlüssel nicht validiert wurde. Arbeitsanforderungen und Lebenszyklusstatus weisen auf den Grund für den Fehler hin.
      • OKV-Schlüssel nach Wiederherstellung der Datenbank anzeigen: Wenn Sie eine CDB wiederherstellen, wird auch der mit dem Backup verknüpfte Masterschlüssel wiederhergestellt.
      • Wallet-Namen in CDB-Backups erfassen: CDB sichert Informationen über das Wallet, das mit dem Backup verknüpft ist.
      • OKV-Wallet oder TDE-Masterschlüssel beim Löschen der CDB: Wenn Sie eine CDB löschen, bleiben Wallet und TDE-Masterschlüssel in OKV erhalten und werden nicht gelöscht.
    • Management: Wählen Sie für Zeichensatz und Länderspezifischer Zeichensatz Werte aus der Dropdown-Liste aus.
    • Database In-memory:
      • In-Memory-Datenbank aktivieren: Um In-Memory zu aktivieren, sind mindestens vier OCPUs und ein Prozentsatz der System Global Area (SGA) erforderlich. Wenn Sie In-Memory aktivieren, wählen Sie den Prozentsatz der SGA, die dem IM-Spaltenspeicher zugewiesen werden soll. In-Memory kann sich auf die Performance der autonomen Datenbank auswirken, wenn eine große Speichermenge zugewiesen oder deaktiviert ist.
        Hinweis

        Wenn Sie In-Memory in einer Primärdatenbank mit aktiviertem Data Guard aktivieren, wird die Konfiguration in der Standbydatenbank schreibgeschützt repliziert.

    • Tags: Optional können Sie Tags anwenden. Wenn Sie über Berechtigungen zum Erstellen von Ressourcen verfügen, sind Sie auch berechtigt, Freiformtags auf diese Ressource anzuwenden. Um ein definiertes Tag anzuwenden, benötigen Sie die Berechtigung zum Verwenden des Tag-Namespace. Weitere Informationen zum Tagging finden Sie unter Ressourcentags. Wenn Sie nicht sicher sind, ob Sie Tags anwenden sollten, überspringen Sie diese Option, oder fragen Sie Ihren Administrator. Sie können die Tags auch später noch zuweisen. Geben Sie dabei keine vertraulichen Informationen ein.

      Ihre Mandanten verfügen über eine Library mit Standardtags, die für die meisten Ressourcen gelten. Diese Tags sind derzeit als Set von Tag-Namespaces verfügbar, die von Governance-Administratoren bereitgestellt werden können. Gemäß Best Practices für OCI ist es empfehlenswert, diese Tags auf alle Ressourcen anzuwenden. Neben Reporting und Governance kann die OCI-Serviceautomatisierung Workload-spezifische Optimierungen basierend auf Standardtagwerten bereitstellen.

      Beispiel: Für Datenbank-Deployments für die PeopleSoft-Anwendung ist eine bestimmte Konfiguration erforderlich. Wenn Sie beim Deployment einer autonomen Datenbank den entsprechenden Anwendungstagschlüssel im Tag-Namespace "Oracle-ApplicationName" festlegen, können Sie sicherstellen, dass die Datenbank für die jeweilige Anwendung (z.B. PeopleSoft) out-of-the-box konfiguriert und bereit ist.

      Weitere Informationen finden Sie unter Oracle Exadata Database Service on Cloud@Customer-Ressourcen taggen.

  12. Klicken Sie auf Autonome Containerdatenbank erstellen.

Details einer autonomen Primär- oder Standbycontainerdatenbank mit aktiviertem Data Guard anzeigen

Führen Sie diese Schritte aus, um detaillierte Informationen zu einer autonomen Primär- oder Standbycontainerdatenbank auf einem Oracle Exadata Database Service on Cloud@Customer-System anzuzeigen.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der automatischen Containerdatenbanken auf den Anzeigenamen der Datenbank, deren Details Sie anzeigen möchten.
  4. Prüfen Sie auf der Seite Details zur autonomen Containerdatenbank den Status der Autonomous Data Guard-Verknüpfung und den Status der Peerdatenbank.
  5. Um den Schutzmodus und den Lag-Grenzwert für Fast-Start Failover der Primärdatenbank zu ändern, wählen Sie in der Dropdown-Liste Weitere Aktionen die Option Autonomous Data Guard aktualisieren aus.
    1. Nehmen Sie im daraufhin angezeigten Dialogfeld "Autonomous Data Guard aktualisieren" Änderungen vor, und klicken Sie auf Änderungen speichern.
  6. Klicken Sie unter Ressourcen auf Autonomous Data Guard, um die Verknüpfungsdetails anzuzeigen.

Einstellungen für autonomes Containerdatenbankbackup bearbeiten

Wenn automatische Backups beim Provisioning einer autonomen Containerdatenbank (ACD) deaktiviert wurden, können Sie sie später über die Oracle Cloud Infrastructure-(OCI-)Konsole aktivieren.

  1. Gehen Sie zur Seite "Details" der autonomen Containerdatenbank, deren Backupeinstellungen Sie ändern möchten.
  2. Klicken Sie unter Weitere Aktionen auf Backupeinstellungen bearbeiten.
    Hinweis

    Sie können die Backupeinstellungen auch bearbeiten, indem Sie auf der Registerkarte "Informationen zur autonomen Containerdatenbank" im Abschnitt Backup auf den Link Bearbeiten klicken.

    Das Dialogfeld "Backupeinstellungen bearbeiten" wird geöffnet.

  3. Wenn automatische Backups für diese ACD deaktiviert sind, aktivieren Sie sie, indem Sie das Kontrollkästchen Automatische Backups aktivieren aktivieren und die entsprechenden Werte für die folgenden Einstellungen auswählen:
    • Backupzieltyp: Wählen Sie einen Backupzieltyp aus, und geben Sie dann Optionen basierend auf dem ausgewählten Typ an.
      Hinweis

      Der Backupzieltyp kann nur bei der Aktivierung automatischer Backups auf einer ACD festgelegt und später nicht mehr geändert werden.
      Folgende Optionen sind möglich:
      • Object Storage: Speichert Backups in einem von Oracle verwalteten Objektspeichercontainer in Oracle Cloud Infrastructure.

        Wenn Sie "Object Storage" als Typ auswählen, können Sie optional einen Internet-HTTP-Proxy angeben, der für die Verbindung zum Speichercontainer verwendet werden soll. Oracle empfiehlt, nach Möglichkeit einen Proxy für erweiterte Sicherheit zu verwenden.

      • Network File System (NFS): Speichert Backups an einem Network File System-(NFS-)Speicherort.

        Wenn Sie "Network File System (NFS)" als Typ auswählen, wählen Sie ein zuvor definiertes Backupziel aus, das Network File System-(NFS-)Speicher verwendet.

      • Recovery Appliance: Speichert Backups in einem der zuvor definierten Backupziele, die Oracle Zero Data Loss Recovery Appliance verwenden.

        Wenn Sie "Recovery Appliance" als Typ auswählen, wählen Sie ein zuvor definiertes Backupziel aus, das Oracle Zero Data Loss Recovery Appliance, DB_UNIQUE_NAME der autonomen Containerdatenbank sowie den VPC-Benutzernamen und das zugehörige Kennwort verwendet.

        Geben Sie die Verbindungszeichenfolge für die Verbindung zur Recovery Appliance im Oracle-Zeichenfolgenformat "easy connect" an, d.h. <host>:<port>/<service name>, wobei <host> der SCAN-Hostname der Zero Data Loss Recovery Appliance ist.

    • Backupaufbewahrungszeitraum (in Tagen): Geben Sie einen Wert für den Backupaufbewahrungszeitraum an, der Ihren Anforderungen entspricht. Sie können einen beliebigen Wert zwischen 7 und 95 Tagen auswählen.

      Für die Backupzieltypen Object Storage und Network File System (NFS) wird der Wert der Backupaufbewahrungs-Policy standardmäßig auf 30 Tage gesetzt.

      Beim Backupzieltyp Recovery Appliance wird dieser Wert von der Schutz-Policy der Recovery Appliance gesteuert.

      Alle Backups werden nach dem Backupaufbewahrungszeitraum automatisch gelöscht.

  4. Klicken Sie auf Änderungen speichern.

Physische Standby-ACD in Snapshot-Standby-ACD konvertieren

Bei einer Snapshot-Standbydatenbank handelt es sich um eine vollständig aktualisierbare Standbydatenbank, die durch das Konvertieren einer physischen Standbydatenbank in eine Snapshot-Standbydatenbank erstellt wurde.

Eine Snapshot-Standbydatenbank empfängt und archiviert Redo-Daten, die von einer Primärdatenbank empfangen wurden. Redo-Daten, die von einer Primärdatenbank empfangen wurden, werden jedoch nicht angewendet. Die Redo-Daten werden angewendet, wenn eine Snapshot-Standbydatenbank in eine physische Standbydatenbank zurück konvertiert wird, nachdem alle lokalen Aktualisierungen an der Snapshot-Standbydatenbank verworfen wurden. Nach Abschluss der Konvertierung wird die Rolle der Standby-ACD in SNAPSHOT_STANDBY geändert. Sie können DDL- und DML-Vorgänge für alle ADBs in der ACD SNAPSHOT_STANDBY ausführen.

Hinweis

  • Eine Snapshot-Standbydatenbank wird nach 7 Tagen automatisch in eine physische Standbydatenbank zurück konvertiert.
  • Für eine Snapshot-Standbydatenbank werden keine automatischen Backups erstellt.
  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten physischen Standbydatenbank.

    Die Seite "Autonome Containerdatenbank - Details" wird angezeigt.

  4. Wählen Sie in der Dropdown-Liste Weitere Aktionen die Option In Snapshot-Standbydatenbank konvertieren aus.
    Hinweis

    Bei aktiviertem automatischem Failover können Sie eine physische Standbydatenbank nicht in eine Snapshot-Standbydatenbank konvertieren. Deaktivieren Sie den automatischen Failover, um die Standbydatenbank in den Snapshot-Standbymodus zu konvertieren.

  5. So deaktivieren Sie den automatischen Failover:
    1. Klicken Sie unter Ressourcen auf Autonomous Data Guard.
    2. Klicken Sie auf den Namen der Peerdatenbank (Primärdatenbank).

      Die Seite mit den Details zur Primär-ACD wird angezeigt.

    3. Wählen Sie in der Dropdown-Liste Weitere Aktionen die Option Autonomous Data Guard aktualisieren aus.
    4. Deaktivieren Sie im daraufhin angezeigten Dialogfeld "Autonomous Data Guard aktualisieren" das Kontrollkästchen Automatischen Failover aktivieren.
    5. Klicken Sie auf Änderungen speichern.
  6. Nachdem Sie den automatischen Failover deaktiviert haben, fahren Sie mit der Konvertierung der physischen Standbydatenbank in eine Snapshot-Standbydatenbank fort.

    Prüfen Sie die Warnmeldung im Fenster "In Snapshot-Standbydatenbank konvertieren".

    Beim Konvertieren in eine Snapshot-Standbydatenbank werden zwei Optionen unterstützt:

    • Neue Datenbankservices verwenden: Stellen Sie mit neuen Services, die nur im Snapshot-Standbymodus aktiv sind, eine Verbindung zur Snapshot-Standbydatenbank her.
    • Services der Primärdatenbank verwenden: Stellen Sie mit denselben Services wie die Primärdatenbank eine Verbindung zur Snapshot-Standbydatenbank her.

    Wenn Sie die Option Services der Primärdatenbank verwenden auswählen, wird eine zusätzliche Warnmeldung zur Konfiguration geeigneter Verbindungszeichenfolgen für die Verbindung zu Primär- und Snapshot-Standbydatenbank angezeigt, um falsche Datenbankverbindungen zu vermeiden.

  7. Klicken Sie auf Konfiguration.

    Nach der Konvertierung ändert sich die Rolle der Standbydatenbank in Snapshot-Standbydatenbank, und die Option In physische Standbydatenbank konvertieren wird in der Dropdown-Liste Weitere Aktionen angezeigt.

    Hinweis

    Die Option zur Konvertierung in eine physische Standby-ACD ist nur aktiviert, wenn sich die ACD im Modus SNAPSHOT_STANDBY befindet.

    • Beim Konvertieren in eine physische Standby-ACD werden alle lokalen Updates von allen ADBs verworfen und Redo-Daten von der Primär-ACD angewendet.
    • Durch die Konvertierung in eine physische Standbydatenbank werden die Standby-ACD-Rolle und die Rollen aller zugehörigen ADBs auf STANDBY zurückgesetzt.

Snapshot-Standby-ACD in physische Standby-ACD konvertieren

Eine Snapshot-Standbydatenbank wird nach 7 Tagen automatisch in eine physische Standbydatenbank zurück konvertiert.

Das System zeigt ein Banner mit dem tatsächlichen Datum an, an dem die Snapshot-Standbydatenbank in eine physische Standbydatenbank zurück konvertiert wird. Die Datenbankrolle für alle ADBs in dieser ACD wird ebenfalls entsprechend geändert. Die Bannermeldung über die automatische Konvertierung ist nur für ACDs verfügbar.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Snapshot-Datenbank.

    Die Seite "Autonome Containerdatenbank - Details" wird angezeigt.

  4. Wählen Sie in der Dropdown-Liste Weitere Aktionen die Option In physische Standbydatenbank konvertieren aus.
    Hinweis

    Wenn Sie die Snapshot-Standby-ACD in eine physische Standbydatenbank konvertieren, werden alle lokalen Aktualisierungen an der Snapshot-Standbydatenbank verworfen, und Daten von der autonomen Primärcontainerdatenbank werden angewendet.

  5. Klicken Sie auf Konfiguration.

CDB-Verschlüsselungsschlüssel rotieren

Führen Sie diese Schritte aus, um den TDE-Masterschlüssel zu rotieren. Bei der Schlüsselrotation durchläuft der ACD-Lebenszyklus den regulären Updatestatus und nimmt dann wieder den Status "Verfügbar" an.

Sie können den TDE-Masterschlüssel beliebig oft rotieren. Der neue TDE-Masterschlüssel wird in dem Wallet gespeichert, in dem auch der vorherige Schlüssel gespeichert wurde. Durch Rotieren des TDE-Masterschlüssels wird der neue Schlüssel in OKV generiert und dieser Datenbank zugewiesen. Sie können alle Schlüssel in OKV anzeigen.

Hinweis

Sie können sowohl von Oracle verwaltete als auch vom Kunden verwaltete Verschlüsselungsschlüssel rotieren.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der Primär- oder Standbydatenbank, deren Details Sie anzeigen möchten.
  4. Klicken Sie auf der Seite Autonome Containerdatenbank - Details auf Verschlüsselungsschlüssel rotieren.
  5. Klicken Sie im Dialogfeld Verschlüsselungsschlüssel rotieren auf Verschlüsselungsschlüssel rotieren.

Autonome Standbycontainerdatenbanken verwalten

Durch die Aktivierung von Autonomous Data Guard in einer autonomen Containerdatenbank wird eine autonome Standby-(Peer-)Containerdatenbank erstellt, die Datenschutz, High Availability und Disaster Recovery für die Primärdatenbank bietet.

Wenn die autonome Primärcontainerdatenbank aufgrund eines Regionsfehlers, eines Fehlers der autonomen Exadata-Infrastruktur oder eines Fehlers bei der autonomen Containerdatenbank selbst nicht verfügbar ist, wird automatisch ein Failover zur autonomen Standbycontainerdatenbank ausgeführt, wenn der automatische Failover aktiviert ist. Die Rolle der fehlerhaften Primärdatenbank wird in Deaktivierte Standbydatenbank geändert. Nach kurzer Zeit übernimmt die Standbydatenbank die Rolle der Primärdatenbank.

In der folgenden Tabelle werden die Datenbankzustandsbedingungen aufgeführt, die neben Hardwarefehlern und regionalen Ausfällen ebenfalls einen automatischen Failover auslösen:

Tabelle 6-8: Datenbankzustand

Datenbankzustand Beschreibung
Datendatei-Schreibfehler Das System startet einen Fast-Start Failover, wenn Schreibfehler in Datendateien auftreten, einschließlich temporäre Dateien, Systemdatendateien und Undo-Dateien.
Beschädigtes Dictionary Dictionary-Beschädigung einer kritischen Datenbank. Dieser Status wird derzeit nur erkannt, wenn die Datenbank geöffnet ist.
Beschädigte Kontrolldatei Die Kontrolldatei ist wegen eines Datenträgerfehlers dauerhaft beschädigt.
Hinweis

  • Nach Abschluss des automatischen Failovers wird auf der Detailseite der deaktivierten Standbydatenbank gemeldet, dass ein Failover stattgefunden hat.
  • Bei der Konfiguration von Autonomous Data Guard ist der automatische Failover optional. Nach der Konfiguration von Autonomous Data Guard können Sie den automatischen Failover aktivieren oder deaktivieren.
  • Das Konfigurationsattribut FastStartFailoverLagLimit legt einen zulässigen Grenzwert in Sekunden fest, bis zu dem die Standbydatenbank in Bezug auf die Redo-Anwendung hinter der Primärdatenbank zurückliegen kann. Wenn die Grenze erreicht ist, erfolgt kein Fast-Start Failover. Dieses Attribut wird verwendet, wenn Fast-Start Failover aktiviert ist und die Konfiguration im Modus für maximale Performance arbeitet.
    Für das Attribut FastStartFailOverLagLimit gilt Folgendes:
    • Der Standardwert beträgt 30 Sekunden.
    • Es kann nicht konfiguriert werden.
    • Es gilt nur für den Schutzmodus "Maximale Performance".

Nachdem der Service die Probleme mit der ursprünglichen autonomen Primärcontainerdatenbank behoben hat, können Sie einen manuellen Switchover ausführen, um beiden Datenbanken wieder ihre ursprüngliche Rolle zuzuweisen.

Nachdem Sie die Standbydatenbank bereitgestellt haben, können Sie verschiedene Verwaltungsaufgaben für die Standbydatenbank ausführen, darunter:
  • Manueller Switchover einer Primärdatenbank zu einer Standbydatenbank
  • Manueller Failover einer Primärdatenbank zu einer Standbydatenbank
  • Primärdatenbank nach Failover in Standbyrolle neu instanziieren
  • Standbydatenbank beenden

Failover zur autonomen Standbycontainerdatenbank ausführen

Initiieren Sie einen Failover-Vorgang mit der Data Guard-Verknüpfung der Standbydatenbank.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Infrastrukturressource.
  4. Klicken Sie auf den Namen der Standbydatenbank oder Snapshot-Standbydatenbank, die mit der autonomen Primärcontainerdatenbank verknüpft ist, für die Sie einen Failover ausführen möchten.

    Das System zeigt eine Warnung an, wenn Sie einen Failover-Vorgang ausführen, wenn sich die Standby-ACD im Snapshot-Standbymodus befindet:

    WARNUNG:

    Die Standby-Datenbank hat eine Snapshot-Standbyrolle. Beim Failover wird die Snapshot-Standbydatenbank in eine physische Standbydatenbank konvertiert, indem alle lokalen Aktualisierungen an der Snapshot-Standbydatenbank verworfen und Daten von der Primärdatenbank angewendet werden.
  5. Klicken Sie auf Failover.
  6. Geben Sie im Dialogfeld Manuellen Failover zu Standby bestätigen den Namen der autonomen Containerdatenbank ein, für die ein Failover durchgeführt werden soll, und klicken Sie dann auf Failover.

    Alternative:

    1. Klicken Sie unter Ressourcen auf "Autonomous Data Guard", um eine Liste der Peerdatenbanken für die von Ihnen verwaltete Primärdatenbank anzuzeigen.
    2. Klicken Sie bei der Data Guard-Verknüpfung, in der Sie ein Failover ausführen möchten, auf das Symbol "Aktionen" (drei Punkte), und klicken Sie dann auf Failover.
    3. Geben Sie im Dialogfeld Manuellen Failover zu Standby bestätigen den Namen der autonomen Containerdatenbank ein, für die ein Failover durchgeführt werden soll, und klicken Sie dann auf Failover.
      Hinweis

      Nach erfolgreichem Abschluss des Failovers wird die Rolle der Standby-ACD in "Primär" geändert, und die Primär-ACD wird in den deaktivierten Standbystatus versetzt.

Switchover zu autonomer Standby- oder Primärcontainerdatenbank ausführen

Starten Sie einen Switchover-Vorgang mit der Data Guard-Verknüpfung der Primärdatenbank.

  • Sie können Switchover nur ausführen, wenn sowohl Primär- als auch Standbydatenbank verfügbar sind.
  • Sie können keinen Switchover ausführen, wenn auf der Primär- oder Standbydatenbank Patching- oder Wartungsvorgänge ausgeführt werden.
  • Sie können keinen Switchover-Vorgang ausführen, wenn sich die Standby-ACD im Snapshot-Standbymodus befindet.
  • Nach dem Switchover werden die Wartungsvoreinstellungen für die neue Standby- und Primärdatenbank von der alten Standby- und Primärdatenbank übernommen.
  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Infrastrukturressource.
  4. Klicken Sie auf den Namen der Primär- oder Sekundärdatenbank.
  5. Klicken Sie auf Switchover.
  6. Klicken Sie im Bestätigungsdialogfeld auf Switchover.

    Alternative:

    1. Klicken Sie unter Ressourcen auf Data Guard-Verknüpfungen.
    2. Klicken Sie bei der Data Guard-Verknüpfung, in der Sie einen Switchover ausführen möchten, auf das Symbol "Aktionen" (drei Punkte), und klicken Sie dann auf Switchover.
    3. Klicken Sie im Dialogfeld Manuellen Switchover zu Standby bestätigen auf Switchover.

      Diese Datenbank nimmt jetzt die Rolle der Standbydatenbank an, und die Standbydatenbank übernimmt die Rolle der Primärdatenbank in der Data Guard-Verknüpfung.

Autonome Standbycontainerdatenbank mit aktiviertem Data Guard neu instanziieren

Nach dem Failover einer Primärdatenbank zur Standbydatenbank nimmt die Standbydatenbank die Primärrolle an, und die bisherige Primärdatenbank wird als deaktivierte Standbydatenbank gekennzeichnet.

Nachdem das Operations-Team den Fehler korrigiert hat, können Sie die betreffende Datenbank mit der Data Guard-Verknüpfung als funktionsfähige Standbydatenbank für die aktuelle Primärdatenbank neu instanziieren.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Infrastrukturressource.
  4. Klicken Sie auf den Namen der deaktivierten Standbydatenbank.
  5. Klicken Sie unter Ressourcen auf Autonomous Data Guard..
  6. Klicken Sie bei der Data Guard-Verknüpfung, in der Sie die Datenbank neu instanziieren möchten, auf das Symbol "Aktionen" (drei Punkte), und klicken Sie dann auf Neu instanziieren.
  7. Klicken Sie im Dialogfeld Datenbank neu instanziieren auf Neu instanziieren.

    Diese Datenbank sollte jetzt als Standbydatenbank in der Data Guard-Verknüpfung neu instanziiert werden. Sie können nun einen Switchover-Vorgang ausführen, um die betreffenden Datenbanken auf ihre ursprünglichen Rollen zurückzusetzen.

Autonome Primärcontainerdatenbank mit aktiviertem Data Guard beenden

Führen Sie diese Schritte aus, um eine autonome Containerdatenbank auf einem Oracle Exadata Cloud@Customer-System zu beenden.

Sie müssen alle autonomen Datenbanken in einer Containerdatenbank beenden, bevor Sie die Containerdatenbank selbst beenden können. Durch das Beenden der autonomen Containerdatenbank wird auch Autonomous Data Guard beendet, wodurch High Availability und Disaster Recovery der autonomen Datenbanken beeinträchtigt werden.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Infrastrukturressource.
  4. Wählen Sie auf der Seite Autonome Containerdatenbank - Details in der Dropdown-Liste "Weitere Aktionen" die Option Beenden aus.
  5. Klicken Sie auf Beenden.
  6. Geben Sie im Bestätigungsdialogfeld den Namen der autonomen Containerdatenbank ein, und klicken Sie dann auf Autonome Containerdatenbank beenden.

Autonome Standbycontainerdatenbank mit aktiviertem Data Guard beenden

Führen Sie diese Schritte aus, um eine autonome Containerdatenbank auf einem Oracle Exadata Cloud@Customer-System zu beenden.

Sie können eine autonome Standbycontainerdatenbank auch dann beenden, wenn sie autonome Standbydatenbanken enthält. Sie können jedoch keine autonomen Standbydatenbanken innerhalb einer autonomen Standbycontainerdatenbank beenden. Um eine autonome Standbydatenbank zu beenden, müssen Sie zuerst die autonome Primärdatenbank beenden. Durch das Beenden der autonomen Containerdatenbank wird auch Autonomous Data Guard beendet, wodurch High Availability und Disaster Recovery der autonomen Datenbanken beeinträchtigt werden.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Infrastrukturressource.
  4. Wählen Sie auf der Seite Autonome Containerdatenbank - Details in der Dropdown-Liste "Weitere Aktionen" die Option Beenden aus.
  5. Klicken Sie auf Beenden.
  6. Geben Sie im Bestätigungsdialogfeld den Namen der autonomen Containerdatenbank ein, und klicken Sie dann auf Autonome Containerdatenbank beenden.

Mit den APIs ausgeführte Vorgänge

Hier erfahren Sie, wie Sie mit der API autonome Containerdatenbanken mit aktiviertem Data Guard verwalten.

Informationen zum Verwenden der API und Signieren von Anforderungen finden Sie unter "REST-APIs" und "Sicherheitszugangsdaten". Informationen zu SDKs finden Sie unter "Software Development Kits und Befehlszeilenschnittstelle".

In der folgenden Tabelle sind die REST-API-Endpunkte für die Verwaltung einer autonomen Containerdatenbank mit aktiviertem Autonomous Data Guard aufgeführt.

Vorgang REST-API-Endpunkt

Autonome Containerdatenbanken erstellen (Update der vorhandenen API)

CreateAutonomousContainerDatabase

Details der angegebenen autonomen Containerdatenbank anzeigen

GetAutonomousContainerDatabase

Liste autonomer Containerdatenbanken mit Autonomous Data Guard-Verknüpfungen anzeigen

ListAutonomousContainerDatabaseDataguardAssociations

Details der Autonomous Data Guard-Verknüpfungen einer autonomen Containerdatenbank anzeigen

GetAutonomousContainerDatabaseDataguardAssociation

Führen Sie einen Failover der mit dem Parameter autonomousContainerDatabaseId identifizierten autonomen Standbycontainerdatenbank zur autonomen Primärcontainerdatenbank aus, wenn die vorhandene autonome Primärcontainerdatenbank ausfällt oder nicht mehr erreichbar ist.

FailoverAutonomousContainerDatabaseDataguardAssociation

Die autonome Primärcontainerdatenbank einer Autonomous Data Guard-Peerverknüpfung per Switchover auf die Standbyrolle umschalten. Die mit autonomousContainerDatabaseDataguardAssociationId verknüpfte autonome Standbycontainerdatenbank übernimmt die Rolle der autonomen Primärcontainerdatenbank.

SwitchoverAutonomousContainerDatabaseDataguardAssociation

Eine deaktivierte autonome Standbycontainerdatenbank, die mit dem Parameter autonomousContainerDatabaseId identifiziert wird, neu instanziieren.

ReinstateAutonomousContainerDatabaseDataguardAssociation

Eine Liste der Datenbanken mit aktiviertem Autonomous Data Guard anzeigen, die mit der angegebenen autonomen Datenbank verknüpft sind.

ListAutonomousDatabaseDataguardAssociations

Details zu Autonomous Data Guard-Verknüpfungen einer autonomen Datenbanken abrufen

GetAutonomousDatabaseDataguardAssociation

Details wie Peerdatenbankrolle, Lag-Zeit, Transport-Lag und Status abrufen

GetAutonomousDatabase

Autonomous Data Guard auf autonomer Datenbank aktivieren

Autonome Datenbanken erben die Data Guard-Einstellungen der übergeordneten Containerdatenbank.

Autonomous Data Guard-Aktivierung anzeigen

Die Autonomous Data Guard-Einstellungen werden in der autonomen Containerdatenbank konfiguriert, in der die Datenbanken ausgeführt werden.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonome Containerdatenbanken.

    Diese Seite zeigt an, ob für eine autonome Datenbank Data Guard aktiviert ist oder nicht. Ist Data Guard aktiviert, wird die Rolle der Datenbank in der Data Guard-Verknüpfung angezeigt.

Autonome Datenbank mit aktiviertem Autonomous Data Guard erstellen

Führen Sie diese Schritte aus, um eine autonome Datenbank auf einem Oracle Exadata Cloud@Customer-System zu erstellen.
Hinweis

Sie können keine Autonomous Database für Entwicklerinstanz auf einer Autonomous Data Guard-fähigen Containerdatenbank erstellen.
  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie auf Autonome Datenbank erstellen.
  4. Geben Sie im Dialogfeld Autonome Datenbank erstellen Folgendes ein:

    Allgemeine Datenbankinformationen

    • Compartment: Wählen Sie das Compartment der autonomen Datenbank aus.
    • Anzeigename: Eine benutzerdefinierte Beschreibung oder andere Informationen, anhand derer Sie die Ressource leicht identifizieren können. Der Anzeigename muss nicht eindeutig sein. Geben Sie dabei keine vertraulichen Informationen ein.
    • Datenbankname: Der Datenbankname darf nur Buchstaben und Zahlen enthalten und muss mit einem Buchstaben beginnen. Geben Sie dabei keine vertraulichen Informationen ein.

    Workload-Typ

    Wählen Sie den gewünschten Workload-Typ aus. Informationen zu jedem Workload-Typ finden Sie unter Autonomous Data Warehouse und Autonomous Transaction Processing.

    Autonomous Container Database: Aktivieren Sie das Kontrollkästchen Autonomous Data Guard-fähige autonome Containerdatenbanken, und wählen Sie dann eine autonome Containerdatenbank aus.

    Compartment: Geben Sie das Compartment an, das die zu verwendende autonome Containerdatenbank enthält.

    Anzahl CPU-Cores und Speicherkonfiguration der Datenbank

    • CPU-Anzahl: Die Gesamtanzahl der Cores, die für alle Datenbanken innerhalb der autonomen Exadata-Infrastruktur verfügbar sind, ist von der Infrastrukturausprägung und davon abhängig, was bereits anderen autonomen Datenbanken zugewiesen ist.

      Der CPU-Typ, d.h. OCPU oder ECPU, wird anhand des Compute-Typs der übergeordneten autonomen Exadata-VM-Clusterressource bestimmt.

      Die ausgewählte CPU-Anzahl wird anhand einer Liste mit bereitstellbaren CPUs validiert. Wenn die Datenbank nicht auf die ausgewählte CPU-Anzahl vertikal skaliert werden kann, werden die beiden nächsten bereitstellbaren CPU-Werte angegeben.

      Je nach Ressourcenauslastung auf den einzelnen Knoten können möglicherweise nicht alle Werte der verfügbaren CPUs zum Bereitstellen oder Skalieren autonomer Datenbanken verwendet werden. Beispiel: Angenommen, auf AVMC-Ebene sind 20 CPUs verfügbar. Abhängig von der Ressourcenverfügbarkeit auf Knotenebene können nicht alle Werte von 1 bis 20 CPUs zum Bereitstellen oder Skalieren autonomer Datenbanken verwendet werden. Die Liste der CPU-Werte, mit denen eine autonome Datenbank bereitgestellt oder skaliert werden kann, wird als bereitstellbare CPUs bezeichnet.

      Wenn Sie in der Konsole versuchen, eine autonome Datenbank bereitzustellen oder zu skalieren, wird die CPU-Anzahl anhand der Liste der bereitstellbaren CPUs validiert. Wenn der Wert nicht bereitgestellt werden kann, werden die beiden nächsten bereitstellbaren CPU-Werte angegeben. Wenn Sie die vollständige Liste der bereitstellbaren CPU-Werte für ein autonomes Exadata-VM-Cluster anzeigen möchten, können Sie die folgende API verwenden:

      GetAutonomousContainerDatabase gibt eine Liste der OCPU-Werte zurück, die bereitgestellt und zur Erstellung einer neue autonomen Datenbank in der angegebenen autonomen Containerdatenbank verwendet werden können. Weitere Einzelheiten finden Sie unter GetAutonomousContainerDatabase.

      Bei ECPUs ist dieser Wert standardmäßig auf 2 ECPUs gesetzt. Bei Datenbanken, die mindestens 2 ECPUs benötigen, müssen Sie die Anzahl der zugewiesenen ECPUs in einem Schritt von 1 angeben.

      Hinweis

      CPU-Overprovisioning ist bei ECPUs nicht zulässig.

      Bei OCPUs ist der Standardwert 1 OCPU. Sie können jedoch Datenbanken, die keine ganze OCPU benötigen, einen partiellen OCPU-Wert zwischen 0,1 und 0,9 (in Schritten von 0,1 OCPU) zuweisen. Dies ermöglicht das Overprovisioning von CPU und das Ausführen von mehr Datenbanken auf jeder Infrastrukturinstanz. Bei Datenbanken, die mindestens 1 OCPU benötigen, müssen Sie die Anzahl der zugewiesenen OCPUs als Ganzzahl angeben. Beispiel: Sie können einer Datenbank keine 3,5 OCPUs zuweisen. Die nächste verfügbare OCPU-Anzahl nach 3 ist 4.

      Datenbanken mit CPU-Overprovisioning können nur Verbindungen mit TCP- und Low-Services herstellen.

      Um die automatische Skalierung zu deaktivieren, deaktivieren Sie "Autoscaling". Standardmäßig ist die automatische Skalierung aktiviert, damit das System automatisch bis zu dreimal mehr CPU- und I/O-Ressourcen verwenden kann, um den Workload-Bedarf zu decken.

    • Speicher (TB): Geben Sie den Speicher in Terabyte an, den Sie der autonomen Datenbank zur Verfügung stellen möchten. Der verfügbare Speicher hängt von der Ausprägung der Infrastruktur und davon ab, was bereits von anderen autonomen Datenbanken belegt wird.

    Administratorzugangsdaten

    Legen Sie das Kennwort für den Admin-Benutzer für Autonomous Database fest. Das Kennwort muss die folgenden Kriterien erfüllen. Sie verwenden dieses Kennwort, wenn Sie auf die Autonomous Database-Servicekonsole zugreifen und ein SQL-Clienttool verwenden.

    • Umfasst 12 bis 30 Zeichen
    • mindestens einen Kleinbuchstaben enthält
    • mindestens einen Großbuchstaben enthält
    • Enthält mindestens eine Ziffer
    • Enthält keine doppelten Anführungszeichen (")
    • Enthält nicht die Zeichenfolge "admin", unabhängig von der Groß- und Kleinschreibung

    Netzwerkzugriff konfigurieren

    Sie können eine ACL optional während des Provisionings der Datenbank oder danach erstellen.

    1. Klicken Sie auf Zugriffskontrolle ändern.
    2. Wählen Sie im Dialogfeld Access-Control-Liste bearbeiten das Kontrollkästchen Zugriffskontrolle auf Datenbankebene aktivieren.
    3. Geben Sie in der Access-Control-Liste der Primärdatenbank mithilfe des Dropdown-Selektors "IP-Notationstyp" die folgenden Adresstypen in der Liste an:

      Mit "IP-Adresse" können Sie eine oder mehrere öffentliche IP-Adressen angeben. Verwenden Sie Kommas zur Trennung der Adressen im Eingabefeld.

      Mit "CIDR-Block" können Sie einen oder mehrere Bereiche von öffentlichen IP-Adressen mit CIDR-Notation angeben. Trennen Sie die Einträge für "CIDR-Block" im Eingabefeld durch Kommas.

    4. Führen Sie unter "Zugriffskontrolle der Standbydatenbank" die folgenden Schritte aus:

      (Standard) Identisch mit Primärdatenbank: Übernehmen Sie diese Option, wenn Sie dieselbe Access-Control-Liste wie für die Sekundärdatenbank verwenden möchten.

      Zugriffskontrolle der Standbydatenbank definieren: Wird mit denselben Details wie die Primärdatenbank initialisiert. Fügen Sie nach Bedarf Einträge hinzu, oder ändern Sie sie.

    Erweiterte Optionen

    Tags: Optional können Sie Tags anwenden. Wenn Sie über Berechtigungen zum Erstellen von Ressourcen verfügen, sind Sie auch berechtigt, Freiformtags auf diese Ressource anzuwenden. Um ein definiertes Tag anzuwenden, benötigen Sie die Berechtigung zum Verwenden des Tag-Namespace. Weitere Informationen zum Tagging finden Sie unter Ressourcentags. Wenn Sie nicht sicher sind, ob Sie Tags anwenden sollten, überspringen Sie diese Option, oder fragen Sie Ihren Administrator. Sie können die Tags auch später noch zuweisen. Geben Sie dabei keine vertraulichen Informationen ein.

    Verschlüsselungsschlüssel: Die ADB erbt die Verschlüsselungseinstellungen der übergeordneten ACD. Wenn die übergeordnete ACD für die vom Kunden verwaltete OKV-basierte Verschlüsselung konfiguriert ist, wird für die untergeordnete ADB auch ein TDE-Masterschlüssel generiert und in dem OKV-Wallet verwaltet, in dem ACD-Masterschlüssel gespeichert werden. Darüber hinaus ist mit allen von der autonomen Datenbank erstellten Backups der OKV-basierte Schlüssel verknüpft.

  5. Klicken Sie auf Autonome Datenbank erstellen.
    Hinweis

    Für Autonomous Transaction Processing- und Autonomous Data Warehouse-Datenbanken gelten die folgenden Einschränkungen:

    • Namen, die mit Datenbanken verknüpft sind, die innerhalb der letzten 60 Tage beendet wurden, können beim Erstellen einer neuen Datenbank nicht verwendet werden.
    • Ein Datenbankname kann nicht gleichzeitig für eine Autonomous Data Warehouse- und eine Autonomous Transaction Processing-Datenbank verwendet werden.

Details einer autonomen Primär- oder Standbydatenbank mit aktiviertem Data Guard anzeigen

Führen Sie diese Schritte aus, um detaillierte Informationen zu einer autonomen Primär- oder Standbydatenbank auf einem Oracle Exadata Database Service on Cloud@Customer-System anzuzeigen.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie in der Liste der autonomen Datenbanken auf den Anzeigenamen der Datenbank, deren Details Sie anzeigen möchten.
  4. Prüfen Sie auf der Seite Details zur autonomen Datenbank den Status der Autonomous Data Guard-Verknüpfung und den Status der Peerdatenbank.
  5. Klicken Sie unter Ressourcen auf Autonomous Data Guard, um die Verknüpfungsdetails anzuzeigen.

ADB-Verschlüsselungsschlüssel rotieren

Führen Sie diese Schritte aus, um den TDE-Masterschlüssel zu rotieren. Bei der Schlüsselrotation durchläuft der ADB-Lebenszyklus den regulären Updatestatus und nimmt dann wieder den Status "Verfügbar" an.

Sie können den TDE-Masterschlüssel beliebig oft rotieren. Der neue TDE-Masterschlüssel wird in dem Wallet gespeichert, in dem auch der vorherige Schlüssel gespeichert wurde. Durch Rotieren des TDE-Masterschlüssels wird der neue Schlüssel in OKV generiert und dieser Datenbank zugewiesen. Sie können alle Schlüssel in OKV anzeigen.

Hinweis

Sie können sowohl von Oracle verwaltete als auch vom Kunden verwaltete Verschlüsselungsschlüssel rotieren.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie in der Liste der autonomen Datenbanken auf den Anzeigenamen der Datenbank, deren Details Sie anzeigen möchten.
  4. Wählen Sie auf der Seite Details zur autonomen Datenbank in der Dropdown-Liste Weitere Aktionen die Option Verschlüsselungsschlüssel rotieren aus.
  5. Klicken Sie im Dialogfeld Verschlüsselungsschlüssel rotieren auf Verschlüsselungsschlüssel rotieren.

Wartung von autonomer Containerdatenbank mit aktiviertem Data Guard planen und Datenbank patchen

Führen Sie diese Schritte aus, um den Wartungsplan einer autonomen Containerdatenbank mit aktiviertem Data Guard zu ändern.

Automatischen Wartungsplan für eine autonome Containerdatenbank mit aktiviertem Data Guard konfigurieren

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Containerdatenbank.
  4. Klicken Sie auf der Seite mit den Details zur autonomen Containerdatenbank auf Wartungsvoreinstellungen bearbeiten.

    Im Dialogfeld Automatische Wartung bearbeiten können Sie dann sowohl den Wartungsplan als auch den Patchtyp konfigurieren.

    Hinweis

    Die Standbydatenbank hat standardmäßig keine Voreinstellung. Die Wartung der Standbydatenbank hängt vom Wartungsplan der Primärdatenbank ab.

  5. Optional können Sie den Wartungspatchtyp ändern. Um diese Einstellung zu bearbeiten, wählen Sie entweder Releaseupdate (RU) oder Releaseupdaterevision (RUR).

    Releaseupdate (RU): Autonomous Database installiert nur das aktuelle Releaseupdate.

    Releaseupdaterevision (RUR): Autonomous Database installiert das Releaseupdate und zusätzliche Fixes.

    Hinweis

    Die Standbydatenbank wird immer vor der Primärdatenbank gepatcht. Der Standardzeitabstand zwischen den Patchings beträgt7 Tage. Sie können den Standardzeitabstand jederzeit ändern. Gültig sind Werte von 1 bis 7 Tagen.

    Wartungsversion der Containerdatenbank konfigurieren
    • Nächstes Releaseupdate (RU): Führen Sie im nächsten Wartungszyklus eine Aktualisierung auf das nächste Releaseupdate durch.
    • Neuestes Releaseupdate (RU): Führen Sie im nächsten Wartungszyklus eine Aktualisierung auf das neueste Releaseupdate durch.
  6. Zum Konfigurieren des Wartungsplans wählen Sie unter "Zeitplan für automatische Wartung konfigurieren" die Option "Zeitplan angeben" aus. Wählen Sie den Monat, die Woche, den Wochentag und die Startuhrzeit für die Wartung der Containerdatenbank aus.
    • Geben Sie unter "Wartungsmonate" mindestens einen Monat für jedes Wartungsquartal an, in dem die Wartung der autonomen Exadata-Infrastruktur ausgeführt werden soll.

      Hinweis

      Die Wartungsquartale beginnen im Februar, Mai, August und November. Das erste Wartungsquartal des Jahres beginnt im Februar.

    • Geben Sie unter "Woche des Monats" an, in welcher Woche des Monats die Wartung stattfinden soll. Wochen beginnen jeweils am 1., 8., 15. und 22. Tag des Monats und dauern jeweils 7 Tage. 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.
    • Geben Sie unter "Wochentag" den Tag der Woche an, an dem die Wartung stattfinden soll.
    • Geben Sie unter "Startstunde" die Stunde an, in welcher der Wartungslauf beginnen soll.
    • Wählen Sie den Pufferzeitraum zwischen der Ausführung der Wartung der Primär- und der Standbydatenbank aus. Der Pufferzeitraum entspricht dem Zeitraum in Tagen, der zwischen der Wartung der autonomen Standbydatenbank und der Wartung der autonomen Primärcontainerdatenbank verstreichen soll.
  7. Klicken Sie auf Änderungen speichern.

Nächsten geplanten Wartungslauf einer Containerdatenbank mit aktiviertem Data Guard anzeigen

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Containerdatenbank.
  4. Klicken Sie auf der Seite Autonome Containerdatenbank - Details unter Wartung im Feld Nächste Wartung auf den Link Anzeigen.
  5. Klicken Sie auf der Seite Wartung unter Autonomous Database-Wartung auf Wartung.

    In der Liste der Wartungsereignisse werden die Details der geplanten Wartungsläufe angezeigt. Die Details zum Wartungsereignis umfassen folgende Informationen:

    • Status des geplanten Wartungslaufs
    • Typ des Wartungslaufs (vierteljährliche Softwarewartung oder kritischer Patch)
    • OCID des Wartungsereignisses
    • Startuhrzeit und Datum der Wartung

Wartungshistorie einer autonomen Containerdatenbank mit aktiviertem Data Guard anzeigen

  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der gewünschten Containerdatenbank.
  4. Klicken Sie auf der Seite Autonome Containerdatenbank - Details unter Wartung im Feld Nächste Wartung auf den Link Anzeigen.
  5. Klicken Sie auf der Seite Wartung unter Autonomous Database-Wartung auf Wartungshistorie.

    In der Liste mit früheren Wartungsereignissen können Sie auf einen Ereignistitel klicken, um die Details der Wartung anzuzeigen, die stattgefunden hat. Die Details zum Wartungsereignis umfassen folgende Informationen:

    • Kategorie der Wartung (vierteljährliche Softwarewartung oder kritischer Patch)
    • Ob die Wartung geplant oder nicht geplant war
    • OCID des Wartungsereignisses
    • Startuhrzeit und Datum der Wartung

Autonome Containerdatenbank mit aktiviertem Data Guard sofort patchen

Hinweis

Beim sofortigen Patchen der Primärdatenbank wird zuerst die Standbydatenbank gepatcht, wenn diese noch nicht gepatcht ist.
  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie in der Liste der autonomen Containerdatenbanken auf den Anzeigenamen der autonomen Containerdatenbank, die Sie patchen möchten.
  4. Klicken Sie auf der Seite Autonome Containerdatenbank - Details im Abschnitt Wartung im Feld Nächste Wartung auf den Link Anzeigen, um die Wartungsseite für die autonome Containerdatenbank anzuzeigen, die Sie patchen möchten.
  5. Klicken Sie im Abschnitt Autonome Containerdatenbank im Feld Geplante Startzeit auf Jetzt patchen, um das Dialogfeld Wartung ausführen anzuzeigen.
  6. Klicken Sie auf Jetzt patchen, um den Patching-Vorgang zu starten.

Geplante Wartung für autonome Containerdatenbank mit aktiviertem Data Guard neu planen oder überspringen

Hinweis

Wenn Sie die Primärdatenbank überspringen, wird auch die Standbydatenbank übersprungen. Wenn die Standbydatenbank gepatcht wird, ist das Überspringen der Primärdatenbank nicht zulässig.
  1. Öffnen Sie das Navigationsmenü. Klicken Sie unter Oracle Database auf Exadata Database Service on Cloud@Customer.
  2. Klicken Sie auf Autonomous Databases.
  3. Klicken Sie in der Liste der automatischen Containerdatenbanken auf den Anzeigenamen der Containerdatenbank, die Sie verwalten möchten.
  4. Klicken Sie auf der Seite Autonome Containerdatenbank - Details im Abschnitt Wartung im Feld Nächste Wartung auf den Link Anzeigen.
  5. Auf der Seite Wartung werden alle für die nächsten 15 Tage geplanten Wartungsereignisse für die Containerdatenbank in der Liste der Wartungsereignisse angezeigt.

    Um die geplante Wartung für eine Containerdatenbank zu überspringen, klicken Sie auf Überspringen.

    Hinweis

    Sie können die geplante Wartung höchstens zweimal nacheinander überspringen.

    Klicken Sie zum Neuplanen der Wartung auf Bearbeiten, und geben Sie im Dialogfeld Wartung bearbeiten eine Startzeit für das Update ein. Stellen Sie sicher, dass das angegebene Wartungsfenster der Containerdatenbank später im Quartal angesetzt ist als die geplante Wartung der Exadata-Infrastruktur.