Oracle Cloud Infrastructure-Dokumentation

Workload-Ressourcen mit Database Resource Manager in einer autonomen KI-Datenbank verwalten

Um die Ressourcenzuweisung für verschiedene Benutzer, Apps oder Workload-Typen in der autonomen KI-Datenbank anzupassen, können Sie Ihre eigenen Database Resource Manager-(DBRM-)Pläne und Nutzungsgruppen mit cs_resource_manager-Unterprogrammen erstellen und verwalten.

Die autonome KI-Datenbank verwendet einen Standardplan für die RessourcenAdministration, der die den einzelnen Services zugewiesenen Ressourcen steuert. Wenn Sie jedoch möchten, dass ein benutzerdefinierter Resource Manager-Plan die Ressourcen für verschiedene Benutzer, Apps und Workloads in Ihrer Datenbank steuert, können Sie mit cs_resource_manager-Unterprogrammen Ihre eigenen Database Resource Manager-(DBRM-)Pläne definieren und verwalten, benutzerdefinierte Nutzungsgruppen definieren und Ressourcenverwendungs-Policys in Autonomous AI Database anpassen, um die Workload-Priorisierung und die Systemressourcenzuweisung zu kontrollieren.

Themen:

Package cs_resource_manager

Mit den Unterprogrammen cs_resource_manager können Sie bestimmte Policys und Anweisungen für die Ressourcennutzung mit jeder Nutzungsgruppe verknüpfen und Ihre Policys implementieren, überwachen und ändern, wenn sich Ihre Anforderungen ändern.

Mit den Unterprogrammen cs_resource_manager können Sie:

  • Erstellen Sie Ihren eigenen Database Resource Manager-(DBRM-)Plan.

  • Benutzerdefinierte Nutzungsgruppen erstellen und löschen

  • Legen Sie Nutzungsgruppenzuordnungen fest, d.h. Regeln und Prioritäten für die Zuweisung von Sessions zu diesen Nutzungsgruppen.

  • Legen Sie Mappingprioritäten für Nutzungsgruppe fest.

  • Definieren Sie Plananweisungen, um jeder benutzerdefinierten Nutzungsgruppe die folgenden Resource Controls zuzuweisen:

    • Anteil der Ressourcenzuweisung für die Nutzungsgruppe. Shares bestimmen, wie viel CPU- und I/O-Ressource eine Nutzungsgruppe relativ zu anderen Nutzungsgruppen erhält. Beispiel: Eine Nutzungsgruppe mit einem Anteil von 2 erhält das Doppelte der CPU- und I/O-Ressourcen als eine Nutzungsgruppe mit einem Anteil von 1. Der Standardwert ist 1.

    • Ressourcenlimits, die bestimmen, wie viele CPU- und I/O-Ressourcen eine Nutzungsgruppe maximal abrufen kann.

    • CPU-Zeit (in Sekunden), die eine Session ausgeführt werden kann, bevor die durch den Parameter switch_action festgelegte Aktion ausgeführt wird. Der Standardwert ist NULL, d.h. unbegrenzt.

    • I/O-Menge (in MB), die eine Session ausgeben kann, bevor die durch den Parameter switch_action festgelegte Aktion ausgeführt wird. Der Standardwert ist NULL, d.h. unbegrenzt.

    • Anzahl der I/O-Anforderungen, die eine Session absetzen kann, bevor die durch den Parameter switch_action festgelegte Aktion ausgeführt wird. Der Standardwert ist NULL, d.h. unbegrenzt.

    • Anzahl der logischen I/Os, die die mit switch_action angegebene Aktion auslösen.

    • Verstrichene Zeit (in Sekunden), die die von switch_action angegebene Aktion auslöst.

    • Anzahl der Sekunden, die eine Session inaktiv sein kann, bevor die Session beendet wird. Der Standardwert ist NULL, d.h. unbegrenzt.

    • Maximale Zeit in Sekunden, die eine Session inaktiv sein kann, bevor die Session beendet wird, wenn die Session eine Sperre oder Ressource hält, die von anderen Sessions benötigt wird.

    • Maximale Anzahl von Sessions, die gleichzeitig einen aktiven Aufruf haben können.

    • Zeit (in Sekunden), nach der ein Aufruf in der inaktiven Sessionqueue (wartet auf Ausführung) wegen Timeout abgebrochen wird. Der Standardwert ist NULL, d.h. unbegrenzt.

    • Grenzwert für den Parallelitätsgrad (DOP) für jeden Vorgang. Der Standardwert ist NULL, d.h. unbegrenzt. Wert 1 für einen Arbeitsvorgang als Seriennummer verwenden

    • Nebenläufigkeitsebene für parallele Anweisungen. Da die Nebenläufigkeitsebene indirekt den DOP bestimmt, verursacht das Festlegen beider Werte einen Konflikt. Es wird empfohlen, nur die Parallelität oder den Parallelisierungsgrad für eine Nutzungsgruppe festzulegen, nicht beides.

    • Maximale Größe der nicht optimierbaren PGA (in MB), die eine Session in dieser Nutzungsgruppe zuweisen kann, bevor sie beendet wird. NULL (Standard) gibt keinen Grenzwert an. SQL-Vorgänge, die optimierbare PGA zuweisen (Operationen, die temporären Speicherplatz verwenden können), werden nicht von diesem Grenzwert gesteuert.

    • Zeit (in Sekunden), die eine parallele Anweisung in der Queue der parallelen Anweisung der Nutzungsgruppe verbleiben kann. Sie müssen sie mit der Aktion verknüpfen, die ausgeführt werden soll, wenn eine parallele Anweisung aufgrund eines Timeouts aus der Queue entfernt wird. Sie können die Anweisung entweder abbrechen oder ausführen.

    • Maßnahmen, die zu ergreifen sind, wenn die in den Richtlinien festgelegten Grenzen erreicht werden. Gültige Werte sind cancel_sql, kill_session oder ein Nutzungsgruppenname, zu dem gewechselt werden soll.

  • Aktivieren Sie Ihren benutzerdefinierten DBRM-Plan, und setzen Sie ihn bei Bedarf auf den Standardwert zurück.

In den folgenden Themen wird der detaillierte Workflow zur Definition benutzerdefinierter Nutzungsgruppen, Pläne und Sessionzuordnungen in einem praktischen Beispielanwendungsfall beschrieben. Dieser Workflow und die zugehörigen Codebeispiele können entsprechend Ihren Anforderungen geändert und implementiert werden.

Anwendungsfall

Betrachten Sie ein Unternehmen, das sich für die Verwendung einer autonomen KI-Datenbank für eine gemischte Workload-Umgebung entschieden hat, die sowohl OLTP- als auch Lakehouse-Anwendungen enthält. Basierend auf den Ressourcenanforderungen und Workload-Eigenschaften der Anwendungen entschied der Datenbankadministrator, dass es optimal wäre, benutzerdefinierte DBRM-Pläne zu definieren und zu verwenden, anstatt die vordefinierten Nutzungsgruppen und Pläne, die mit Autonomous AI Database geliefert werden.

Sie haben folgende Anforderungen erfüllt:

  1. Erstellen Sie drei (3) Nutzungsgruppen:

    • OLTP_HIGH zur Verarbeitung von Transaktionsverarbeitungssessions mit hoher Priorität.

    • OLTP_LOW zur Verarbeitung von Transaktionsverarbeitungssessions mit Hintergrund- oder niedriger Priorität.

    • LH_BATCH für Batch- oder Reporting-Workloads.

  2. Erstellen Sie einen Plan mit dem Namen OLTP_LH_PLAN, um Ressourcen zwischen Transaktionsverarbeitung und Lakehouse-Workloads aufzuteilen.

  3. Erstellen Sie vier (4) Plananweisungen für die folgenden Szenarios:

    • Sessions mit hoher Priorität bei der Transaktionsverarbeitung erhalten 8 CPU- und I/O-Shares und keine Parallelität.

    • Transaktionsverarbeitungssitzungen mit niedrigerer Priorität erhalten 4 CPU- und I/O-Shares und keine Parallelität.

    • Lakehouse- und Batchtransaktionen erhalten 4 CPU- und I/O-Shares, und der Parallelisierungsgrad ist auf 4 begrenzt.

    • Alle anderen Sessions, die keiner Nutzungsgruppe zugeordnet sind, erhalten 1 CPU/IO-Share und keine Parallelität.

  4. Erstellen Sie die folgenden Zuordnungen von Benutzern zu Nutzungsgruppen:

    • APP_USER bis OLTP_HIGH

    • LH_USER bis LH_BATCH

  5. Aktivieren Sie den Plan.

Voraussetzungen

Um die Unterprogramme cs_resource_manager zu verwenden, stellen Sie als Benutzer ADMIN eine Verbindung zur autonomen KI-Datenbank her. Als ADMIN-Benutzer können Sie anderen Benutzern bei Bedarf auch Berechtigungen für dieses Package erteilen.

Schritt 1: Nutzungsgruppen erstellen

Sie können benutzerdefinierte Nutzungsgruppen mit der Prozedur cs_resource_manager.create_consumer_group erstellen.

Eine Verbindung (Session) kann in der neuen Nutzungsgruppe platziert werden, indem entweder die Nutzungsgruppe in der Verbindungszeichenfolge angegeben wird oder indem Nutzungsgruppenzuordnungsregeln mit den Unterprogrammen set_consumer_group_mapping und set_consumer_group_mapping_pri konfiguriert werden.

  • Starten Sie einen Pending Area, um alle Resource Manager-DDL-Anweisungen auszuführen.

    BEGIN
  CS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
END;
/

  • Erstellen Sie drei (3) Nutzungsgruppen:

    • OLTP_HIGH zur Verarbeitung von Transaktionsverarbeitungssessions mit hoher Priorität.

    • OLTP_LOW zur Verarbeitung von Transaktionsverarbeitungssessions mit Hintergrund- oder niedriger Priorität.

    • LH_BATCH für Batch- oder Reporting-Workloads.

    BEGIN
  CS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'OLTP_HIGH',
    comment        => 'Priority OLTP sessions');

  CS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'OLTP_LOW',
    comment        => 'Background/low-priority OLTP');

  CS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'LH_BATCH',
    comment        => 'Batch / reporting workloads');
END;
/

    Hinweis

    Hinweis: OTHER_GROUPS ist eine implizite Gruppe, die standardmäßig für alle nicht zugeordneten Sessions verfügbar ist.

Syntaxverweise finden Sie unter Prozedur CREATE_PENDING_AREA und Prozedur CREATE_CONSUMER_GROUP.

Schritt 2: Plan erstellen

Erstellen Sie einen Plan mit dem Namen OLTP_LH_PLAN, um Ressourcen zwischen Transaktionsverarbeitung und Lakehouse-Workload-Typen aufzuteilen.

BEGIN
  CS_RESOURCE_MANAGER.CREATE_PLAN(
    plan    => 'OLTP_LH_PLAN',
    comment => 'Split resources between OLTP and Lakehouse workload types');
END;
/

Syntaxreferenz finden Sie unter CREATE_PLAN-Prozedur.

Schritt 3: Plananweisungen erstellen

Sie können Plananweisungen, wie CPU-Share, I/O-Limits, Parallelität und Parallelität, für Ihre benutzerdefinierten Nutzungsgruppen zuweisen und anpassen. Eine vollständige Liste der Anweisungen finden Sie unter About cs_resource_manager Package.

Erstellen Sie vier (4) Plananweisungen für die folgenden Szenarios:

  • Sessions mit hoher Priorität bei der Transaktionsverarbeitung erhalten 8 CPU- und I/O-Shares und keine Parallelität.

  • Transaktionsverarbeitungssitzungen mit niedrigerer Priorität erhalten 4 CPU- und I/O-Shares und keine Parallelität.

  • Lakehouse- und Batchtransaktionen:

    • 4 CPU- und I/O-Shares abrufen.

    • Der Parallelitätsgrad ist auf 4 begrenzt.

    • Setzen Sie den Timeout für die parallele Queue auf 60 Sekunden, und die SQL-Anweisung wird nach dem Timeout beendet.

  • Alle anderen Sessions, die keiner Nutzungsgruppe zugeordnet sind, erhalten 1 CPU/IO-Share und keine Parallelität.

BEGIN

  -- High-priority OLTP gets 8 CPU/IO shares and no parallelism
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                  => 'OLTP_LH_PLAN',
    consumer_group        => 'OLTP_HIGH',
    comment               => 'OLTP high priority',
    shares                => 8,
    parallel_degree_limit => 1
  );

  -- Lower-priority OLTP gets 4 CPU/IO shares and no parallelism
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                  => 'OLTP_LH_PLAN',
    consumer_group        => 'OLTP_LOW',
    comment               => 'OLTP low priority',
    shares                => 2,
    parallel_degree_limit => 1
  );

  -- Lakehouse / batch gets 4 shares and the degree of parallelism is capped to 4.
  -- If a parallel SQL statement waits in the queue for more than 60 seconds, it will be canceled.
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                          => 'OLTP_LH_PLAN',
    consumer_group                => 'LH_BATCH',
    comment                       => 'Lakehouse/reporting workloads',
    shares                        => 4,
    parallel_degree_limit         => 4,     -- cap DOP within this group (adjust as needed)
    parallel_queue_timeout        => 60,
    parallel_queue_timeout_action => 'CANCEL'
  );

  -- Catch-all for anything unmapped; sessions that are not mapped to a consumer group get 1 CPU/IO share and no parallelism
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                  => 'OLTP_LH_PLAN',
    consumer_group        => 'OTHER_GROUPS',
    comment               => 'Catch-all for unmapped sessions',
    shares                => 1,
    parallel_degree_limit => 1
  );
END;
/

Syntaxreferenz finden Sie unter CREATE_PLAN_DIRECTIVE-Prozedur.

4. Schritt: Nutzungsgruppenzuordnungen erstellen

Sie können Sessions Ihren benutzerdefinierten Nutzungsgruppen basierend auf den Anmelde- und Laufzeitattributen der Session zuordnen. Mit den Unterprogrammen cs_resource_manager.set_consumer_group_mapping und cs_resource_manager.set_consumer_group_mapping_pri können Sie Regeln und Prioritäten für die Zuweisung von Sessions zu diesen Nutzungsgruppen definieren und Prioritäten für die Zuordnung von Nutzungsgruppen definieren. Sie können mehrere Zuordnungen mit verschiedenen Attributen haben. In diesem Beispiel wird APP_USER OLTP_HIGH zugeordnet, und LH_USER LH_BATCH. Diese Zuordnungen werden in der Prioritätsreihenfolge ausgewertet, die durch SET_CONSUMER_GROUP_MAPPING_PRI festgelegt ist.

Sie können bestimmen, wie Sessions in Nutzungsgruppen platziert werden:

  • Zuweisung der Verbindungszeichenfolge: Geben Sie die Zeichenfolge CONSUMER_GROUP in der Datenbankverbindung wie unten dargestellt an. Dieser Ansatz hat Vorrang vor dem Mapping und überschreibt alle definierten Mappings. 
    (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=my_database_low.adb.oraclecloud.com)(CONSUMER_GROUP=OLTP_LOW))(security=(ssl_server_dn_match=yes)))

  • Zuordnungsregeln: Mit den Unterprogrammen set_consumer_group_mapping und set_consumer_group_mapping_pri können Sie Nutzungsgruppen Sessions oder Anwendungen basierend auf Attributen wie Benutzername oder Anwendungsname zuweisen.

    Hinweis

    Hinweis: set_consumer_group_mapping und set_consumer_group_mapping_pri können nicht für vordefinierte Nutzungsgruppen verwendet werden, die mit der autonomen KI-Datenbank ausgestattet sind, also TPURGENT, TP, HIGH, MEDIUM und LOW.

Sessions können Nutzungsgruppen durch eines der in DBMS_RESOURCE_MANAGER-Konstanten aufgeführten Attribute zugeordnet werden. Diese Zuordnungen werden in der Prioritätsreihenfolge ausgewertet, die durch SET_CONSUMER_GROUP_MAPPING_PRI festgelegt ist. In diesem Beispiel ordnen wir die Nutzungsgruppen den folgenden Benutzern zu:

  • APP_USER bis OLTP_HIGH

  • LH_USER bis LH_BATCH

BEGIN
  -- Map schema APP_USER to OLTP_HIGH
  CS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    attribute  => 'ORACLE_USER',
    value      => 'APP_USER',
    consumer_group => 'OLTP_HIGH');

  CS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    attribute  => 'ORACLE_USER',
    value      => 'LH_USER',
    consumer_group => 'LH_BATCH');
END;
/

Verwenden Sie validate_pending_area, um Ihre Änderungen zu prüfen, und submit_pending_area, um die Plananweisungen zu aktivieren.

BEGIN
  CS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA;
  CS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA;
END;
/

Syntaxreferenz finden Sie unter Prozedur SET_CONSUMER_GROUP_MAPPING, Prozedur SET_CONSUMER_GROUP_MAPPING_PRI, ProzedurVALIDATE_PENDING_AREA und ProzedurSUBMIT_PENDING_AREA.

Schritt 5: Plan aktivieren

Schließlich können Sie den angepassten DBRM-Plan aktivieren, indem Sie eine ALTER-Anweisung wie unten gezeigt ausführen.

ALTER SYSTEM SET resource_manager_plan='OLTP_LH_PLAN';

Optionale Maßnahmen

Wenn sie nicht mehr benötigt werden, können Sie den Plan deaktivieren und die Plananweisungen, Plan- und Nutzungsgruppen mit den folgenden Anweisungen löschen:

  • So setzen Sie den Standardplan zurück: 
    ALTER SYSTEM SET resource_manager_plan= DWCS_PLAN; -- To revert to the default plan for the Autonomous AI Lakehouse workload type.
ALTER SYSTEM SET resource_manager_plan= OLTP_PLAN; -- To revert to the default plan for other Autonomous AI Database workload types.

  • So löschen Sie eine Plananweisung:

    CS_RESOURCE_MANAGER.DELETE_PLAN_DIRECTIVE (
   plan            => <plan_name>,
   consumer_group  => <consumer_group_name>);

  • So löschen Sie einen Plan:

    CS_RESOURCE_MANAGER.DELETE_PLAN (
  plan    ==> <plan_name>);

  • So löschen Sie eine Nutzungsgruppe:

    CS_RESOURCE_MANAGER.DELETE_CONSUMER_GROUP (
   consumer_group ==> <consumer_group_name>);

Hinweis

Hinweis: Sie können keine vordefinierten Nutzungsgruppen löschen, die eine autonome KI-Datenbank enthalten, d.h. TPURGENT, TP, HIGH, MEDIUM und LOW.

Syntaxverweise finden Sie unter Prozedur DELETE_CONSUMER_GROUP, Prozedur DELETE_PLAN und Prozedur DELETE_PLAN_DIRECTIVE.

SQL-Parallelitätsverhalten mit benutzerdefinierten Plänen

Wenn Sie einen benutzerdefinierten DBRM-Plan verwenden und sich mit den Services LOW, TP oder TPURGENT bei der Datenbank anmelden, werden diese Sessions manuell parallelisiert, und Sie können den Parallelisierungsgrad für diese Sessions mit den Anweisungen in Ihrem Plan begrenzen. Wenn Sie eine Verbindung über die Dienste HIGH und MEDIUM herstellen, werden diese Sitzungen automatisch parallelisiert, und Sie können den Parallelisierungsgrad für diese Sitzungen mithilfe der Anweisungen in Ihrem Plan begrenzen.