Lastprofile für mehrere Datenbanken auf einem Server - DOAG SIG Database 2011- OPITZ CONSULTING - Thorsten Bruhns

Lastprofile für mehrere Datenbanken
auf einem Server

Lastprofile für mehrere Datenbanken auf einem Server © OPITZ CONSULTING GmbH 2011 Seite 1

Lastprofile für mehrere
Datenbanken auf einem Server

Thorsten Bruhns
Seniorberater
OPITZ CONSULTING Bad Homburg GmbH

DOAG SIG Database, Essen, 24. Februar 2011


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


Agenda
1. Wofür Performanceauswertung?

2. Statspack als Datensammler

3. Was ist RRD?

4. Wie spielt das zusammen?

5. Zukunftsvisionen


1 Wofür Performanceauswertung?


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?


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


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

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
 …


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


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


2 Statspack als Datensammler


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


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.


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


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


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
 …

3 Was ist RRD?


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 …


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


4 Wie sieht das in der Praxis aus?


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


 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: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


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

 Beispielausgabe vom SQL-Statement
rrdtool update aim10/db_cpu_1.rrd 1266868804:4984823120080


 Ergebnisgrafik einer RRD


5 Zukunftsvisionen


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


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?


Fragen und Antworten


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 - DOAG SIG Database 2011- OPITZ CONSULTING - Thorsten Bruhns

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (12)

Mehr von OPITZ CONSULTING Deutschland

Mehr von OPITZ CONSULTING Deutschland (20)

Lastprofile für mehrere Datenbanken auf einem Server - DOAG SIG Database 2011- OPITZ CONSULTING - Thorsten Bruhns