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.