Database Resource Manager im praktischen Einsatz

München, November 2012
Database Resource Manager im praktischen
Einsatz
Referenten:
Thomas Riedel – Payback GmbH
Ulrike Schwinn – Oracle B.V. & Co. KG
Inhalt
A.
B.
C.
Was und Wo ist PAYBACK
D.
E.
F.
G.
H.
GoLive-Planung & GoLive & Monitoring
Resource Manager? Warum bei PAYBACK?
Konzeptionierung, Implementierung und Testing eines globalen
Ressourcen-Plans
LIVE-Erfahrung
Zukunftspläne
Direktinfo Oracle
Q&A
A.
Was und Wo ist PAYBACK
PAYBACK ist das größte europäische Bonusprogramm –
und gleichzeitig die größte Multichannel-Plattform in
Deutschland
8 von 10 Deutschen kennen die
Marke PAYBACK
Rund 15,2 Mrd. € Umsatz über
PAYBACK Karten bei den Partnern
(2011)
Drittwichtigste Karte in den
Geldbörsen der Deutschen (nach
EC- und Kreditkarte, TNS Emnid 2012)
In 2011 verschickte PAYBACK
1 Mrd. Printcoupons und 2,4 Mrd.
digitale Coupons an Kunden
In 2011 wurden Punkte im Wert von
rund 160 Mio. € gesammelt
97% aller gesammelten Punkte
werden wieder eingelöst
Die Karte wird am Tag durchschnittlich 1,5 Mio. mal an den
Kassen vorgezeigt
PAYBACK ist auf Platz 1 in Deutschland, Polen und Indien
Seit Juni2012 gibt es Payback auch in Mexiko
Weitere Länder werden folgen
C.
Warum bei PAYBACK und was ist der Resource
Manager überhaupt?
Warum hat sich PAYBACK für den Einsatz des Resource
Managers entschieden?
Stand 2009
○ Wachstum Payback
○ Schlechte
Performance des
bestehenden DWH
Exadata V1
○ Schnellere
Antwortzeiten
Migration V1
Resource Plan
○ Kontrolle über die
verwendeten
Parallelitätsgrade
○ Gleiche Problematik
in DWHs anderer
Projekte / Länder
○ Sicherung der
maximalen CPUAuslastung
○ Problematik hat sich
mittlerweile auch auf
die OLTPs
ausgedehnt
○ Mehre Parallelität
○ Database Services
○ Prozesse brechen
immer häufiger
aufgrund von
Ressourcenmangel
ab
Einsatz Resource
Manager
○ Analysten / User
haben kontinuierlich
mehr Ressourcen
in Anspruch genommen
Ressourcenengpass
Resource Plan
Globaler Resource
Plan
Was ist der Resource Manager?
○ Seit Oracle 8i, aktueller Release-Stand 11.2.0.3
○ Steht ohne zusätzliche Installation zur Verfügung
○ Muss aktiviert werden; Ausnahme: Scheduler Windows
○ Hauptaufgabe: Verteilung der Rechenleistung auf Benutzer/Applikationen
○ Unterstützt zusätzliche Funktionen wie “Instance Caging” und “Automated
Maintenance Tasks “ (Integration mit Datenbank Scheduler)
○ Nutzung über PL/SQL API oder über Enterprise Manager und
SQL*Developer
○ Enterprise Edition erforderlich
Bestandteile
○ Resource Consumer Group
Vordefinierte oder user definierte Gruppen
Definition mit Name und Switch Privileg
Manueller bzw. automatischer Wechsel zu anderer Gruppe ist möglich
○ Consumer Group Mapping
Manuell oder über spezielle Attribute (wie DB User, Service, Module Name ...)
Priorisierung möglich
○ Resource Plan und Resource Plan Directive
Vordefinierte oder user definierte Pläne
Dynamische Pläne: ein Plan zu einer Zeit !
Single und multi Level Pläne
Beispiele für Direktiven
○ CPU Methode: Single oder Multi Level
ab 11g: MAX_UTILIZATION_LIMIT Einstellung
○ Active Session Pool: Maximale Anzahl Sessions
○ Parallelität: Maximaler Parallelisierungsgrad
ab 11g Parallel Statement Queuing, Parallel Target Limit
○ Automatisches Consumer Group Switching
○ Execution Time-Grenze
○ Undo Pool-Begrenzung
○ Idle Time-Begrenzung
○ Resource Plan und Resource Plan Directive
D.
Konzeptionierung, Implementierung und Testing
eines globalen Ressourcen-Plans
Konzeptionierung
○ Aufbau der Consumer-Groups
Welche Betriebsprozesse gibt es und wie lassen sich diese untergliedern?
○ Aufbau der Subpläne
Wie kann ich meine Consumer-Groups am besten mit Ressourcen belegen?
○ Aufbau des "Masterplans"
Bleibt der "Masterplan" dauerhaft aktiv oder wird er z.B. Nachts deaktiviert?
Konzeptionierung – finaler Plan
○ Aufteilung der LEVEL
○ MAX Systemauslastung
○ MAX-CPU
○ MAX-PARALLEL
Implementierung
1
Erstellen der "Consumer Groups"
2
Erstellen der "Subplans" & "Directives"
3
Erstellen des "Masterplan"
4
Erstellen der "Consumer-Group-Mapping"
5
Anpassung der "Scheduler-Windows"
6
"Switch-Group"-Privileg an dedizierte User bzw. PUBLIC granten
Code Beispiel
BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_plan(plan => 'PB_RES_PLAN',
comment => 'Default Resourceplan for PB-Projects');
dbms_resource_manager.create_plan_directive(plan
=> 'PB_RES_PLAN',
group_or_subplan => 'SYS_GROUP',
comment
=> 'System Group',
MGMT_P1
=> 90,
max_utilization_limit => 95);
dbms_resource_manager.create_plan_directive(plan
=> 'PB_RES_PLAN',
group_or_subplan => 'HIGH_PRIO_PLAN',
comment
=> 'HighPrio Subplan',
MGMT_P2
=> 70,
max_utilization_limit => 75);
dbms_resource_manager.create_plan_directive(plan
=> 'PB_RES_PLAN',
group_or_subplan => 'ORA$AUTOTASK_SUB_PLAN',
comment
=> 'Subplan for Autotasks',
MGMT_P2
=> 25,
max_utilization_limit => 35);
dbms_resource_manager.create_plan_directive(plan
=> 'PB_RES_PLAN',
group_or_subplan => 'ORA$DIAGNOSTICS',
comment
=> 'Subplan for Autotasks',
MGMT_P2
=> 5,
max_utilization_limit => 15);
dbms_resource_manager.create_plan_directive(plan
=> 'PB_RES_PLAN',
group_or_subplan => 'LOW_PRIO_PLAN',
comment
=> 'LowPrio Subplan',
MGMT_P3
=> 30,
max_utilization_limit => 50);
dbms_resource_manager.create_plan_directive(plan
=> 'PB_RES_PLAN',
group_or_subplan => 'OTHER_GROUPS',
comment
=> 'Other Groups',
MGMT_P4
=> 10,
parallel_degree_limit_p1 => 0,
max_utilization_limit => 15);
dbms_resource_manager.validate_pending_area();
dbms_resource_manager.submit_pending_area();
END;
Testing
Testcase 1: Parallelität
Connect gegen diverse "Consumer-Groups" via DB-Service
ALTER SESSION FORCE PARALLEL QUERY PARALLEL 64
Starten eines SQL-Statements
Prüfen, ob die DOP (Degree Of Parallelism) dem konfigurierten entspricht
Testcase 2: CPU-Usage
Connect gegen diverse "Consumer-Groups" via DB-Service
Start einer "Sortierung-Procedure"
Prüfen, ob die zu beobachteten Werte den Konfigurierten entsprechen
E.
GoLive-Planung & GoLive & Monitoring
GoLive-Planung & GoLive
Planung
○ Abstimmung Zeitpunkt
○ Erläuterung der bevorstehenden Änderung
○ Fallback-Plan
GoLive
begin
dbms_resource_manager.switch_plan(plan_name => 'PB_RES_PLAN', sid => '*');
end;
Monitoring
OEM
LIVE-Monitoring
MonitoringZahlen
SQL
UDM (User Defined Metric)
11g / 12c
gv$rsrcmgrmetric_history
gv$rsrc_consumer_group
gv$rsrc_session_info
Schwellwert-Messung
und Alerting
aktuell nicht
verfügbar
gv$rsrcmgrmetric_history
gv$rsrc_consumer_group
gv$rsrc_session_info
Keine historischen Werte
Monitoring - Beispiele
Beispiel OEM (Top Activity):
Beispiel UDM:
select 'resource_bottleneck_detected',
count(*)
from gv$rsrcmgrmetric_history rmh,
(select distinct to_char(rh.begin_time, 'HH24:MI') time
from gv$rsrcmgrmetric_history rh,
(select max(begin_time) time
from gv$rsrcmgrmetric_history
group by inst_id) max_time
where to_char(rh.begin_time, 'HH24:MI') >=
to_char(max_time.time - 1 / 24 / 60 * 5, 'HH24:MI')
group by rh.begin_time
order by 1) act_time
where to_char(rmh.begin_time, 'HH24:MI') = act_time.time
and round(cpu_wait_time / 60000, 2) > <zahl>
F.
LIVE-Erfahrung & Analyse
LIVE-Erfahrung
Erfolg
○ Verhalten in Produktion wie in den
Testcases beobachtet (mittlerweile auf X2)
○ Businesskritische Prozesse laufen nun
ohne Probleme
○ Anwender geben positives Feedback
Positiver Nebeneffekt:
Unternehmen spart Geld und Zeit
G.
Zukunftspläne
Zukunftspläne
Rollout des Konzepts in andere Länder und das OLTP
Group-Mapping anhand von "Action und Module"
Automatisches Beenden von Langläufern
Limitieren der Sessionanzahl
In Verbindung mit dem Resource Manager die neue Funktionalität des
"Auto-DOP" nutzen
H.
Direktinfo Oracle
Resource Manager Ausblick
Zukunftsinformationen aus erster Hand von:
payback.de
Q/A
PAYBACK GmbH
Theresienhöhe 12
80339 München
Thomas Riedel
Databases
[email protected]
www.payback.de
[email protected]
Unterstützen Sie
mit Punkten Hilfsprojekte,
die Ihnen am Herzen liegen:
www.payback.de/spendenwelt