Compute-Management in einer autonomen KI-Datenbank auf einer dedizierten Exadata-Infrastruktur

Autonomous AI Database on Dedicated Exadata Infrastructure bietet zwei Compute-Modelle, während Sie Ihre Autonomous AI Database-Ressourcen konfigurieren. Diese sind:

  • ECPU: Eine ECPU ist eine abstrakte Kennzahl für Compute-Ressourcen. ECPUs basieren auf der Anzahl der Cores, die elastisch aus einem Pool von Compute- und Speicherservern zugewiesen werden. Sie benötigen mindestens 2 ECPUs, um eine autonome KI-Datenbank 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 Autonome KI-Datenbank für Entwickler-Instanzen in ECPU-basierten Containerdatenbanken erstellen. Es handelt sich um kostenlose autonome KI-Datenbanken, mit denen Entwickler neue Anwendungen erstellen und testen können. Weitere Informationen finden Sie unter Autonome KI-Datenbank 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 AI Database on Dedicated Exadata Infrastructure eingestellt. Oracle empfiehlt die Verwendung von ECPUs für alle neuen und vorhandenen Autonomous AI 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 autonomen KI-Datenbankinstanzen.

Verwandte Themen

Compute-Management

Autonome KI-Datenbankinstanzen 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, sind die gesamten CPUs, die für ihre autonomen KI-Datenbanken verfügbar sind. Wenn Sie mehrere AVMCs erstellen, kann jede AVMC einen eigenen Wert für Gesamt-CPUs haben.

Ein autonomes Exadata-VM-Cluster mit mehreren VMs ist in keinem Oracle Public Cloud-Deployment von Exadata-Infrastrukturressourcen (EI) verfügbar, die vor dem Start des Features Autonome KI-Datenbank mit mehreren VMs erstellt wurden. Für Exadata-Infrastrukturressourcen der X8M-Generierung und höher, die nach dem Start des Features "Mehrere AVMC" erstellt wurden, wird jeder AVMC mit einem Clusterknoten für jeden Server der ausgewählten Exadata-Systemausprägung erstellt. Informationen zum Einschränken dieser CPU-Gesamtanzahl über verschiedene Benutzergruppen hinweg finden Sie unter Auswirkungen von Compartment-Quotas auf das CPU-Management.

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 Gesamtanzahl der CPUs, die zum Erstellen von Datenbanken verfügbar sind, als verfügbare CPUs bezeichnet. Auf AVMC-Ressourcenebene werden die verfügbaren CPUs bis zum Erstellen der ersten ACD mit den gesamten CPUs identisch. Nachdem Sie eine ACD erstellt hat, 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 autonome KI-Datenbank in dieser ACD erstellen, verbraucht 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 mehr ACDs erstellen und autonome KI-Datenbanken 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 autonomen KI-Datenbank manuell vertikal skalieren, werden CPUs von den verfügbaren CPUs auf der übergeordneten AVMC-Ebene belegt, und der Wert ändert sich entsprechend.

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

Bei der Ausführung einer autonomen KI-Datenbank wird Ihnen die Anzahl der CPUs in Rechnung gestellt, die der Datenbank derzeit zugewiesen sind, unabhängig vom Zeitpunkt der Erstellung oder später durch einen manuellen Skalierungsvorgang angegeben wurde. Wenn Autoscaling für die Datenbank aktiviert ist, wird Ihnen außerdem jede Sekunde für zusätzliche CPUs in Rechnung gestellt, die von der Datenbank aufgrund einer automatischen vertikalen Skalierung verwendet werden. Weitere Informationen zur Messung und Berechnung für die Abrechnung finden Sie unter CPU-Abrechnungsdetails.

Wenn eine autonome KI-Datenbank gestoppt wird, werden Ihnen keine Gebühren 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 autonome KI-Datenbank beendet oder vertikal skaliert 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 weiterhin in die Anzahl der CPUs aufgenommen, die ihrer übergeordneten Containerdatenbank zur Verfügung stehen, bis diese übergeordnete Containerdatenbank neu gestartet wird. Diese CPUs werden als freigabefähige 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 freizugebenden CPUs an die verfügbaren CPUs auf der übergeordneten AVMC-Ebene zurückgegeben.

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 autonome KI-Datenbank bis zu dreimal mehr CPU- und I/O-Ressourcen nutzen als die zugewiesene CPU-Anzahl. Wenn bei einem CPU-Overprovisioning das Dreifache der CPU-Anzahl einen Wert kleiner als 1 ergibt, wird diese auf die nächste Ganzzahl gerundet. CPU-Overprovisioning wird nur mit OCPUs unterstützt. Weitere Informationen finden Sie unter CPU-Overprovisioning.

Um sicherzustellen, dass keine einzelne autonome KI-Datenbank automatisch skaliert werden kann, um alle im Pool für das gesamte Deployment verfügbaren CPUs zu nutzen, verwendet Oracle Autonomous AI Database on Dedicated Exadata Infrastructure die autonome Containerdatenbank als Begrenzungskontrolle.

Wenn beim Provisioning einer autonomen KI-Datenbank mit aktiviertem Autoscaling in einer ACD die verfügbaren CPUs in dieser ACD kleiner als der CPU-Wert 3X der neuen Datenbank ist, werden zusätzliche CPUs in dieser ACD reserviert. Diese CPUs werden als reservierte CPUs bezeichnet. Reservierte CPUs stellen sicher, dass die verfügbaren CPUs auf ACD-Ebene immer größer oder 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 AI Databases in dieser ACD zu erstellen oder manuell zu skalieren.

Wenn eine autonome KI-Datenbank automatisch vertikal skaliert wird, sucht Oracle Autonomous AI Database on Dedicated Exadata Infrastructure nach inaktiven CPUs in der übergeordneten Containerdatenbank. Wenn inaktive CPUs verfügbar sind, wird die autonome KI-Datenbank vertikal skaliert, andernfalls nicht. 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, die zur automatischen Skalierung einer autonomen KI-Datenbank verwendet wurde, aus einer anderen ausgeführten autonomen KI-Datenbank stammt, die leicht geladen ist und daher nicht alle zugewiesenen CPUs verwendet, skaliert Oracle Autonomous AI Database on Dedicated Exadata Infrastructure die automatisch skalierte Datenbank automatisch herunter, wenn die Last in der anderen Datenbank steigt und die zugewiesene CPU zurück benötigt wird.

Betrachten Sie das Beispiel einer autonomen Containerdatenbank, in der vier autonome KI-Datenbanken mit 4 CPUs gehostet werden, für die Autoscrolling aktiviert ist. Die Anzahl der CPUs, die der Containerdatenbank für Autoscaling-Zwecke zur Verfügung stehen, beträgt 12. Wenn einer dieser Datenbanken aufgrund einer Erhöhung der Last automatisch über 4 CPUs skaliert werden muss, führt Oracle Autonomous AI Database auf dedizierter Exadata-Infrastruktur den Autoscaling-Vorgang nur aus, wenn mindestens eine der anderen Datenbanken geringfügig geladen ist und nicht alle zugewiesenen CPUs verwendet. Die Abrechnungskosten in diesem Beispiel belaufen sich mindestens auf 16 CPUs, da alle vier Datenbanken mit 4 CPUs immer ausgeführt werden.

Betrachten Sie im Gegensatz dazu das Beispiel einer autonomen Containerdatenbank, die vier ausgeführte 2-CPU-autonome KI-Datenbank mit aktivierter Autoscaling-Funktion hostet, und eine gestoppte autonome KI-Datenbank mit 8 CPUs. Die Anzahl der CPUs, die der Containerdatenbank für Autoscaling-Zwecke zur Verfügung stehen, beträgt erneut 16. Wenn eine der ausgeführten Datenbanken aufgrund einer Lasterhöhung über 2 CPUs automatisch skaliert werden muss, kann Oracle Autonomous AI Database on Dedicated Exadata Infrastructure den Vorgang mit CPUs ausführen, die der gestoppten 8-CPU-Datenbank zugewiesen sind. In diesem Beispiel können die vier ausgeführten Datenbanken bis zu 8 zusätzliche CPUs gleichzeitig nutzen, ohne dass die zugewiesenen CPUs der anderen belegt werden. Die Abrechnungskosten in diesem Beispiel belaufen sich nur 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 autonome KI-Datenbank erstellen oder vertikal skalieren, hängt die Fähigkeit von Oracle Autonomous AI Database on Dedicated Exadata Infrastructure zur Erfüllung Ihrer Anforderung nur von der Verfügbarkeit nicht zugewiesener CPUs im einzelnen CPU-Pool über das gesamte Deployment ab.

Mit dem Feature für Compartment Quotas von Oracle Cloud Infrastructure können Sie jedoch die Anzahl der verfügbaren CPUs, um autonome KI-Datenbanken jedes Workload-Typs (Autonomous AI Lakehouse oder autonome KI-Transaktionsverarbeitung) einzeln zu erstellen, manuell anzupassen 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 werden detaillierte Details erläutert, wie Oracle Cloud Infrastructure autonome KI-Datenbanken in den VM-Clusterknoten platziert und wie sich die Platzierung auf das Autoscaling und das parallele Verarbeiten auswirkt.

Die folgenden Attribute bestimmen, wann und wie eine autonome KI-Datenbank auf mehreren Knoten platziert wird:

  • Aufteilungsschwellenwert: Der CPU-Wert, über den Oracle Cloud Infrastructure eine autonome KI-Datenbank auf mehreren Knoten öffnet. Der Standardaufteilungsschwellenwert ist 64 für ECPUs und 16 für OCPUs. Wenn jedoch VM-Cluster mit einer CPU-Knotenanzahl unter dem Standardwert erstellt werden, wird der Standardwert auf die Knotenanzahlgröße des VM-Clusters überschrieben.Sie können den Aufteilungswert beim Provisioning einer autonomen Containerdatenbank (ACD) auch explizit mit dem Attribut "Aufteilungsschwellenwert" festlegen.

    Autonome KI-Datenbanken, die mit einem CPU-Wert erstellt werden, der kleiner als der Split-Wert ist, werden auf einem Knoten im Cluster geöffnet, und diejenigen, die mit einem CPU-Wert erstellt werden, der größer als der Split-Schwellenwert 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 autonome KI-Datenbank mit einer CPU-Anforderung größer als 40 auf mehrere Knoten aufgeteilt und geöffnet, sodass DML-Anforderungen über diese Knoten hinweg zulässig sind. Wenn die AVMC jedoch mit zwei Knoten und 80 ECPUs pro Knoten erstellt wurde, wird jede Datenbank mit einer ECPU-Anforderung größer 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 legen den Split-Schwellenwert explizit auf einen viel kleineren Wert fest, z.B. 20 ECPUs. Jede autonome KI-Datenbank mit einer CPU-Anforderung größer als 20 wird auf mehrere Knoten aufgeteilt und geöffnet. Datenbanken mit einer CPU-Anforderung kleiner 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 setzen den Aufteilungsschwellenwert in einem AVMC mit zwei Knoten und 40 ECPUs explizit auf einen viel höheren Wert ein als der Standardwert, z.B. 80 ECPUs. Jede autonome KI-Datenbank mit einer CPU-Anforderung größer als 40 wird auf mehrere Knoten aufgeteilt und geöffnet. Datenbanken mit einer CPU-Anforderung kleiner 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 autonome KI-Datenbank 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. 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 autonome KI-Datenbank geöffnet wird, sobald sie den Aufteilungsschwellenwert überschreitet.

    Beispiel: Sie haben eine AVMC-Ressource mit 4 Knoten und 80 ECPUs pro Knoten erstellt und eine ACD in diesem AVMC erstellt, wobei der Aufteilungsschwellenwert der Datenbank auf 64 gesetzt ist. Wenn Sie eine autonome KI-Datenbank mit einer ECPU-Anforderung von 120 erstellen, wird die Datenbank auf mehrere Knoten aufgeteilt und geöffnet, wobei 120 größer als 64 (Split Threshold) 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.

    • Bis zu einem gewissen Grad 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 autonome KI-Datenbank auf 4 Knoten aufgeteilt ist. Wenn Sie einen Knoten im Rolling-Modus entfernen, während eine Wartungsaktivität ausgeführt wird, haben Sie immer 3 Knoten, die noch hochgefahren sind und Traffic aufnehmen, sodass Ihre Performance-Reserve effektiv 75% und nicht die üblichen 50% beträgt. Mit größeren Clustern können Sie diese Reserve noch weiter erhöhen, z. B. eine Reserve von 87,5% auf einem Cluster mit 8 Knoten.
Die Verteilung der CPU-Zuweisung einer autonomen KI-Datenbank auf VM-Clusterknoten wirkt sich auf die folgenden Aktionen 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.

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

Wenn Sie versuchen, eine autonome KI-Datenbank über die OCI-Konsole bereitzustellen oder zu skalieren, wird im Feld "CPU" eine Dropdown-Liste mit der Liste der bereitstellbaren CPUs angezeigt. 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 eine neue autonome KI-Datenbank 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 zum Skalieren einer bestimmten autonomen KI-Datenbank verwendet werden können. Weitere Informationen finden Sie unter GetAutonomousContainerDatabase.