Gerenciar Recursos de Carga de Trabalho com o Database Resource Manager no Autonomous Database

Os subprogramas cs_resource_manager permitem que você associe políticas e diretivas específicas de uso de recursos a cada grupo de consumidores e implemente, monitore e revise suas políticas à medida que seus requisitos forem alterados.

Com os subprogramas cs_resource_manager, você pode:

• Crie seu próprio plano do Database Resource Manager (DBRM).
• Crie e exclua grupos de consumidores personalizados.
• Defina mapeamentos de grupos de consumidores, ou seja, regras e prioridades para como as sessões são atribuídas a esses grupos de consumidores.
• Defina as prioridades do mapeamento do grupo de consumidores.
• Defina diretivas de plano para atribuir os seguintes controles de recursos para cada grupo de consumidores personalizado:
  • Compartilhamento de alocação de recursos para o grupo de consumidores. Os compartilhamentos determinam a quantidade de recursos de CPU e E/S que um grupo de consumidores recebe em relação a outros grupos de consumidores. Por exemplo, um grupo de consumidores com um compartilhamento de 2 obterá o dobro dos recursos de CPU e E/S do que um grupo de consumidores com um compartilhamento de 1. O valor padrão é 1.
  • Limites de recursos que determinam o máximo de recursos de CPU e E/S que um grupo de consumidores pode obter.
  • Tempo na CPU (em segundos) que uma sessão pode executar antes da ação determinada pelo parâmetro switch_action ser executada. O padrão é NULL, o que significa ilimitado.
  • Quantidade de E/S (em MB) que uma sessão pode emitir antes da ação determinada pelo parâmetro switch_action ser executada. O padrão é NULL, o que significa ilimitado.
  • Número de solicitações de Entrada/Saída que uma sessão pode emitir antes da ação determinada pelo parâmetro switch_action ser executada. O padrão é NULL, o que significa ilimitado.
  • Número de E/Ss lógicas que acionarão a ação especificada por switch_action.
  • Tempo decorrido (em segundos) que acionará a ação especificada por switch_action.
  • Número de segundos que uma sessão pode ficar ociosa antes de ser encerrada. O padrão é NULL, o que significa ilimitado.
  • Tempo máximo, em segundos, que uma sessão pode ficar ociosa antes de ser encerrada, se a sessão estiver mantendo um bloqueio ou recurso necessário para outras sessões.
  • Número máximo de sessões que podem ter simultaneamente uma chamada ativa.
  • Tempo (em segundos) após o qual uma chamada na fila de sessão inativa (aguardando a execução) expirará. O padrão é NULL, o que significa ilimitado.
  • Limite do Grau de Paralelismo (DOP) para qualquer operação. O padrão é NULL, o que significa ilimitado. Valor de uso de 1 para uma operação ser serial
  • Nível de simultaneidade para demonstrativos paralelos. Como o nível de simultaneidade determina indiretamente o DOP, a definição de ambos os valores criará um conflito. É recomendável definir apenas a simultaneidade ou o grau de paralelismo para um grupo de consumidores, não ambos.
  • Quantidade máxima de PGA não ajustável (em MB) que uma sessão deste grupo de consumidores pode alocar antes de ser encerrada. NULL (padrão) indica que não há limite. As operações SQL que alocam PGA ajustável (operações que podem optar por usar espaço temporário) não são controladas por esse limite.
  • Tempo (em segundos) que uma instrução paralela pode permanecer na fila de instruções paralelas do grupo de consumidores. Você deve emparelhá-lo com a ação a ser tomada quando uma instrução paralela for removida da fila devido ao tempo limite. As opções são cancelar ou executar a instrução.
  • Medidas a tomar para atingir qualquer dos limites especificados nas directivas. Os valores válidos são cancel_sql, kill_session ou um nome de grupo de consumidores para alternar.
• Ative seu plano de DBRM personalizado e reverta para o padrão, se necessário.

Os tópicos a seguir descrevem o workflow detalhado para definir grupos de consumidores personalizados, planos e mapeamentos de sessão em um exemplo de caso de uso prático. Esse fluxo de trabalho e os exemplos de código associados podem ser modificados e implementados de acordo com seus requisitos.

Considere uma organização que decidiu usar um Autonomous Database para um ambiente de carga de trabalho misto que tenha aplicativos OLTP e Lakehouse. Com base nos requisitos de recursos e nas características da carga de trabalho dos aplicativos, o administrador do banco de dados decidiu que seria ideal definir e usar planos DBRM personalizados em vez dos grupos de consumidores e planos predefinidos que acompanham o Autonomous Database.

Finalizaram os seguintes requisitos:

1. Crie três (3) grupos de consumidores:
   • OLTP_HIGH para tratar sessões de processamento de transações de alta prioridade.
   • OLTP_LOW para tratar sessões de processamento de transações em segundo plano ou de baixa prioridade.
   • LH_BATCH para cargas de trabalho em lote ou de relatório.
2. Crie um plano chamado OLTP_LH_PLAN para dividir recursos entre o processamento de transações e as cargas de trabalho do lakehouse.
3. Crie quatro (4) diretivas de plano para os seguintes cenários:
   • Sessões de processamento de transações de alta prioridade obtêm 8 compartilhamentos de CPU e E/S e sem paralelismo.
   • Sessões de processamento de transações de baixa prioridade obtêm 4 compartilhamentos de CPU e E/S e sem paralelismo.
   • O Lakehouse e as transações em lote obtêm 4 compartilhamentos de CPU e E/S e o grau de paralelismo é limitado a 4.
   • Todas as outras sessões que não são mapeadas para um grupo de consumidores obtêm 1 compartilhamento de CPU/E/S e nenhum paralelismo.
4. Crie os seguintes mapeamentos de usuário para grupo de consumidores:
   • APP_USER a OLTP_HIGH
   • LH_USER a LH_BATCH
5. Ative o plano.

Para usar os subprogramas cs_resource_manager, estabeleça conexão com o Autonomous Database como o usuário ADMIN. Como usuário ADMIN, você também pode conceder privilégios neste pacote a outros usuários, conforme necessário.

Você pode criar grupos de consumidores personalizados usando o procedimento cs_resource_manager.create_consumer_group.

Uma conexão (sessão) pode ser colocada no novo grupo de consumidores especificando o grupo de consumidores na string de conexão ou configurando regras de mapeamento do grupo de consumidores usando os subprogramas set_consumer_group_mapping e set_consumer_group_mapping_pri.

• Inicie uma área pendente para executar todas as instruções DDL do Resource Manager.

  BEGIN
    CS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
  END;
  /

• Crie três (3) grupos de consumidores:
  • OLTP_HIGH para tratar sessões de processamento de transações de alta prioridade.
  • OLTP_LOW para tratar sessões de processamento de transações em segundo plano ou de baixa prioridade.
  • LH_BATCH para cargas de trabalho em lote ou de relatório.

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

  Observação
  
  OTHER_GROUPS é um grupo implícito que está disponível por padrão para qualquer sessão não mapeada.

Consulte Procedimento CREATE_PENDING_AREA e Procedimento CREATE_CONSUMER_GROUP para obter referência de sintaxe.

Crie um plano chamado OLTP_LH_PLAN para dividir recursos entre o processamento de transações e os tipos de carga de trabalho do lakehouse.

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

Consulte CREATE_PLAN Procedure para obter referência de sintaxe.

Você pode atribuir e ajustar diretivas de plano, como compartilhamento de CPU, limites de E/S, simultaneidade e paralelismo, para seus grupos de consumidores personalizados. Consulte Sobre o pacote cs_resource_manager para obter a lista completa de diretivas.

Crie quatro (4) diretivas de plano para os seguintes cenários:

• Sessões de processamento de transações de alta prioridade obtêm 8 compartilhamentos de CPU e E/S e sem paralelismo.
• Sessões de processamento de transações de baixa prioridade obtêm 4 compartilhamentos de CPU e E/S e sem paralelismo.
• Lakehouse e transações em lote:
  • Obter 4 compartilhamentos de CPU e E/S.
  • Ter o grau de paralelismo limitado a 4.
  • Defina o timeout da fila paralela como 60 segundos e a instrução SQL será encerrada após o timeout.
• Todas as outras sessões que não são mapeadas para um grupo de consumidores obtêm 1 compartilhamento de CPU/E/S e nenhum paralelismo.

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

Consulte CREATE_PLAN_DIRECTIVE Procedure para obter referência de sintaxe.

Você pode mapear sessões para seus grupos de consumidores personalizados, com base nos atributos de log-in e runtime da sessão. Usando os subprogramas cs_resource_manager.set_consumer_group_mapping e cs_resource_manager.set_consumer_group_mapping_pri, você pode definir regras e prioridades de como as sessões são designadas a esses grupos de consumidores e definir prioridades de mapeamento de grupos de consumidores. Você pode ter vários mapeamentos com atributos diferentes. Neste exemplo, APP_USER é mapeado para OLTP_HIGH e LH_USER é mapeado para LH_BATCH. Esses mapeamentos são avaliados na ordem de precedência definida por SET_CONSUMER_GROUP_MAPPING_PRI.

Você pode determinar como as sessões são colocadas em grupos de consumidores por meio de:

• Designação da String de Conexão: Especifique o CONSUMER_GROUP na string de conexão do banco de dados, conforme mostrado abaixo. Esta abordagem tem precedência sobre o mapeamento e substituirá todos os mapeamentos definidos.

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

• Regras de Mapeamento: Use os subprogramas set_consumer_group_mapping e set_consumer_group_mapping_pri para designar sessões ou aplicativos a grupos de consumidores com base em atributos como nome de usuário ou nome de aplicativo.

As sessões podem ser mapeadas para grupos de consumidores por qualquer um dos atributos listados em DBMS_RESOURCE_MANAGER Constants. Esses mapeamentos são avaliados na ordem de precedência definida por SET_CONSUMER_GROUP_MAPPING_PRI. Neste exemplo, vamos mapear os grupos de consumidores pelos seguintes usuários:

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

Use validate_pending_area para revisar suas alterações e submit_pending_area para ativar as diretivas do plano.

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

Consulte Procedimento SET_CONSUMER_GROUP_MAPPING, Procedimento SET_CONSUMER_GROUP_MAPPING_PRI, Procedimento VALIDATE_PENDING_AREA e Procedimento SUBMIT_PENDING_AREA para referência de sintaxe.

Por fim, você pode ativar o plano DBRM personalizado executando uma instrução ALTER, conforme mostrado abaixo.

ALTER SYSTEM SET resource_manager_plan='OLTP_LH_PLAN';

Quando não for mais necessário, você poderá desativar o plano e excluir as diretivas, o plano e os grupos de consumidores do plano usando as seguintes instruções:

• Para reverter para o plano padrão:

  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.

• Para excluir uma diretiva de plano:

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

• Para excluir um plano:

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

• Para excluir um grupo de consumidores:

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

Consulte Procedimento DELETE_CONSUMER_GROUP, Procedimento DELETE_PLAN e Procedimento DELETE_PLAN_DIRECTIVE para obter referência de sintaxe.

Se você usar um plano DBRM personalizado e se conectar ao seu banco de dados usando os serviços LOW, TP ou TPURGENT, essas sessões terão paralelismo manual e você poderá limitar o grau de paralelismo dessas sessões usando as diretivas do seu plano. Se você se conectar usando os serviços HIGH e MEDIUM, essas sessões obterão paralelismo automaticamente e você poderá limitar o grau de paralelismo dessas sessões usando as diretivas do seu plano.