Ressourcen managen mit Database Resource Manager
von Ulrike Schwinn, ORACLE Deutschland GmbH

Ressourcen in der Datenbank mit dem Database Resource Manager zu verwalten, ist schon seit der Version 8i mit der Enterprise Edition der Datenbank möglich. Zu Beginn war diese Funktion der Datenbank noch wenig bekannt und fand nur spärlichen Einsatz. Gründe dafür lagen sicherlich in der eingeschränkten Verwendbarkeit, die ausschliesslich über PL/SQL Packages und für dedizierte Datenbankuser-Sessions möglich war.

Spätestens mit der Oracle Database Version 10g und der Verfügbarkeit über die graphische Oberfläche des Enterprise Managers und die Erweiterung der Nutzung über Services, Module, Programme usw. sind diese Gründe aufgehoben. Dabei soll unabhängig von der Datenbanklast gewissen Sessions ein Minimum an Ressourcen garantiert werden. So können zum Beispiel CPU-Ressourcen für verschiedene Applikationen priorisiert werden, langlaufende Operationen unterbunden oder die Anzahl der Sessions begrenzt werden, um nur einige Beispiele zu nennen.

Die folgende Liste gibt einen guten Überblick über alle Ressourcen, die über den Database Resource Manager verwaltet werden können (Stand Datenbank Version 11g):

  • CPU-Nutzung
  • Parallelität
  • Session-Anzahl
  • Undo-Nutzung
  • Idle-Zeit
  • Execution Zeit
  • I/O Limit

    • Auch intern findet das Ressourcen-Management über den Database Resource Manager schon seit Oracle Database 10g seine Anwendung. Beispiele dafür sind die "Automated Maintenance Tasks" in 11g oder die Aufgabe "Manage Optimizer Statistics" in 10g. Der folgende Tipp gibt einen Überblick über die möglichen Funktionen und illustriert die Anwendung an einem Beispiel.

    Ein erster Einstieg in das Setup des Datenbase Resource Managers findet sich in der graphische Oberfläche des Enterprise Managers - je nach Datenbank-Release im Bereich "Server" oder "Administration". Der folgende Screenshot zeigt die 11g Variante im Enterprise Manager.


    Für eine größere Ansicht auf das Bild klicken.

    Um das Konzept zu verstehen, werden folgende 3 Begriffe verwendet, die im Ressourcemanagement-Zusammenhang als Standardbegriffe verwendet werden:

  • Resource Consumer Group
  • Resource Consumer Mapping
  • Resource Plan

    • Der erste Schritt beim Setup besteht aus der Erzeugung von Benutzergruppen nach unterschiedlichen Ressource-Anforderungsprofilen; sie werden als Resource Consumer Group bezeichnet. Darüberhinaus existieren von Oracle fest definierte Resource Consumer Groups, die zusätzlich verwendet werden sollten. Zum Beispiel ist die sogenannte SYS_GROUP eine Gruppe, die aus den Usern SYS und SYSTEM besteht; OTHER_GROUPS hingegen besteht aus allen anderen Usern, die keine Zuweisung zu einer Gruppe erhalten haben. Der folgende Screenshot zeigt das Anlegen einer neuen user definierten Resource Consumer Group mit dem sprechenden Namen GRUPPE_CPU_HIGH.


    Für eine größere Ansicht auf das Bild klicken.

    Ausser dem Namen und der Beschreibung muss man diejenigen Datenbankuser angeben, die dieser Gruppe angehören können - in unserem Beispiel der User SCOTT. Die Scheduling Policy bezieht sich dabei auf die Ressource CPU. Wir wählen die Standardeinstellung aus, die Verteilung nach ROUND-ROBIN-Methode; RUN-TO-COMPLETION wäre eine zweite Möglichkeit.

    Die Implementierung mit PL/SQL sieht in diesem Fall folgendermassen aussehen: 
    begin
  DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); 
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(consumer_group=>'GRUPPE_CPU_HIGH', comment=>'Kommentar');
  DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (attribute => dbms_resource_manager.oracle_user, -
                                                      value => 'SCOTT',consumer_group => 'GRUPPE_CPU_HIGH');
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
  DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(grantee_name => 'SCOTT', -
                                                   onsumer_group => 'GRUPPE_CPU_HIGH',grant_option => true);
end;

/

    Aus welchen Datenbankusern oder Sessions besteht nun eine Resource Consumer Group? Diese Information wird über das sogenannte Resource Consumer Group Mapping festgelegt. Hier werden Regeln bzw. Eigenschaften definiert, nach denen die einzelnen Sessions den Gruppen initial zugeordnet werden. Ändern sich die Eigenschaften einer Session oder tritt eine Überschreitung einzelner Ressourcegrenzen auf, kann dies zu einem automatischen Wechsel in eine andere Gruppe führen. Darüberhinaus kann ein Gruppenwechsel natürlich auch manuell angestossen werden. Die folgende Liste zeigt die wichtigsten Mapping-Regeln, die verwendet werden können:

  • Oracle User: Datenbank User
  • Service: TNS Servicename wie z.B. ORA11GR1 oder Oracle definierte wie SYS$USERS als Bezeichnung für die lokale Nutzung
  • MODULE und ACTION: Verwendung von DBMS_APPLICATION_INFO Package
  • Client OS User
  • Client Program wie SQL Developer
  • Client Machine


    • Damit es keine Überlagerungen der einzelnen Regeln gibt, können diese zusätzlich priorisiert werden (siehe Spalte Priority). Die folgende Abbildung zeigt ein Beispiel für das Mapping von Gruppen.


    Für eine größere Ansicht auf das Bild klicken.

    Im Beispiel wird Oracle User als eine Mapping Regel für die Resource Consumer Groups SYS_GROUP, GRUPPE_HIGH_CPU und GRUPPE_LOW_CPU verwendet. Dies bedeutet, dass zum Beispiel der User SCOTT initial der Gruppe GRUPPE_HIGH_CPU zugeordnet ist. Die Mapping Regel Service gilt für die Consumer Group GRUPPE_HIGH. Damit gehören alle User, die sich mit dem TNS-Service ORA11GR1 connected haben, automatisch der Gruppe GRUPPE_HIGH an.

    Nachdem wir dieses Setup durchgeführt haben, wird der Resource Plan definiert. Resource Pläne enthalten die Regeln (auch Direktiven genannt), nach denen die Ressourcen an die Resource Consumer Groups aufgeteilt werden. Resource Pläne sind dynamisch und können mit einem einfachen Befehl aktiviert bzw. deaktiviert werden (siehe folgendes Listing). Es gilt allerdings immer nur ein Plan zu einer Zeit. 
    ALTER SYSTEM SET resource_manager_plan='CPU_LAST';

    Resource Pläne können aus einem simplen Plan bestehend aus einer Ebene (auch Single Level genannt) oder komplexer aus mehreren Ebenen (auch Multi Level Plan genannt) und somit mehreren Subplänen bestehen. Es gibt allerdings auch vordefinierte Resource Pläne wie z.B. den Plan DEFAULT_MAINTENANCE_PLAN, der für die oben schon erwähnten Maintenance Aufgaben eingesetzt wird. Die Resource Pläne können nun aus den oben schon gelisteten Ressourcen zusammengesetzt werden.

    Zwei generelle Tipps: Machen Sie den Resource Plan nicht zu komplex, d.h. verwenden Sie nicht zu viele unterschiedliche Ressourcen und Ebenen. Sorgen Sie auch dafür, dass Sie als Administrator in der SYS_GROUP immer ausreichend Ressourcen zur Verfügung haben.

    In diesem Tipp wollen wir uns auf die Zuweisung von CPU-Ressourcen in einem Multi Level Plan konzentrieren. Folgender Multi Level Plan mit Namen CPU_LAST zeigt eine mögliche Plankonstellation an. Standardmässig wird die Nutzung von CPU-Ressourcen als erstes im Menüpunkt "General" (siehe Screenshot) abgefragt. Die Nutzung von Prozentzahlen zur CPU-Zuordnung pro Gruppe ist dabei die gängige Variante.

     Level 1Level 2Level 3
    SYS_GROUP80
    GRUPPE_CPU_HIGH 80
    GRUPPE_CPU_LOW 20
    OTHER_GROUPS 100

    Folgende Abbildung zeigt das Anlegen des Resource Plans CPU_LAST.


    Für eine größere Ansicht auf das Bild klicken.

    Was bedeutet dieser Plan? 80% garantierte CPU-Ressourcen erhalten die Administratoren in der SYS_GROUP. Die verbleibenden 20% bzw. alle ungenutzten CPU-Ressourcen werden an Level 2 weitergegeben. Hier erhält die GRUPPE_HIGH 80% (der 20%); 20% (der 20%) erhält GRUPPE_CPU_LOW. Sind ungenutzte CPU-Ressourcen übrig, werden diese an Level 3 und somit an alle anderen User in der OTHER_GROUPS zugewiesen.

    Wie können wir nun die Ressourcen-Nutzung monitoren? Data Dictionary Views, V$Views, der Enterprise Manager und natürlich auch AWR- und ASH-Berichte zeigen Informationen zu der Nutzung im Database Resource Manager. Im Folgenden sind einige interessante Views aufgelistet:

  • V$RSRC_PLAN: aktiver Plan
  • V$RSRC_PLAN_HISTORY: Plan Historie
  • V$RSRC_CONSUMER_GROUP: Ressource pro Gruppe
  • V$RSRC_CONS_GROUP_HISTORY: Historie der Statistiken
  • V$RSRC_SESSION_INFO: Statistiken pro Session
  • V$SESSION: Aktive Sessions und Consumer Group Zuordnung mit V$SESSION
  • DBA_RSRC_CONSUMER_GROUP_PRIVS: Zuordnung der User zu (initialen) Resource Consumer Groups

    • Folgende Abfrage gibt zum Beispiel einen Überblick über den Einsatz von Resource Plänen über die Zeit. 
    SQL> SELECT sequence# seq, name plan_name,
     to_char(start_time, 'DD-mon HH24:mi') start_time,
     to_char(end_time, 'dd-mon hh24:mi') end_time
     FROM v$rsrc_plan_history;

       SEQ PLAN_NAME                      START_TIME   END_TIME
---------- ------------------------------ ------------ ------------
         1                                31-mar 10:20 31-mar 22:00
         2 DEFAULT_MAINTENANCE_PLAN       31-mar 22:00 01-apr 02:00
         3                                01-apr 02:00 01-apr 04:30
         4 PLAN2                          01-apr 04:30 01-apr 04:45
         5                                01-apr 04:45 01-apr 17:47
         6                                01-apr 17:47 20-apr 13:31
         7 CPU_LAST                       20-apr 13:31
    Möchten Sie einen Überblick und eine Beschreibung aller vordefinierten Resource Consumer Groups, Resource Plans, Data Dictionary Views erhalten, werfen Sie einen Blick in den Oracle Database Administrator's Guide in Kapitel 25.

    Folgende Beispiele dokumentieren den Einsatz des Multi Level Plan in unserem Beispiel von oben. Nicht zu vergessen ist dabei, dass sich der Effekt des Database Resource Managers erst in Umgebungen unter hoher Systemlast bemerkbar macht. Um eine repräsentative Demonstration durchzuführen, muss eine Last (hohe CPU-Nachfrage) erzeugt werden, die eine CPU-Knappheit bewirkt. Daher sorgen wir mit einem einfachen CPU-intensiven SQL Skript dafür, dass die vorhandenen CPU-Ressourcen vollständig ausgelastet werden, um die Effekte monitoren zu können Möchte man zum Beispiel einen Gesamtüberblick über die verbrauchten CPU-Ressourcen erhalten, bietet sich dann folgende Abfragen an. 
    SQL> SELECT name, active_sessions,
     consumed_cpu_time, cpu_waits, cpu_wait_time
     FROM v$rsrc_consumer_group

NAME                 ACTIVE_SESSIONS CONSUMED_CPU_TIME  CPU_WAITS CPU_WAIT_TIME
-------------------- --------------- ----------------- ---------- -------------
GRUPPE_CPU_HIGH                    4           7728720        820        142587
GRUPPE_CPU_LOW                     1           3127331        131        125479
OTHER_GROUPS                       1         677625544        193       1074625
SYS_GROUP                          0          50258939          5           339
_ORACLE_BACKGROUND_G              21                 0          0             0
ROUP_
    Es ist deutlich zu sehen, dass die meisten CPU-Ressourcen von der Gruppe SYS_GROUP und weiterhin von der GRUPPE_CPU_HIGH verbraucht werden. Möchte man ein Session genaues Monitoren durchführen, sollte folgende Abfrage verwendet werden: 
    SQL> set pagesize 100
SQL> col username format a10
SQL> osuser format a7
SQL> col state format a15
SQL> col gruppe format a15
SQL> SELECT s.username username,s.osuser osuser, co.name gruppe,
     se.state, se.consumed_cpu_time cpu_time, se.cpu_wait_time
     FROM v$rsrc_session_info se, v$rsrc_consumer_group co , v$session s
     WHERE se.current_consumer_group_id = co.id and  s.sid=se.sid and se.state!='NOT MANAGED'

USERNAME   OSUSER  GRUPPE          STATE             CPU_TIME CPU_WAIT_TIME
---------- ------- --------------- --------------- ---------- -------------
SCOTT      oracle  GRUPPE_CPU_HIGH WAITING            3525784           270
SCOTT      oracle  GRUPPE_CPU_HIGH RUNNING                  6             0
SCOTT      oracle  GRUPPE_CPU_HIGH WAITING                 61          3228
SCOTT      oracle  GRUPPE_CPU_HIGH RUNNING             831799         77373
DWH_DATA   oracle  GRUPPE_CPU_LOW  WAITING FOR CPU    3106216        109117
SYSMAN     oracle  OTHER_GROUPS    WAITING FOR CPU     474559       1441907
SYSMAN     oracle  OTHER_GROUPS    WAITING FOR CPU    3448037        338454
SYSMAN     oracle  OTHER_GROUPS    WAITING            2613149        350709
SYSMAN     oracle  OTHER_GROUPS    WAITING FOR CPU       1242        250789
SYSMAN     oracle  OTHER_GROUPS    WAITING              84387        232923
SYSMAN     oracle  OTHER_GROUPS    WAITING            2131904        172459
SYSMAN     oracle  OTHER_GROUPS    WAITING FOR CPU    1767346       1294443
SYSMAN     oracle  OTHER_GROUPS    WAITING FOR CPU    3448351        473166
DBSNMP     oracle  OTHER_GROUPS    WAITING                 60             0
DBSNMP     oracle  OTHER_GROUPS    WAITING            1923994         85333
DBSNMP     oracle  OTHER_GROUPS    WAITING FOR CPU       5064       2402019
SYSMAN     oracle  OTHER_GROUPS    WAITING               1341        390361
SYSMAN     oracle  OTHER_GROUPS    WAITING FOR CPU      14382       1087001
SYSMAN     oracle  OTHER_GROUPS    WAITING            3906930        117776
SYSMAN     oracle  OTHER_GROUPS    WAITING                  0        613161
SYSMAN     oracle  OTHER_GROUPS    WAITING            2673029        118272
SYS        oracle  SYS_GROUP       WAITING                119             0
SYS        oracle  SYS_GROUP       WAITING                 38             0

23 rows selected.
    Auch im AWR Report ist die Verwendung des Resource Managers in unterschiedlichen Abschnitten sichtbar. Zum Beispiel weisen Events mit der Bezeichnung "resmgr:cpu quantum" im AWR Report auf den Einsatz des Database Resource Managers hin.



    Einen Gesamtüberblick als Graphik ist dann auch im Enterprise Manager im Bereich Server=> Resource Manager=>Statistics zu sehen. Die folgende Abildung zeigt eine mögliche Ansicht im Enterprise Manager.


    Für eine größere Ansicht auf das Bild klicken.

    Mehr zu diesem Thema bzw. zu weiteren Themen rund um die Datenbank lesen Sie in den nächsten Ausgaben ...

    Zurück zur Community-Seite