Database Resource Manager (DRM) lo strumento di Oracle per gestire in modo ottimale l'allocazione delle risorse computazionali del database server fra le varie sessioni. si tratta di uno strumento disponibile solo con la versione Enterprise Edition di Oracle.
DRM uno strumento molto interessante, potente e sofisticato. Nella guida che utilizzo per la mia preparazione alla certificazione Oracle database OCP viene premesso che la descrizione di tutti gli elementi di DRM pone il problema dell'uovo e della gallina. Questo per giustificare la difficolt nel dare un'ordine lineare e chiaro all'esposizione dei vari concetti e alla descrizione delle componenti di DRM. In questo articolo quindi seguir un ordine (discutibile) che si discosta da quello usato da tale guida e si avvicina di pi a quello del manuale oracle.
Resource Consumer Group
Come anticipato nell'introduzione DRM uno strumento di smistamento delle risorse computazionali fra sessioni Oracle (intese come utenti che lavorano sul database). Il primo elemento e concetto di DRM quello di Resource Consumer Group la cui definizione pi corretta quella di "sessioni utente raggruppate insieme in base a requisiti di risorse computazionali". Cio delle sessioni utente vengono raggruppate secondo esigenze di allocazione delle risorse computazionali del database server e esigenza di risorse computazionali da parte di queste sessioni. Una volta raggruppate insieme delle sessioni in Resource Group si potranno stabilire delle politiche di ripartizione delle risorse computazionali del database server tra i Resource Group, che quindi costituiscono una partizione delle sessioni utente sul database server. Definizione di Resource Group
Un Resource Group ha tre caratteristiche che sono i tre parametri della procedura da utilizzare per la sua creazione. Il package PL/SQK principale di gestione di DRM si chiama DBMS_RESOURCE_MANAGER. La procedura CREATE_RESOURCE_GROUP, i parametri sono:- CONSUMER_GROUP: il nome del Resource Group che chiave
- COMMENT: una descrizione
- CPU_MTH: che serve a specificare in che modo viene ripartita la CPU fra le sessioni del grouppo, il default ROUND_ROBIN, l'alternativa RUN_TO_COMPLETION
EXEC DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (CONSUMER_GROUP => 'sales', -
COMMENT => 'retail and wholesale sales');
Resource Plan
Le politiche di ripartizione delle risorse computazionali del database server tra i Resource Group sono contenute nella seconda componente di DRM: i Resource Plan che si possono definire come "dei contenitori di direttive che specificano come allocare le risorse tra i Resource Group".Il primo passo passo da fare per utilizzare DRM quindi definire i Resource Group; una volta fatto ci possibile definire i Resource Plan per indicare a DRM come ripartire le risorse. Esistono due tipologie principali di Resource plan: Simple e Complex.
Simple Resource Plan
Si tratta di piani relativamente semplici in cui l'unica risorsa smistabile la CPU la definizione di un Simple Resource Plan permette di indicare le percentuali secondo cui ripartire la CPU tra i Resource Group.
L'immagine, presa dal manuale Oracle descrive abbastanza chiaramente come lavora un Simple Resource Plan. Un Simple Resource Plan definibile per un massimo di 8 Resource Group.
Il package PL/SQK principale di gestione di DRM si chiama DBMS_RESOURCE_MANAGER. La procedura per la creazione di un Simple Resource Plan CREATE_SIMPLE_PLAN.
Ecco un esempio di creazione di un Simple Resource Plan che suddivide l'allocazione di CPU secondo la percentuale 80/20 tra i gruppi mygroup1 e mygroup2
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'simple_plan1',
CONSUMER_GROUP1 => 'mygroup1', GROUP1_CPU => 80,
CONSUMER_GROUP2 => 'mygroup2', GROUP2_CPU => 20);
END;
In realt DRM converte automaticamente il piano creato con la procedura CREATE_SIMPLE_PLAN in un piano a tre livelli secondo la tabella:
| Consumer Group | Level 1 | Level 2 | Level 3 |
|---|---|---|---|
| SYS_GROUP | 100% | - | - |
| mygroup1 | - | 80% | - |
| mygroup2 | - | 20% | - |
| OTHER_GROUPS | - | - | 100% |
In questa tabella compaiono due gruppi Resource Group predefiniti da Oracle:
- SYS_GROUP, un gruppo privilegiato a cui appartengono gli utenti SYS e SYSTEM e tutte le attivit interne del database
- OTHER_GROUP, un gruppo in cui vengono inserite tutte le sessioni utente non appartenenti ad alcun Resource Group regolato dal Resource Plan correntemente attivo.
- tutta la CPU disponibile viene lasciata ai processi di sistema Oracle, appartenenti in quanto tali a SYS_GROUP
- la CPU non utilizzata dalle sessioni in SYS_GROUP viene ripartita per l'80% alle sessioni del gruppo mygroup1 e per il 20% alle sessioni del gruppo mygroup2.
- La rimanente CPU, quindi quella non utilizzata da SYS_GROUP, da mygroup1 e mygroup2 viene lasciata alle sessioni non appertenenti a questi gruppi e quini inserite nel gruppo OTHER_GROUPS
Complex Resource Plan
DRM fornisce la possibilit di definire piani pi complessi, basati su una struttura a pi livelli (come quella a tre livelli implicitamente definita da un Simple Resource Plan) e con la possibilti di definire ulteriori regole oltre alla ripartizione della CPU in percentuali. Per fare ci si usano i Complex Resource Plan. In questo caso la definizione pi complessa, va fatta in pi passi: creazione del Resource Plan e creazione delle Resource Plan directives o direttive che sono la terza componente di DRM, dopo i Resource Group e i Resource Plan.Creazione di un Complex Resource Plan
La crezione di un Complex Resource Plan pi semplice della crezione di un Simple Resource Plan perch in questo caso nella creazione del piano non vi sono le politiche di ripartizione delle risorse che vengono definite successivamente tramite le Resource Plan Directive. La procedura per la creazione di un Complex Resource Plan CREAT_PLAN ed ha virtualmente sei parametri, di cui tre per accettano un unico valore:- PLAN, il nome del piano, chiave
- COMMENT, una descrizione
- CPU_MTH, EMPHASIS o RATIO. EMPHASIS indica che la ripartizione della CPU si specifica con le stesse regole dei Simple Resource Plan, cio in percentuali; RATIO invece permette di specificare la ripartizione della CPU in forma di rapporto, ad esempio 10:2:1 significa che ogni 10 cicli CPU assegnati al primo gruppo ne vengono assegnati 2 al secondo e ogni 2 del secondo 1 all terzo. Questo metodo si pu usare solo per piani a un livello (si capir meglio in seguito)
- ACTIVE_SESS_POOL_MTH, unico valore consentito e default ACTIVE_SESS_POOL_ABSOLUTE
- PARALLEL_DEGREE_LIMIT_MTH unico valore consentito e default PARALLEL_DEGREE_LIMIT_ABSOLUTE
- QUEUEING_MTH univo valore consentito e default FIFO_TIMEOUT
EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'great_bread', -
COMMENT => 'great plan');
Resource Plan Directive
Come detto e visto la creazione di un Complex Resource Plan di per s non contiene la definizione delle politiche di ripartizione delle risorse. Essendo possibile definire dei piani a pi livelli e avendo a disposizione altre risorse da gestire tali politiche vengono definite tramite le Resource Plan Directive che in sostanza mettono in relazione Resource Plan e Resource Group definendo come in quel piano vengono gestite le risorse per quel gruppo. La possibilit di definire piani a pi livelli si realizza con la possibilit di creare direttive che stabiliscono delle regole di assegnazione delle risorse di un piano verso un'altro piano.Le "risorse" regolate da una Resource Plan Directive sono:
- CPU (CPU_p1, ..., CPU_P8)
- numero di sessioni attive contemporaneamente (ACTIVE_SESS_POOL_P1)
- Livello di parallelismo (PARALLEL_DEGREE_LIMIT_P1)
- Queueing (?) (QUEUEING_P1)
- spazio di Undo (UNDO_POOL)
- tempo massimo di esecuzione stimato (MAX_EST_EXEC_TIME, SWITCH_ESTIMATE e SWITCH_TIME, SWITCH_TIME_IN_CALL)
- tempo massimo di esecuzione (SWITCH_TIME, SWITCH_TIME_IN_CALL)
- tempo massimo di inattivit (MAX_IDLE_TIME)
- tempo massimo di inattivit da "bloccante"
Le Resource Plan Directive si creano con la procedura CREATE_PLAN_DIRECTIVE (sempre nel package DBMS_RESOURCE_MANAGER) che ha i seguenti parametri:
- PLAN, il nome del piano a cui la direttiva appartiene
- GROUP_OR_SUBPLAN, il gruppo o il "sotto-piano" a cui la direttiva assegna le risorse, specificando un'altro piani si definisce un piano a pi livelli.
- COMMENT, una descrizione
- CPU_P1,..., CPU_P8, se il piano usa CPU_MTH=RATIO si pu utilizzare solo CPU_P1 per definire il "peso" da applicare al gruppo nell'assegnazione della CPU al gruppo; se il piano usa CPU_MTH=EMPHASIS ci vanno le percentuali di ripartizione, ovviamente la somma delle percentuali non deve superare 100.
- ACTIVE_SESS_POOL_P1, specifica in numero massimo di sessioni attive che il gruppo o sottopiano pu avere
- QUEUEING_P1, il numero di secondi prima che un job nella coda nelle sessioni inattive vada in time-out. Non mi del tutto chiaro cosa significhi
- PARALLEL_DEGREE_LIMIT_P1, il massimo livello di parallelismo per un'operazione
- SWITCH_GROUP, nome del gruppo in cui viene fatta passare una sessione secondo i criteri definiti dai parametri SWITCH_TIME O SWITCH_TIME_IN_CALL. In alternativa a un nome di gruppo possibile specificare una fra le costanti CANCEL_SQL, che provoca l'interruzione dell'operazione che ha sforato o KILL_SESSION che provoca il KILL della sessione che ha sforato il criterio.
- SWITCH_TIME, il numero di secondi che una sessione pu impiegare per eseguire un'operazione. Se tale intervallo viene superato la sessione viene spostata sul gruppo definito dal parametro SWITCH_GROUP.
- SWITCH_ESTIMATE, accetta i valori TRUE O FALSE (il default). Questo parametro condiziona il comportamento della direttiva nel caso sia stato specificato il parametro SWITCH_TIME, se SWITCH_ESTIMATE=TRUE oracle stima il tempo delle operazioni prima di eseguirle e le confronta con il valore specificato per SWITCH_TIME se sfora esegue l'azione definita tramite il parametro SWITCH_GROUP (cio sposta la sessione di gruppo, cancella l'operazione o uccide la sessione).
- MAX_EST_EXEC_TIME, permette di specificare un tempo massimo stimato in secondi di esecuzione per le operazioni, se il tempo stimato supera il valore impostato con questo parametro Oracle restituisce alla sessione l'errore ORA-07455. Il manuale precisa che se l'ottimizzatore non fornisce una stima questa direttiva non ha effetto.
- UNDO_POOL spazio massimo in KByte usato dal Resource Consumer Group
- MAX_IDLE_TIME, l'intervallo massimo, in secondi, che una sessione pu rimanere inattiva prima che venga uccisa
- MAX_IDLE_BLOCKER_TIME, intervallo massimo, in secondi, che una sessione bloccante pu rimanere attiva prima che venga uccisa.
- SWITCH_TIME_IN_CALL, molto simile al parametro SWITCH_TIME, specifica il numero massimo di secondi che un'operazione pu rimanere in esecuzione prima che venga spostata su un'altro gruppo, una terminata l'operazione per la sessione viene riportata nel suo gruppo. SWITCH_TIME e SWITCH_TIME_IN_CALL non possono essere defininiti sulla stessa direttiva contemporaneamente (per ovvi motivi).
Resource Plan e Subplan
come detto in precedenza una delle caratteristiche dei Complex Resource Plan quella di poter definire piani a pi livelli.
La figura ne mostra un'esempio. Questa struttura multilivello per vale solo per la ripartizione della CPU (in modalit EMPHASIS), quindi il disegno rappresenta un esempio completo. Infatti come indicato esplicitamente nella documentazione i seguenti parametri possono essere definiti solo in direttive che si applicano a Gruppi e non a risorse (cio il parametro GROUP_OR_SUBPLAN impostato al nome di un Resource Group):
- PARALLEL_DEGREE_LIMIT_P1
- ACTIVE_SESS_POOL_P1
- QUEUEING_P1
- SWITCH_GROUP
- SWITCH_TIME
- SWITCH_ESTIMATE
- MAX_EST_EXEC_TIME
- UNDO_POOL
- MAX_IDLE_TIME
- MAX_IDLE_BLOCKER_TIME
- SWITCH_TIME_IN_CALL
- non vi possono essere "loop"
- tutti gli oggetti (resource group e resource plan) riferiti dalle direttive devono esistere
- tutti i piani devono avere direttive che puntano a piani o gruppi
- tutte le percentuali specificate in un livello non devono fare somma superiore a 100
- un piano in uso non pu essere cancellato
- Un piano pu comprendere al massimo 32 gruppi
- Piani e gruppi non possono avere lo stesso nome
- deve esserci sempre una direttiva per il gruppo OTHER_GROUPS
Procedura di definizione di un Complex Resource Plan
La definizione di un piano di allocazione delle risorse complesso come visto avviene tramite pi a procedure PL/SQL, tale successione di chiamate deve avvenire tutta all'interno di una transazione; la transazione viene gestita tramite la cosiddetta Pending Area. Prima di iniziare le operazioni si crea una pending area:SQL> exec dbms_resource_manager.create_pending_area();
PL/SQL procedure successfully completed.
SQL> exec dbms_resource_manager.create_plan(plan=>'testplan1',comment=>'test');
Se la pending area non stata definita:
PL/SQL procedure successfully completed.
SQL> exec dbms_resource_manager.create_plan(plan=>'testplan1',comment=>'test');
BEGIN dbms_resource_manager.create_plan(plan=>'testplan1',comment=>'test'); END;
*
ERROR at line 1:
ORA-29371: pending area is not active
ORA-06512: at "SYS.DBMS_RMIN", line 63
ORA-06512: at "SYS.DBMS_RESOURCE_MANAGER", line 35
ORA-06512: at line 1Alla fine, o a passi intermedi possibile "validare" la pending area ovvero richiedere la verifica della correttezza piano definito, la procedura per fare ci : DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA().
Una volta finita la definizione di un piano e verifacata la sua correttezza possibile "confermarne" la creazione con l'equivalente di un commit della transazione di crezione del piano; tale conferma si d tramite la procedura DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA().
Ecco un esempio completo di definizione di un piano di risorse complesso:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'erp_plan',
COMMENT => 'Resource plan/method for ERP Database');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'oltp',
COMMENT => 'Resource consumer group/method for OLTP jobs');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'batch',
COMMENT => 'Resource consumer group/method for BATCH jobs');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan',
GROUP_OR_SUBPLAN => 'oltp', COMMENT => 'OLTP sessions', CPU_P1 => 80,
SWITCH_GROUP => 'batch', SWITCH_TIME => 3,SWITCH_ESTIMATE => TRUE,
UNDO_POOL => 200);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan',
GROUP_OR_SUBPLAN => 'batch', COMMENT => 'BATCH sessions', CPU_P2 => 100,
ACTIVE_SESS_POOL_P1 => 5, QUEUEING_P1 => 600,
MAX_EST_EXEC_TIME => 3600);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => 'mandatory', CPU_P3 => 100);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
Piano predefinito da Oracle
Oracle ha un piano predefinito chiamato SYSTEM_PLAN, definito secondo la seguente tabella:| Resource Consumer Group | CPU Resource Allocation | ||
|---|---|---|---|
| Level 1 | Level 2 | Level 3 | |
| SYS_GROUP | 100% | 0% | 0% |
| OTHER_GROUPS | 0% | 100% | 0% |
| LOW_GROUP | 0% | 0% | 100% |
Oltre ai gruppi SYS_GROUP e OTHER_GROUPS, gi menzionati vi un altro gruppo predefinito: LOW_GROUP, si tratta di un gruppo a bassa priorit per il cui passaggio (switch) concesso il privileggio a PUBLIC
Questi gruppi possono essere usati o no e possono essere modificati o eliminati.
Assegnazione delle Sessioni ad un Resource Group
Un'altro elemento importante del Database Resource Manager l'assegnazione delle sessioni utente a un gruppo di risorse. Oltre ai gi citati gruppi SYS_GROUP e OTHER_GROUPS vi un'altro gruppo predefinito, DEFAULT_CONSUMER_GROUP; questo il gruppo iniziale per tutti gli utenti/Sessioni che non sono stati esplicitamente assegnati ad altri gruppi.SET_CONSUMER_GROUP_MAPPING
E' possibile definire una mappatura tra sessioni/utenti e gruppi tramite la procedura del package DBMS_RESOURCE_MANAGER SET_CONSUMER_GROUP_MAPPING, questa procedura ha tre parametri: ATTRIBUTE, VALUE, CONSUMER_GROUP, dove i possibili valori per il parametro ATTRIBUTE sono le seguenti constanti:- ORACLE_USER
- SERVICE_NAME
- CLIENT_OS_USER
- CLIENT_PROGRAM
- CLIENT_MACHINE
- MODULE_NAME
- MODULE_NAME_ACTION
- SERVICE_MODULE
- SERVICE_MODULE_ACTION
BEGINSiccome pi regole possono andare in conflitto possibile ridefinire la priorit da dare ai vari valori usati per il parametro ATTRIBUTE, ci si fa con la procedura SET_CONSUMER_GROUP_MAPPING_PRI sempre contenuta nel package DBMS_RESOURCE_MANAGER, ad esempio:
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.ORACLE_USER, 'scott', 'dev_group');
END;
BEGIN
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI(
EXPLICIT => 1,
SERVICE_MODULE_ACTION => 2,
SERVICE_MODULE => 3,
MODULE_NAME_ACTION => 4,
MODULE_NAME => 5,
SERVICE_NAME => 6,
ORACLE_USER => 7,
CLIENT_PROGRAM => 8,
CLIENT_OS_USER => 9,
CLIENT_MACHINE => 10);
END;
SWITCH_CONSUMER_GROUP_FOR_SESS
Tramite la procedura SWITCH_CONSUMER_GROUP_FOR_SESS del package DBMS_RESOURCE_MANAGER possibile spostare esplicitamente una sessione su un gruppo, ad esempio:EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('17', '12345', -
'high_priorty');SWITCH_CONSUMER_GROUP_FOR_USER
Tramite la procedura SWITCH_CONSUMER_GROUP_FOR_USER del packagte DBMS_RESOURCE_MANAGER possibile spostare su un resource consumer group tutte le sessioni di un particolare utente, ad esempio:EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ('scott', -
'low_group'); DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP
Se un utente dotato dei necessari privilegi esso pu autonomamente spostare di gruppo le proprie sessioni tramite la procedura SWITCH_CURRENT_CONSUMER_GROUP del package DBMS_SESSION. La procedura ha i seguenti parametri:- NEW_CONSUMER_GROUP
- OLD_CONSUMER_GROUP, parametro di output
- INITIAL_GROUP_ON_ERROR, TRUE o FALSE, se TRUE , in caso di errore nello switch ritorna al gruppo iniziale, se FALSE in caso di errore nello switch restituisce errore.
SET serveroutput on
DECLARE
old_group varchar2(30);
BEGIN
DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('sales', old_group, FALSE);
DBMS_OUTPUT.PUT_LINE('OLD GROUP = ' || old_group);
END;
Gestione del privilegio di Switch
Per poter utilizzare la procedura DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP l'utente deve aver i privilegi, tali privilegi si concedono tramite le procedura GRANT_SWITCH_CONSUMER_GROUP del package DBMS_RESOURCE_MANAGER, questa procedura ha i seguenti parametri:- GRANTEE_NAME, l'utente a cui si concede il privilegio
- CONSUMER_GROUP, il gruppo su cui l'utente pu fare lo switch
- GRANT_OPTION, TRUE o FALSE
EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP ('scott', -
'bug_batch_group', TRUE);Analoga la procedure per revocare il privilegio: REVOKE_SWITCH_CONSUMER_GROUP che ha i paremetri:- REVOKEE_NAME, l'utente a cui si revoca il privilegio
- CONSUMER_GROUP
EXEC DBMS_RESOURCE_MANAGER_PRIVS.REVOKE_SWITCH_CONSUMER_GROUP ('scott', -
'bug_batch_group');Attivazione di Database Resource Manager
Database Resource Manager si attiva impostando il parametro di sistema RESOURCE_MANAGER_PLAN, ad esempio:ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';Per disattivarlo:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';Lo scheduler pu automaticamente cambiare il resource plan attivo a determinati orari (se cos stato configurato), per impedire che lo faccia si pu preporre al nome del piano il prefisso "FORCE:", ad esempio:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';In questo modo lo scheduler non pu cambiare il piano corrente (non mi chiaro)
Le stessa funzionalit viene offerta anche dalla procedura SWITCH_PLAN del package DBMS_RESOURCE_MANAGER:
DBMS_RESOURCE_MANAGER.SWITCH_PLAN(
plan_name IN VARCHAR2,
sid IN VARCHAR2 DEFAULT '*',
allow_scheduler_plan_switches IN BOOLEAN DEFAULT TRUE);
Viste si sistema
Viste per controllare la configurazione
- DBA_RSRC_CONSUMER_GROUPS
- DBA_RSRC_PLANS
- DBA_RSRC_PLAN_DIRECTIVES
- DBA_RSRC_GROUP_MAPPINGS
- DBA_RSRC_MAPPING_PRIORITY
- [DBA|USER]_RSRC_CONSUMER_GROUP_PRIVS
Viste per controllare il funzionamento di DRM
- V$RSRC_CONSUMER_GROUP: visualizza il quantitativo (cumulativo) di tempo CPU consumato da tutte le session per ogni gruppo
- V$RSRC_SESSION_INFO da informazioni sullo stato attuale della singola sessione
- V$RSRC_PLAN_HISTORY: statistiche cumulative di ogni resource plan
| Next > |
|---|
Feed Articoli
