Automatische Backups: Der Speicher für Backups wird zusätzlich zum ausgewählten Datenbankspeicher pro GB in Rechnung gestellt.

Beispiel: Wenn Backups 200 GB Speicher belegen, werden Ihnen 200 GB Backupspeicher in Rechnung gestellt (zusätzlich zur Nutzung, die für die ausgewählte Anzahl von ECPUs und den Datenbankspeicher in Rechnung gestellt wird). Weitere Informationen dazu, welche SKUs für Backups in Rechnung gestellt werden, finden Sie unter Rechnungsinformationen zum ECPU-Compute-Modell.

Langfristige Backups: Der Speicher für langfristige Backups wird zusätzlich zu Ihrem Datenbankspeicher pro GB als Backupspeicher abgerechnet.

Beispiel: Wenn automatische Backups derzeit 200 GB belegen und langfristige Backups 600 GB Speicher belegen, werden Ihnen zusätzlich zu der für die ausgewählten ECPUs und den Datenbankspeicher in Rechnung gestellten Nutzung 800 GB Backupspeicher in Rechnung gestellt. Weitere Informationen dazu, welche SKUs für die einzelnen Workload-Typen und Backups in Rechnung gestellt werden, finden Sie unter Rechnungsinformationen zum ECPU-Compute-Modell.

Compute-Autoscaling: Wenn Compute-Autoscaling aktiviert ist, verwendet Ihre Datenbank möglicherweise zusätzliche ECPU-Nutzung, die von Ihrer Workload benötigt wird, bis zu dreimal (3x) die Anzahl der Basis-ECPUs, wie in der ECPU-Anzahl in der Oracle Cloud Infrastructure-Konsole dargestellt.

• Die abgerechnete ECPU-Nutzung pro Stunde während der Ausführung der Datenbank basiert auf der Basisanzahl der ECPUs, die Sie für die Datenbank ausgewählt haben, sowie auf der zusätzlichen ECPU-Nutzung aufgrund von Autoscaling.

• Eine gestoppte Autonomous Database-Instanz hat keine ECPU-Nutzung.

• Die ECPU-Nutzung wird jede Sekunde in Einheiten ganzer ECPUs gemessen und über eine Stunde gemittelt. Wenn Ihre Datenbank weniger als eine Stunde läuft oder sich automatisch für nur eine Stunde skaliert, wird sie pro Sekunde für den durchschnittlichen ECPU-Verbrauch über die Basis-ECPUs während dieser Stunde abgerechnet. Der minimale ECPU-Verbrauch beträgt eine Minute.

Beispiel: Wenn in Ihrer Datenbank ECPU-Anzahl 4 mit aktiviertem Compute-Autoscaling vorhanden ist:

• Angenommen, Ihre Datenbank ist während der gesamten Stunde verfügbar, und die ECPU-Auslastung liegt unter 4 ECPUs. Ihrer Datenbank werden 4 ECPUs in Rechnung gestellt.

• Angenommen, Ihre Datenbank ist in Stunde zwei für die gesamte Stunde verfügbar, und die ECPU-Auslastung liegt unter 4 ECPUs für 30 Minuten, 50% der Stunde und wird automatisch für 30 Minuten auf 8 ECPUs skaliert (die anderen 50% der Stunde). Die Nutzung für diesen Zeitraum beträgt für die Abrechnung 6 ECPUs (basierend auf der durchschnittlichen ECPU-Nutzung pro Sekunde für die zweite Stunde).

Automatische Speicherskalierung:

• Für die Speichernutzung unterhalb Ihres reservierten Basisspeichers werden Ihnen basierend auf Ihrem Basisspeicher Gebühren in Rechnung gestellt.

• Nachdem der zugewiesene Speicher den reservierten Basisspeicher überschreitet, wird die Speichernutzung basierend auf dem zugewiesenen Speicher in einer bestimmten Stunde auf das nächste TB aufgerundet.

Beispiel: Wenn Ihr reservierter Basisspeicher 4 TB beträgt, wird Ihnen der zugewiesene Speicher basierend auf Ihrem Basisspeicher (4 TB) in Rechnung gestellt, bis er 4 TB Speicher überschreitet. Nachdem Sie 4 TB überschritten haben, wird der Speicher basierend auf dem zugewiesenen Speicher in einer bestimmten Stunde auf das nächste TB aufgerundet. Wenn in diesem Beispiel der zugewiesene Speicher in einer bestimmten Stunde um mehr als 4 TB wächst (z. B. 4,9 TB), werden Ihnen ab dieser Stunde 5 TB Speicher in Rechnung gestellt.

Wenn Sie dann 1 TB Daten löschen, bleibt der zugewiesene Speicher bei 4,9 TB und es werden 5 TB in Rechnung gestellt, bis Sie einen Verkleinerungsvorgang ausführen. Wenn Sie einen Verkleinerungsvorgang ausführen, kann der zugewiesene Speicher möglicherweise auf 3,9 TB verkleinert/reduziert werden. Nachdem der Verkleinerungsvorgang abgeschlossen ist und Ihr zugewiesener Speicher (3,9 TB) wieder unter Ihrem reservierten Basisspeicher (4 TB) liegt, wird Ihnen erneut Ihr reservierter Basisspeicher von 4 TB in Rechnung gestellt. Weitere Informationen finden Sie unter Speicher verkleinern.

Autonomous Data Guard-Standbydatenbank – lokal (gleiche Region)

Bei lokalen Autonomous Data Guard-Peerdatenbanken fallen die zusätzlichen Kosten für die Basis-ECPUs und den Speicher der Primärdatenbank an, einschließlich der automatisch skalierten Speicherauslastung, die in der Primärdatenbank selbst abgerechnet wird. Automatisch skalierte ECPUs der Primärdatenbank werden nicht zusätzlich in der lokalen Autonomous Data Guard-Peerdatenbank abgerechnet. Die Anzahl der Basis-ECPUs wird durch die Anzahl der ECPUs angegeben, wie in der ECPU-Anzahl in der Oracle Cloud Infrastructure-Konsole dargestellt.

Beispiel: Wenn Sie einen lokalen Autonomous Data Guard-Peer in einer Quelldatenbank aktivieren mit:

• 2 (Basis-)ECPUs mit aktiviertem Compute-Autoscaling und Verbrauch von etwa 4 ECPUs pro Stunde
• 1 TB (Basis-)Speicher mit automatischer Speicherskalierung, der insgesamt 2 TB Datenbankspeicher belegt

Für den lokalen Autonomous Data Guard-Peer werden Ihnen zusätzliche 2 ECPUs (Ihre ECPU-Basisauswahl) plus weitere 2 TB Speicher in der Primärdatenbank in Rechnung gestellt (d.h. die gleiche Speichermenge, die für die Primärdatenbank der Quelle mit automatischer Skalierung reserviert ist).

Wenn die primäre Datenbank gestoppt wird, wird weder die primäre noch die Peerdatenbank für ECPU abgerechnet.

Autonomous Data Guard Standby – Remote (regionsübergreifend)

Für regionsübergreifende Peerdatenbanken von Autonomous Data Guard fallen zusätzliche Kosten für die Basis-ECPUs und zweimal (2x) den Speicher der Primärdatenbank an, einschließlich der automatisch skalierten Speicherauslastung, die in der Remote-Peerdatenbank abgerechnet wird. Automatisch skalierte ECPUs der Primärdatenbank werden nicht zusätzlich in der Remote-Peer-Datenbank abgerechnet. Die Anzahl der Basis-ECPUs wird durch die Anzahl der ECPUs angegeben, wie in der ECPU-Anzahl in der Oracle Cloud Infrastructure-Konsole dargestellt.

Beispiel: Sie aktivieren einen regionsübergreifenden Autonomous Data Guard-Peer für eine Quelldatenbank mit:

• 2 (Basis-)ECPUs mit aktiviertem Compute-Autoscaling und Verbrauch von etwa 4 ECPUs pro Stunde
• 1 TB (Basis-)Speicher mit automatischer Speicherskalierung, der insgesamt 2 TB Datenbankspeicher belegt

Für den regionsübergreifenden Autonomous Data Guard-Peer werden Ihnen zusätzliche 2 ECPUs (Ihre ECPU-Basisauswahl) plus 4 TB Speicher in Rechnung gestellt (d.h. 2x der für die Quelle "Primär" reservierte Speicher mit Autoscaling, der in der Remote-Peerdatenbank abgerechnet wird).

Wenn die primäre Datenbank gestoppt wird, werden weder die primäre noch die Peerdatenbank für ECPU abgerechnet.

Wenn die Option Regionsübergreifende Backupreplikation in Disaster-Recovery-Peer aktivieren ausgewählt ist, wird Ihnen zweimal (2x) die Backupspeichergröße in Rechnung gestellt, die für die replizierten Backups erforderlich ist und in der Remote-Standbydatenbank abgerechnet wird.

Wenn ein regionsübergreifender Peer als Snapshot-Standby ausgeführt wird, wird die Snapshot-Standby-CPU-Auslastung basierend auf der CPU-Basisanzahl und jeder zusätzlichen CPU-Auslastung abgerechnet, wenn Compute-Autoscaling aktiviert ist. Die Anzahl der Basis-CPUs wird durch die Anzahl der ECPUs angegeben, wie im Feld ECPU-Anzahl in der Oracle Cloud Infrastructure-Konsole angezeigt.

Backupbasiertes Disaster Recovery - Lokale Backupkopien (gleiche Region) Es fallen keine zusätzlichen Kosten für lokales Backup-basiertes Disaster Recovery an, abgesehen von den Speicherkosten für automatische Backups.

Backupbasiertes Disaster Recovery – regionsübergreifende Backupkopien Die Abrechnung für ein regionsübergreifendes backupbasiertes Disaster Recovery ist doppelt so hoch (2x), wie viel Backupspeicher für die replizierten regionsübergreifenden Backups erforderlich ist, die dem Remote-Peer in Rechnung gestellt werden.

Beispiel: Sie aktivieren eine regionsübergreifende Backupkopie in einer Quelldatenbank mit:

• 2 (Basis) ECPUs
• 2 TB Datenbankspeicher

Wenn die in der Remoteregion replizierten Backups 1,9 TB Speicher belegen, werden Ihnen 3,8 TB Backupspeicher in der Peerdatenbank der Remotebackupkopie in Rechnung gestellt.

Wenn die Option Regionsübergreifende Backupreplikation in Disaster-Recovery-Peer aktivieren ausgewählt ist, wird Ihnen zweimal (2x) die erforderliche Backupspeichergröße für die zusätzlichen replizierten Backups in Rechnung gestellt, die dem Remote-Peer in Rechnung gestellt wird. Diese Abrechnung basiert wie folgt auf der Anzahl der Tage, die für die Backupaufbewahrung in der primären Datenbank festgelegt wurden:

• Wenn die automatische Backupaufbewahrung auf 7 Tage oder mehr festgelegt ist, basiert die Abrechnung auf der Speichergröße für replizierte Backups von 7 Tagen.
• Wenn die automatische Backupaufbewahrung auf weniger als 7 Tage festgelegt ist, basiert die Abrechnung auf der Speichergröße für die angegebene Anzahl von Tagen Daten, die in der regionsübergreifenden Standbydatenbank repliziert werden.

Lokaler aktualisierbarer Klon (gleiche Region) Lokale aktualisierbare Klone haben eine eigene konfigurierbare ECPU-Auswahl. Daher werden ihnen ECPU basierend auf der vom Benutzer ausgewählten Anzahl von ECPUs mit oder ohne Autoscaling in Rechnung gestellt. Sie werden nicht zusätzlich über die ECPU-Auswahl abgerechnet. Die Anzahl der ECPUs wird durch die Anzahl der ECPUs angegeben, wie in der ECPU-Anzahl in der Oracle Cloud Infrastructure-Konsole dargestellt.

Lokale aktualisierbare Klone werden mit der gleichen Speichermenge wie ihre Quelldatenbank abgerechnet.

Beispiel: Wenn Sie einen lokalen aktualisierbaren Klon mit 2 ECPUs aus einer Quelldatenbank erstellen mit:

• 4 ECPUs
• 1 TB Speicher mit automatischer Speicherskalierung und 2 TB Speicherbedarf

Für den lokalen aktualisierbaren Klon werden Ihnen 2 ECPUs in Rechnung gestellt, d.h. der Wert für ECPU-Anzahl des aktualisierbaren Klons und 2 TB Speicher (d.h. der für die Quelldatenbank reservierte Speicher).

Wenn Sie die Quelldatenbank starten oder stoppen, wirken sich Ihre Aktionen in der Quelldatenbank nicht auf den aktualisierbaren Klon aus. Ein aktualisierbarer Klon wird unabhängig von der Quelldatenbank gestartet oder gestoppt.

Refreshable Clone Remote (regionsübergreifend) Aktualisierbare Remoteklone haben eine eigene konfigurierbare ECPU-Auswahl. Daher werden ihnen ECPU basierend auf der vom Benutzer ausgewählten ECPU (mit oder ohne Autoscaling) in Rechnung gestellt. Sie werden nicht zusätzlich über die ECPU-Auswahl abgerechnet. Die Anzahl der ECPUs wird durch die Anzahl der ECPUs angegeben, wie in der ECPU-Anzahl in der Oracle Cloud Infrastructure-Konsole dargestellt.

Aktualisierbare Remoteklone werden zweimal in Rechnung gestellt (2x) die Speichermenge als Quelldatenbank.

Beispiel: Wenn Sie einen Remote-aktualisierbaren Klon mit 2 ECPUs aus einer Quelldatenbank erstellen mit:

• 4 ECPUs
• 1 TB Speicher mit automatischer Speicherskalierung und 2 TB Speicherbedarf

Für den remoten aktualisierbaren Klon werden Ihnen 2 ECPUs (d.h. die ECPU-Auswahl des aktualisierbaren Klons) und 4 TB Speicher in Rechnung gestellt (d.h. 2x der für die Quelldatenbank reservierte Speicher).

Das Starten oder Stoppen der Quelldatenbank wirkt sich nicht auf den aktualisierbaren Klon aus - Der aktualisierbare Klon kann unabhängig gestartet oder gestoppt werden.

Snapshot-Standbydatenbank für Remote-Disaster Recovery (regionsübergreifend)

Die Snapshot-Standby-ECPU-Nutzung wird basierend auf der ECPU-Basisanzahl und jeder zusätzlichen ECPU-Nutzung abgerechnet, wenn Compute-Autoscaling aktiviert ist. Die Anzahl der Basis-ECPUs wird durch die Anzahl der ECPUs angegeben, wie in der ECPU-Anzahl in der Oracle Cloud Infrastructure-Konsole dargestellt.

Die Snapshot-Standby-Speicherauslastung wird basierend auf dem Speicher der Snapshot-Standbydatenbank und (1x) dem Speicher der primären Quelldatenbank abgerechnet.

Beispiel: Wenn Sie eine Snapshot-Standbydatenbank mit 2 ECPUs und 3 TB von einer Quelldatenbank mit:

• 4 ECPUs
• 1 TB Speicher mit automatischer Speicherskalierung und 2 TB Speicherbedarf

Die Snapshot-Standbydatenbank erhält 2 ECPUs (d.h. die ECPU-Auswahl der Snapshot-Standbydatenbank) und 3 TB + 2 TB = 5 TB Datenbankspeicher (d.h. der in der Snapshot-Standbydatenbank reservierte Speicher + der in der Quelldatenbank reservierte Speicher)

Elastische Pools: Mit einem elastischen Pool können Sie die 4-fache ECPU-Anzahl bereitstellen, die Sie als Poolgröße haben. Beispiel: Wenn Sie einen Pool mit einer Poolgröße von 128 ECPUs haben, können Sie in diesem Pool bis zu 512 ECPUs bereitstellen. Das heißt, wenn die Poolgröße 128 ECPUs beträgt, entspricht die Poolkapazität dem Vierfachen der Poolgröße (in diesem Beispiel 512 ECPUs).

Datenbanken, die zu einem Pool gehören, werden nicht einzeln für Compute abgerechnet. Die Compute-Abrechnung für alle Poolmitglieder und den Leader erfolgt über den Leader. Mit anderen Worten: Einzelne Member eines elastischen Pools werden nicht für Compute abgerechnet, solange sie Teil des Pools sind. Dies gilt unabhängig vom Workload-Typ für das Pool Member. Beispiel: Wenn ein Poolmitglied mit dem Workload-Typ Data Warehouse zu einem Pool hinzugefügt wird, wird die Compute-Nutzung dem Poolleiter bei der Compute-Nutzungsrate der Transaktionsverarbeitung in Rechnung gestellt. Die Speicherabrechnung hingegen wird weiterhin einzelnen Autonomous Database-Instanzen in Rechnung gestellt, unabhängig davon, ob sie Teil eines Pools sind oder nicht.

Angenommen, Sie haben einen elastischen Pool mit einer Poolgröße von 128 ECPUs. Bei der Poolgröße beträgt die Poolkapazität 512 ECPUs (Poolkapazität = 4x Poolgröße). Für dieses Beispiel finden Sie hier einige allgemeine Fragen und Antworten zur Fakturierung:

• Wie viele Autonomous Database-Instanzen sind in diesem Pool maximal zulässig? Insgesamt 512 Autonomous Database-Instanzen mit jeweils 1 ECPU (elastische Poolmitglieder oder der Leader können eine individuelle ECPU-Zuweisung von bis zu 1 ECPU haben).

• Was geschieht, wenn das hohe Wasserzeichen der aggregierten ECPU-Auslastung des Pools größer als die Poolgröße ist? Wenn das hohe Wasserzeichen für die aggregierte ECPU-Auslastung in einer bestimmten Abrechnungsstunde kleiner oder gleich der Poolgröße ist, wird die stündliche Gebühr in Höhe der Poolgröße berechnet. Wenn das hohe Wasserzeichen für die aggregierte ECPU-Auslastung größer als die Poolgröße ist, aber kleiner oder gleich der Poolgröße 2x in einer bestimmten Abrechnungsstunde ist, beträgt die stündliche Gebühr die Poolgröße 2x. Wenn das hohe Wasserzeichen für die aggregierte ECPU-Auslastung mehr als 2x Poolgröße in einer bestimmten Abrechnungsstunde beträgt, beträgt die stündliche Gebühr die Poolgröße 4x.

  Beispiel: Angenommen, 512 Autonomous Database-Instanzen mit je 1 ECPU befinden sich in einem elastischen Pool mit einer Poolgröße von 128 ECPUs. Wenn das hohe Wasserzeichen für die aggregierte ECPU-Auslastung dieser Datenbanken 100 ECPUs zwischen 1pm-2pm und 250 ECPUs zwischen 2pm-3pm beträgt, beträgt die Abrechnung 128 ECPU-Stunden zwischen 1pm-2pm und 256 ECPU-Stunden zwischen 2pm-3pm.

Weitere Informationen finden Sie unter Info über Elastic Pool Billing.

Löschen einer Autonomous Database-Instanz rückgängig machen

Wenn Sie das Löschen einer Autonomous Database-Instanz rückgängig machen, werden Ihnen in der ersten Stunde nach dem Vorgang zum Aufheben des Löschvorgangs die Basis-CPU und -Speicher, einschließlich Datenbankspeicher und Langzeitbackups, für die Gesamtzeit in Rechnung gestellt, in der die Datenbank gelöscht wurde, als ob die Datenbank nie gelöscht wurde und ausgeführt wurde.

Beispiel: Wenn Sie eine Autonomous Database-Instanz beenden mit:

• 4 ECPU mit aktiviertem Compute-Autoscaling
• 2 TB Speicher mit 100 GB automatischem Backup-Speicher und 20 GB langfristigem Backup-Speicher

Wenn Sie nach 5 Stunden und 30 Minuten das Löschen der beendeten Instanz rückgängig machen, beinhaltet die Abrechnung in der ersten Stunde nach dem Aufheben des Löschvorgangs die zusätzlichen Kosten, als ob die Datenbank nie gelöscht wurde und ausgeführt wurde, einschließlich:

• 5 Stunden und 30 Minuten für die Basis 4 ECPUs
• 2 TB Speicherplatz
• 100 GB automatischer Backup-Speicher
• 20 GB langfristiger Backup-Speicher

Geplantes Upgrade auf 23ai

Wenn Sie ein Upgrade für eine Autonomous Database-Instanz planen, gibt es zwei Möglichkeiten für den Upgradetyp:

• Zeitplan mit der frühesten Verfügbarkeit: Bei dieser Upgradeoption fallen keine zusätzlichen Kosten an.

• Zukünftiger Plan: Wenn Sie ein Upgrade mit einem zukünftigen Plan planen, werden zusätzliche Ressourcen für die Datenbank und die angehängten Klone oder Standbydatenbanken sofort deaktiviert, die wie folgt abgerechnet werden:

  • Die zusätzlichen Kosten für die Basis-ECPUs und den Speicher der Autonomous Database-Quellinstanz werden Ihnen in Rechnung gestellt.

  • Ihnen werden die zusätzlichen Kosten der Basis-ECPUs und der Datenbankspeicher für jeden angehängten lokalen und Remote-aktualisierbaren Klon in Rechnung gestellt.

  • Ihnen werden die zusätzlichen Kosten der Basis-ECPUs und des Datenbankspeichers für jede lokale und Remote-Autonomous Data Guard-Standbydatenbank in Rechnung gestellt.

  Beispiel: Wenn Sie ein Upgrade der Datenbank vornehmen und auf einer Autonomous Database-Instanz mit der folgenden Konfiguration Zukünftiger Plan mit einem Zeitplan 30 Tage in der Zukunft auswählen:

  • 4 ECPUs mit aktiviertem Compute-Autoscaling

  • 1 TB Speicher

  • 1 aktualisierbarer Klon

  • 1 autonome Remote-Data Guard-Standbydatenbank

  Sie werden wie folgt in Rechnung gestellt:

  Zweimal (2x) für die Basis-ECPUs und 2x für den Datenbankspeicher für 30 Tage, bis das Upgrade abgeschlossen ist:

  4 + 4 = 8 ECPUs

  1 + 1 = 2 TB Datenbankspeicher

  Darüber hinaus werden Ihnen die Basis-ECPUs und der Speicher auf dem angehängten aktualisierbaren Klon und der Remote-Autonomous Data Guard-Standby 30 Tage lang zweimal (2x) in Rechnung gestellt, bis das Upgrade abgeschlossen ist.

  Bei Upgrades mit elastischen Pool-Mitgliedern oder einem Elastic Pool Leader mit einem Upgrade des Typs Zukünftiger Plan:

  • Die Abrechnung für ein Member oder den Leader, wenn eines ein Upgrade plant: Die Basis-CPU-Auslastung der Datenbank wird 2x der Datenbank-OCID des Leader in Rechnung gestellt.

  • Die Abrechnung für die Speichernutzung für ein Mitglied mit einem geplanten Upgrade wird 2x direkt in der Datenbank-OCID des Mitglieds abgerechnet, getrennt von den Speicherbeträgen, die für die Abrechnung im Poolleiter gemeldet werden.

  • Die Speichernutzung für den Leader mit einem geplanten Upgrade wird 2x direkt der Datenbank-OCID des Leader in Rechnung gestellt.

  Für das Abbrechen eines geplanten Upgrades fallen keine Gebühren an. Die Gebühren, die zwischen dem Zeitpunkt, zu dem Sie das Upgrade geplant haben, und dem Zeitpunkt, zu dem Sie das Upgrade abgebrochen haben, in Rechnung gestellt wurden, bleiben jedoch erhalten.