Gestisci le risorse del carico di lavoro con Database Resource Manager in Autonomous Database

I sottoprogrammi cs_resource_manager consentono di associare criteri e direttive specifici per l'uso delle risorse a ciascun gruppo di consumer e di implementare, monitorare e rivedere i criteri man mano che i requisiti cambiano.

Con i sottoprogrammi cs_resource_manager è possibile effettuare le operazioni indicate di seguito.

• Creare il proprio piano DBRM (Database Resource Manager).
• Consente di creare ed eliminare gruppi di consumer personalizzati.
• Impostare i mapping dei gruppi di consumer, ovvero regole e priorità per l'assegnazione delle sessioni a questi gruppi di consumer.
• Impostare le priorità del mapping del gruppo di consumer.
• Definire le direttive del piano per assegnare i controlli delle risorse seguenti per ogni gruppo di consumer personalizzati:
  • Condivisione dell'allocazione delle risorse per il gruppo di consumer. Le condivisioni determinano la quantità di risorse CPU e IO che un gruppo di consumer ottiene rispetto ad altri gruppi di consumer. Ad esempio, un gruppo di consumer con una quota di 2 otterrà il doppio delle risorse CPU e IO rispetto a un gruppo di consumer con una quota di 1. Il valore predefinito è 1.
  • Limiti delle risorse che determinano il numero massimo di risorse CPU e I/O che un gruppo di consumer può ottenere.
  • Tempo alla CPU (in secondi) durante il quale una sessione può essere eseguita prima dell'esecuzione dell'azione determinata dal parametro switch_action. L'impostazione predefinita è NULL, ovvero illimitato.
  • Quantità di I/O (in MB) che una sessione può emettere prima dell'esecuzione dell'azione determinata dal parametro switch_action. L'impostazione predefinita è NULL, ovvero illimitato.
  • Numero di richieste di I/O che una sessione può emettere prima dell'esecuzione dell'azione determinata dal parametro switch_action. L'impostazione predefinita è NULL, ovvero illimitato.
  • Numero di I/O logici che attiveranno l'azione specificata da switch_action.
  • Tempo trascorso (in secondi) che attiverà l'azione specificata da switch_action.
  • Numero di secondi durante i quali una sessione può rimanere inattiva prima dell'interruzione della sessione. L'impostazione predefinita è NULL, ovvero illimitato.
  • Periodo di tempo massimo, in secondi, durante il quale una sessione può rimanere inattiva prima dell'interruzione della sessione, se la sessione contiene un blocco o una risorsa necessari per altre sessioni.
  • Numero massimo di sessioni che possono contemporaneamente avere una chiamata attiva.
  • Tempo (in secondi) trascorso il quale si verificherà il timeout di una chiamata nella coda della sessione inattiva (in attesa di esecuzione). L'impostazione predefinita è NULL, ovvero illimitato.
  • Limitare il grado di parallelismo (DOP) per qualsiasi operazione. L'impostazione predefinita è NULL, ovvero illimitato. Utilizzare il valore 1 affinché un'operazione sia seriale
  • Livello di concorrenza per istruzioni parallele. Poiché il livello di concorrenza determina indirettamente DOP, l'impostazione di entrambi i valori creerà un conflitto. Si consiglia di impostare solo la concorrenza o il grado di parallelismo per un gruppo di consumer, non entrambi.
  • Quantità massima di PGA non configurabile (in MB) che una sessione in questo gruppo di consumer può allocare prima di essere interrotta. NULL (impostazione predefinita) indica l'assenza di limiti. Le operazioni SQL che allocano PGA configurabile (operazioni che possono scegliere di utilizzare lo spazio temporaneo) non sono controllate da questo limite.
  • Tempo (in secondi) durante il quale un'istruzione parallela può rimanere nella coda delle istruzioni parallele del gruppo di consumer. È necessario abbinarla all'azione da eseguire quando un'istruzione parallela viene rimossa dalla coda a causa del timeout. Le opzioni consentono di annullare o eseguire l'istruzione.
  • Azioni da intraprendere al raggiungimento di uno qualsiasi dei limiti specificati nelle direttive. I valori validi sono cancel_sql, kill_session o il nome di un gruppo di consumer a cui passare.
• Attivare il piano DBRM personalizzato e, se necessario, ripristinare l'impostazione predefinita.

Gli argomenti riportati di seguito descrivono il flusso di lavoro dettagliato per la definizione di gruppi di consumer personalizzati, piani e mapping di sessioni in un esempio di caso d'uso pratico. Questo flusso di lavoro e gli esempi di codice associati possono essere modificati e implementati in base alle proprie esigenze.

Prendi in considerazione un'organizzazione che ha deciso di utilizzare un Autonomous Database per un ambiente di carico di lavoro misto con applicazioni OLTP e Lakehouse. In base ai requisiti delle risorse e alle caratteristiche del carico di lavoro delle applicazioni, l'amministratore del database ha deciso che sarebbe stato ottimale definire e utilizzare piani DBRM personalizzati anziché i gruppi di consumatori e i piani predefiniti forniti con Autonomous Database.

Sono stati definiti i seguenti requisiti:

1. Creare tre (3) gruppi di consumer:
   • OLTP_HIGH per gestire le sessioni di elaborazione delle transazioni ad alta priorità.
   • OLTP_LOW per gestire le sessioni di elaborazione delle transazioni in background o con priorità bassa.
   • LH_BATCH per carichi di lavoro batch o di reporting.
2. Creare un piano denominato OLTP_LH_PLAN per suddividere le risorse tra l'elaborazione delle transazioni e i carichi di lavoro lakehouse.
3. Creare quattro (4) direttive di piano per i seguenti scenari:
   • Le sessioni di elaborazione delle transazioni ad alta priorità ottengono 8 condivisioni di CPU e I/O e nessun parallelismo.
   • Le sessioni di elaborazione delle transazioni con priorità inferiore ottengono 4 condivisioni di CPU e I/O e nessun parallelismo.
   • Le transazioni lakehouse e batch ottengono 4 condivisioni di CPU e I/O e il grado di parallelismo è limitato a 4.
   • Tutte le altre sessioni non mappate a un gruppo di consumer ottengono 1 condivisione CPU/IO e nessun parallelismo.
4. Creare i mapping utente-gruppo di consumer riportati di seguito.
   • Da APP_USER a OLTP_HIGH
   • Da LH_USER a LH_BATCH
5. Abilitare il piano.

Per utilizzare i sottoprogrammi cs_resource_manager, connettersi ad Autonomous Database come utente ADMIN. Gli utenti ADMIN possono anche concedere privilegi su questo pacchetto ad altri utenti, se necessario.

È possibile creare gruppi di consumer personalizzati utilizzando la procedura cs_resource_manager.create_consumer_group.

Una connessione (sessione) può essere inserita nel nuovo gruppo di consumer specificando il gruppo di consumer nella stringa di connessione o configurando le regole di mapping dei gruppi di consumer utilizzando i sottoprogrammi set_consumer_group_mapping e set_consumer_group_mapping_pri.

• Avviare un'area in sospeso per eseguire tutte le istruzioni DDL di Resource Manager.

  BEGIN
    CS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
  END;
  /

• Creare tre (3) gruppi di consumer:
  • OLTP_HIGH per gestire le sessioni di elaborazione delle transazioni ad alta priorità.
  • OLTP_LOW per gestire le sessioni di elaborazione delle transazioni in background o con priorità bassa.
  • LH_BATCH per carichi di lavoro batch o di reporting.

  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;
  /

  Nota
  
  OTHER_GROUPS è un gruppo implicito disponibile per impostazione predefinita per qualsiasi sessione non mappata.

Per informazioni sulla sintassi, vedere CREATE_PENDING_AREA Procedure e CREATE_CONSUMER_GROUP Procedure.

Creare un piano denominato OLTP_LH_PLAN per suddividere le risorse tra l'elaborazione delle transazioni e i tipi di carico di lavoro lakehouse.

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

Per un riferimento alla sintassi, vedere CREATE_PLAN Procedure.

È possibile assegnare e modificare le direttive del piano, ad esempio la condivisione della CPU, i limiti di I/O, la concorrenza e il parallelismo, per i gruppi di consumer personalizzati. Per la lista completa delle direttive, vedere Informazioni sul package cs_resource_manager.

Creare quattro (4) direttive di piano per i seguenti scenari:

• Le sessioni di elaborazione delle transazioni ad alta priorità ottengono 8 condivisioni di CPU e I/O e nessun parallelismo.
• Le sessioni di elaborazione delle transazioni con priorità inferiore ottengono 4 condivisioni di CPU e I/O e nessun parallelismo.
• Transazioni lakehouse e batch:
  • Ottieni 4 condivisioni CPU e I/O.
  • Avere il grado di parallelismo limitato a 4.
  • Impostare il timeout della coda parallela su 60 secondi e l'istruzione SQL verrà interrotta dopo il timeout.
• Tutte le altre sessioni non mappate a un gruppo di consumer ottengono 1 condivisione CPU/IO e nessun parallelismo.

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;
/

Per un riferimento alla sintassi, vedere CREATE_PLAN_DIRECTIVE Procedure.

È possibile mappare le sessioni ai gruppi di consumer personalizzati in base agli attributi di login e runtime della sessione. Utilizzando i programmi secondari cs_resource_manager.set_consumer_group_mapping e cs_resource_manager.set_consumer_group_mapping_pri, è possibile definire regole e priorità per l'assegnazione delle sessioni a questi gruppi di consumer e definire le priorità di mapping dei gruppi di consumer. È possibile avere più mapping con attributi diversi. In questo esempio, APP_USER viene mappato a OLTP_HIGH e LH_USER viene mappato a LH_BATCH. Questi mapping vengono valutati con l'ordine di precedenza impostato da SET_CONSUMER_GROUP_MAPPING_PRI.

È possibile determinare la modalità di inserimento delle sessioni nei gruppi di consumer mediante:

• Assegnazione stringa di connessione: specificare il valore CONSUMER_GROUP nella stringa di connessione al database come mostrato di seguito. Questo approccio ha la precedenza sul mapping e sostituirà tutti i mapping definiti.

  (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)))

• Regole di mapping: utilizzare i programmi secondari set_consumer_group_mapping e set_consumer_group_mapping_pri per assegnare sessioni o applicazioni a gruppi di consumer in base ad attributi quali nome utente o nome applicazione.

Le sessioni possono essere mappate ai gruppi di consumer in base a qualsiasi attributo elencato in DBMS_RESOURCE_MANAGER Costanti. Questi mapping vengono valutati con l'ordine di precedenza impostato da SET_CONSUMER_GROUP_MAPPING_PRI. In questo esempio è possibile mappare i gruppi di consumer in base agli utenti riportati di seguito.

• Da APP_USER a OLTP_HIGH
• Da LH_USER a 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;
/

Utilizzare validate_pending_area per rivedere le modifiche e submit_pending_area per abilitare le direttive del piano.

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

Per un riferimento alla sintassi, vedere SET_CONSUMER_GROUP_MAPPING Procedure, SET_CONSUMER_GROUP_MAPPING_PRI Procedure, VALIDATE_PENDING_AREA Procedure e SUBMIT_PENDING_AREA Procedure.

Infine, è possibile abilitare il piano DBRM personalizzato eseguendo un'istruzione ALTER come mostrato di seguito.

ALTER SYSTEM SET resource_manager_plan='OLTP_LH_PLAN';

Quando non è più necessario, è possibile disabilitare il piano ed eliminare le direttive, il piano e i gruppi di consumer del piano utilizzando le istruzioni riportate di seguito.

• Per ripristinare il piano predefinito:

  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.

• Per eliminare una direttiva piano:

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

• Per eliminare un piano:

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

• Per eliminare un gruppo di consumer:

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

Per informazioni sulla sintassi, vedere DELETE_CONSUMER_GROUP Procedure, DELETE_PLAN Procedure e DELETE_PLAN_DIRECTIVE Procedure.

Se utilizzi un piano DBRM personalizzato e ti connetti al tuo database utilizzando i servizi LOW, TP o TPURGENT, tali sessioni otterranno un parallelismo manuale e puoi limitare il grado di parallelismo per tali sessioni utilizzando le direttive del tuo piano. Se ti connetti usando i servizi HIGH e MEDIUM, quelle sessioni otterranno automaticamente il parallelismo e puoi limitare il grado di parallelismo per quelle sessioni utilizzando le direttive nel tuo piano.