=Paper=
{{Paper
|id=Vol-1313/paper_05
|storemode=property
|title=Proaktive modellbasierte Performance-Analyse und -Vorhersage von Datenbankanwendungen
|pdfUrl=https://ceur-ws.org/Vol-1313/paper_5.pdf
|volume=Vol-1313
|dblpUrl=https://dblp.org/rec/conf/gvd/Koch14
}}
==Proaktive modellbasierte Performance-Analyse und -Vorhersage von Datenbankanwendungen==
https://ceur-ws.org/Vol-1313/paper_5.pdf
Proaktive modellbasierte Performance-Analyse und
-Vorhersage von Datenbankanwendungen
Christoph Koch
Friedrich-Schiller-Universität Jena
Lehrstuhl für Datenbanken und DATEV eG
Informationssysteme Abteilung Datenbanken
Ernst-Abbe-Platz 2 Paumgartnerstr. 6 - 14
07743 Jena 90429 Nürnberg
Christoph.Koch@uni-jena.de Christoph.Koch@datev.de
KURZFASSUNG
Moderne (Datenbank-)Anwendungen sehen sich in der heutigen
1. EINLEITUNG
Zur Erfüllung komplexerer Anforderungen und maximalen
Zeit mit immer höheren Anforderungen hinsichtlich Flexibilität,
Benutzerkomforts ist gute Performance eine Grundvoraussetzung
Funktionalität oder Verfügbarkeit konfrontiert. Nicht zuletzt für
für moderne Datenbankanwendungen. Neben Anwendungs-
deren Backend – ein meist relationales Datenbankmanagement-
Design und Infrastrukturkomponenten wie Netzwerk oder
system – entsteht dadurch eine kontinuierlich steigende Kom-
Anwendungs- beziehungsweise Web-Server wird sie maßgeblich
plexität und Workload, die es frühestmöglich proaktiv zu er-
durch die Performance ihres Datenbank-Backends – wir beschrän-
kennen, einzuschätzen und effizient zu bewältigen gilt. Die dazu
ken uns hier ausschließlich auf relationale Datenbankmanage-
nötigen Anwendungs- und Datenbankspezialisten sind jedoch
mentsysteme (DBMS) – bestimmt [1]. Dabei ist die Datenbank-
aufgrund immer engerer Projektpläne, kürzerer Release-Zyklen
Performance einer Anwendung selbst ebenfalls durch zahlreiche
und weiter wachsender Systemlandschaften stark ausgelastet,
Faktoren beeinflusst. Während Hardware- und systemseitige
sodass für regelmäßige proaktive Expertenanalysen hinsichtlich
Eigenschaften oftmals durch bestehende Infrastrukturen vor-
der Datenbank-Performance kaum Kapazität vorhanden ist.
gegeben sind, können speziell das Datenbank-Design sowie die
Zur Auflösung dieses Dilemmas stellt dieser Beitrag ein anwendungsseitig implementierten Zugriffe mittels SQL weit-
Verfahren vor, mit dessen Hilfe frühzeitig auf Grundlage der gehend frei gestaltet werden. Hinzu kommt als Einflussfaktor
Datenmodellierung und synthetischer Datenbankstatistiken Per- noch die Beschaffenheit der zu speichernden/gespeicherten Daten,
formance-Analysen und -Vorhersagen für Anwendungen mit die sich in Menge und Verteilung ebenfalls stark auf die
relationalem Datenbank-Backend durchgeführt und deren Performance auswirkt.
Ergebnisse auf leicht zugängliche Weise visualisiert werden
können. Das Datenbank-Design entwickelt sich über unterschiedlich
abstrakte, aufeinander aufbauende Modellstrukturen vom konzep-
tionellen hin zum physischen Datenmodell. Bereits bei der
Kategorien und Themenbeschreibung Entwicklung dieser Modelle können „Designfehler“ wie beispiels-
Data Models and Database Design, Database Performance weise fehlende oder „übertriebene“ Normalisierungen gravierende
Auswirkungen auf die späteren Antwortzeiten des Datenbank-
Allgemeine Bestimmungen systems haben. Der Grad an Normalisierung selbst ist jedoch nur
Performance, Design als vager Anhaltspunkt für die Performance von Datenbank-
systemen anzusehen, der sich ab einem gewissen Maß auch
negativ auswirken kann. Eine einfache Metrik zur Beurteilung der
Schlüsselwörter Qualität des Datenbank-Designs bezüglich der zu erwartenden
Performance, Proaktivität, Statistiken, relationale Datenbanken, Performance (in Abhängigkeit anderer Einflussfaktoren, wie etwa
Modellierung, UML, Anwendungsentwicklung der Workload) existiert nach vorhandenem Kenntnisstand nicht.
Etwas abweichend dazu verhält es sich mit dem Einfluss der
Workload – repräsentiert als Menge von SQL-Statements und der
Häufigkeit ihrer Ausführung, die von der Anwendung an das
Datenbanksystem zum Zugriff auf dort gespeicherte Daten
abgesetzt wird. Moderne DBMS besitzen einen kostenbasierten
Copyright © by the paper’s authors. Copying permitted only Optimierer zur Optimierung eingehender Statements. Dieser
for private and academic purposes. berechnet mögliche Ausführungspläne und wählt unter Zu-
In: G. Specht, H. Gamper, F. Klan (eds.): Proceedings of the 26 GI- hilfenahme von gesammelten Objekt-Statistiken den günstigsten
Workshop on Foundations of Databases (Grundlagen von Ausführungsplan zur Abarbeitung eines SQL-Statements aus.
Datenbanken), Mittels DBMS-internen Mechanismen – im Folgenden als
21.10.2014 - 24.10.2014, Bozen, Italy, published at http://ceur-ws.org.
EXPLAIN-Mechanismen bezeichnet – besteht die Möglichkeit, netzwerks. Ein Überblick dazu findet sich in [3]. Demnach zeigt
noch vor der eigentlichen Ausführung von Statements den vom sich für all diese Konzepte ein eher wissenschaftlicher Fokus und
Optimierer bestimmten optimalen Ausführungsplan ermitteln und eine damit einhergehende weitgehend unerprobte Übertragbarkeit
ausgeben zu lassen. Zusätzlich umfasst das EXPLAIN-Ergebnis auf die Praxis. So fehlen Studien zur Integration in praxisnahe
eine Abschätzung der zur Abarbeitung des Ausführungsplans (Entwicklungs-)Prozesse, zur Benutzerfreundlichkeit sowie zum
erwarteten Zugriffskosten bezüglich der CPU-und I/O-Zeit – Kosten-Nutzen-Verhältnis der notwendigen Maßnahmen. Ein
fortan als Kosten bezeichnet. Anhand dieser Informationen damit einhergehendes Defizit ist zusätzlich der mangelnde Tool-
können bereits frühzeitig in Hinblick auf die Datenbank- support. Das in Kapitel 4 vorgestellte Konzept verfolgt diesbe-
Performance (häufige) teure Zugriffe erkannt und gegebenenfalls züglich einen davon abweichenden Ansatz. Es baut direkt auf
optimiert werden. Voraussetzung für dieses Vorgehen ist aller- etablierten modellbasierten Praxisabläufen bei der Entwicklung
dings, dass dem DBMS zur Berechnung der Ausführungspläne von Datenbankanwendungen auf (vgl. Kapitel 3). Insbesondere
repräsentative Datenbank-Statistiken vorliegen, was insbeson- durch die Verwendung von standardisierten UML-Erweiterungs-
dere für neue Datenbankanwendungen nicht der Fall ist. mechanismen integriert es sich auch Tool-seitig nahtlos in
bestehende UML-unterstützende Infrastrukturen.
Auf der anderen Seite sehen sich sowohl Anwendungsentwickler-
beziehungsweise -designerteams als auch Datenbankspezialisten Die Methodik der synthetischen Statistiken – also dem künstli-
mit immer komplexeren Anforderungen und Aufgaben konfron- chen Erstellen sowie Manipulieren von Datenbank-Statistiken –
tiert. Kapazitäten für umfangreiche Performance-Analysen oder ist neben dem in Kapitel 4 vorgestellten Ansatz wesentlicher
auch nur die Aneignung des dafür nötigen Wissens sind oft nicht Bestandteil von [4]. Sie wird zum einen verwendet, um Statistiken
gegeben. Nicht zuletzt deshalb geraten proaktive Performance- aus Produktionsumgebungen in eine Testumgebung zu trans-
Analysen verglichen mit beispielsweise funktionalen Tests ver- ferieren. Zum anderen sieht der Ansatz aber auch die gezielte
mehrt aus dem Fokus. manuelle Veränderung der Statistiken vor, um mögliche dadurch
entstehende Änderungen in den Ausführungsplänen und den zu
Das im vorliegenden Beitrag vorgestellte modellbasierte Konzept deren Abarbeitung benötigten Kosten mithilfe anschließender
setzt an diesen beiden Problemen an und stellt Mechanismen vor, EXPLAIN-Analysen feststellen zu können. Dies kann beispiels-
um auf einfache Art und Weise eine repräsentative proaktive weise bezogen auf Statistiken zur Datenmenge dafür genutzt
Analyse der Datenbank-Performance zu ermöglichen. Nachdem in werden, um Zugriffe auf eine (noch) kleine Tabelle mit wenigen
Kapitel 2 eine Abgrenzung zu alternativen/verwandten Ansätzen Datensätzen bereits so zu simulieren, als ob diese eine enorme
gegeben wird, rückt Kapitel 3 den Entwicklungsprozess einer Menge an Daten umfasst. Weitere Einbettungen in den Entwick-
Datenbank-Anwendung in den Fokus. Kapitel 4 beschäftigt sich lungsprozess von Datenbankanwendungen sieht [4] gegenüber
mit dem entwickelten proaktiven Ansatz und stellt wesentliche dem hier vorgestellten Ansatz allerdings nicht vor.
Schritte/Komponenten vor. Abschließend fasst Kapitel 5 den
Ein weiterer Ansatzpunkt zur Performance-Analyse und -Optimie-
Beitrag zusammen.
rung existiert im Konzept des autonomen Datenbank-Tunings
[5][6],[7] – also dem fortlaufenden Optimieren des physischen
2. VERWANDTE ARBEITEN Designs von bereits bestehenden Datenbanken durch das DBMS
Das Ziel des im Beitrag vorgestellten proaktiven Ansatzes zur selbst. Ein autonomes System erkennt anhand von erlerntem
Performance-Analyse und -Vorhersage von Datenbankanwendun- Wissen potentielle Probleme und leitet passende Optimierungs-
gen ist die frühzeitige Erkennung von potentiellen Perfor- maßnahmen ein, bevor sich daraus negative Auswirkungen
mance-Problemen auf Basis einer möglichst effizienten, leicht ergeben. Dazu zählt beispielsweise die autonome Durchführung
verständlichen Methodik. Dies verfolgt auch der Ansatz von [2], einer Reorganisierung von Daten, um fortwährend steigenden
dessen Grundprinzip – Informationen über Daten und Datenzu- Zugriffszeiten entgegenzuwirken. Ähnlich können auch die
griffe, die aus der Anforderungsanalyse einer Anwendung bekannt mittlerweile je System vielseitig vorhandenen Tuning-Advisor wie
sind, zur frühzeitigen Optimierung zu nutzen – sich auch im beispielsweise [8] und [9] angesehen werden, die zwar nicht auto-
vorliegenden Beitrag wiederfindet. Dabei gelangt [2] durch eine matisch optimierend ins System eingreifen, dem Administrator
eigene, dem Datenbank-Optimierer nachempfundene Logik und aber Empfehlungen zu sinnvoll durchzuführenden Aktionen
dem verwendeten Modell des offenen Warteschlangennetzwerks geben. Sowohl das autonome Tuning als auch die Tuning-Advisor
frühzeitig zu Kostenabschätzungen bezüglich der Datenbank- sind nicht als Alternative zu dem im vorliegenden Beitrag
Performance. Das in Kapitel 4 des vorliegenden Beitrags vorge- vorgestellten Ansatz einzuordnen. Vielmehr können sich diese
stellte Konzept nutzt dagegen synthetisch erzeugte Statistiken und Konzepte ergänzen, indem die Anwendungsentwicklung auf Basis
datenbankinterne EXPLAIN-Mechanismen, um eine kostenmäßi- des in Kapitel 4 vorgestellten Konzepts erfolgt und für die spätere
ge Performance-Abschätzung zu erhalten. Damit berücksichtigt es Anwendungsadministration/ -evolution verschiedene Tuning-
stets sowohl aktuelle als auch zukünftige Spezifika einzelner Advisor und die Mechanismen des autonomen Tunings zum Ein-
Datenbank-Optimierer und bleibt entgegen [2] von deren interner satz kommen.
Berechnungslogik unabhängig. Ein weiterer Unterschied zwischen
beiden Ansätzen besteht in der Präsentation der Analyse- 3. ENTWICKLUNGSPROZESS VON
ergebnisse. Während sich [2] auf tabellarische Darstellungen
beschränkt, nutzt das im Beitrag vorstellte Konzept eine auf der DATENBANKANWENDUNGEN
Grundlage der Unified Modeling Language (UML) visualisierte Der Entwicklungsprozess von Anwendungen lässt sich anhand
Darstellungsform. des System Development Lifecycle (SDLC) beschreiben und in
verschiedene Phasen von der Analyse der Anforderungen bis hin
Ähnlich wie [2] basieren auch weitere Ansätze zur Performance- zum Betrieb/zur Wartung der fertigen Software gliedern [1].
Analyse und -Evaluation auf dem Modell des Warteschlangen-
Project Manager
Analyse Analyse Business Analyst
Datenbank Software
Datenbank Daten- Reports Designer/
Designer/ Detail Design
Design modelle Prozesse Architekt
Architekt
Implementierung Program-
Implementierung mierer
und Laden Erstellen Prototyping
Laden
Test und Tuning Test und Debugging Tester
Auswertung Auswertung
Datenbank System-
Administrator Betrieb Administrator
Datenbank- Wartung der
Wartung Anwendung
Abbildung 1: Phasen und Akteure im Database und Software Development Lifecycle
(DBLC und SDLC)
Zusätzlich zur reinen Anwendungsentwicklung sind weitere der Entwicklungsprozess von Datenbankanwendungen auf die in
Abläufe zur Planung und Bereitstellung einer geeigneten Infra- Abbildung 2 visualisierten Aufgaben. Anhand der analysierten
struktur nötig. Für Datenbankanwendungen wäre das unter ande- Anforderungen wird im Datenbank-Design ein konzeptionelles
rem der Entwicklungsprozess der Datenbank, welcher sich nach Datenmodell entwickelt, das anschließend hin zum physischen
[1] ebenfalls durch ein dem SDLC ähnliches Modell – dem Data- Datenmodell verfeinert wird. Da sich der Beitrag auf die in der
base Lifecycle (DBLC) – formalisieren lässt. Beide Entwicklungs- Praxis vorherrschenden relationalen DBMS beschränkt, wird auf
prozesse verlaufen zeitlich parallel und werden insbesondere in das in der Theorie gebräuchliche Zwischenprodukt des logischen
größeren Unternehmen/Projekten durch verschiedene Akteure Datenmodells (relationale Abbildung) verzichtet.
realisiert. Auf Grundlage von [1] liefert Abbildung 1 eine Über-
sicht dazu. Sie visualisiert parallel ablaufende Entwicklungspha- Nachdem die Design-Phase abgeschlossen ist, beginnt die
sen und eine Auswahl an zuständigen Akteuren, deren konkrete Implementierung. Datenbankseitig wird dabei das physische
Zusammensetzung/Aufgabenverteilung aber stark abhängig von Datenmodell mittels Data Definition Language (DDL) in ein
der Projektgröße und dem Projektteam ist. Wichtig sind hier be- Datenbankschema innerhalb eines installierten und geeignet
sonders zwei Erkenntnisse. Zum einen finden ähnliche Entwick- konfigurierten DBMS umgesetzt und möglicherweise vorhandene
lungsprozesse bei Anwendung und Datenbank parallel statt – in Testdaten geladen. Anwendungsseitig erfolgt parallel dazu die
etwa das Anwendungsdesign und das Datenbankdesign. Zum Entwicklung von SQL-Statements zum Zugriff auf die Datenbank
anderen können sehr viele Akteure am gesamten Entwicklungs- sowie die Implementierung der Anwendung selbst. Nach
prozess beteiligt sein, sodass Designer, Programmierer, Tester und Fertigstellung einzelner Module finden mithilfe des Entwick-
Administratoren in der Regel disjunkte Personenkreise bilden. lungs- und Qualitätssicherungssystems kontinuierliche Tests
statt, die sich allerdings anfangs auf die Prüfung funktionaler
Analyse Konzeptionelles Korrektheit beschränken. Performance-Untersuchungen, insbe-
Datenmodell Physisches sondere bezogen auf die Datenbankzugriffe, erfolgen in der Regel
Datenmodell
erst gezielt zum Abschluss der Implementierungsphase mittels
Design
aufwändig vorzubereitender und im Qualitätssicherungssystem
durchzuführender Lasttests.
Impl.
SQL
Die Folgen aus diesem Vorgehen für die Erkennung und Behand-
Test Entwicklungs- SQL- lung von Performance-Problemen sind mitunter gravierend. Eng-
system Statements
pässe werden erst spät (im Betrieb) bemerkt und sind aufgrund
Qualitäts-
Betrieb sicherungs- des fortgeschrittenen Entwicklungsprozesses nur mit hohem
Produktions- system Aufwand zu korrigieren. Basieren sie gar auf unvorteilhaften
Wartung system Design-Entscheidungen beispielsweise bezogen auf die Daten-
modellierung, ist eine nachträgliche Korrektur aufgrund zahlrei-
Abbildung 2: Performance-relevante Entwicklungsschritte cher Abhängigkeiten (Anwendungslogik, SQL-Statements, Test-
datenbestände, etc.), getrennten Zuständigkeiten und in der Regel
Aus dem Blickwinkel der Datenbank-Performance und der darauf engen Projektzeitplänen nahezu ausgeschlossen. Erfahrungen aus
einwirkenden bereits genannten Einflussfaktoren reduziert sich dem Arbeitsumfeld des Autors haben dies wiederholt bestätigt.
Performance
Indikatoren
Abbildung und Statistikerzeugung
Konzeptionelles 1. 2.
Datenmodell Physisches Kosten
Datenmodell EXPLAIN EP2
EP1
3. 4.
SQL
Entwicklungs-
Testsystem Performance-Modell
system SQL-
Qualitäts-
Statements
Produktions- sicherungs-system
system
Abbildung 3: Ansatz zur proaktiven modellbasierten Performance-Analyse und -Vorhersage
bei Anwendungsweiterentwicklungen weitgehend vorliegen, exis-
4. PROAKTIVE MODELLBASIERTE tieren für neu zu entwickelnde Anwendungen im Normalfall keine
PERFORMANCE-ANALYSE repräsentativen Datenbestände. Somit fehlen auch geeignete
Alternativ zur Performance-Analyse mittels Lasttests (vgl. Kapitel Datenbankstatistiken zur Grundlage für die EXPLAIN-Auswer-
3) bieten sich zur Kontrolle der SQL-Performance die eingangs tungen. Die Folge sind Ausführungspläne und Kostenabschätzun-
erwähnten EXPLAIN-Mechanismen an. Mit deren Hilfe lassen gen, die mit denen eines späteren produktiven Einsatzes der State-
sich bei vorliegendem physischen Datenbank-Design (inklusive ments oftmals nur wenig gemeinsam haben und für eine proaktive
Indexe, etc.) bereits in frühen Abschnitten der Implementierungs- Performance-Analyse somit (nahezu) unverwertbar sind.
phase Auswertungen zu Ausführungsplänen und geschätzten Der im folgenden Kapitel vorgestellte proaktive modellbasierte
Kosten für entwickelte SQL-Statements durchführen. Auf diese Ansatz zur Performance-Analyse und -Vorhersage greift beide
Weise gewonnene Erkenntnisse können vom Designer/Program- Probleme auf: die fehlende repräsentative Datenbasis für Daten-
mierer direkt genutzt werden, um Optimierungen in Hinblick auf bankstatistiken und die mangelnde Expertise zur Ausführungs-
die quasi grade entworfenen/implementierten SQL-Statements planbewertung durch Designer/Programmierer. Dabei sieht dieser
durchzuführen. Durch die gegebene zeitliche Nähe zum Anwen- Ansatz zur Bereitstellung geeigneter Datenbankstatistiken ein
dungs- und Datenbank-Design sind auch Performance-Optimie- synthetisches Erzeugen anhand von Performance-Indikatoren vor.
rungen auf Basis von Datenmodellanpassungen (Normalisie- Das Problem der mangelnden Expertise wird durch eine einfache
rung/Denormalisierung) ohne größeren Aufwand möglich. modellbasierte Darstellung von gewonnenen EXPLAIN-Ergeb-
Das beschriebene Vorgehen hat zwar den Vorteil, dass mögliche nissen adressiert. Wie diese gestaltet ist und mit den Performance-
Performance-Probleme schon von den Akteuren (Designer/Pro- Indikatoren zusammenwirkt verdeutlichen die weiteren Ausfüh-
grammierer) erkannt werden können, die diese durch Design- rungen des Kapitels anhand Abbildung 3.
Änderungen am effektivsten zu lösen wissen. Demgegenüber
erfordern die EXPLAIN-Analysen und das Verständnis der Aus- 4.1 Performance-Indikatoren im Datenmodell
führungspläne einen Grad an Expertise, den Designer/Program- Als Performance-Indikatoren bezeichnet die vorliegende Arbeit
mierer in der Regel nicht besitzen. Ein Datenbank Administrator ausgewählte Metadaten zu Entitäten und deren Attributen
(DBA), der über diese verfügt, ist wiederum von den fachlichen (beziehungsweise zu Tabellen und deren Spalten), die Aufschluss
Anforderungen zu distanziert, sodass er zwar mögliche Perfor- über die erwarteten realen Datenbestände geben und in Zusam-
mance-Ausreißer erkennen, nicht aber fachlich bewerten kann. menhang mit dem Datenbank-Design und der Infrastruktur erste
Führt eine Anwendung beispielsweise einmal monatlich eine sehr Rückschlüsse auf die zukünftige Datenbank-Performance erlau-
komplexe Auswertung mithilfe eines entsprechend Laufzeit- ben. Dazu zählen Informationen zu den erwarteten Datenmengen
intensiven SQL-Statements durch, dann würde dem DBA diese wie in etwa die erwartete Anzahl an Zeilen pro Tabelle und
Abfrage bei EXPLAIN-Analysen als kritisch erscheinen. Denn er Kennzahlen zur Datenverteilung – beispielsweise in Form von
weiß weder, dass damit ein fachlich aufwändiger Prozess Wertebereichsangaben, Einzelwertwahrscheinlichkeiten oder der
durchgeführt wird, noch dass es sich dabei um eine einmalig pro Kardinalität pro Spalte. Viele dieser Informationen sind Teil des
Monat auszuführende Abfrage handelt. Um sich als DBA in einer Ergebnisses der Anforderungsanalyse und somit frühzeitig im
Infrastruktur von nicht selten mehr als 100 unterschiedlichen SDLC bekannt und vom Business Analyst erfasst worden. Dabei
Anwendungen über die fachlichen Anforderungen und speziellen reicht die Dokumentation von rein textuellen Beschreibungen bis
Prozesse jeder einzelnen im Detail zu informieren beziehungs- hin zu tief strukturierten Darstellungen. Eine einheitlich stan-
weise um sich als Designer/Programmierer das nötige Knowhow dardisierte Form zur Erfassung von Performance-Indikatoren im
zur Ausführungsplanbewertung aufzubauen, ist personelle DBLC existiert jedoch bislang nicht, wodurch die Metadaten
Kapazität vonnöten, die in der Regel nicht verfügbar ist. kaum bis gar nicht in den weiteren Entwicklungsprozess ein-
fließen.
Ein anderes Problem, dass sich in Zusammenhang mit frühzei-
tigen EXPLAIN-Analysen zeigt, begründet sich in dem dritten In der Praxis basiert die Datenmodellierung ähnlich wie weite
zuvor genannten Performance-Faktor: den Daten. Während diese Teile der Anwendungsmodellierung auf der Sprache UML. Dabei
wurde diese ursprünglich nicht zur Abbildung von Daten- der Designer/Programmierer beim Modellieren oder dem Ent-
strukturen im Sinn einer Entity-Relationship-Modellierung kon- wickeln von SQL-Statements auf relationale Weise. Die im vorlie-
zipiert, sodass die Verbindung beider Welten – und damit die genden Ansatz als Performance-Modell bezeichnete vereinfachte
Modellierung von Anwendung und Datenstrukturen mithilfe einer Präsentation von Ausführungsplänen versucht, diese Diskrepanz
gemeinsamen Sprache in einem gemeinsamen Tool – erst durch aufzulösen.
Ansätze wie [10] oder auch den Entwurf zum IMM Standard der
OMG [11] geschaffen wurde. Die Voraussetzung dafür bildet Das Performance-Modell basiert auf dem physischen Datenmo-
jeweils die UML-Profil-Spezifikation, die es ermöglicht, beste- dell und damit auf einer dem Designer/Programmierer bekannten
hende UML-Objekte über Neu-Stereotypisierungen zu erweitern. Darstellungsform. Zusätzlich umfasst es die für diesen Personen-
kreis wesentlichen Informationen aus den EXPLAIN-Ergebnissen.
Um die zuvor genannten Performance-Indikatoren für den weite- Dazu zählen die vom DBMS abgeschätzten Kosten für die Aus-
ren Entwicklungsprozess nutzbar zu machen und sie innerhalb führung des gesamten Statements sowie wichtiger Operatoren wie
bestehender Infrastrukturen/Tool-Landschaften standardisiert zu Tabellen- beziehungsweise Indexzugriffe oder Tabellenverknü-
erfassen, kann ebenfalls der UML-Profil-Mechanismus genutzt pfungen mittels Join – jeweils skaliert um die erwartete Aus-
werden. So ließe sich beispielsweise mithilfe eines geeigneten führungshäufigkeit des Statements. Weitere Detailinformationen
Profils wie in Abbildung 3 in 1. schematisch angedeutet aus einem innerhalb der Ausführungspläne wie beispielsweise die konkrete
UML-Objekt „entity“ ein neues Objekt „entity_extended“ ablei- Abarbeitungsreihenfolge einzelner Operatoren oder Angaben zu
ten, das in einem zusätzlichen Merkmal „cardinality“ Infor- abgeschätzten Prädikat-Selektivitäten werden vom Modell zum
mationen über die produktiv erwartete Datenmenge zu einer Zweck der Einfachheit und Verständlichkeit bewusst vernach-
Entität/Tabelle aufnehmen kann. lässigt. Für die gleichzeitige Analyse mehrerer Statements erfolgt
eine Aggregation der jeweils abgeschätzten Kosten auf Objekt-
4.2 Synthetische Datenbankstatistiken ebene.
Eines der eingangs aufgezeigten Hindernisse für proaktive Perfor- Zentrale Komponente im Performance-Modell ist eine ebenfalls
mance-Analysen beziehungsweise -Vorhersagen bestand in der dem physischen Datenmodell angelehnte Diagrammdarstellung.
fehlenden repräsentativen Datenbasis für Datenbank-Statisti- Mithilfe farblicher Hervorhebung und geeigneter Bewertungs-
ken. Diese Statistiken werden im Normalfall vom DBMS anhand metriken sollen sämtliche Objekte gemäß den vom DBMS
der gespeicherten Daten selbst gesammelt. Dem entgegen verfolgt geschätzten Zugriffskosten zur Abarbeitung der Workload
das hier vorgestellte Konzept den Ansatz, dem DBMS Statistiken klassifiziert und visualisiert werden. Auf diese Weise kann ein
vorzugeben, ohne dazu datenbankseitig repräsentative Datenbe- Designer/Programmierer frühzeitig Auskunft über aus Perfor-
stände vorhalten zu müssen. Dafür bieten zwar die wenigsten mance-Perspektive zu optimierende Bereiche im Datenbank-
DBMS vordefinierte Schnittstellen an, allerdings sind sämtliche schema beziehungsweise kritische, alternativ zu konzipierende
Statistik-Informationen in der Regel innerhalb DBMS-interner SQL-Statements erhalten. Abbildung 3 veranschaulicht exempla-
manipulierbarer Tabellen gespeichert, wie dies beispielswiese risch ein visualisiertes Performance-Modell für zwei Statements/
auch bei DB2 oder Oracle der Fall ist [12]. Ausführungspläne (EP). Während der untere Bereich weitgehend
grün/unkritisch markiert ist, befinden sich im oberen Diagramm-
Datenbankstatistiken enthalten Informationen über Datenmengen
teil mögliche Performance-kritische rot gekennzeichnete Zugriffe,
und Datenverteilungen sowie Kennzahlen zur physischen Spei-
die es gezielt zu untersuchen und an geeigneter Stelle (SQL-State-
cherung wie beispielsweise die Anzahl der verwendeten Daten-
ment, Datenbank-Design) zu optimieren gilt (vgl. gestrichelte
bankseiten pro Tabelle. Während erstere inhaltlich den zuvor
Pfeile in Abbildung 3).
beschriebenen Performance-Indikatoren entsprechen, sind die
Statistikdaten zur physischen Speicherung interne DBMS-abhän- Die technische Realisierung des Performance-Modells sowie der
gige Größen. Mithilfe geeigneter, von den DBMS-Herstellern zur dazugehörigen Diagrammdarstellung erfolgt analog zur Erfassung
Unterstützung beim Datenbank-Design bereitgestellter Abschät- der Performance-Indikatoren über den UML-Profil-Mechanismus,
zungsvorschriften lassen sich aber auch diese Kennzahlen auf wodurch auch in diesem Punkt die Kompatibilität des vorge-
Grundlage der Performance-Indikatoren approximieren. Somit ist stellten Ansatzes zu bestehenden Tool-Infrastrukturen gewähr-
es wie in Abbildung 3 in 2. gezeigt möglich, anhand geeignet leistet ist.
formalisierter Performance-Indikatoren frühzeitig im SDLC/
DBLC repräsentative Datenbankstatistiken künstlich zu erzeugen.
4.4 Ablauf einer Analyse/Vorhersage
Für den Designer/Programmierer sieht der in Abbildung 3
4.3 EXPLAIN und Performance-Modell vorgestellte proaktive Ansatz folgende Vorgehensweise vor.
Auf Grundlage von synthetischen Datenbankstatistiken können Nachdem nach 1. ein Datenbank-Design-Entwurf fertiggestellt ist,
wie in Abbildung 3 in 3. und 4. zu sehen, mittels der vom DBMS initiiert er in 2. einen Automatismus zur Abbildung des Designs
bereitgestellten EXPLAIN-Funktionalität, der SQL-Workload in ein Datenbank-Schema sowie zur Erstellung von synthetischen
und dem aus dem physischen Datenmodell ableitbaren Daten- Datenbank-Statistiken anhand der von ihm modellierten Perfor-
bankschema proaktive Performance-Vorhersagen durchgeführt mance-Indikatoren. Mithilfe einer weiteren Routine startet der
werden. Die resultierenden, teils komplexen Ausführungspläne Designer/Programmierer in 3. und 4. anschließend einen Simu-
lassen sich allerdings nur mit ausreichend Expertise und vor- lationsprozess, der auf Basis der EXPLAIN-Mechanismen Perfor-
handenen personellen Kapazitäten angemessen auswerten, sodass mance-Vorhersagen für eine gegebene Workload erstellt und diese
diese Problematik vorläufig weiterbesteht. Eine Hauptursache, die als Performance-Modell aufbereitet. Von dort aus informiert er
das Verständnis von Ausführungsplänen erschwert, ist ihre sich mithilfe der Diagrammdarstellung über mögliche kritische
hierarchische Darstellung als Zugriffsbaum. Demgegenüber denkt Zugriffe, die er daraufhin gezielt analysiert und optimiert.
5. ZUSAMMENFASSUNG Ansatzes entgegensteht. Somit sind alternative Varianten zur
Datenbank-Performance ist ein wichtiger, oftmals jedoch vernach- Beschaffung der Workload für den Analyseprozess zu
lässigter Faktor in der Anwendungsentwicklung. Durch moderne untersuchen und abzuwägen.
Anforderungen und dazu implementierte Anwendungen sehen
sich speziell deren Datenbank-Backends mit kontinuierlich 7. LITERATUR
wachsenden Herausforderungen insbesondere betreffend der [1] C. Coronel, S. Morris, P. Rob. Database Systems: Design,
Performance konfrontiert. Diese können nur bewältigt werden, Implementation, and Management, Course Technology, 10.
wenn das Thema Datenbank-Performance intensiver betrachtet Auflage, 2011.
und durch proaktive Analysen (beispielsweise mittels EXPLAIN-
[2] S. Salza, M. Renzetti. A Modeling Tool for Workload
Mechanismen) kontinuierlich verfolgt wird. Doch auch dann sind
Analysis and Performance Tuning of Parallel Database
einzelne Hindernisse unvermeidlich: fehlende repräsentative
Applications, Proceedings in ADBIS'97, 09.1997
Daten(-mengen) und Expertise/Kapazitäten zur Analyse.
http://www.bcs.org/upload/pdf/ewic_ad97_paper38.pdf
Der vorliegende Beitrag präsentiert zur Lösung dieser Probleme [3] R. Osman, W. J. Knottenbelt. Database system performance
einen modellbasierten Ansatz, der auf Basis synthetisch erzeugter evaluation models: A survey, Artikel in Performance
Statistiken proaktive Performance-Analysen sowie -Vorhersagen Evaluation, Elsevier Verlag, 10.2012
erlaubt und die daraus gewonnenen Ergebnisse in einer einfach http://dx.doi.org/10.1016/j.peva.2012.05.006
verständlichen Form visualisiert. Die technologische Grundlage
dafür bietet die in der Praxis vorherrschende Modellierungs- [4] Tata Consultancy Services. System and method for SQL
sprache UML mit ihrer UML-Profil-Spezifikation. Sie erlaubt es performance assurance services, Internationales Patent
das hier vorgestellte Konzept und die dazu benötigten Kom- PCT/IN2011/000348, 11.2011
ponenten mit vorhandenen technischen Mitteln abzubilden und http://dx.doi.org/10.1016/j.peva.2012.05.006
nahtlos in bestehende UML-Infrastrukturen zu integrieren. [5] D. Wiese. Gewinnung, Verwaltung und Anwendung von
Performance-Daten zur Unterstützung des autonomen
6. AUSBLICK Datenbank-Tuning, Dissertation, Fakultät für Mathematik
Bei dem im Beitrag vorgestellten Konzept handelt es sich um und Informatik, Friedrich-Schiller-Universität Jena, 05.2011.
einen auf Basis wiederkehrender praktischer Problemstellungen http://www.informatik.uni-jena.de/dbis/alumni/wiese/pubs/D
und den daraus gewonnenen Erfahrungen konstruierten Ansatz. issertation__David_Wiese.pdf
Während die technische Umsetzbarkeit einzelner Teilaspekte wie [6] S. Chaudhuri, V. Narasayya. A Self-Tuning Database
etwa die Erfassung von Performance-Indikatoren oder die Kon- Systems: A Decade of Progress, Proceedings in VLDB'07,
struktion des Performance-Modells auf Basis von UML-Profilen 09.2007
bereits geprüft wurde, steht eine prototypische Implementierung http://research.microsoft.com/pubs/76506/vldb07-10yr.pdf
des gesamten Prozesses zur Performance-Analyse noch aus.
[7] N. Bruno, S. Chaudhuri. An Online Approach to Physical
Zuvor sind weitere Detailbetrachtungen nötig. So ist beispiels- Design Tuning, Proceedings in ICDE'07, 04.2007
weise zu klären, in welchem Umfang Performance-Indikatoren http://research.microsoft.com/pubs/74112/continuous.pdf
im Datenmodell vom Analyst/Designer sinnvoll erfasst werden
[8] Oracle Corporation. Oracle Database 2 Day DBA 12c
sollten. Dabei ist ein Kompromiss zwischen maximalem
Release 1 (12.1) – Monitoring and Tuning the Database,
Detailgrad und minimal nötigem Informationsgehalt anzustreben,
2013.
sodass der Aufwand zur Angabe von Performance-Indikatoren
http://docs.oracle.com/cd/E16655_01/server.121/e17643/mo
möglichst gering ist, mit deren Hilfe aber dennoch eine
ntune.htm#ADMQS103
repräsentative Performance-Vorhersage ermöglicht wird.
[9] Microsoft Corporation. SQL Server 2005 – Database Engine
Weiterhin gilt es, eine geeignete Metrik zur Bewertung/Katego- Tuning Advisor (DTA) in SQL Server 2005, Technischer
risierung der Analyseergebnisse zu entwickeln. Hier steht die Artikel, 2006.
Frage im Vordergrund, wann ein Zugriff anhand seiner Kosten als http://download.microsoft.com/download/4/7/a/47a548b9-
schlecht und wann er als gut zu bewerten ist. Ein teurer Zugriff ist 249e-484c-abd7-29f31282b04d/SQL2005DTA.doc
nicht zwangsweise ein schlechter, wenn er beispielsweise zur
Realisierung einer komplexen Funktionalität verwendet wird. [10] C.-M. Lo. A Study of Applying a Model-Driven Approach to
the Development of Database Applications, Dissertation,
Zuletzt sei noch die Erfassung beziehungsweise Beschaffung der Department of Information Management, National Taiwan
für die EXPLAIN-Analysen notwendigen Workload erwähnt. University of Science and Technology, 06.2012.
Diese muss dem vorgestellten proaktiven Analyseprozess [11] Object Management Group. Information Management
zugänglich gemacht werden, um anhand des beschriebenen Metamodel (IMM) Specification Draft Version 8.0,
Konzepts frühzeitige Performance-Untersuchungen durchführen Spezifikationsentwurf, 03.2009.
zu können. Im einfachsten Fall könnte angenommen werden, dass http://www.omgwiki.org/imm/doku.php
sämtliche SQL-Statements (inklusive ihrer Ausführungshäu-
figkeit) vom Designer/Programmierer ebenfalls im Datenmodell [12] N. Burgold, M. Gerstmann, F. Leis. Statistiken in
beispielsweise als zusätzliche Merkmale von Methoden in der relationalen DBMSen und Möglichkeiten zu deren
UML-Klassenmodellierung zu erfassen und kontinuierlich zu synthetischer Erzeugung, Projektarbeit, Fakultät für
pflegen wären. Dies wäre jedoch ein sehr aufwändiges Verfahren, Mathematik und Informatik, Friedrich-Schiller-Universität
das der gewünschten hohen Praxistauglichkeit des proaktiven Jena, 05.2014.