In einer Oracle-Datenbank konkurrieren oft kurze Online-Transaktionen und lange Batch-Abfragen um CPU und parallele Ausführungsserver. Der Oracle Database Resource Manager (DBRM) kann Sessions nach ihrem Workload gruppieren und Ressourcen gezielt verteilen. Anders als ein SQL-Tuning greift er damit nicht in den Ausführungsplan einer einzelnen Abfrage ein, sondern steuert die Fairness zwischen Workloads.
Consumer Groups und Resource Plans
Eine Consumer Group fasst Sessions mit ähnlichen Anforderungen zusammen. Ein Resource Plan enthält Direktiven, die etwa CPU-Anteile, aktive Session-Pools oder Parallelitätsgrenzen für diese Gruppen festlegen. Für einen ersten CPU-Plan kann CREATE_SIMPLE_PLAN mehrere Gruppen anlegen:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(
SIMPLE_PLAN => 'APP_WORKLOAD_PLAN',
CONSUMER_GROUP1 => 'INTERACTIVE',
GROUP1_PERCENT => 70,
CONSUMER_GROUP2 => 'BATCH',
GROUP2_PERCENT => 30
);
END;
/Die Zahlen sind keine starren CPU-Deckel: Nicht genutzte Kapazität kann anderen Gruppen zugutekommen. Ein einfacher Plan steuert außerdem nur CPU. Wenn Sie beispielsweise Parallel-Server begrenzen, lange Abfragen herunterstufen oder aktive Sessions in eine Warteschlange stellen möchten, benötigen Sie einen erweiterten Plan.
Sessions verlässlich zuordnen
Die Regeln für das Session-Mapping entscheiden, ob der Plan überhaupt den gewünschten Effekt hat. Zuordnungen können sich etwa auf Datenbank-Service, Datenbankbenutzer oder Laufzeitattribute wie MODULE_NAME stützen. Bei einer Anwendung mit eigenem Batch-Service ist die Zuordnung über SERVICE_NAME meist gut nachvollziehbar. Nicht zugeordnete Sessions landen in OTHER_GROUPS; diese Gruppe muss im aktiven Plan ebenfalls berücksichtigt werden.
Wichtig für Connection Pools: Ein gemeinsam verwendeter Datenbank-Service unterscheidet nicht automatisch einzelne Endnutzer. Modul- oder Action-Namen müssen von der Anwendung korrekt gesetzt und beim Wiederverwenden der Verbindung bereinigt werden. Prüfen Sie außerdem die Priorität konkurrierender Mapping-Regeln, bevor Sie den Plan aktivieren.
Schrittweise einführen und messen
Für erweiterte Pläne wird die Konfiguration zunächst in einem Pending Area erstellt, validiert und erst danach übernommen. Testen Sie mit repräsentativer Last: Bleiben Antwortzeiten der interaktiven Gruppe stabil, während Batch-Arbeit noch ausreichend Fortschritt macht? Prüfen Sie die aktuelle Zuordnung und Ressourcenstatistiken über die Resource-Manager-Views, etwa V$RSRC_SESSION_INFO und V$RSRC_CONSUMER_GROUP. Ein Plan, der Batch-Prozesse dauerhaft aushungert, löst den Konflikt nicht – er verschiebt ihn nur.
Fazit
Resource Manager ist besonders hilfreich, wenn mehrere Workloads dieselbe Datenbank teilen und ihre Prioritäten klar sind. Beginnen Sie mit sauberem Session-Mapping, einer einfachen CPU-Verteilung und Messpunkten für beide Seiten. Erweiterte Limits sollten erst folgen, wenn konkrete Engpässe und gewünschtes Verhalten getestet sind.
Weiterführend: Oracles Anleitung zum Verwalten von Ressourcen mit Resource Manager.