Archivo por días: 23 agosto, 2017

Uso del gestor de recursos en un CBD y PDB

Posted on por
Responder

Con la llegada de la 12c se han introducido mejoraras en el manejo de los gestores de recursos, de manera que el Resource Manager puede ser usado a dos niveles:
• CDB: Gestiona los recursos entre los distintos PDB
• PDB: Gestiona los recursos de manera tradicional

Gestión de los recursos en el CDB: Administrando recursos entre los PDBS

Algo que puede parecer evidente pero que debemos de decir, es que esta gestión se lleva a cabo en el CBD$ROOT, No se puede poner recursos al CDB$ROOT, igualmente no aparece en el computo de los shares
El Resource Manager lleva a cabo esta tarea mediante dos conceptos, shares y límites

  • Shares
    Los shares es la manera que tiene de repartir los recursos, a más shares, mas recursos dispone el PDB
    El porcentaje que asigna cada share se obtiene dividiendo el 100% de los recursos entre el numero de shares y multiplicándolo.

  • Limites
    EL otro parámetro que puedes indicar es el límite de utilización sobre el global, este límite puedes aplicarlo solamente a:

    • CPU
    • Cantidad de ejecuciones paralelas en el servidor

[table caption=»Planes de recursos» width=500]
Contenedor,shares,utilization limit, PARALLEL SERVER LIMIT
Default, 1 ,100%, 100%
PDB1 ,4 ,50% , 100%
PDB2 ,1 ,100% ,50%
[/table]

¿Qué significa un valor de 50% en PARALLEL SERVER LIMIT?

El PARALLEL SERVER LIMIT indica un porcentaje, este porcentaje es sobre el valor de inicialización de la base de datos de PARALLEL_SERVERS_TARGET, así pues, si tenemos un valor de 200 en PARALLEL_SERVER_TARGETS tendremos que el PARALLEL_SERVER_LIMITS será de 0.50*200=100 procesos paralelos.

No todos los PDBs tienen por que tener una política de asignación, aquellos que no la tengan irán a parar a el “Default allocation”.
Las directivas sobre los PDBs se han de crear en el momento de CREATE_CDB_PLAN_DIRECTIVE, y un PDB solamente puede ser afectado por una directiva.

¿Cuáles son los parámetros por defecto de la directiva “Default allocation”?

Si no especificas ninguna política específica para un PDB irá a la de por defecto con :
Shares=1
Utilization_limit=100
Parallel_srever_limit=100

Pasos para crear/modificar un plan

Para modificarlos el paquete DMNS_RESOURCE_MANAGER tiene su propia directiva llamada UPDATE_CDB_DEFAULT_DIRECTIVE

Pasos para la creacion

Al igual que en las BBDD clásicas hay que:
1. Crear el pending area
2. Crear el plan
3. Crear directivas (DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE)
4. Validar el pending area
5. Submit el pending area

Habilitar el plan

Al igual que en las versiones antiguas 

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=’myplan;

Se puede deshabilitar el plan quitando la variable de inicialización

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=’’;

PDB: Administracion de recursos dentro de los PDB

La administracion de recursos dentro del PDB se lleva a cabo igual que se llevaba dentro de las bases de datos tradicionales, teniendo en cuenta:

  • Ha de ser un single level resource plan, ya no puede ser multilevel
  • Tienes solamente 8 grupos de consumidores ( en el no-cdb son 32)
  • No puedes tener subplans dentro del plan ( en el no-dbs se podia)

Hay que tener en cuenta que hay dos parámetros que cambian de nombre:
MAX_UTILIZATION_LIMIT pasa a ser UTILIZATION_LIMIT
PARALLEL_TARGET_PERCENTAGE pasa a ser PARALLEL_SERVER_LIMIT

Es importante que, para poder crear una politica de gestor de recursos dentro de un PDB,la política del CDB para los recursos que quieres administrar debe de debe de satisfacer :
CPU

  • La directiva debe de tener definido el valor de SHARES para ese PDB
  • La directiva debe de tener definido el valor de UTILIZATION_LIMIT a menos del 100%

PARALLEL EXECUTION

  • Las dos de arriba de CPU
  • La directiva debe de tener definido el valor de PARALLEL_SERVER_LIMIT a menos del 100%

Notas finales del resource manager

Se ha introducido un Nuevo grupo de consumidores llamado LOG_ONLY que sirve para usarlo en como switch group en los casos en los que merely want to log the runaway query but don’t want to change its consumer group or perform any other action
Puedes ver lo definido en las vistas
V$RSRC_PLAN
DBA_CDB_RSRC_PLANS

Otra de las cosas que ofrece el RESOURCE MANAGER es que ha añadido nuevas columnas en la vista V$SQL_MONITOR

  • RM_LAST_ACTION The most recent action taken by the Resource Manager, such as cancelling a SQL execution or killing a session
  • RM_LAST_ACTION_REASON The reason for the most recent action taken by theResource Manager on this SQL operation, such as SWITCH_CPU_TIME orSWITCH_ELAPSED_TIME
  • RM_LAST_ACTION_TIME The time of the most recent action taken by the Resource Manager on this SQL operation
  • RM_CONSUMER_GROUP The current consumer group for this SQL operation