(riferimendo: www.oracle.com)
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 GroupUn
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
Esempio di crezione di un Resource Group:
EXEC DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (CONSUMER_GROUP => 'sales', -
COMMENT => 'retail and wholesale sales');
Resource PlanLe
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:
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.
In questo caso la ripartizione della CPU fatta secondo il piano simple_plan1 dell'esempio funziona così:
- 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
Il vantaggio dei Simple Resource Plan è che sono abbastanza semplici da definire e gestire.
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 PlanLa
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
Esempio di creazione di un piano:
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"
In realtà alcune non sono proprio risorse nel senso più generale del termine.
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).
In un Complex
Resource Plan occorre sempre definire esplicitamente una direttiva per
il gruppo OTHER_GROUPS, altrimenti la procedura di attivazione del
piano fallisce.
Resource Plan e Subplancome 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
Altri limiti che si applicano alla definizione dei piani sono:
- 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 PlanLa
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');
PL/SQL procedure successfully completed.
Se la pending area non è stata definita:
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 1 Alla
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:
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
Ecco un esempio di definizione di una regola di assegnazione di sessioni a un gruppo:
BEGIN
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.ORACLE_USER, 'scott', 'dev_group');
END; Siccome
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:
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_SESSTramite
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_GROUPSe
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.
Esempio:
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 SwitchPer
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
Ad esempio:
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
Ad esempio:
EXEC DBMS_RESOURCE_MANAGER_PRIVS.REVOKE_SWITCH_CONSUMER_GROUP ('scott', -
'bug_batch_group');Attivazione di Database Resource ManagerDatabase 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
|
