Mobiliar Oracle Performance Warehouse Was war, ist oder wird kritisch? Jochen Maas Teamleiter IT Betrieb Data Management

Transkript

1 Mobiliar Oracle Performance Warehouse Was war, ist oder wird kritisch? ASH, AWR, APEX und Grid Control im Orchester für konsolidierte Performance- und Trend-Analysen über die gesamte Oracle-Landschaft Jochen Maas Teamleiter IT Betrieb Data Management Paolo Kreth Datenbank-Spezialist IT Betrieb Data Management

2 Die Mobiliar Die persönlichste Versicherung der Schweiz genossenschaftlich verankert, dem Kunden verpflichtet breite Palette moderner Versicherungslösungen, inklusive Lebensversicherungen nahe beim Kunden, dank rund 80 Generalagenturen und weiterer rund 60 Geschäftsstellen im ganzen Land 1,6 Millionen Versicherte Prämienvolumen 3,4 Mrd. CHF Mitarbeitende und 300 Lernende 11x in Folge 2

3 Ausgangslage Unsere Aufgabenstellung: 450 Oracle-Instanzen (70 Produktiv) auf eine neue Plattform migrieren AIX Red Hat Linux Virtualisiert (45 LPARs) Phys. Server (7 Blades) Big Endian Format Little Endian Format 3

4 Die Fragestellung Wie sollen die Datenbanken auf den Servern verteilt werden? Wie soll das Monitoring ausgebaut werden für ein proaktives Handeln bei Wachstum aussergewöhnlichen Situationen Für umfassende Auswertungen der Last eines Systems, analysieren wir verschiedene Kennzahlen: Last-Daten Performance-Daten Verarbeitungszyklen (Batch) 4

5 Kennzahlen für die Analyse Wie definieren wir den Verbrauch einer Oracle-Datenbank? CPU CPU used by Session Session Logical Reads: Bleibt konstant vor und nach der Migration! I/O Physical Reads (Anzahl und Geschwindigkeit) Pysical Writes (Anzahl und Geschwindigkeit) 5

6 Was wir schon in Grid Control haben 6

7 Die Aggregation Grid Control hat die Performance-Daten für die einzelnen Datenbanken, aber Grid Control kann diese nur für einzelne DBs anzeigen, d.h. Grid Control weiss, was DWH, RICO und MobiGIS einzeln verbrauchen, weiss aber nicht, was Sie zusammen verbrauchen. 7

8 Zweiter Lösungsansatz : Performance DWH Performance Daten werden täglich vom Grid Control Repository und von den DBs selber geladen und aggregiert (pro Stunde und Tag). AWR auf DBs DB1 DBA_HIST_SYSSTAT DBA_HIST_OSSTAT DBA_HIST_PGA_STAT Web Browser DB2 DBA_HIST_SGA_STAT DBA_HIST_SNAPSHOT DB3 DBA_HIST_ACTIVE_SESS_HISTORY DBA_HIST_SQLSTAT DB4 DBA_HIST_SQL_TEXT DBA_HIST_SYSTEM_EVENT Apex Repository DB5 Grid Control Repository 8

9 Summe Logical Reads verschiedener DBs Tagesebene Übers Jahresende circa 13 Mrd. Session Logical Reads /Tag 9

10 Summe Logical Reads verschiedener DBs Stundenebene Drill Down auf Stundenebene 1.1 Mrd. Session Logical Reads /Stunde 10

11 Ziel 1 erreicht Wir können jetzt mit realen Lastdaten die Gruppierung der Datenbanken planen und so die physischen Blades optimal auslasten. Wir können Trends aufzeigen Gibt es daraus allenfalls auch Möglichkeiten, die wir nach erfolgter Migration nutzen können? 11

12 Was wurde bei der Analyse entdeckt? Noch einmal die gleichen DBs über die Jahreswende und pro Tag summiert 12

13 Wir nehmen eine 8GB-Datenbank dazu Von 13 Mrd. auf 100 Mrd Session Logical Reads pro Tag 13

14 Ausreisser hier hat es angefangen Am 16/12/2012 fing es an: Applikatorischer Bug durch Patch behoben Patch eingespielt 14

15 Ziel 2 erreicht Wir können jetzt mit realen Lastdaten die Gruppierung der DBs planen und so die physischen Blades optimal auslasten. Wir können Trends aufzeigen. Wir haben mit den gleichen Mitteln Ausreisser entdeckt. Kann man das Erkennen ungewöhnlichen Verhaltens automatisieren? Was kann man noch aus den Daten herausholen? 15

16 Big Picture: OEM & APEX Oracle Enterprise Manager & Mobi Performance Forecaster Performance-Daten sind einzeln in jeder Datenbank enthalten (AWR-Daten). Sie werden täglich mehrmals erhoben und in der APEX-DB geladen. OEM & APEX lesen Performance-Daten für eine Analyse und für ein Reporting. AWR DB1 AWR DB2 Reporting & Alerting On Demand Analyse APEX DB OEM AWR DB3 RAMON AWR DB4 GRID DB 16

17 Technische Umsetzung Performance DWH Prozeduren greifen via Database-Link auf die Remote-DBs zu. Die AWR-Rohdaten werden in Tabellen gespeichert. AWR APEX DB 17

18 Konsumenten des Performance DWH Zugriffe erfolgen auf Views bzw. Tabellen von OEM & APEX Enterprise Manager Grid-Control APEX DB 18

19 Trendanalyse (1) Grid Control Report Monitoring eines Hosts in Grid Control Die letzten 30 Tage im Überblick Ressourcenverbrauch Stichtag 19

20 Trendanalyse (2) : Das «EKG» - Grid-Control Wie war die Last in den letzten 75 Tagen? Gab es Unregelmässigkeiten (phys. I/O, SLR, CPU)? AKV: Datenload (unangekündigt) INFRA: Optimierungspotential (implementiert) Business-Object: Standard-Verhalten?????? 20

21 Trendanalyse (3) SQL-Auswertungen - APEX Monitoring der SQLs Überblick in APEX 21

22 Report: Top 50 SQLs pro Tag Grid-Control Welche Abfragen verursachten den grössten Performance-Index? * Performance-Index = Σ Ausführungen pro SQL-ID x Ø Ausführungszeit ** * ** Report auf Tagesbasis verdichtet und gescheduled -Versand having sum(number_of_executions) * avg(avg_time_per_exec_sec) > 100 and sum(number_of_executions) > 2 22

23 Top 50 SQLs pro Tag inkl. History >= 3 Abfragen sind nicht unbedingt performancerelevant, aber: Wie sieht die Vergangenheit einer SQL-ID aus? Die Frequenz der Abfrage ist ein weiterer Indikator. 23

24 Beispiel: Qualität einer SQL-Abfrage Anzahl Session Logical Reads pro Tag DB Σ Logical R/ hh24 prico1 poppms1 pedwh1 palm2 pojade1 73'299'188'522 6'836'566'448 4'201'441'884 2'692'859'599 2'645'916'654 podyna1 pkgis3 ptarget1 PERFO possp1 poakv1 ptarget2 pdwh22 povut1 1'692'639'337 1'339'138' '312' '945'690 94'485'482 86'851'897 70'130'752 68'552'029 60'687'724 Anzahl Session Logical Reads pro Zeile DB Σ Logical R / Row pojade ptarget1 prico1 palm2 poppms1 possp1 pkgis3 poakv1 ptarget2 pdwh22 povut1 podyna1 pomkr1 pedwh

25 Qualität einer SQL-Abfrage Prico1 600 Gb Risk Management Pojade1 2 GB Java Konfigurations-Datenbank Prico1 ist 300 Mal grösser als Pjade1. Prico1 macht nur 35 mal mehr Logical Reads als Pojade1. Etwas stimmt mit der Qualität der Abfragen nicht. Pojade1 verbraucht 140 Session Logical Reads pro zurückgegebener Zeile. 25

26 Von 1500 auf 69 Logical Reads per Abfrage Id Operation Name E-Rows A-Rows Buffers SELECT STATEMENT SORT ORDER BY * 2 HASH JOIN RIGHT OUTER TABLE ACCESS FULL T_ENVIRONMENT * 4 HASH JOIN RIGHT OUTER TABLE ACCESS FULL T_PROJECT * 6 TABLE ACCESS FULL T_DEPLOYMENT Id Operation Name E-Rows A-Rows Buffers SELECT STATEMENT SORT ORDER BY * 2 HASH JOIN RIGHT OUTER TABLE ACCESS FULL T_ENVIRONMENT * 4 HASH JOIN RIGHT OUTER TABLE ACCESS FULL T_PROJECT INLIST ITERATOR 0 6 * 7 TABLE ACCESS BY INDEX ROWID T_DEPLOYMENT * 8 INDEX RANGE SCAN T_DEPLOYMENT_IDX

27 Im EKG ersichtlich Änderung: Session Logial Reads gesunken 27

28 Ziel 3 erreicht Wir können jetzt mit realen Lastdaten die Gruppierung der DBs planen und so die physischen Blades optimal auslasten. Wir können Trends aufzeigen. Wir haben mit den gleichen Mitteln Ausreisser entdeckt. Aussergewöhnliche Situation werden automatisch entdeckt Können wir mit den Daten auch vergleichen wie sich die Datenbanken vor und nach der Migration verhalten? 28

29 Umfangreiche Analyse anhand eines Beispiels Neuer Tuning Ansatz Migration auf neue Plattform 29

30 Zeit-Vergleich vor/nach Migration Was ist schlechter? 30

31 Wir packen die SQLs an Drill Down in Apex Migration auf neue Plattform 31

32 Was verursacht die Verschlechterung? Migration auf neue Plattform 32

33 Was ist 8d45v0ykdn4fw? Refresh von Materialized View Tuning des Refreshs Truncate + Insert Append ATOMIC_REFRESH => FALSE 33

34 Wiederholung auf weiteren SQLs Resultat des Tunings Migration auf neue Plattform Tuning-Massnahmen 34

35 Ziel 4 erreicht Wir können jetzt mit realen Lastdaten die Gruppierung der DBs planen und so die physischen Blades optimal auslasten. Wir können Trends aufzeigen. Wir haben mit den gleichen Mitteln Ausreisser entdeckt. Aussergewöhnliche Situation werden automatisch entdeckt Wir können Datenbanken vor und nach der Migration vergleichen Können wir, jetzt wo die neue Plattform im Betrieb ist, auch auf Betriebssystem Ebene sehen wo wir auf Engpässe zusteuern und welche Datenbank der Verursacher ist? 35

36 Big Picture: OEM & APEX OS Datentensicht Oracle Enterprise Manager & Mobi Performance Forecaster Auf jedem Server werden Performance Daten mittels Nmon erhoben. Sie werden täglich in das Performance Warehouse geladen. OEM & APEX lesen OS Performance-Daten für eine Analyse und für ein Reporting. NMON Blade1 Reporting & Alerting On Demand Analyse NMON Blade2 APEX DB OEM RAMON NMON Blade3 GRID DB 36

37 Beispiel CPU Metrik User, Idle, Sys, Wait 37

38 Beispiel CPU Metrik APEX Sicht OS CPU 38

39 Beispiel CPU Metrik APEX Absprung auf Sicht Datenbank 1) Wir selektieren alle Datenbanken auf dem Server 2) Wir schauen von 10:00 bis 16:00 Uhr. Metrik CPU_USED_BY_THIS_SESSION 3) Grafik Anzeigen und. 39

40 Beispiel CPU Metrik APEX Sicht OS Datenbank Es ist die Dedwh1 40

41 Beispiel CPU Metrik : ASH Sicht Stimmt mit AWR Daten überein 41

42 Beispiel CPU Metrik : Ab jetzt verfeinern im Grid Control 42

43 Ziel 5 erreicht Wir können jetzt mit realen Lastdaten die Gruppierung der DBs planen und so die physischen Blades optimal auslasten. Wir können Trends aufzeigen. Wir haben mit den gleichen Mitteln Ausreisser entdeckt. Aussergewöhnliche Situation werden automatisch entdeckt Wir können Datenbanken vor und nach der Migration vergleichen Engpässe auf Betriebssystemebe werden frühzeitig erkannt Mit 12c ( ) gibt es neu das AWR Warehouse. Könnte diese Feature unsere Bedürfnisse ebenfalls abdecken, oder kann es sogar noch mehr? 43

44 Vergleich MoPW AWR Warehouse Mobiliar Performance Warehouse AWR Warehouse 12c Daten werden nur von einigen gezielten Views gesammelt Weniger Speicherbedarf für den MoPW 10 Tabellen 2 Gb/Jahr pro DB Anpassung bei Erweiterungen notwendig Man kann alle Datenbanken der Landschaft oder pro Server vergleichen Vergleich besteht auf ASH und System Statistiken OS Performance Metriken werden gesammelt Analysen können bis zu einem gewissen Punkt im Warehouse gefahren werden, danach Absprung auf Grid Control/Target DB notwendig Es wird das ganze AWR gesammelt 130 Tabellen, 14Gb/Jahr pro DB Mehr Flexibilität, keine Anpassungen bei Erweiterungen notwendig Vergleich nur auf 2 Datenbanken möglich via AWR in Cloud Control Vergleich besteht aus AWR Reports Keine OS Performance Metriken Kein Absprung auf Grid Control/Target DB notwendig 44

45 Zusammenfassung Auslöser für die Zusammenstellung unseres Orchesters war dass Grid-Control nur auf Datenbank-/Hostebene Performance-Daten anzeigen kann. Durch die aggregierten Daten konnten wir eine optimale Verteilung der DBs vornehmen. Der nachhaltige Nutzen auf der neuen Plattform Ausreisser werden zeitnah und automatisch entdeckt SQLs mit grossem Performance-Index Langsame I/O-Operationen Überdurchschnittlicher CPU-/IO-Konsum Vergleich vor und nach der Migration Trendanalysen sind jederzeit verfügbar Vergleich mit OS Performance Metriken Erhöhte Handlungsfähigkeit Effiziente Nutzung der Hardware 45