Compute-Management in Autonomous Database on Dedicated Exadata Infrastructure

Autonomous Database on Dedicated Exadata Infrastructure bietet bei der Konfiguration Ihrer Autonomous Database-Ressourcen zwei Compute-Modelle. Diese sind:

  • ECPU: Eine ECPU ist eine abstrakte Kennzahl für Compute-Ressourcen. ECPUs basieren auf der Anzahl an Cores, die elastisch aus einem Pool von Compute- und Storage Servern zugewiesen werden. Sie benötigen mindestens 2 ECPUs, um eine Autonomous Database-Instanz bereitzustellen.

    Während Sie eine neue Datenbank bereitstellen, eine vorhandene Datenbank klonen und die CPU-Ressourcen einer vorhandenen Datenbank vertikal oder horizontal skalieren, wird die CPU-Anzahl standardmäßig auf 2 ECPUs in Schritten von 1 gesetzt. Beispiel: Die nächste verfügbare Anzahl von ECPUs über 2 ist 3.

    Sie können Autonomous Database für Entwickler-Instanzen in ECPU-basierten Containerdatenbanken erstellen. Sie sind kostenlose Autonomous Database-Anwendungen, mit denen Entwickler neue Anwendungen erstellen und testen können. Weitere Informationen finden Sie unter Autonomous Database für Entwickler.

  • OCPU: Eine OCPU ist eine physische Kennzahl für Compute-Ressourcen. OCPUs basieren auf dem physischen Core eines Prozessors mit aktiviertem Hyperthreading.

    Hinweis:

    OCPU ist eine Legacy-Abrechnungsmetrik und wurde für Autonomous Database on Dedicated Exadata Infrastructure eingestellt. Oracle empfiehlt die Verwendung von ECPUs für alle neuen und vorhandenen Autonomous Database-Deployments. Weitere Informationen finden Sie im Oracle Support-Dokument 2998755.1.

    Beim Provisioning einer neuen Datenbank, beim Klonen einer vorhandenen Datenbank und beim vertikalen oder horizontalen Skalieren der CPU-Ressourcen einer vorhandenen Datenbank gilt Folgendes:

    • Die CPU-Anzahl beträgt standardmäßig 1 OCPU in 1er Schritten. Beispiel: Die nächste verfügbare Anzahl von OCPUs über 1 beträgt 2.
    • Bei Datenbanken, für die keine ganze OCPU erforderlich ist, können Sie OCPUs von 0,1 bis 0,9 in Schritten von 0,1 OCPUs zuweisen. Dies ermöglicht das Overprovisioning von CPU und das Ausführen von mehr Datenbanken auf jeder Infrastrukturinstanz. Weitere Informationen finden Sie unter CPU-Overprovisioning.

Der Compute-Typ des autonomen Exadata-VM-Clusters gilt für alle autonomen Containerdatenbanken und Autonomous Database-Instanzen.

Verwandte Themen

Compute-Management

Autonomous Database-Instanzen werden in einem autonomen Exadata-VM-Cluster (AVMC) und in einer der untergeordneten autonomen Containerdatenbanken (ACD) bereitgestellt. Exadata-Infrastrukturen können mehrere AVMCs ausführen. Die CPUs, die Sie beim Provisioning einer AVMC-Ressource zuweisen, entsprechen den gesamt verfügbaren CPUs für die Autonomous Databases. Wenn Sie mehrere AVMCs erstellen, kann jedes AVMC einen eigenen Wert für die gesamten CPUs haben.

Mehrere autonome VM-Exadata-VM-Cluster sind in keinem Oracle Public Cloud-Deployment von Exadata-Infrastrukturressourcen (EI) verfügbar, die vor dem Start des Features "Mehrere VMs - Autonomous Database" erstellt wurden. Für die X8M-Generierung und höher als die Exadata-Infrastrukturressourcen, die nach dem Start des Features "Mehrere AVMC" erstellt wurden, wird jeder AVMC mit einem Clusterknoten für jeden der Server der ausgewählten Exadata-Systemausprägung erstellt. Informationen zum Einschränken dieser gesamten CPUs über verschiedene Benutzergruppen hinweg finden Sie unter Wie Compartment-Quotas sich auf die CPU-Verwaltung auswirken.

Hinweis:

Die maximale Anzahl von AVMC- und ACD-Ressourcen, die Sie auf einer bestimmten Exadata-Infrastruktur erstellen können, hängt von der Generierung der Hardware ab. Weitere Informationen zu Constraints für jede Generation finden Sie unter Ressourcenlimits und Merkmale von Infrastrukturausprägungen.

Auf AVMC- oder ACD-Ebene wird die gesamte Anzahl der CPUs, die zum Erstellen von Datenbanken verfügbar sind, als verfügbare CPUs bezeichnet. Auf AVMC-Ressourcenebene sind die verfügbaren CPUs bis zum Erstellen der ersten ACD mit den gesamten CPUs identisch. Nachdem Sie ein ACD erstellt haben, werden 8 ECPUs oder 2 OCPUs pro Knoten der neuen ACD aus den verfügbaren CPUs des AVMC zugewiesen. Die verfügbaren CPUs auf AVMC-Ressourcenebene werden also entsprechend reduziert. Wenn Sie die erste Autonomous Database-Instanz in dieser ACD erstellen, belegt die neue Datenbank die anfänglich zugewiesenen CPUs (8 ECPUs oder 2 OCPUs pro Knoten). Wenn die neue Datenbank mehr als 8 ECPUs oder 2 OCPUs benötigt, werden sie aus den verfügbaren CPUs der übergeordneten AVMC zugewiesen. Hierdurch werden die verfügbaren CPUs auf der übergeordneten AVMC-Ebene reduziert. Wenn Sie weitere ACDs erstellen und Autonomous Databases innerhalb jeder ACD bereitstellen, ändert sich der verfügbare CPU-Wert entsprechend.

Die verfügbaren CPUs auf der Ebene des autonomen Exadata-VM-Clusters gelten für alle autonomen Containerdatenbanken. Diese Anzahl der für die Containerdatenbank verfügbaren CPUs ist wichtig, wenn Sie das Autoscaling-Feature verwenden, wie unter CPU-Zuweisung bei Autoscaling beschrieben.

Wenn Sie die CPUs einer Autonomous Database-Instanz manuell vertikal skalieren, werden CPUs von den verfügbaren CPUs auf der übergeordneten AVMC-Ebene verbraucht, und der Wert ändert sich entsprechend.

Wenn Sie eine Autonomous Database erstellen, reserviert Oracle standardmäßig zusätzliche CPUs, um sicherzustellen, dass die Datenbank auch bei Knotenausfällen mit mindestens 50% Kapazität ausgeführt werden kann. Beim Provisioning einer ACD können Sie den Prozentsatz der CPUs, die über Knoten hinweg reserviert sind, auf 0% oder 25% ändern. Anweisungen finden Sie unter Knoten-Failover-Reservierung in Autonome Containerdatenbank erstellen. Diese zusätzlichen CPUs sind in der Abrechnung nicht enthalten.

Wenn eine Autonomous Database-Instanz ausgeführt wird, wird Ihnen die Anzahl der CPUs in Rechnung gestellt, die der Datenbank derzeit zugewiesen sind, unabhängig davon, ob sie bei der Erstellung oder später durch einen manuellen Skalierungsvorgang angegeben wurde. Wenn das Auto-Scaling für die Datenbank aktiviert ist, wird Ihnen außerdem jede Sekunde für zusätzliche CPUs in Rechnung gestellt, die die Datenbank aufgrund einer automatischen vertikalen Skalierung verwendet. Weitere Informationen zur Messung und Berechnung der Abrechnung finden Sie unter CPU-Abrechnungsdetails.

Wenn eine Autonomous Database gestoppt wird, werden Sie nicht in Rechnung gestellt. Die Anzahl der ihr zugewiesenen CPUs wird jedoch nicht an die verfügbaren CPUs auf der übergeordneten AVMC-Ebene für das gesamte Deployment zurückgegeben.

Wenn eine Autonomous Database beendet oder herunterskaliert wird, wird die Anzahl der ihr zugewiesenen CPUs nicht sofort an die verfügbaren CPUs auf der übergeordneten AVMC-Ebene für das gesamte Deployment zurückgegeben. Sie werden auch weiterhin in die Anzahl der CPUs aufgenommen, die für die übergeordnete Containerdatenbank verfügbar sind, bis diese übergeordnete Containerdatenbank neu gestartet wird. Diese CPUs werden als freizugebende CPUs bezeichnet. Die freizugebenden CPUs auf der übergeordneten AVMC-Ebene sind die Summe der freizugebenden CPUs aller ACDs. Wenn eine ACD neu gestartet wird, werden alle ihre freigegebenen CPUs wieder den verfügbaren CPUs auf der übergeordneten AVMC-Ebene zugewiesen.

Das Neustarten einer autonomen Containerdatenbank (ACD) ist ein Onlinevorgang, der im gesamten Cluster rollierend ausgeführt wird. Wenn die Konfiguration gemäß den Best Practices für die Verwendung von Transparent Application Continuity erfolgt, führt dies nicht zu Anwendungsausfallzeiten.

Tipp:

Sie können die verschiedenen Compute-(CPU-)Attribute, die in diesem Artikel behandelt werden, auf der Seite Details eines autonomen Exadata-VM-Clusters (AVMC) oder einer autonomen Containerdatenbank (ACD) verfolgen. Weitere Informationen finden Sie unter Resource Usage Tracking.

CPU-Zuweisung bei Autoscaling

Mit dem Autoscaling-Feature kann eine Autonomous Database bis zu dreimal mehr CPU- und E/A-Ressourcen nutzen als die zugewiesene CPU-Anzahl. Wenn bei einem CPU-Overprovisioning die dreifache CPU-Anzahl zu einem Wert kleiner als 1 führt, wird sie auf die nächste Ganzzahl gerundet. CPU-Overprovisioning wird nur mit OCPUs unterstützt. Weitere Details finden Sie unter CPU-Overprovisioning.

Um sicherzustellen, dass keine einzelne Autonomous Database-Instanz automatisch vertikal skalieren kann, bis alle im Pool verfügbaren CPUs für das Gesamt-Deployment belegt sind, verwendet Oracle Autonomous Database on Dedicated Exadata Infrastructure die autonome Containerdatenbank als Begrenzungskontrolle.

Beim Provisioning eines für Autoscaling aktivierten Autonomous Database in einer ACD werden zusätzliche CPUs in dieser ACD reserviert, wenn die verfügbaren CPUs in dieser ACD kleiner als der CPU-Wert 3X der neuen Datenbank ist. Diese CPUs werden als reservierte CPUs bezeichnet. Reservierte CPUs stellen sicher, dass die verfügbaren CPUs auf ACD-Ebene immer größer/gleich dem CPU-Wert 3x der größten Datenbank mit aktiviertem Autoscaling in dieser ACD sind. Diese reservierten CPUs können weiterhin verwendet werden, um Autonomous Databases in dieser ACD zu erstellen oder manuell zu skalieren.

Wenn eine Autonomous Database automatisch vertikal skaliert wird, sucht Oracle Autonomous Database on Dedicated Exadata Infrastructure nach inaktiven CPUs in der übergeordneten Containerdatenbank. Wenn CPUs im Leerlauf verfügbar sind, wird Autonomous Database vertikal skaliert. Andernfalls wird es nicht skaliert. Datenbanken haben grundsätzlich viel Leerlaufzeit. Daher ist Autoscaling eine Möglichkeit, die Ressourcennutzung zu maximieren sowie gleichzeitig Kosten zu kontrollieren und eine gute Isolation von Datenbanken in anderen autonomen Containerdatenbanken zu gewährleisten.

Wenn die CPU für die automatische Skalierung einer Autonomous Database von einer anderen ausgeführten Autonomous Database stammt, die gering geladen ist und daher nicht alle zugewiesenen CPUs verwendet, skaliert Oracle Autonomous Database on Dedicated Exadata Infrastructure die automatisch skalierte Datenbank automatisch herunter, wenn die Last auf der anderen Datenbank steigt und die zugewiesene CPU wieder benötigt wird.

Betrachten Sie das Beispiel einer autonomen Containerdatenbank, die vier autonome Datenbanken mit 4 CPUs hostet, für die Autoscaling aktiviert ist. Die Anzahl der CPUs, die der Containerdatenbank für Autoskalierungszwecke zur Verfügung stehen, beträgt 12. Wenn eine dieser Datenbanken aufgrund einer Erhöhung der Last automatisch über 4 CPUs skaliert werden muss, führt Oracle Autonomous Database on Dedicated Exadata Infrastructure den Autoscaling-Vorgang nur dann aus, wenn eine oder mehrere der anderen Datenbanken gering beladen sind und nicht alle zugewiesenen CPUs verwenden. Die Abrechnungskosten in diesem Beispiel belaufen sich auf mindestens 16 CPUs, da alle vier Datenbanken mit 4 CPUs immer ausgeführt werden.

Betrachten Sie hingegen das Beispiel einer autonomen Containerdatenbank, die vier aktive autonome Datenbanken mit 2 CPUs hostet, für die Autoscaling aktiviert ist, und eine Autonomous Database mit 8 CPUs. Die Anzahl der CPUs, die der Containerdatenbank für Autoskalierungszwecke zur Verfügung stehen, beträgt erneut 16. Wenn eine der ausgeführten Datenbanken aufgrund einer Erhöhung der Last über 2 CPUs automatisch skaliert werden muss, kann Oracle Autonomous Database on Dedicated Exadata Infrastructure den Vorgang mit CPUs ausführen, die der gestoppten Datenbank mit 8 CPUs zugewiesen sind. In diesem Beispiel können die vier aktiven Datenbanken bis zu 8 zusätzliche CPUs gleichzeitig nutzen, ohne die zugewiesenen CPUs der anderen zu belegen. Die Abrechnungskosten in diesem Beispiel belaufen sich auf mindestens 8 CPUs, da nur die vier Datenbanken mit 2 CPUs immer ausgeführt werden.

Bei jeder lokalen oder regionsübergreifenden Autonomous Data Guard-Serviceinstanz entspricht die zusätzliche Preisgestaltung der Anzahl von ECPUs oder OCPUs, die Sie beim Erstellen oder expliziten Skalieren Ihrer primären Serviceinstanz reserviert haben, unabhängig davon, ob Autoscaling aktiviert ist oder nicht. ECPU- oder OCPU-Verbrauch in Bezug auf Autoscaling auf Primärserviceinstanzen tritt nicht auf Autonomous Data Guard-Standbyserviceinstanzen auf.

Auswirkungen von Compartment Quotas auf die CPU-Management

Wenn Sie eine Autonomous Database-Instanz erstellen oder vertikal skalieren, hängt die Fähigkeit von Oracle Autonomous Database on Dedicated Exadata Infrastructure zur Erfüllung Ihrer Anforderung normalerweise nur von der Verfügbarkeit nicht zugewiesener CPUs im einzelnen Pool von CPUs im gesamten Deployment ab.

Mit dem Feature für Compartment Quotas von Oracle Cloud Infrastructure können Sie jedoch die Anzahl der verfügbaren CPUs weiter einschränken, um autonome Datenbanken jedes Workload-Typs (Data Warehouse oder Transaktionsverarbeitung) einzeln zu erstellen, manuell zu skalieren und automatisch zu skalieren.

Kurz gesagt, verwenden Sie das Feature für Compartment Quotas, indem Sie set-, unset- und zero-Policy-Anweisungen erstellen, um die Verfügbarkeit einer bestimmten Ressource in einem bestimmten Compartment einzuschränken. Weitere Informationen und Anweisungen finden Sie unter Compartment Quotas.

Auswirkungen von VM-Clusterknoten auf die CPU-Management

In der vorhergehenden Erläuterung zu CPU-Management und Zuweisung wird angegeben, dass Sie beim Provisioning der AVMC-Ressource mehrere autonome Exadata-VM-Clusterressourcen (AVMC) erstellen können, indem Sie die CPU-Anzahl pro Knoten auswählen.

In diesem Abschnitt wird detailliert erörtert, wie Oracle Cloud Infrastructure Autonomous Databases in den VM-Clusterknoten platziert und wie sich diese Platzierung auf das Autoscaling und die parallele Verarbeitung auswirkt.

Die folgenden Attribute bestimmen, wann und wie eine Autonomous Database auf mehreren Knoten platziert wird:

  • Geteilter Schwellenwert: Der CPU-Wert, über den Oracle Cloud Infrastructure eine Autonomous Database über mehrere Knoten hinweg öffnet. Der Standardaufteilungsschwellenwert beträgt 64 für ECPUs und 16 für OCPUs. Wenn VM-Cluster jedoch mit einer CPU-Knotenanzahl unter dem Standardwert erstellt werden, wird der Standardwert auf die Knotenanzahlgröße des VM-Clusters außer Kraft gesetzt.Sie können den Aufteilungswert auch beim Provisioning einer autonomen Containerdatenbank (ACD) explizit mit dem Attribut "Aufteilungsschwellenwert" festlegen.

    Autonomous Databases, die mit einem CPU-Wert erstellt werden, der kleiner als der Aufteilungswert ist, werden auf einem Knoten im Cluster geöffnet, und diejenigen, die mit einem CPU-Wert erstellt werden, der größer als der Aufteilungsschwellenwert ist, werden auf mehreren Knoten geöffnet.

    • Angenommen, Sie erstellen eine ACD mit einem Standardaufteilungsschwellenwert (64 ECPUs) in einem AVMC mit zwei Knoten und 40 ECPUs pro Knoten. Da 40 kleiner als 64 ist, wird jede Autonomous Database mit einer CPU-Anforderung von mehr als 40 auf mehrere Knoten aufgeteilt und geöffnet, sodass DML-Anforderungen über diese Knoten hinweg möglich sind. Wenn der AVMC jedoch mit zwei Knoten und 80 ECPUs pro Knoten erstellt wurde, wird jede Datenbank mit einer ECPU-Anforderung von mehr als 64 auf mehrere Knoten aufgeteilt und geöffnet.

    • Angenommen, Sie erstellen eine ACD in einem VM-Cluster mit zwei Knoten und 40 ECPUs pro Knoten und stellen den Aufteilungsschwellenwert explizit auf einen viel kleineren Wert, z.B. 20 ECPUs. Jede Autonomous Database mit einer CPU-Anforderung von mehr als 20 wird auf mehrere Knoten aufgeteilt und geöffnet. Datenbanken mit einer CPU-Anforderung von weniger als 20 werden auf einem einzelnen Knoten geöffnet.

      Wenn Sie den Split-Schwellenwert auf eine viel kleinere Anzahl als den Standardwert setzen, erhöht sich die Wahrscheinlichkeit, dass Datenbanken mit kleineren CPU-Zählungen auf mehreren Knoten geöffnet werden, solange ihre CPU-Anzahl größer als der festgelegte Split-Wert ist. Wenn eine Datenbank erstellt oder auf eine Größe skaliert wird, die größer als dieser Aufteilungswert ist, wird sie auf mehreren Knoten geöffnet. Dies ist nützlich, wenn Datenbanken auf mehreren Knoten geöffnet werden sollen, um die Performancebeeinträchtigung bei einem Knotenausfall oder einer geplanten Wartung zu steuern. Bei Datenbanken, die auf mehrere Knoten in größeren RAC-Clustern aufgeteilt sind, können Sie bei einem Ausfall eines Knotens oder bei einer geplanten Wartung weiterhin eine höhere Performance erzielen, anstatt sich auf ein Performanceprofil von 50% herabzusetzen.

    • Angenommen, Sie stellen den Aufteilungsschwellenwert in einem AVMC mit zwei Knoten und 40 ECPUs explizit auf einen viel höheren Wert als den Standardwert, z.B. 80 ECPUs, ein. Jede Autonomous Database mit einer CPU-Anforderung von mehr als 40 wird auf mehrere Knoten aufgeteilt und geöffnet. Datenbanken mit einer CPU-Anforderung von weniger als 40 werden auf einem einzelnen Knoten geöffnet.

      Wenn Sie den Split-Schwellenwert auf einen Wert einstellen, der viel höher als der Standardwert ist, bleibt die Datenbank-DML auf einem einzelnen RAC-Knoten erhalten, und die Wahrscheinlichkeit, dass Cluster-Wait-Konflikte auftreten, wird ausgeschlossen.

    • Wenn Sie eine Autonomous Database manuell skalieren, wird der neue CPU-Wert auf das vorhandene Splitmodell angewendet. Das heißt, wenn der neue Wert kleiner als der Aufteilungsschwellenwert ist, wird er auf einem Knoten geöffnet, und wenn der Wert größer als der Aufteilungsschwellenwert ist, wird er auf mehreren Knoten geöffnet.

  • Verteilungsaffinität: Bestimmt die Anzahl der Knoten, auf denen eine Autonomous Database geöffnet wird, sobald sie den Aufteilungsschwellenwert überschreitet.

    Beispiel: Sie haben eine AVMC-Ressource mit 4 Knoten und 80 ECPUs pro Knoten erstellt, und Sie haben in diesem AVMC eine ACD mit dem Geteilten Schwellenwert der Datenbank auf 64 erstellt. Wenn Sie eine Autonomous Database mit einer ECPU-Anforderung von 120 erstellen, wird die Datenbank auf mehrere Knoten aufgeteilt und geöffnet, wenn 120 größer als 64 (Geteilter Schwellenwert) ist.

    • Wenn Ihre Verteilungsaffinität auf Minimale Knoten gesetzt ist, versucht Oracle Cloud Infrastructure, die Datenbank auf 2 Knoten mit 60 ECPUs auf jedem Knoten zu erstellen. Wenn dies nicht möglich ist, wird es auf 3 Knoten mit je 40 ECPUs aufgeteilt. Wenn dies auch nicht möglich ist, versucht Oracle Cloud Infrastructure, die Datenbank über 4 Knoten mit jeweils 30 ECPUs zu öffnen.

    • Wenn Sie die Verteilungsaffinität für Maximale Knoten angeben, versucht Oracle Cloud Infrastructure, die Datenbankaufteilung auf alle 4 Knoten mit jeweils 30 ECPUs zu erstellen. Wenn dies nicht möglich ist, wird es auf drei Knoten mit je 40 ECPUs aufgeteilt. Wenn dies auch nicht möglich ist, versucht Oracle Cloud Infrastructure, die Datenbank über 2 Knoten mit jeweils 60 ECPUs zu öffnen.

  • Knoten-Failover-Reservierung (%): Die Anzahl der CPUs, die auf angrenzenden Knoten (Knoten, auf denen die Datenbanksoftware vorhanden, aber nicht geöffnet ist) in Ihrem AVMC für lokalisierte Fehler- und Wartungsereignisse beiseite gelegt wurden. Die Knoten-Failover-Reservierung gilt für nicht aufgeteilte Datenbank-Deployments.Standardmäßig ist eine Reserve von 50% vorhanden, d.h. während eines Fehlerereignisses oder einer Wartung werden Sie weiterhin ausgeführt, jedoch mit 50% der zugewiesenen CPU.

    • Bei nicht kritischen Datenbanken oder Datenbanken mit sehr geringer Auslastung können Sie die Node Failover-Reservierung auf einen kleineren Wert setzen, sodass Sie am Ende eine größere Anzahl von Datenbanken in Ihrer dedizierten Exadata-Infrastruktur erstellen und konsolidieren können.

    • Sie können diesen Wert für Entwicklungsumgebungen und Datenbanken, bei denen eine Ausfallzeit während der Wartung zulässig ist, auf null setzen.

    • In gewissem Maße kann die Node Failover-Reservierung auch gesteuert werden, indem sichergestellt wird, dass eine Datenbank auf mehr als 2 Knoten aufgeteilt wird, wobei der Split-Schwellenwert und die Verteilungsaffinität verwendet werden.Betrachten Sie ein Szenario, in dem eine Autonomous Database auf 4 Knoten aufgeteilt ist. Wenn Sie einen Knoten nach dem anderen im Rolling-Modus entfernen, während eine Wartungsaktivität ausgeführt wird, haben Sie immer noch 3 Knoten und nehmen Traffic auf, sodass Ihre Leistungsreserve effektiv um 75% anstatt der üblichen 50% bleibt. Bei größeren Clustern können Sie diese Reserve noch weiter erhöhen, z. B. bei einer Reserve von 87,5% auf einem Cluster mit 8 Knoten.
Die Verteilung der CPU-Zuweisung von Autonomous Database auf VM-Clusterknoten wirkt sich auf die folgenden Vorgänge aus:
  • Autoscaling:
    • Die automatische Skalierung kann innerhalb eines einzelnen VM-Clusterknotens für nicht parallelisierbare DML und über VM-Clusterknoten hinweg erfolgen, wenn die DML parallelisierbar ist.
    • Mehrere gleichzeitige Sessions mit nicht-parallelisierbaren Abfragen können an alle Knoten im Cluster weitergeleitet werden, sodass eine automatische Skalierung über alle Knoten in einer Datenbank mit mehreren Knoten hinweg möglich ist.
  • Parallele Verarbeitung:
    • Die parallele Verarbeitung von SQL-Anweisungen erfolgt innerhalb von autonomen Exadata-VM-Clusterknoten, die offen sind, zuerst innerhalb eines einzelnen Knotens und dann in angrenzenden offenen Knoten. Wie oben beschrieben, hängt dies von der Größe des autonomen Exadata-VM-Clusters ab.

Je nach Ressourcenauslastung auf jedem Knoten können nicht alle Werte der verfügbaren CPUs zum Provisioning oder Skalieren von Autonomous Databases verwendet werden. Beispiel: Sie haben 20 CPUs auf AVMC-Ebene verfügbar. Nicht alle Werte von 1 bis 20 CPUs können verwendet werden, um Autonomous Databases je nach Ressourcenverfügbarkeit auf Knotenebene bereitzustellen oder zu skalieren. Die Liste der CPU-Werte, mit denen eine Autonomous Database bereitgestellt oder skaliert werden kann, wird als bereitstellbare CPUs bezeichnet.

Wenn Sie versuchen, eine Autonomous Database über die OCI-Konsole bereitzustellen oder zu skalieren, erhalten Sie im Feld "CPU" eine Dropdown-Liste mit der Liste der bereitstellbaren CPUs. Alternativ können Sie die folgenden APIs verwenden, um die Liste der vorläufigen CPU-Werte abzurufen:

  • GetAutonomousContainerDatabase gibt eine Liste der bereitstellbaren CPU-Werte zurück, mit denen ein neues Autonomous Database in der angegebenen autonomen Containerdatenbank erstellt werden kann. Weitere Informationen finden Sie unter GetAutonomousContainerDatabase.

  • GetAutonomousDatabase gibt eine Liste der bereitstellbaren CPU-Werte zurück, die zur Skalierung einer bestimmten Autonomous Database-Instanz verwendet werden können. Weitere Informationen finden Sie unter GetAutonomousContainerDatabase.