Database Resource Manager im praktischen Einsatz

Transkript

1 München, November 2012 Database Resource Manager im praktischen Einsatz Referenten: Thomas Riedel Payback GmbH Ulrike Schwinn Oracle B.V. & Co. KG

2 Inhalt A. Was und Wo ist PAYBACK B. Resource Manager? Warum bei PAYBACK? C. Konzeptionierung, Implementierung und Testing eines globalen Ressourcen-Plans D. GoLive-Planung & GoLive & Monitoring E. LIVE-Erfahrung F. Zukunftspläne G. Direktinfo Oracle H. Q&A

3 A. Was und Wo ist PAYBACK

4 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

5 PAYBACK ist auf Platz 1 in Deutschland, Polen und Indien Seit Juni2012 gibt es Payback auch in Mexiko Weitere Länder werden folgen

6 C. Warum bei PAYBACK und was ist der Resource Manager überhaupt?

7 Warum hat sich PAYBACK für den Einsatz des Resource Managers entschieden? Stand 2009 Exadata V1 Einsatz Resource Manager Resource Plan Wachstum Payback Schlechte Performance des bestehenden DWH Prozesse brechen immer häufiger aufgrund von Ressourcenmangel ab Schnellere Antwortzeiten Mehre Parallelität Database Services Analysten / User haben kontinuierlich mehr Ressourcen in Anspruch genommen Kontrolle über die verwendeten Parallelitätsgrade Sicherung der maximalen CPU- Auslastung Gleiche Problematik in DWHs anderer Projekte / Länder Problematik hat sich mittlerweile auch auf die OLTPs ausgedehnt Migration V1 Ressourcenengpass Resource Plan Globaler Resource Plan

8 Was ist der Resource Manager? Seit Oracle 8i, aktueller Release-Stand 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

9 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

10 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

11 D. Konzeptionierung, Implementierung und Testing eines globalen Ressourcen-Plans

12 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?

13 Konzeptionierung finaler Plan Aufteilung der LEVEL MAX Systemauslastung MAX-CPU MAX-PARALLEL

14 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

15 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;

16 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

17 E. GoLive-Planung & GoLive & Monitoring

18 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;

19 Monitoring OEM SQL UDM (User Defined Metric) LIVE-Monitoring 11g / 12c gv$rsrcmgrmetric_history gv$rsrc_consumer_group gv$rsrc_session_info Schwellwert-Messung und Alerting Monitoring- Zahlen aktuell nicht verfügbar gv$rsrcmgrmetric_history gv$rsrc_consumer_group gv$rsrc_session_info Keine historischen Werte

20 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>

21 F. LIVE-Erfahrung & Analyse

22 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

23 G. Zukunftspläne

24 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

25 H. Direktinfo Oracle

26 Resource Manager Ausblick Zukunftsinformationen aus erster Hand von:

27 payback.de Q/A Unterstützen Sie mit Punkten Hilfsprojekte, die Ihnen am Herzen liegen: PAYBACK GmbH Theresienhöhe München Thomas Riedel Databases