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

Die autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur bietet zwei Rechenmodelle bei der Konfiguration Ihrer autonomen KI-Datenbankressourcen. 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.

  Beim Provisioning einer neuen Datenbank, beim Klonen einer vorhandenen Datenbank und bei der vertikalen oder horizontalen Skalierung der CPU-Ressourcen einer vorhandenen Datenbank gilt die CPU-Anzahl standardmäßig in 2 ECPUs (in Schritten von 1). Beispiel: Die nächste verfügbare Anzahl von ECPUs über 2 ist 3.

  Sie können eine autonome KI-Datenbank für Entwicklerinstanzen in ECPU-basierten Containerdatenbanken erstellen. Dabei handelt es 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 die autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur eingestellt. Oracle empfiehlt die Verwendung von ECPUs für alle neuen und vorhandenen autonomen KI-Datenbankbereitstellungen. 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 Schritten von 1. Beispiel: Die nächste verfügbare Anzahl von OCPUs über 1 ist 2.

  • Bei Datenbanken, für die keine ganze OCPUs erforderlich sind, können Sie OCPUs in Schritten 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.

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

Mehrere autonome VM-Exadata-VM-Cluster sind in keinem Oracle Public Cloud-Deployment von Exadata-Infrastrukturressourcen verfügbar, die vor dem Start des Features "Autonome VM-KI-Datenbank" erstellt wurden. Bei 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 die CPU-Verwaltung.

Hinweis: Die maximale Anzahl von AVMC- und ACD-Ressourcen, die Sie auf einer bestimmten Exadata-Infrastruktur erstellen können, variiert je nach Hardwaregenerierung. Einzelheiten zu Constraints für jede Generation finden Sie unter Ressourcenlimits und Eigenschaften 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, 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 von den verfügbaren CPUs des übergeordneten AVMC zugewiesen, indem die verfügbaren CPUs auf der übergeordneten AVMC-Ebene reduziert werden. Wenn Sie mehr ACDs erstellen und autonome KI-Datenbanken in 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 die 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 mindestens 50% Kapazität 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. 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 Gesamt-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.

Der Neustart einer autonomen Containerdatenbank (ACD) ist ein Onlinevorgang, der im gesamten Cluster rollierend ausgeführt wird und keine Ausfallzeit der Anwendung zur Folge hat, wenn er gemäß den Best Practices für die Verwendung von Transparent Application Continuity konfiguriert wurde.

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

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 Begrenzungssteuerung.

Wenn beim Provisioning einer autonomen KI-Datenbank mit aktiviertem Autoscaling in einer ACD die verfügbaren CPUs in dieser ACD kleiner als der 3-fache CPU-Wert 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 3-fachen CPU-Wert der größten Datenbank mit aktiviertem Autoscaling in dieser ACD sind. Diese reservierten CPUs können weiterhin zum Erstellen oder manuellen Skalieren autonomer KI-Datenbanken in dieser ACD verwendet werden.

Wenn eine autonome KI-Datenbank automatisch skaliert wird, sucht Oracle Autonomous AI Database auf dedizierter Exadata-Infrastruktur 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 für die automatische 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 das Autoscaling 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 gering geladen ist und nicht alle zugewiesenen CPUs verwendet werden. 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 autonome 2-CPU-KI-Datenbanken mit aktivierter Autoscaling-Funktion hostet, und eine autonome 8-CPU-KI-Datenbank mit angehaltener CPU. 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 auf dedizierter Exadata-Infrastruktur 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 der 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. Autoscaling-bezogene ECPU- oder OCPU-Nutzung auf Primärserviceinstanzen erfolgt nicht auf Autonomous Data Guard-Standbyserviceinstanzen.

Auswirkungen von Compartment-Quotas auf das CPU-Management

Wenn Sie eine autonome KI-Datenbank erstellen oder vertikal skalieren, hängt die Fähigkeit von Oracle Autonomous AI Database auf einer dedizierten Exadata-Infrastruktur 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 für das Erstellen, manuelle Skalieren und automatische Skalieren autonomer KI-Datenbanken jedes Workload-Typs (Autonomous AI Lakehouse oder Autonomous AI Transaction Processing) einzeln auf Compartment-Basis weiter einschränken.

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 das CPU-Management

In der vorherigen Erläuterung zu CPU-Management- und Zuweisungsstatus können Sie mehrere autonome Exadata-VM-Cluster-(AVMC-)Ressourcen erstellen, indem Sie die CPU-Anzahl pro Knoten beim Provisioning der AVMC-Ressource 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 Splitwert ist, werden auf einem Knoten im Cluster geöffnet, und Datenbanken, 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 Aufteilungsschwellenwert auf eine viel kleinere Zahl als den Standardwert setzen, erhöht sich die Wahrscheinlichkeit, dass Datenbanken mit einer kleineren CPU-Anzahl auf mehreren Knoten geöffnet werden, solange ihre CPU-Anzahl größer als der festgelegte Aufteilungswert ist. Wenn eine Datenbank erstellt oder auf eine Größe skaliert wird, die größer als dieser Split-Wert ist, wird sie auf mehreren Knoten geöffnet. Dies ist nützlich, wenn Datenbanken auf mehreren Knoten geöffnet werden sollen, um die Performanceverschlechterung im Falle eines Knotenausfalls oder einer geplanten Wartung zu kontrollieren. Wenn Datenbanken auf mehrere Knoten in größeren RAC-Clustern aufgeteilt sind und ein Knoten ausfällt oder eine geplante Wartung stattfindet, können Sie weiterhin eine höhere Performance erzielen, anstatt sich auf ein Performanceprofil von 50% zu reduzieren.

  • 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 Aufteilungsschwellenwert auf einen viel höheren Wert als den Standardwert setzen, bleibt die Datenbank-DML auf einem einzelnen RAC-Knoten und vermeidet die Wahrscheinlichkeit von Cluster-Wait-Konflikten.

  • 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 ist (Split Threshold).

  • 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 jeweils 40 ECPUs aufgeteilt. Wenn dies auch nicht möglich ist, versucht Oracle Cloud Infrastructure, die Datenbank auf 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 jeweils 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.

• Node Failover-Reservierung (%): Die Anzahl der CPUs, die auf benachbarten Knoten (Knoten, auf denen Ihre Datenbanksoftware vorhanden, aber nicht geöffnet ist) in Ihrem AVMC für lokalisierte Fehler- und Wartungsereignisse reserviert sind. Die Knoten-Failover-Reservierung gilt für nicht geteilte Datenbank-Deployments. Standardmäßig gibt es eine 50%ige Reserve, d.h. während eines Ausfallereignisses oder einer Wartung werden Sie weiterhin ausgeführt, aber bei 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 auf Ihrer dedizierten Exadata-Infrastruktur erstellen und konsolidieren können.

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

  • In gewissem Umfang kann die Node Failover-Reservierung auch gesteuert werden, indem sichergestellt wird, dass eine Datenbank über 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 8-Knoten-Cluster.

Wie sich die Verteilung der CPU-Zuweisung einer autonomen KI-Datenbank auf VM-Clusterknoten auf die folgenden Vorgänge auswirken:

• Autoscaling:

  • Autoscaling 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, wodurch eine automatische Skalierung über alle Knoten in einer Datenbank mit mehreren Knoten ermöglicht wird.

• Parallele Verarbeitung:

  • Die parallele Verarbeitung von SQL-Anweisungen erfolgt innerhalb von autonomen Exadata-VM-Clusterknoten, die geöffnet sind, zuerst innerhalb eines einzelnen Knotens und dann in benachbarten offenen Knoten. Wie oben beschrieben, hängt dies von der Größe des autonomen Exadata-VM-Clusters ab.

Je nach Ressourcenauslastung auf den einzelnen Knoten können nicht alle Werte der verfügbaren CPUs zum Bereitstellen oder Skalieren autonomer KI-Datenbanken verwendet werden. Beispiel: Angenommen, Sie haben 20 CPUs auf AVMC-Ebene verfügbar. Abhängig davon, ob die Ressourcenverfügbarkeit auf Knotenebene vorhanden ist, 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 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.

Verwandte Inhalte

• Autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur fakturieren