Weitere ähnliche Inhalte Mehr von OPITZ CONSULTING Deutschland (20) Lastprofile für mehrere Datenbanken auf einem Server - DOAG SIG Database 2011- OPITZ CONSULTING - Thorsten Bruhns1. Lastprofile für mehrere Datenbanken
auf einem Server
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 1
2. Lastprofile für mehrere
Datenbanken auf einem Server
Thorsten Bruhns
Seniorberater
OPITZ CONSULTING Bad Homburg GmbH
DOAG SIG Database, Essen, 24. Februar 2011
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 2
3. OPITZ CONSULTING – wer sind wir?
Märkte Kunden Leistungs- Fakten
angebot
Java Branchen- IT-Strategie Gründung 1990
SOA übergreifend Beratung 400 Mitarbeiter
ORACLE Über 600 Implementierung 8 Standorte in
BI/DWH Kunden Betrieb D/PL/CH
Outtasking Training
Industrie / Versorger / Handel / Logistik /
Telekommunikation Dienstleistungen
29% 29%
42%
Öffentliche Auftraggeber /
Banken & Versicherungen /
Vereine & Verbände
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 3
4. Agenda
1. Wofür Performanceauswertung?
2. Statspack als Datensammler
3. Was ist RRD?
4. Wie spielt das zusammen?
5. Zukunftsvisionen
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 4
5. 1 Wofür Performanceauswertung?
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 5
6. Wofür Performanceauswertung?
Warum hat der Server keine freien Resourcen mehr?
Sizing der Hardware
CPU
Memory
Festplattenspeicher
Migration auf neue Hardware
Ist eine ausreichende Zukunftssicherheit gewährleistet?
Kann die geplante Hardware über den notwendigen Zeitraum genutzt
werden?
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 6
7. Wofür Performanceauswertung?
Lastprofil eines Servers ermitteln
Wer verursacht wann Last?
Kostenmodell nach Last
Wer verursacht wie viel Last?
Lastabhängige Kostenaufteilung
Z.B. Eine DB verursacht 75% der Last, zahlt aber nur 10% der Kosten
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 7
8. Methoden zur Datensammlung
Tools für die OS-Ebene
top
sar
iostat
mpstat
…
Tools sind nicht auf jedem OS verfügbar
insb. Unix Windows problematisch
Tools für Oracle Datenbanken
AWR (lizenzpflichtig!)
Statspack
Extended SQL-Trace
utlbstat/utlestat
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 8
9. Probleme bei der Auswertung
Vergleichbarkeit der Daten
Z. B. Formatierung sar/iostat OS abhängig
Windows Unix
Auswertbarkeit
SQL-Trace ist extrem aufwendig
Diverse Ad-hoc-Tools (z. B. top) bieten nur eine Momentaufnahme
Formatierung sehr unterschiedlich
Performanceauswertung von RAC-Clustern mit mehr als eine Datenbank
…
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 9
10. Gibt es eine Lösung?
Bedingungen
plattformunabhängig
Einheitliche Tools für alle Betriebssysteme
clusterfähig
Lastprofil von Datenbanken auf mehreren Clusterknoten muß erstellbar sein
Keine Lasterzeugung während der Auswertung
Möglichst Langzeitbetrachtung über Monate
Visualisierung der Ergebnisse
‚managementtaugliche‘ Darstellung
Geringer Implementierungsaufwand
Möglichst kostenlose Tools
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 10
11. Gibt es eine Lösung?
Konzept
Datensammler pro Instanz
Export der Daten in Textform
Import der Daten auf externen Server
Auswertung der Performancedaten auf externen Server
Vorteil
Auswertung der Daten ohne Belastung des Quellsystems
Langzeitarchivierung auf dem externen System
Datenvolumen in den Datenbanken wird gering gehalten
Die Datensammlung in der Datenbank kann für jede Art der
Performanceanalyse einer Datenbank genutzt werden
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 11
12. 2 Statspack als Datensammler
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 12
13. Warum Statspack?
Vorteile
Kostenloses Tools zur Sammlung von Performancedaten
AWR ist hier nicht geeignet, da erst ab 10g verfügbar und lizenzpflichtig
=> keine allgemeine Alternative!
Liefert Performancedaten der Datenbank und vom Server
Für Oracle 8.1.6 – 11.2 verfügbar
Wird mit hoher Sicherheit erhalten bleiben, da für Supportzwecke notwendig
Leicht installierbar
Gut für detaillierte Performanceanalysen geeignet
Möglicherweise schon vorhanden
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 13
14. Wieso Statspack?
Nachteile
Platzbedarf, da Daten relational abgelegt werden
Kann durch kurze Purge-Zeit und entsprechendem snap_level ausgeglichen
werden.
Viel gesammelt und nur wenig tatsächlich genutzt
Kann optional aber für Detailanalysen sehr hilfreich sein.
Größerer Overhead im Vergleich zum AWR
Statspack wird traditionell aus v$-Views gebildet. AWR ist Bestandteil vom Kernel.
Keine Visualisierung
Von Oracle nur spreport und sprepsql verfügbar.
Alles andere muß man selbst bauen.
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 14
15. Wieso export in Textform?
Vorteile
Einfache SQLs zum Export der Daten
Individuell erweiterbar
Einfacher Transfer der Ergebnisdaten
Keine permanente Verbindung zwischen Datensammler und Auswerter
benötigt
Sammlung erfolgt automatisch beim Kunden
Auswertung und Erstellung von Reports Offline im Office möglich
Einfache Archivierung mit hoher Dichte möglich
Textfiles können für später noch aufgehoben werden
Aufgrund der RRD eigentlich nicht erforderlich
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 15
16. Wieso export in Textform?
Nachteile
Overhead
direktes Lesen per SQL mit anschließendem Import in RRD wäre möglich
Umweg über die Files würde entfallen
Formatänderungen an 2 Stellen notwendig
Statements zum Erzeugen der Textfiles
Parser, falls keine direkten RRD-Aufrufe generiert werden
Zusätzlicher Platzbedarf für ASCII-Files
Umweg „Select in Textfile“ und dann erst in RRD
Ist vernachlässigbar, da Files nach Import in RRD gelöscht werden können
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 16
17. Was wird denn exportiert?
Performancedaten pro Snapshot
Snap-Interval bestimmt die kleinste Granularität
Stündliches Intervall für Langzeitbetrachtung ausreichend
Stat$osstat
Relative Betrachtung Auslastung des Servers durch Instanz
stats$sys_time_model
Betrachtung DB Time / CPU Time
Zahlreiche Wait-Events
Insbesonder I/O-Events mit Zeitbedarf
Betrachtung der I/O-Last der entsprechenden Instanz
Elapsed SQL Time / Parse Time
…
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 17
18. 3 Was ist RRD?
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 18
19. Was ist RRD
RRD steht für ‚Round-Robin-Database‘
Autor: Tobias Oetiker
http://oss.oetiker.ch/rrdtool
Lizenz: Gnu Public License
File-basierte Datenbank
Automatische Aggregation von Daten über die Zeit
Zahlreiche Berechnungsmethoden
Automatische 0-Punkt-Erkennung bei der Datenpflege
Für V$Views die nach einem Neustart der DB wieder mit 0 beginnen
Tools für Pflege der Datenbanken
rrdtool
rrdupdate, rrdump …
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 19
20. Was ist RRD
Umfangreiches Reporting
Erstellung von Graphen aus mehreren Datenbanken
u. a. Linien-, Balkendiagramme einzeln oder aggregiert möglich
Auf sehr vielen Plattformen verfügbar
Unter Linux überall verfügbar
Unter Linux32/64 unterschiedliche Datenformate
Zahlreiche GUI-Frontends verfügbar
ddraw erfolgreich eingesetzt
http://web.taranis.org/drraw/
CGI-Skripte, die direkt rrdgraph zur Generierung aufrufen
Apache WebServer mit CGI benötigt
Direkter Zugriff auf die RRDs ist erforderlich
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 20
21. 4 Wie sieht das in der Praxis aus?
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 21
22. Wie sieht das in der Praxis aus?
Sammlung der Daten mittels Statspack
Automatisch mittels dbms_job
Purge alter Daten mittels dbms_job
Täglicher Export der Performance-Daten
Spoolfile mittels SQLPlus über cronjob gestartet
Import der Daten in die RRD
Ausführen der gespoolten Skripte
Erstellung von Ergebnisgrafiken aus der RRD
Individuelle Erstellung von Reports mittels ddraw über Web-Browser
Optional vorgefertige Berichte abrufbar
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 22
23. Wie sieht das in der Praxis aus?
RRDs erzeugen (nur einmalig erforderlich!)
rrdtool create datenbankname
--start "now -1month"
--step 1800
DS:cnt:DERIVE:10800:0:U
RRA:AVERAGE:0.5:1:1440
RRA:AVERAGE:0.5:30:336
RRA:AVERAGE:0.5:120:372
RRA:AVERAGE:0.5:720:730
RRA:MIN:0.5:1:1440
RRA:MIN:0.5:30:336
RRA:MIN:0.5:120:372
RRA:MIN:0.5:720:730
RRA:MAX:0.5:1:1440
RRA:MAX:0.5:30:336
RRA:MAX:0.5:120:372
RRA:MAX:0.5:720:730
RRA:LAST:0.5:1:1440
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 23
24. Wie sieht das in der Praxis aus?
Beispiel SQL für stat$sys_time_model
select
lower(vd.name)||':'||lower(s.sname)||'_'||s.instance_number||'.rr
d:‚ || s.unixtime ||':'||s.wert
from v$database vd
join (select ss.snap_id ,ss.snap_time
,round(( cast((ss.snap_time) as date) - to_date('01-JAN-
1970','DD-MON-YYYY')) * (86400)) unixtime
…
from stats$sys_time_model stm
join stats$time_model_statname se on stm.stat_id = se.stat_id
join stats$snapshot ss on ss.snap_id = stm.snap_id
where ( stat_name in( 'DB time‚ 'background cpu time‚
…
)
))s on 1=1
order by s.instance_number,s.sname, s.unixtime
;
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 24
25. Wie sieht das in der Praxis aus?
Beispielausgabe vom SQL-Statement
rrdtool update aim10/db_cpu_1.rrd 1266868804:4984823120080
rrdtool update aim10/db_cpu_1.rrd 1266872405:4986749110063
rrdtool update aim10/db_cpu_1.rrd 1266876000:4988710608834
rrdtool update aim10/db_cpu_1.rrd 1266879602:4991040643966
rrdtool update aim10/db_cpu_1.rrd 1266883202:4992951567828
rrdtool update aim10/db_cpu_1.rrd 1266886803:4994868748816
rrdtool update aim10/db_cpu_1.rrd 1266890404:4996766485685
rrdtool update aim10/db_cpu_1.rrd 1266894005:4998676703838
rrdtool update aim10/db_cpu_1.rrd 1266897600:5000601974938
rrdtool update aim10/db_cpu_1.rrd 1266901201:5002558786266
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 25
26. Wie sieht das in der Praxis aus?
Ergebnisgrafik einer RRD
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 26
27. Wie sieht das in der Praxis aus?
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 27
28. Wie sieht das in der Praxis aus?
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 28
29. 5 Zukunftsvisionen
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 29
30. Zukunftsvisionen
Bisher in zwei Projekten erfolgreich eingesetzt
1. Projekt: RAC-Cluster zwei Knoten sechs Datenbanken
(Quelle Statspack-Daten)
Darstellung der Datenbanken-Last im Cluster
2. Projekt: Visualisierung von I/O-Events (Quelle AWR-Daten)
Klärung, ob mehrere Datenbanken zeitgleich Performanceprobleme im SAN auslösen, da SAN-
Monitoringtool nicht vorhanden war
AWR kann nur Anzahl und Zeit für Events liefern, nicht durchschnittliche Zeit pro Event
Überarbeitung des Systems
SQLs und Skripte noch im Betastadium
Es werden Projekte für weitere Ausarbeitung gesucht
Langfristige Vision
Framework zur Performancebeobachtung mit Langzeitspeicherung
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 30
31. Zukunftsvisionen
Bessere Visualisierung
Ggf. ddraw durch Skripte ablösen
Falls vorhanden: Einbindung in Cacti oder ganglia
Weitere Ideen?
Immer her damit!
Live-Demo von ddraw erwünscht?
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 31
32. Fragen und Antworten
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 32
33. Kontakt
Thorsten Bruhns
Seniorberater
OPITZ CONSULTING Bad Homburg GmbH
Kaiser-Friedrich-Promenade 91
51647 Bad Homburg
Tel. +49 (6172) 6626 0
thorsten.bruhns@opitz-consulting.com
Besuchen Sie uns im Internet:
www.opitz-consulting.com
Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 33