Oracle Database 12c: Gerenciamento de Recursos com Resource Manager

Por Joel Pérez , Wissem El Khlifi e Rodrigo Mufalani
Postado em Maio de 2014


Introdução:

O Oracle database 12c possui varias melhorias nas funcionalidades de gerenciamento de recursos, principalmente com os CDBs e PDBs. Neste artigo nós iremos focar no uso do Resource Manager em um ambiente CDB.
Antes do Oracle database 12c, usávamos Resource Manager para gerenciar database workloads “brigando” por recursos do sistema como CPU. Para ambientes que tinham multiplas instances ou até mesmo múltiplas instalações do Oracle database rodando no mesmo servidor, o uso Oracle Resource Manager para gerenciar recursos do sistema (CPU, I/O e etc…) usado por todos os databases era impossível.
Porém, com o Oracle 12c, nós podemos ter múltiplas cargas de trabalho “workloads” com múltiplos PDBs “brigando” por recursos de CDB e de sistema. Assim, há possibilidade de usar Oracle Resource Manager para gerenciar system resources (CPU, I/O …)utilizados por todos aqueles databases.

O Oracle Resource Manager pode gerenciar recursos em 2 níveis diferentes:

  • Em nível CDB: Oracle Resource Manager pode gerenciar recursos utilizados por todos PDBs com um CDB.
  • Em nível PDB:  Oracle Resource Manager pode gerenciar o uso de recursos dentro de cada PDB.

Que soluções o Resource Manager fornece para um CDB?

Por padrão, todo sistema pode ter os seguintes problemas:

  • Alocação inapropriada de recursos entre os PDBs: Todos os PDBs tem o mesmo nível de prioridade.
  • Alocação inapropriada de recursos de um único PDB: Todas as cargas de trabalho de um PDB tem o mesmo nível de prioridade.
  • Falta de utilização de recursos para PDBs.

Oracle Resource Manager ajuda a superar estes problemas.
No seguinte artigo, iremos ver como o Oracle Resource Manager gerencia os recursos:

  • Entre PDBs.
  • Em um único PDB.
Gerenciando recursos entre PDBs:

Em um CDB, os PDBs podem ter diferentes níveis de prioridade / importância . Você pode criar CDB Resource Plans para distribuir recursos entre diferentes PDBs baseado em suas prioridades. PDBs podem disputar por CPU e/ou recursos de I/O. 
Um CDB Resource Plan aloca recursos para os PDBs de acordo com suas configurações de diretivas do plano de recursos (Resource Plan Directives). Cada diretiva referencia um PDB, e duas diretivas para um plano ativo não podem referenciar o mesmo PDB.
As diretivas controlam a alocação dos seguintes recursos dos PDBs:

  • CPU
  • I/O
  • Parallel Execution Servers

Compartilhamento de alocação de recursos para PDBs:
Uma diretiva pode controlar a alocação de recursos para os PDBs baseado em um valor compartilhado concedido para cada PDB. Você pode conceder diferentes valores para diferentes PDBs então há mais recursos de sistema alocados em um PDB que possui a prioridade mais alta.
Por exemplo:
A imagem seguinte mostra que cada PDB tem um "share" com um total de 4 shares, sendo assim, cada PDB foi permitido a usar 1/4 ou 25% de CPU.


Para alocar mais recursos para o PDB4, você pode designar mais valores para o PDB que resulta em mais alocação de recursos para o PDB4.
A seguinte imagem mostra que para o PDB4 foi designado 4 shares e para os outros PDBs somente 3, 1 e 2shares respectivamente. Com um total de 10 shares, PDB1, PDB2 e PDB3 estão permitidos a usar 3/10 (30%), 1/10 (10%), 2/10 (20%) dos recursos de sistema respectivamente.
Porque o PDB4 é o mais importante, ele conseguiu 4shares; ele foi autorizado a usar 4/10ou 40% dos recursos do sistema.


Limites para restringir a utilização de recursos para um PDB específico:

Uma restrição de limites de uso de recursos de sistema para um PDB específico. Você pode especificar a utilização de limites para CPU e paralelismo. O limite padrão é 100%.
Restrição de limites de utilização de recursos; você pode criar uma diretiva de Resource Manager Plan usando  o parâmetro UTILIZATION_LIMIT para limitar CPU para cada PDB. Por exemplo, se você criar uma diretiva de plano com um UTILIZATION_LIMIT igual a 20% para um PDB específico, e com a prioridade mais baixa irá poder usar somente 20% do uso máximo de CPU no nível de CDB.
Para paralelismo, você pode sobrepor os valores padrão definidos pelo parâmetro UTILIZATION_LIMIT criando uma diretiva de plano que usa o parâmetro PARALLEL_SERVER_LIMIT. Um PDB não pode usar mais que o valor do parâmetro de inicialização PARALLEL_SERVERS_TARGET multiplicado pelo valor do parâmetro PARALLEL_SERVER_LIMIT no procedimento CREATE_CDB_PLAN_DIRECTIVE. Por exemplo, se o PARALLEL_SERVERS_TARGET está configurado para 100 e o PARALLEL_SERVER_LIMIT para um PDB está configurado para 20%, então o limite de utilização para um PDB é um paralelismo de 20 (100 X 0.20).

Criando um CDB ResourcePlanpara PDBs usando o  SQL*Plus:
No exemplo a seguir:

  • Para o PDBBI está alocado 1 share que representa 1/3 ou 33% da CPU e de paralelismo. Além disso, um UTILIZATION_LIMIT de 40% dos recursos e também 60% do limite está disponível para parallel servers.
  • Para o PDBHR está alocado 2 shares que representam 2/3 ou 66% da CPU e paralelismo. Além disso,  um UTILIZATION_LIMIT de 60% dos recursos e também 100% do limite disponível para parallel servers.

 

PDB Name

Shares

Utilization Limit

Parallel Server Limit

Plan Name

PDBBI

1

40

60

everyday_plan

PDBHR

2

60

100

everyday_plan


 

SQL> select con_id, dbid, NAME, OPEN_MODE fromv$pdbs;

    CON_ID       DBID NAME                           OPEN_MODE
---------- ---------- ------------------------------ ----------
2 4063385794 PDB$SEED                       READ ONLY
4 1911833382 PDBBI                          READ WRITE
5  889037338 PDBHR                          READ WRITE

SQL>


Connecte-se ao root container database e faça o seguinte:

  • Crie uma pending area; pending area é uma staging area onde os objetos de recursos são criados, definidos, antes de serem validados e ativados.
  • Crie um CDB resource plan; chamado “everyday_plan”.
  • Crie diretivas para os PDBs.
  • (Opcional) Atualize a diretiva padrão do PDB usando a procedure UPDATE_CDB_DEFAULT_DIRECTIVE.
  • (Opcional) Atualize a diretiva de tarefas automáticas padrão usando a procedure UPDATE_CDB_AUTOTASK_DIRECTIVE.
  • Valide a pending area.
  • Submeta a apending area.

 

Use a procedure CREATE_CDB_PLAN para criar o plano do CDB. Crie uma diretiva de resource plan CDB para os PDBs usando a procedure CREATE_CDB_PLAN_DIRECTIVE.

 

C:\Users\sesa258020>sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Sat Jul 20 16:10:30 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

 

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL>
SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
3     plan    => 'everyday_plan',
4     comment => 'CDB ResourcePlan for PDBBI $ PDBHR'
5     );
6  END;
7  /

PL/SQL procedure successfully completed.

SQL>

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
3  plan => 'everyday_plan',
4  pluggable_database => 'PDBBI',
5  shares => 1,
6  utilization_limit => 40,
7  parallel_server_limit => 60
8  );
9  END;
10  /

PL/SQL procedure successfully completed.

SQL>

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
3  plan => 'everyday_plan',
4  pluggable_database => 'PDBHR',
5  shares => 2,
6  utilization_limit => 60,
7  parallel_server_limit => 100
8  );
9  END;
10  /

PL/SQL procedure successfully completed.

SQL>

SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL>

Atualize o CDB Resource Plan para PDBs usando o SQL*Plus:
Use a procedure UPDATE_CDB_AUTOTASK_DIRECTIVE para atualizar o CDB auto task (tarefas automáticas).
Por exemplo:


SQL> EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> BEGIN
2    DBMS_RESOURCE_MANAGER.UPDATE_CDB_AUTOTASK_DIRECTIVE(
3      plan                  => 'everyday_plan',
4      new_shares            => 2,
5      new_utilization_limit => 20,
6      new_parallel_server_limit => 75);
7  END;
8  /

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL>


Você pode criar novas diretivas para novo PDB. Você também pode mudar os atributos da diretiva padrão para PDBs usando a procedure UPDATE_CDB_DEFAULT_DIRECTIVE da package DBMS_RESOURCE_MANAGER. O novo PDB irá ter 1 share de CPU. Também, um UTILIZATION_LIMIT de 40% dos recursos e 30% do limite disponível para parallel servers. 

SQL> EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

PL/SQL procedure successfullycompleted.

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.UPDATE_CDB_DEFAULT_DIRECTIVE(
3  plan => 'everyday_plan',
4  new_shares => 1,
5  new_utilization_limit => 40,
6  new_parallel_server_limit => 30
7  );
8  END;
9  /

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL>


Você pode deletar uma diretiva de resource plan de CDB para PDBs usando o procedimento DELETE_CDB_PLAN_DIRECTIVE
Exemplo:


BEGIN
DBMS_RESOURCE_MANAGER.DELETE_CDB_PLAN_DIRECTIVE(
plan               => 'everyday_plan',
pluggable_database => 'PDBBI');
END;

 

Visualizando o CDBResourcePlanpara PDBs usando o SQL*Plus:
Consulte a  DBA_CDB_RSRC_PLAN_DIRECTIVES para ver todas as diretivas definidas em todos os CDB resource plans no container raiz (root).

Nota: O ORA$DEFAULT_PDB_DIRECTIVE é a diretiva padrão para PDBs (Você pode ver shares configurados para 1, o UTILIZATION_LIMIT configurado para 40% e  PARALLEL_SERVER_LIMIT configurado para 30% como nós já modificamos usando a procedure UPDATE_CDB_DEFAULT_DIRECTIVE.)
Consulte  a DBA_CDB_RSRC_PLANS para ver todos os resource plans definidos no root container.



Habilitando um CDB Resource Plan para PDBs usando o SQL*Plus:

Você pode habilitar o Resource Manager para um CDB configurando RESOURCE_MANAGER_PLAN parameter no root. Este parâmetro especifica um CDB resource plan para ser ativado;

 

SQL> ALTER SYSTEM SET resource_manager_plan='everyday_plan';

System altered.

Ou usando o FORCE

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:everyday_plan';

 

Você pode desabilitar o CDB resource management;


SQL> ALTER SYSTEM SET resource_manager_plan=’’;

System altered.

 

Criando um PDB resource plan:

Nós já vimos mas previamente, um CDB resource plan determina a quantidade de recursos alocados para cada PDB em um ambiente multitenant. Um PDB resource plan determina quanto desses é alocado para um PDB específico que são alocados para um consumer group com o PDB. Um PDB resource plan é similar a um resource plan de um não-CDB, similar as versões anteriores do Oracle database.
O seguinte sumário são os passos requeridos para criar um PDB resource plan:

  • No SQL*Plus, garanta que o container atual é um PDB.
  • Crie uma pending area usando a procedure CREATE_PENDING_AREA.
  • Crie, modifique, ou delete consumer groups usando a procedure CREATE_CONSUMER_GROUP.
  • Mapeie as sessions para os consumer groups usando a procedure SET_CONSUMER_GROUP_MAPPING.
  • Crie um PDB resource plan usando a procedure CREATE_PLAN.
  • Crie uma diretiva de PDB resource plan usando a procedure CREATE_PLAN_DIRECTIVE.
  • Valide a pending area usando a procedure VALIDATE_PENDING_AREA.
  • Submeta a pending area usando a procedure SUBMIT_PENDING_AREA.



Exemplo: Para o PDBHR, de acordo com a imagem acima, iremos usar o CPU ratio allocation method; o resultado disso é que  a diretiva irá alocar recursos de CPU usando a distribuição 10:2:1. O grupo OLTP irá ter somente 2 ciclos de CPU para cada 10 que o REPORTING group receber. Iremos criar o seguinte plano e suas diretivas OLTP_PLAN e REPORTING_PLAN. Mas, antes criaremos os resource consumer groups. Consumer groups permitem classificar usuários finais em grupos lógicos baseados      nos requisitos de consumo de recursos, criamos OLTP e REPORTING consumer groups. Depois da criação dos consumer groups, nós podemos assinalar sessões de usuários finais usando a procedure SET_CONSUMER_GROUP_MAPPING (Obviamente nós precisaremos criar os resource groups, planos e suas diretivas antes de usar os seguintes comandos). Por exemplo, nós podemos assinalar o usuário Oracle “WISSEM” para o consumer group OLTP:


SQL> EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
3  (
4  ATTRIBUTE=>'ORACLE_USER',
5  VALUE=> 'WISSEM',
6  CONSUMER_GROUP =>'OLTP'
7  );
8  END;
9  /

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL>


Nós criamos resource groups plans e suas diretivas. Antes de fazer isso, nós precisamos mudar a sessão do container root para o PDBHR usando o comando “alter session set container=PDBHR”.

 

SQL>alter session set container=PDBHR;

Session altered.

SQL> EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('OLTP');
3  END;
4  /

PL/SQL procedure successfully completed.

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('REPORTING');
3  END;
4  /

PL/SQL procedure successfully completed.

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.CREATE_PLAN('OLTP_PLAN');
3  END;
4  /

PL/SQL procedure successfully completed.

SQL> BEGIN
2  DBMS_RESOURCE_MANAGER.CREATE_PLAN('REPORTING_PLAN');
3  END;
4  /

PL/SQL procedure successfully completed.

SQL> BEGIN
2    DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
3     (PLAN             => 'OLTP_PLAN',
4      GROUP_OR_SUBPLAN => 'SYS_GROUP',
5      CPU_P1          =>2);
6    DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
7     (PLAN             => 'REPORTING_PLAN',
8      GROUP_OR_SUBPLAN => 'SYS_GROUP',
9        CPU_P1          =>10);
10  END;
11  /

PL/SQL procedure successfully completed.

SQL>  BEGIN
2   DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
3      (PLAN            => 'OLTP_PLAN',
4      GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
5      CPU_P1          => 1);
6  END;
7  /

PL/SQL procedure successfully completed.

SQL>  BEGIN
2   DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
3      (PLAN            => 'REPORTING_PLAN',
4      GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
5      CPU_P1          => 1);
6  END;
7  /

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL>


Para maiores informações sobre plans e directive plans, por favor leia a documentação oficial da Oracle . No link abaixo:
http://docs.oracle.com/cd/E16655_01/server.121/e17636/dbrm.htm#i1108090


Sumário:

Neste artigo, nós aprendemos como Oracle 12c Resource Manager gerencia recursos:

  • EntrePDBs.
  • Com um único PDB.

Agora, com o novo Oracle 12c database, nós podemos usar o Oracle Resource Manager para gerenciar o consumo de recursos compartilhados entre todos os databases rodando no seu servidor, sob a condição de todos os databases estarem plugados a um CDB (PDBs).



Joel é um DBA expert com mais de 12 anos de experiência, especializado nas áreas de bases de dados com especial ênfase em soluções de alta disponibilidade (RAC, Dataguard, e outros). É um palestrante habitual em eventos de Oracle como: OTN LAD TOUR e outros. É o primeiro latino-americano a ser nomeado "OTN Expert " no ano de 2003 e é Oracle ACE Director. Durante estes anos, Joel trabalhou como consultor senior em um grande número de empresas e clientes em diversos países:Venezuela, Panama, Costa Rica, Dominican Rep., Haiti, Nicaragua, Guatemala, Colombia, Honduras, Ecuador, Mexico, India, Italy, Franceandothers. Joel isfrequent speaker atmanyconferencessuch as OTN LAD TOUR andothers. Joel wasthefirstLatin American tobenamed “OTN Expert” in year 2003, Oracle ACE since 2004 and Oracle ACE Directorsince 2012.

Wissem é um DBA Sr. com mais de 12 anos de experiência, especializado nas soluções RAC &Dataguard. Atualmente trabalha para “Schneider Electric / APC Global operations”. Wissem trabalhou também para várias empresas internacionais líderes em seus sectores como Bancos, Telecomunicações, Internet e Energia. Wissem foi o primer Oracle ACE na Espanha e é um OCP DBA. Siga Wissem no seu blog www.oracle-class.com ou no twitter @orawiss

Mufalani é um DBA Sr. com mais de 10 anos de experiência, começou com o Oracle 8i, mas teve a oportunidade de dar suporte a Oracle 7.3.4 em diante. É especialista em banco de dados Oracle com foco principal em Performance &Tuning e RAC. É palestrante em eventos de Oracle como: OTN LAD TOUR e outros. Atualmente trabalha como consultor diversas empresas no segmento de variados ramos como: Educação, Saúde, Tecnologia, Seguros e etc. Foi o terceiro Oracle ACE a ser nomeado no Brasil e é OCP DBA nas versões 10g e 11g. Siga Mufalani em seu blog www.mufalani.com.br/blog ou no twitter @mufalani