Der Datentyp XML in DB2 for z/OS aus Performance

Der Datentyp XML in DB2 for z/OS aus
Performance-Perspektive
- Diplomarbeit -
zur Erlangung des akademischen Grades Diplom-Informatiker
eingereicht von
Christoph Koch
[email protected]
Betreuer
Prof. Klaus Küspert, Friedrich-Schiller-Universität Jena
Norbert Wolf, DATEV eG
Friedrich-Schiller-Universität Jena
Fakultät für Mathematik und Informatik
Institut für Informatik
Lehrstuhl für Datenbanken und Informationssysteme
Januar 2012
Danksagung
Die vorliegende Diplomarbeit wurde nur durch die breite Unterstützung zahlreicher Akteure
ermöglicht. Ihnen möchte ich an dieser Stelle meinen ausdrücklichen Dank aussprechen.
Prof. Klaus Küspert
Prof. Küspert trug maßgeblich dazu bei, dass ich über ein durch ihn vermitteltes
Praktikum im Jahr 2010 mit der DATEV eG in Kontakt getreten bin. Daran schloss sich eine
Studienarbeit und nun in thematisch ähnlichem Umfeld auch die vorliegende Diplomarbeit an,
deren universitäre Betreuung in beiden Fällen Prof. Küspert selbst übernahm. Dabei scheute er
keine Mühen und reiste neben diversen Besprechungsterminen in Jena auch mehrfach zur
DATEV eG nach Nürnberg.
Norbert Wolf
Herr Wolf übernahm als Fachberater Datenbanken (DB2 for z/OS) die Betreuung der
Diplomarbeit in der DATEV eG. In engem Kontakt stand er mir stets für Fragen zur Verfügung
und investierte viel Zeit darin, mich mit seinem Wissen fachlich zu unterstützen. Darüber hinaus
gab er mir auch zahlreiche persönliche Ratschläge, so dass er für mich eine Funktion als Mentor
einnahm.
„Belegwesen“-Projekt
Das „Belegwesen“-Projekt in der DATEV eG verwaltet in DB2 for z/OS eine sehr
umfangreiche Menge an XML-Dokumenten. Nach Absprache und Prüfung durch die verantwortlichen Kollegen konnte mit Hilfe dieser Daten ein breites Spektrum an PerformanceMessreihen durchgeführt werden. Anhand dieser Tests ließen sich wertvolle Erkenntnisse
hinsichtlich der datenbankseitigen XML-Verarbeitung ableiten.
Mengchu Cai
Mengchu Cai ist Mitarbeiter von IBM im Silicon Valley Lab in San Jose (Kalifornien)
und unterstützt die DATEV eG bei Fragen und Problemen in Verbindung mit der pureXMLImplementierung in DB2 for z/OS. In speziellen Kontexten trug er daher mit sehr hilfreichen,
umfangreichen Ausführungen zu den detaillierten Betrachtungen dieser Arbeit bei.
Dr. Ernst Lugert
Als Leiter der Abteilung Datenbanken der DATEV eG hat mich Dr. Lugert ebenfalls
weitreichend unterstützt. Er ermöglichte es mir parallel zu meinem Studium in Jena diese Arbeit
anzufertigen. Zusätzlich erkundigte sich Dr. Lugert während regelmäßiger Besprechungstermine
nach dem aktuellen Stand der Arbeit und zeigte bei auftretenden Problemen hilfreiche
Gedankenansätze auf.
Karin Arneth
Frau Arneth hat durch ihre Position im Sekretariat der Abteilung Datenbanken einen
großen Beitrag zu der Organisation dieser Arbeit geleistet. Dabei koordinierte sie unter anderem
sämtliche Terminangelegenheiten. Weiterhin nahm sich Frau Arneth die Zeit, um die vorliegende Arbeit grammatikalisch zu prüfen und trug somit merklich zu deren Qualität bei.
Uwe Heger
Herr Heger war bis zu seinem Positionswechsel zu Beginn des Jahres 2012 Mitarbeiter
der Gruppe Datenbankadministration der DATEV eG. Mit seinem breiten Wissensspektrum von
Datenbanken bis hin zur Anwendungsentwicklung unterstützte er mich bei vielen konzeptuellen
Überlegungen und reicherte damit die Diplomarbeit an.
Eva Ising und Christa Hofmann
Frau Ising und Frau Hofmann sind in der DATEV eG Mitarbeiterinnen der Gruppe
Datenbanksysteme. Sie stellten meine Ansprechpartnerinnen bei systemseitigen Problemen im
DB2 for z/OS dar und machten sich viel Mühe, um diese möglichst schnell zu beheben.
Allen diesen Personen, sowie auch den nicht genannten Mitarbeitern der Gruppe
Datenbankadministration, die mich sehr herzlich in ihr Kollegium aufgenommen haben, gilt
mein besonderer Dank.
Kurzfassung
Mit der pureXML-Technologie ermöglicht das IBM-Datenbankmanagementsystem DB2 for
z/OS neben der traditionellen relationalen Datenablage auch die native Speicherung von Daten
im XML-Format. Letztere ermöglicht die XML-spezifische datenbankseitige Verarbeitung von
Dokumenten und verspricht dabei einen hohen Grad an Effizienz zu gewährleisten. Nachdem
bereits in einer vorangegangenen Studienarbeit die native XML-Speicherform aus struktureller
Sicht den in der DATEV eG vorhandenen nicht-nativen Varianten gegenübergestellt wurde, ist
in der vorliegenden Diplomarbeit der Fokus auf den Aspekt Performance gerichtet. In diesem
Zusammenhang erfolgt die gezielte Betrachtung der Themenschwerpunkte Migration und
Parsen, XML-Schema-Management und Query Performance. Aus den dabei gewonnenen
Erkenntnissen wird abschließend ein Fazit gezogen, das diverse Vorzüge der nativen XMLSpeicherung bestätigt, aber auch Schwachpunkte dieser Ablageform zusammenfasst. Hier
erfolgt insbesondere ein Ausblick auf die von IBM angekündigten Optimierungen rund um den
nativen XML-Datentyp. Einige der erwähnten Punkte sind teilweise bereits in der Folgeversion
10 des hier betrachteten DB2 for z/OS implementiert worden. Diese Optimierungen finden im
Kontext der vorliegenden Arbeit an geeigneter Stelle Erwähnung.
Inhaltsverzeichnis
1
Einleitung ..............................................................................................................................8
1.1 Motivation.........................................................................................................................8
1.2 Einstiegsbeispiel .............................................................................................................10
1.3 Gliederung ......................................................................................................................11
2
Die DATEV eG...................................................................................................................14
2.1 Eingetragene Genossenschaft .........................................................................................14
2.2 Daten und Fakten ............................................................................................................14
2.3 Portfolio ..........................................................................................................................14
2.4 Hintergrund der XML-Untersuchung .............................................................................15
3
Grundlagen..........................................................................................................................17
3.1 XML................................................................................................................................17
3.1.1 Nativ vs. nicht-nativ .................................................................................................19
3.1.2 XML-Parsen und XML-Serialisieren .......................................................................20
3.1.3 XPath........................................................................................................................23
3.2 DB2-Infrastruktur in der DATEV...................................................................................24
3.2.1 DB2 for z/OS............................................................................................................25
3.2.2 Entwicklungsumgebung ...........................................................................................26
3.3 Performance-Zeiten: Elapsed- und CPU-Zeit .................................................................28
3.4 Toolumfeld......................................................................................................................29
3.4.1 IBM Data Studio ......................................................................................................30
3.4.2 Visual Explain ..........................................................................................................31
3.4.3 CA Detector..............................................................................................................32
4
Aktueller Kenntnisstand zu Performance-Kennzahlen .......................................................33
4.1 Veröffentlichte Messergebnisse......................................................................................33
4.2 Der TPOX-Benchmark ...................................................................................................34
5
Vorbetrachtungen zur Messdatenerhebung .........................................................................36
5.1 Generelle Vergleichskriterien .........................................................................................37
5.1.1 Größe und Anzahl ....................................................................................................37
5.1.2 Strukturiertheit..........................................................................................................40
5.1.3 Zusammensetzung ....................................................................................................44
5.2 Einflussfaktoren ..............................................................................................................46
5.2.1 Bufferpool-Management ..........................................................................................46
5.2.2 Data Sharing.............................................................................................................49
5.2.3 Zugriffsart.................................................................................................................51
5.2.4 Transaktionslänge.....................................................................................................53
5.3 Verfahrensweise zur Messdatenerhebung.......................................................................56
5.4 Schwankungen und Diskrepanzen ..................................................................................61
6
Migration und Parsen ..........................................................................................................64
6.1 Analyse der INSERT-Performance im Migrationsfall....................................................66
6.1.1 „Einfaches Kopieren“...............................................................................................67
6.1.2 Konkatenation ..........................................................................................................72
6.1.3 Unicode-Konvertierung............................................................................................77
6.1.4 XML-Parsen der Dokumente ...................................................................................81
6.1.5 Zusammenfassung und Verteilung der Kosten.........................................................87
6.2 Analyse der INSERT-Performance bei Neueinfügungen ...............................................90
6.3 Pflege von User-Defined-XML-Indexen ........................................................................92
6.4 Exkurs: UPDATE von XML-Dokumenten.....................................................................96
7
XML-Schema-Management................................................................................................99
7.1 Integrität der Daten .......................................................................................................100
7.1.1 Dokumentstruktur...................................................................................................101
7.1.2 Werteintegrität........................................................................................................103
7.1.3 Entitätsintegrität .....................................................................................................105
7.1.4 Referentielle Integrität............................................................................................107
7.2 Anforderungen an das XML-Schema-Management .....................................................108
7.2.1 Verknüpfung von XML-Dokument und XML-Schema.........................................109
7.2.2 Transparenz zur Anwendung..................................................................................110
7.2.3 Umgang mit ungültigen XML-Dokumenten ..........................................................111
7.2.4 Auskunft über Gültigkeit von XML-Dokumenten .................................................112
7.2.5 Nachträgliche Schemavalidierung..........................................................................113
7.2.6 Unterstützung bei Schemaevolution und nachträgliche Validierung .....................113
7.3 XML-Schema-Management in DB2.............................................................................115
7.3.1 Umsetzung der Anforderungen ..............................................................................117
7.3.2 Performance der Schemavalidierung......................................................................121
7.4 Alternative Konzepte ....................................................................................................126
7.4.1 DTD........................................................................................................................126
7.4.2 RELAX NG............................................................................................................128
7.4.3 Schematron.............................................................................................................129
8
Query Performance ...........................................................................................................130
8.1 Performance-relevante Aspekte ....................................................................................130
8.1.1 XML-Indexe...........................................................................................................131
8.1.2 Statistiken zu XML-Daten......................................................................................134
8.1.3 Zugriffspläne ..........................................................................................................136
8.2 Analyse der Query Performance...................................................................................139
8.2.1 Komplettzugriff ......................................................................................................141
8.2.2 Indexunterstützter Zugriff ......................................................................................145
8.2.3 Selektiver Zugriff ...................................................................................................149
8.2.4 Komplexe Prädikate ...............................................................................................153
9
Zusammenfassung und Bewertung von DB2....................................................................158
10
Schlussbetrachtung............................................................................................................163
Abkürzungs- und Begriffsverzeichnis .......................................................................................165
Abbildungsverzeichnis...............................................................................................................174
Literaturverzeichnis ...................................................................................................................177
Anhang.......................................................................................................................................188
1 Einleitung
1 Einleitung
Das aktuelle Kapitel führt in die Thematik der vorliegenden, in der DATEV erstellten Diplomarbeit ein. Dazu folgt auf eine einleitende Motivation ein Einstiegsbeispiel, durch das die
Bedeutung der hier behandelten Themenschwerpunkte aufgezeigt werden soll. Anknüpfend
daran wird die Gliederung der Arbeit näher erläutert.
1.1
Motivation
Die Extensible Markup Language (XML) [W3C08, W3C06b] wurde 1998 von dem W3CConsortium [W3C11] verabschiedet und entwickelte sich anschließend zum De-facto-Standard
für den Austausch von (semi-)strukturierten Daten. Nachdem sich die Auszeichnungssprache
XML in den vergangenen Jahren zunehmend weiter etabliert hatte, hielt sie auch Einzug in
den Datenbanksektor. In diesem Zusammenhang erfolgte sowohl die Entwicklung dedizierter
XML-Datenbankmanagementsysteme, beginnend schon vor ungefähr zehn Jahren, als auch die
Erweiterung bereits bestehender relationaler Systeme (Oracle [Ora11b], DB2 [IBM11x], SQL
Server [Mic11] und andere), um die Fähigkeit XML-Strukturen verwalten zu können. Ein
Vertreter der zuletzt genannten Kategorie ist das in der vorliegenden Arbeit betrachtete, von
IBM [IBM11e] vertriebene DB2 for z/OS Version 9 [IBM11o].
Die XML-Unterstützung entwickelte sich in DB2 for z/OS in zwei Stufen. Während die
ersten Bestrebungen der datenbankseitigen Speicherung von XML-Daten ab 2001 mit dem
XML-Extender [IBM04b] aufkamen, wurden diese mit der in DB2 for z/OS Version 9
implementierten pureXML-Technologie1 [IBM11w] wesentlich ausgeweitet. Der XMLExtender ist dabei der Form der nicht-nativen XML-Speicherung zuzuordnen. Er ermöglicht die
Ablage von XML-Daten auf zwei Möglichkeiten – entweder durch die definierte Dekomposition
zu relationalen Daten („xml collection“) oder durch die Deklaration eines benutzerdefinierten
Datentyps („xml column“) [IBM04b]. Beide Varianten haben verschiedene Vor- und Nachteile,
unterstützen aber unabhängig von diesen nur gewisse XML-spezifische Funktionalitäten.
1
Die pureXML-Technologie beschränkt sich nicht nur auf DB2 for z/OS, sondern ist auch für die Pro-
duktlinie DB2 for LUW implementiert worden.
8
1 Einleitung
Generell gilt, dass der XML-Extender nicht für den Einsatz in einer „Data Sharing“-Umgebung
[IBM06a] geeignet ist. Da er aufgrund dieser Eigenschaft keine Verwendung in der DATEV eG2
[DAT11e] fand, wird er auch von den in dieser Arbeit durchgeführten Betrachtungen gänzlich
ausgeschlossen [IBM06a].
Stattdessen erfolgt in der vorliegenden Arbeit die Untersuchung der in DB2 for z/OS Version 9
neuartigen pureXML-Technologie und der damit verbundenen Möglichkeit, XML-Daten auf
native Weise datenbankseitig abzuspeichern. Demgegenüber findet in der DATEV momentan
(noch) die nicht-native Speicherung von XML-Daten als einfache Textdokumente in Form des
CLOB- oder VARCHAR-Datentyps statt. Da die native XML-Speicherung im Vergleich zur
nicht-nativen Datenablage viele Vorzüge verspricht, besteht in der DATEV die Anforderung,
den potentiellen Mehrwert dieser Art der XML-Speicherung zu untersuchen. Dahingehend sind
in [Koc11] bereits aus struktureller Sicht diverse Vorbetrachtungen getätigt und Migrationsmöglichkeiten für nicht-native XML-Daten in die native Ablageform aufgezeigt worden. Im
Fokus dieser Arbeit steht die Betrachtung von verschiedenen Anwendungsszenarien, in denen
der Einsatz der pureXML-Technologie gegenüber den bisherigen nicht-nativen XML-Speicherformen sowohl funktional als auch bezüglich der Performance nutzbare Vorteile bietet. Im
Speziellen werden dabei die folgenden Ziele im Kontext von DB2 for z/OS verfolgt.
Performance-Analyse des in [Koc11] erarbeiteten Migrationskonzepts, insbesondere
der Performance-Evaluierung des XML-Parse-Prozesses
Anforderungs- und Performance-Analyse des Schema-Managements
Performance-Analyse der Möglichkeiten des effizienten Datenzugriffs anhand ausgewählter Szenarien
Generell lässt sich hinsichtlich der aufgeführten Themenschwerpunkte erwähnen, dass bereits
IBM selbst diverse Performance-Analysen zur nativen XML-Verarbeitung und -Speicherung in
DB2 for z/OS veröffentlicht hat. Diese sind jedoch bezogen auf die speziellen Anforderungen
der DATEV aus verschiedenen Gründen zu erweitern/verfeinern. Genauere Details dazu finden
sich in Kapitel 4 der vorliegenden Arbeit.
An dieser Stelle sei analog zu [Koc11] folgende abschließende Anmerkung angeführt. Da die
Ausgangssituation in DB2 for z/OS bei der DATEV durch das Vorhandensein von (nicht-nativ)
relational gespeicherten XML-Dokumenten gekennzeichnet ist, wird von einer relationalen
2
fortan auch verkürzt als DATEV bezeichnet
9
1 Einleitung
Speicherung der XML-Inhalte weiterhin ausgegangen. Eine Gegenüberstellung von (rein)
relationaler Datenspeicherung und XML-Speicherung erfolgt nicht. Auch in bestimmten
Szenarien durchaus sinnvolle Mischformen aus relationaler und XML-Speicherung sollen hier
nicht diskutiert werden. Die gestellten Ziele beziehen sich in ihrem vollen Umfang stets auf den
direkten Performance-Vergleich von nicht-nativen und nativen XML-Speicherformen in DB2
for z/OS. Die einzige Ausnahme dazu stellt lediglich die Untersuchung zum Thema XMLSchema-Management dar, da diese Funktionalität für die hier betrachteten nicht-nativen
XML-Speicherformen nicht besteht.
1.2
Einstiegsbeispiel
Die Ausführungen dieses Abschnitts sollen dazu dienen, an einem kompakten Einstiegsbeispiel
die Bedeutung und Notwendigkeit der in der vorliegenden Arbeit betrachteten Themenschwerpunkte aufzuzeigen. Dazu sei eine Anwendung angenommen, die zum aktuellen Zeitpunkt
XML-Daten nicht-nativ in Form von CLOB-Dokumenten speichert und gezielt anwendungsseitig auswertet. Mehrere solcher Anwendungen existieren derart in der DATEV.
Aufgrund der durch die Anwendung datenbankseitig verwendeten nicht-nativen XML-Speicherform werden XML-Dokumente stets komplett (als Ganzes) in DB2 for z/OS eingefügt und
ebenso aus jenem Datenbankmanagementsystem wieder komplett ausgelesen. XML-spezifische
Funktionalitäten wie beispielsweise die XML-Schemavalidierung oder der selektive Datenzugriff sind nur anwendungsseitig realisierbar und finden dementsprechend auch anwendungsseitig statt. Zuvor müssen jedoch die nicht-nativ gespeicherten XML-Dokumente stets in der
Anwendung mithilfe eines speziellen XML-Parsers in das XML-Format transformiert werden.
Obwohl die hier betrachtete (Beispiel-)Anwendung nur gezielte Informationen aus den in
DB2 for z/OS abgelegten XML-Daten benötigt, ist es für den Datenzugriff trotzdem zwingend
erforderlich, die kompletten XML-Dokumente auszulesen und anschließend zu parsen. Aus
dieser Vorgehensweise resultiert ein (zu) hoher Aufwand, der für jeden weiteren Datenzugriff
auf die datenbankseitig gespeicherten XML-Dokumente zu wiederholen ist. Demzufolge besteht
hier erheblicher Optimierungsbedarf.
Bezogen auf die oben beschriebene Anwendung sind diverse Vorteile durch die pureXMLTechnologie denkbar. Zum einen wäre es mit dieser möglich, einzelne Dokumentteile gezielt
10
1 Einleitung
und indexunterstützt aus DB2 for z/OS auszulesen (siehe Kapitel 8). Dementsprechend müssten
anwendungsseitig nicht mehr die kompletten XML-Dokumente geparst und verarbeitet werden,
sondern nur die speziell gewünschten Dokumentteile. Das wiederum hat den Vorteil, dass
sich die Performance der Anwendung verbessert, der Datenzugriff effizienter erfolgt und auch
der Kommunikationsaufwand zwischen DB2 for z/OS und der Anwendung vermindert wird.
Weiterhin könnte die zur Integritätssicherung notwendige XML-Schemavalidierung von der
Anwendung nach DB2 for z/OS verlagert werden (siehe Kapitel 7). Das würde nicht nur die
Anwendung „schlanker“ machen, sondern auch die datenbankseitig abgelegten XML-Daten an
zentraler Stelle konsistent halten.
In welcher Art und Weise und vor allem in welcher Qualität mithilfe der pureXML-Technologie
die hier angedeuteten Verbesserungen tatsächlich realisierbar sind, wird im weiteren Verlauf
der vorliegenden Arbeit geklärt. Dabei wird auch der Aufwand betrachtet, den eine zuvor
notwendige Migration der nicht-nativen Daten in die native Speicherform nach sich zieht
und vor allem wie zeitintensiv die datenbankseitig daraufhin notwendig werdenden Datenmanipulationen insbesondere des XML-Parse-Prozesses wären (siehe Kapitel 6).
1.3
Gliederung
Die Struktur dieser Arbeit leitet sich von den drei Themenkomplexen Migration und Parsen,
XML-Schema-Management und Query Performance ab. Dazu zählen auch Vor- und Nachbetrachtungen sowie eine Vorstellung des Unternehmens DATEV. Im Detail resultiert für die
abzuhandelnden Aspekte aber noch eine feinere Granularität. Der anschließende Abschnitt gibt
einen Gesamtüberblick über die inhaltlichen Schwerpunkte der einzelnen Kapitel.
Die DATEV eG (Kapitel 2)
Die vorliegende Arbeit wurde in der DATEV im Rahmen einer umfassenden Untersuchung zum nativen XML-Datentyp in DB2 for z/OS angefertigt. In Kapitel 2 erfolgt deshalb
eine kurze Vorstellung des Unternehmens. Hier wird neben allgemeinen Informationen zur
DATEV auch auf die dortigen Intentionen Bezug genommen, die zu der Auseinandersetzung
mit der XML-Thematik und demzufolge auch zur Erstellung dieser Arbeit geführt haben.
11
1 Einleitung
Die Ausführungen in diesem Teil sind eng an die Darstellungen aus der dieser Arbeit vorangehenden Studienarbeit [Koc11] angelehnt.
Grundlagen (Kapitel 3)
In Kapitel 3 werden grundlegende Begrifflichkeiten und Sachverhalte wie die Auszeichnungssprache XML, Details zur DB2-Infrastruktur der DATEV sowie nähere Informationen zu
den Performance-relevanten Messzeiten und den verwendeten Tools ausführlich beschrieben.
Da sich auch hier thematische Parallelen zur Studienarbeit [Koc11] ergeben, werden die
dortigen Ausführungen in der vorliegenden Diplomarbeit an passender Stelle aufgegriffen und
mit Zusatzinformationen erweitert beziehungsweise aktualisiert.
Aktueller Kenntnisstand zu Performance-Kennzahlen (Kapitel 4)
Zum momentanen Zeitpunkt existieren keine Veröffentlichungen zu PerformanceAnalysen, die dem Detailgrad der in dieser Arbeit durchgeführten, an die DATEV-Spezifika
angelehnten Betrachtungen zu den Bereichen Migration und Parsen, XML-SchemaManagement und Query Performance entsprechen. Dennoch gibt es zahlreiche allgemein ausgelegte Veröffentlichungen von Performance-Kennzahlen. Diese sollen in Kapitel 4 aufgegliedert
und referenziert werden.
Vorbetrachtungen zur Messdatenerhebung (Kapitel 5)
Die in dieser Arbeit durchgeführten Performance-Messungen orientieren sich alle an
einem gemeinsamen (Ablauf-)Muster. Dieses soll zusammen mit den dazu nötigen Vorüberlegungen in Kapitel 5 vorgestellt werden. Hier wird auch auf die Art und Weise eingegangen,
wie die weiteren Auswertungen zu interpretieren und welche Einflussgrößen bei der Messdatenerhebung zu beachten sind.
Migration und Parsen (Kapitel 6)
Kapitel 6 behandelt den ersten großen thematischen Schwerpunkt – Migration und
Parsen. Hier wird in Anlehnung an die Betrachtungen aus [Koc11] die Performance von wesentlichen, im Rahmen einer Migration oder Neueinfügung stattfindenden Prozessen untersucht und
anhand konkreter Messreihen verifiziert. Darin eingeschlossen ist insbesondere der Aspekt der
Pflege von User-Defined-XML-Indexen. Zum Abschluss des Kapitels erfolgt noch ein Exkurs
zum Thema UPDATE von XML-Dokumenten in DB2 for z/OS.
12
1 Einleitung
XML-Schema-Management (Kapitel 7)
Genau wie im relationalen Kontext nimmt das Thema Integrität auch eine wichtige
Rolle bei der nativen datenbankseitigen Ablage von XML-Dokumenten ein. Das W3CConsortium verabschiedete zu diesem Zweck das Konzept des XML-Schemas. Kapitel 7 setzt
sich damit auseinander, betrachtet alternative Ansätze, stellt Anforderungen und prüft deren
Umsetzung in DB2 for z/OS.
Query Performance (Kapitel 8)
In Kapitel 8 erfolgt die Betrachtung des nativen XML-Datentyps anhand typischer
Performance-Aspekte. Dazu zählen Indexe, Statistiken und Zugriffspläne. Darüber hinaus findet
in diesem Kapitel eine Messdatenerhebung zu verschiedenen Testszenarien statt, anhand deren
die Effizienzvorteile beziehungsweise -defizite der nativen XML-Implementierung in DB2 for
z/OS verifiziert werden.
Zusammenfassung und Bewertung von DB2 (Kapitel 9)
Die im Rahmen der Untersuchungen zu dem nativen XML-Datentyp in DB2 for z/OS
gewonnenen Erkenntnisse werden in Kapitel 9 kompakt zusammengefasst. Neben vielen Vorzügen erfolgt hier auch die Thematisierung nachteiliger Aspekte der nativen XML-Speicherung,
sodass infolgedessen konkrete Defizite gemeinsam mit Anregungen zur Optimierung beschrieben werden.
Schlussbetrachtung (Kapitel 10)
Kapitel 10 zieht ein abschließendes Resümee zu den in dieser Arbeit gewonnenen
Erkenntnissen und gibt zudem einen Ausblick auf mögliche weitere Schritte beziehungsweise
Untersuchungen zum Thema der nativen XML-Verarbeitung in DB2 for z/OS.
Anhang
Ein wichtiger Bestandteil dieser Arbeit sind die verschiedenen Messreihen, die zur
Evaluation der Performance des nativen XML-Datentyps konzipiert und durchgeführt wurden.
Da die vollständige Darstellung der Messresultate innerhalb der jeweiligen Kapitel zu umfangreich wäre, finden sich Informationen zu den Messprozeduren, Ergebnistabellen (inklusive der
Elapsed-Zeiten) und für Kapitel 8 auch zu den Zugriffsplänen generell im Anhang der vorliegenden Arbeit.
13
2 Die DATEV eG
2 Die DATEV eG
Die DATEV eG [DAT11e] ist ein Softwarehaus und IT-Dienstleister für Steuerberater,
Wirtschaftsprüfer und Rechtsanwälte sowie deren Mandanten. In dem folgenden Kapitel soll
eine kurze Vorstellung des Unternehmens erfolgen.
2.1
Eingetragene Genossenschaft
Bei der Organisationsform der DATEV handelt es sich um eine eingetragene Genossenschaft.
Als solche ist sie nicht auf die Maximierung der eigenen Gewinne ausgerichtet. Vielmehr steht
das Wohl der Genossenschaftsmitglieder im Vordergrund. Demnach zeichnet sich eine erfolgreiche Genossenschaft nicht durch ihren eigenen Erfolg aus, sondern durch den ihrer Mitglieder.
Im Fall der DATEV sind dies Steuerberater, Wirtschaftsprüfer und Rechtsanwälte. [DAT11a]
2.2
Daten und Fakten
Die DATEV wurde 1966 von 65 Steuerbevollmächtigten, darunter Heinz Sebiger3, in Nürnberg
gegründet [DAT11h]. Dort befindet sich auch heute noch der Hauptsitz der Genossenschaft.
Bundesweit zählt die DATEV 25 Niederlassungen, mehr als 5.800 Mitarbeiter und über 39.000
Mitglieder [DAT11b]. Seit 1996 wird sie von dem Vorstandsvorsitzenden Prof. Dieter Kempf
[DAT11d] geleitet.
2.3
Portfolio
Das Leistungsspektrum der DATEV umfasst Software für verschiedene Bereiche wie
Rechnungswesen, Personalwirtschaft, betriebswirtschaftliche Beratung, Steuerberechnung und
Organisation von Unternehmen und Kanzleien. Zusätzlich bietet die Genossenschaft ihren
3
bis 1996 Vorstandsvorsitzender der DATEV
14
2 Die DATEV eG
Mitgliedern noch weitere Leistungen, wie Möglichkeiten des IT-Outsourcing [DAT11f]
(beispielsweise in Form von DATEVasp [DAT11g]) oder die Nutzung des hauseigenen Druckund Versandzentrums. Ebenso zählen vielfältige Fortbildungs- und Informationsangebote zu
Gesetzesänderungen, Programmhandling, Betriebswirtschaft oder Qualitätssicherung zum
Portfolio der DATEV. Alle genannten Leistungen unterstehen den höchsten Datenschutz- und
Datensicherheitsanforderungen. [DAT11c]
2.4
Hintergrund der XML-Untersuchung
In der DATEV sind verschiedene Datenbankmanagementsysteme im Einsatz. Eine zentrale
Rolle nimmt dabei IBM DB2 for z/OS ein, das aktuell in Version 9.1 („new-function mode“)
eingesetzt wird. DB2 for z/OS ist auf zwei Mainframes der jüngsten z196-Generation
[DAT11h] installiert, die als zentrale Daten- und Anwendungsserver dienen [DAT10].
Die Zuständigkeit für DB2 for z/OS liegt in der Abteilung Datenbanken. Die dortige Ausrichtung orientiert sich stets an den aktuellen Möglichkeiten im Datenbankmanagementsystem.
Daher trat auch die XML-Thematik in der vergangenen Zeit vermehrt in den Fokus der Betrachtung. Ausschlaggebend dafür ist aber vor allem auch die Tatsache, dass bereits seit längerer Zeit
diverse XML-Daten verschiedener Projektanwendungen auf nicht-native Art in DB2 for z/OS
gespeichert und verarbeitet werden.
Durch die mit DB2 for z/OS Version 9 eingeführten Möglichkeiten der pureXML-Technologie
[IBM11w] ergeben sich verschiedene Fragestellungen. Im Mittelpunkt steht dabei die Frage
nach dem Mehrwert einer möglichen nativen XML-Speicherung gegenüber den bisherigen
nicht-nativen Ablageformen. Um Antworten geben zu können, traf die DATEV den Entschluss,
sich im Rahmen einer Studienarbeit [Koc11] näher mit dem Thema der nativen XMLSpeicherung auseinanderzusetzen. Hier wurden insbesondere die internen Strukturen der nativen
XML-Speicherung in DB2 for z/OS Version 9 detailliert betrachtet, sowie Konzepte zur
Überführung von nicht-nativen Daten in den nativen XML-Datentyp entwickelt. Die daraus
gewonnenen Erkenntnisse hinsichtlich des datenbankseitigen Nutzens von nativem XML waren
durchaus positiv, sodass sich weitere Untersuchungen an diese Arbeit anschließen sollten. Dazu
zählt unter anderem die hier erbrachte Diplomarbeit. Deren Zielstellung ist es, die konkreten
15
2 Die DATEV eG
(Performance-)Vorteile der nativen XML-Speicherung in den unterschiedlichen Themenschwerpunkten
Migration und Parsen,
XML-Schema-Management und
Query Performance
herauszuarbeiten und anhand der Durchführung geeigneter Messreihen zu belegen. Für die
DATEV ist es in diesem Zusammenhang wichtig, mittels eigener Erfahrungswerte einen Überblick darüber zu bekommen, wo der Einsatz der nativen XML-Speicherung sinnvoll ist. Ebenso
soll evaluiert werden, an welchen Stellen (weiterhin) die Verwendung der bestehenden nichtnativen Strukturen effizienter ist.
16
3 Grundlagen
3 Grundlagen
Im folgenden Kapitel werden grundlegende Aspekte beschrieben, die für den weiteren Verlauf
der vorliegenden Arbeit von Bedeutung sind. Zusätzlich zu diesen Erklärungen finden sich im
Abkürzungs- und Begriffsverzeichnis allgemein gehaltene Ausführungen zu den relevanten
Begrifflichkeiten.
3.1
XML
Die Extensible Markup Language (XML) wurde 1998 durch das World Wide Web Consortium
(W3C) [W3C11] eingeführt. Dabei handelt es sich um eine Auszeichnungssprache (Markup
Language) zur Beschreibung hierarchisch strukturierter Daten. Aktuell existieren zwei Versionen der XML-Spezifikation – XML 1.0 [W3C08] und XML 1.1 [W3C06b]. Generell stellt
XML ein flexibles und universell einsetzbares Datenaustausch- und auch Datenspeicherformat
dar. Im Kern der XML-Spezifikation stehen die Konzepte XML-Dokument, XML-Schema
[W3C04a, W3C04b, W3C04c] und XML-Namespace. [Mül08]
Ein XML-Dokument ist grundlegend ein Text-Dokument, das durch diverse Auszeichnungen
(Markups) strukturiert ist. Diese werden auch als Tags bezeichnet, wobei auf jeden öffnenden
genau ein schließender Tag folgen muss. Mithilfe der Auszeichnungen lassen sich die einzelnen
Bestandteile eines XML-Dokuments voneinander separieren. Aufgrund der hierarchischen
(Baum-)Struktur der XML-Daten werden diese Bestandteile fortan auch als Knoten bezeichnet.
Ein XML-Dokument kann aus einem bis beliebig vielen Knoten zusammengesetzt sein. Dabei
ist zwischen Elementen, Attributen, Kommentaren und Verarbeitungsanweisungen zu unterscheiden. Zusätzlich können XML-Dokumente noch eine einleitende XML-Deklaration und
eine Document-Type-Definition (DTD) [W3C06b, W3C08] umfassen. [Von05]
Elemente und Attribute sind die wichtigsten Knotentypen. Ein Element wird durch die
oben genannten Tags begrenzt. Dazwischen befindet sich der Elementinhalt, der mit einem
Textknoten oder weiteren Elementen gefüllt sein kann. Leere Elemente sind ebenfalls zulässig.
Wichtig ist, dass jedes XML-Dokument genau aus einem Wurzelelement besteht, welches alle
weiteren Elemente in sich trägt. Attribute sind stets an bestimmte Elemente gebunden. Dort
17
3 Grundlagen
werden sie innerhalb des öffnenden Element-Tags deklariert. Auf die Beschreibung der weiteren
Knotentypen soll hier verzichtet und auf [Von05] verwiesen werden. [Hee02]
Bei XML-Dokumenten ist zwischen wohlgeformten und gültigen Dokumenten zu unterscheiden [Von05]. Während jedes XML-Dokument, das den in der XML-Spezifikation festgelegten Syntaxregeln4 entspricht, gleichzeitig auch ein wohlgeformtes Dokument darstellt, gilt
dies bezüglich der Gültigkeit nicht. Damit ist die Gültigkeit also „mehr“ als nur die Wohlgeformtheit.
Mithilfe der DTD oder den später in die XML-Spezifikation aufgenommenen XML-Schemas
kann die Struktur von XML-Dokumenten genauer beschrieben und damit auch integritätssteigernd eingeschränkt werden. Auf diese Weise können beispielsweise die einzelnen Elemente
und Attribute, die Reihenfolge ihres Auftretens oder auch die möglichen Werte (Wertebereiche)
vordefiniert werden. Ein XML-Dokument gilt nur dann als gültig, wenn es diesen Einschränkungen genügt. Das dazu notwendige Prüfen des Dokuments wird im Weiteren auch als
Validierung bezeichnet. Sollte weder eine DTD noch ein XML-Schema definiert sein, dann gilt
ein wohlgeformtes XML-Dokument automatisch als gültig. Abbildung 1 zeigt ein Beispiel für
ein solches wohlgeformtes Dokument. Eine ausführliche Abhandlung der genannten Konzepte
DTD und XML-Schema erfolgt zusammen mit weiteren alternativen Ansätzen in Kapitel 7.
Dabei richtet sich der Fokus primär auf die Betrachtung und DB2-seitige Evaluierung des XMLSchema-Konzepts. [Mül08]
Element (öffnender Tag)
Attribut
<seite id="seite1">
<textblock id="textblock1">
Ich bin ein Text!
</textblock>
</seite>
Elementinhalt
Element (schließender Tag)
Abbildung 1: wohlgeformtes XML-Dokument
4
Eine ausführliche Abhandlung der Syntaxregeln findet sich in [W3C06b] beziehungsweise in [W3C08].
18
3 Grundlagen
XML-Namespaces sind Namensräume, die optional für Elemente und Attribute vergeben
werden können. Sie dienen dazu, in unterschiedlichen Kontexten auftretende gleiche Elemente
und Attribute voneinander zu unterscheiden und mittels eines Uniform Resource Identifiers
(URI) [IES98] eindeutig zu identifizieren. Da XML-Namespaces für die hier erbrachte Arbeit
nicht weiter relevant sind, wird von einer detaillierten Betrachtung dieses Konzepts abgesehen
und auf [Mül08] verwiesen.
3.1.1
Nativ vs. nicht-nativ
Im Verlauf der vorliegenden Arbeit wird die Unterscheidung zwischen nativer und nicht-nativer
XML-Speicherung eine wichtige Rolle einnehmen. Um ein grundlegendes Verständnis von
diesen unterschiedlichen Speicherformen zu bekommen, sollen im Folgenden zunächst die
Begriffe „nativ“ und „nicht-nativ“ erläutert werden.
Der Wortherkunft nach bedeutet „nativ“ unter anderem „natürlich“ oder „unverändert“. Das
heißt, native XML-Daten sind natürlich und unverändert in einem hierarchischen Datenmodell
abgelegte Daten. Dabei ist ein Speicherformat vorausgesetzt, das dem Verarbeitungsformat
entspricht. Formen der einfachen Textablage von XML (beispielsweise als VARCHAR oder
CLOB) sind davon ausgeschlossen und werden als nicht-native oder auch XML-enabled
Speicherung betitelt [Päß07]. Für letztere findet daher im weiteren Verlauf der Arbeit ausschließlich der Begriff „nicht-nativ“ Verwendung.
Auf nicht-native Weise gespeicherte XML-Dokumente benötigen für die Zwecke ihrer XMLspezifischen Verarbeitung ein Mapping von dem vorliegenden (relationalen) Speichermodell
hin zu dem XML-Datenmodell [Päß07]. Dazu existiert zum einen die Möglichkeit der XMLDekomposition5 [NK09]. Mit deren Hilfe ist es möglich, XML-Dokumente zur nichtnativen XML-Speicherung datenbankseitig in relationale Strukturen zu zerlegen. Da diese
Funktionalität aber in der DATEV derzeit keine Anwendung findet (und zudem PerformanceNachteile mit sich bringen kann), soll sie auch in den folgenden Ausführungen nicht weiter
betrachtet werden.
5
Das Pendant zur Dekomposition ist das Publishing [NK09], bei dem relationale Daten zu XML-Doku-
menten zusammengesetzt werden.
19
3 Grundlagen
Gemäß den Ausführungen aus [Koc11] sind XML-Daten in der DATEV momentan primär
nicht-nativ in Form von CLOB- und VARCHAR-Dokumenten (in der EBCDIC-Codepage) in
DB2 for z/OS abgelegt. Dementsprechend ergibt sich das oben erwähnte Mapping von den
genannten nicht-nativen Ablageformen in die native Form im Wesentlichen durch ein notwendiges XML-Parsen der nicht-nativ gespeicherten Dokumente. Auf diesen XML-ParseProzess wird im folgenden Abschnitt 3.1.2 näher eingegangen.
Die native XML-Speicherform verspricht durch ihre „natürliche“ Art der Datenablage gegenüber der nicht-nativen Variante viele Vorteile. Da eine theoretische Betrachtung hierzu bereits
in [Koc11] vorgenommen wurde, konzentrieren sich die Ausführungen der vorliegenden Arbeit
auf eine Performance-Untersuchung der nativen XML-Speicherung in Relation zur nichtnativen Ablage. Detaillierte Betrachtungen zu den Strukturen der dabei miteinander verglichenen nativen und nicht-nativen Formen der XML-Speicherung als XML-, CLOBoder VARCHAR-Dokument finden sich ebenfalls in [Koc11] und werden im Verlauf der
vorliegenden Arbeit an geeigneter Stelle aufgegriffen.
3.1.2
XML-Parsen und XML-Serialisieren
In engem Zusammenhang mit den im vorangehenden Abschnitt beschriebenen Begriffen nativ
und nicht-nativ stehen die Prozesse XML-Parsen und XML-Serialisieren. Diese ermöglichen es
zum einen, nicht-native XML-Dokumente in die native Form zu überführen (XML-Parsen).
Umgekehrt lassen sich mit ihrer Hilfe auch native XML-Dokumente wieder in die nicht-native
Form transformieren (XML-Serialisieren). Abbildung 2 veranschaulicht die angesprochenen
Verfahren an einem Beispiel.
20
3 Grundlagen
XML-Parsen
nicht-natives
XML-Dokument
natives
XML-Dokument
<seite id="seite1">
<textblock id="textblock1">
Ich bin ein Text!
</textblock>
</seite>
<seite id="seite1"><t
extblock id="textbloc
k1">Ich bin ein Text!
</textblock></seite>
XML-Serialisieren
Abbildung 2: Beispiel für XML-Parsen und XML-Serialisieren
Die Prozesse XML-Parsen und XML-Serialisieren – fortan auch verkürzt als Parsen und Serialisieren bezeichnet – sind Kernfunktionalitäten im Rahmen der (nativen) XML-Verarbeitung. Das
bedeutet, dass alle aus einer externen Anwendung in DB2 for z/OS nativ einzufügenden XMLDokumente während ihres INSERTs zu parsen sind. Da native XML-Dokumente „DB2 for
z/OS“-intern binär gespeichert sind [Koc11], ist auf der anderen Seite bei jedem anschließenden
Auslesen der Daten aus dem Datenbankmanagementsystem zwingend ein Serialisierungsprozess erforderlich. Beide Prozesse finden aber auch an anderer Stelle, wie beispielsweise innerhalb der in Kapitel 7 beschriebenen Verfahren zur Schemavalidierung, Anwendung.
In DB2 for z/OS sind die beiden beschriebenen Funktionalitäten XML-Parsen und -Serialisieren
in Form der gleichnamigen skalaren Funktionen XMLPARSE und XMLSERIALIZE umgesetzt
worden. Details zu deren Syntax finden sich in [IBM11a] und sollen hier nicht näher betrachtet
werden. Stattdessen wird in den weiteren Ausführungen auf die für diese Arbeit relevanten
Besonderheiten der Funktionen näher eingegangen.
Allgemein lässt sich formulieren, dass die native XML-Speicherung in DB2 for z/OS transparent zu externen Anwendungen implementiert ist. Sämtliche zur nativen XML-Speicherung
benötigten Strukturen werden vom Datenbankmanagementsystem selbst verwaltet und bleiben
durch geeignete Mechanismen extern verborgen (Details siehe [Koc11]). Auch die Funktionen
XML-Parsen und XML-Serialisieren werden implizit benutzt, sofern eine Transformation von
XML-Dokumenten durch eine SQL-Verarbeitung notwendig ist und nicht explizit vom Anwender durch die entsprechenden Funktionsaufrufe veranlasst wird. Durch diese Sachverhalte wird
21
3 Grundlagen
eine umfassende Transparenz der nativen XML-Speicherung erreicht, was vor allem in Migrationsszenarien – Details dazu siehe [Koc11] – viele Vorteile mit sich bringt.
Die XMLPARSE-Funktion nutzt zum Parsen von XML-Dokumenten die z/OS XML System
Services [IBM09c], die das validierende und das nicht-validierende XML-Parsen unterstützen.
Bereits an dieser Tatsache lässt sich erkennen, dass zwischen dem Prozess des Parsens und dem
der Validierung ein enger Zusammenhang besteht, auf den in Kapitel 7 näher eingegangen wird.
Eine wichtige Eigenschaft der XMLPARSE-Funktion besteht in der Art und Weise, wie mit
so genanntem Whitespace umgegangen werden soll. Damit sind Formatierungszeichen wie
beispielsweise Leerzeichen gemeint, die sich zwischen Elementen ohne darin (direkt) enthaltene
Textknoten befinden (siehe Abbildung 3). Dieser Whitespace hat demnach keine inhaltliche
Bedeutung für ein XML-Dokument und dient nur dessen besserer Lesbarkeit durch den Anwender. Die XMLPARSE-Funktion ermöglicht hier zwei Alternativen. Mithilfe der Option
STRIP WHITESPACE lässt sich Whitespace beim Parsen entfernen oder per PRESERVE
WHITESPACE beibehalten. Die Variante STRIP WHITESPACE ist dabei der Default-Wert
und wird aus diesem Grund auch für die weiteren Betrachtungen der vorliegenden Arbeit verwendet.
XML-Dokument mit
Whitespace
XML-Dokument ohne
Whitespace
<seite id="seite1">
<textblock id="textblock1">
Ich bin ein Text!
</textblock>
</seite>
<seite id="seite1"><textbloc
k id="textblock1">Ich bin ei
n Text!</textblock></seite>
Abbildung 3: Whitespace in XML-Dokumenten
Für die XMLSERIALIZE-Funktion lassen sich derartige Besonderheiten nicht aufführen. Sie
ermöglicht es, die nativen XML-Dokumente entweder in einen Binary-String [IBM11a] oder in
einen Character-String [IBM11a], wie beispielsweise ein CLOB-Dokument, zu transformieren.
Dabei lässt sich lediglich der genaue Zieldatentyp bestimmen und ob das resultierende, serialisierte XML-Dokument über eine XML-Deklaration verfügen soll oder nicht. Per Default wird
auf das Hinzufügen der XML-Deklaration verzichtet. Daran orientieren sich auch die weiteren
Ausführungen dieser Arbeit.
22
3 Grundlagen
Aufgrund der bereits angesprochenen großen Bedeutung der beiden Funktionen XMLPARSE
und XMLSERIALIZE für die Verarbeitung von XML-Daten werden diese in der vorliegenden
Arbeit ebenfalls hinsichtlich ihrer Performance untersucht. Zur XMLPARSE-Funktion
finden sich in Abschnitt 6.1.4 verschiedene Messreihen zu diversen Vergleichskriterien (siehe
Abschnitt 5.1). Die Effizienz der XMLSERIALIZE-Funktion wird in Zusammenhang mit den
Ausführungen in Abschnitt 8.2 betrachtet.
3.1.3
XPath
Die XML Path Language (XPath) [W3C99] ist eine 1999 in Version 1.0 vom W3C-Consortium
verabschiedete Abfragesprache für XML-Dokumente. Sie orientiert sich an der baumartigen
Struktur der XML-Dokumente und verwendet XPath-Ausdrücke zur Adressierung einzelner
(Baum-)Knoten. Die wichtigste Form eines XPath-Ausdrucks ist der Lokalisierungspfad, der
sich aus verschiedenen durch „/“ getrennte Lokalisierungsschritten zusammensetzt. Diese
wiederum bestehen aus je
einer Achse,
einem Knotentest und
optional aus beliebig vielen Prädikaten. [W3C99]
Mithilfe der Achsendefinition lässt sich auf unterschiedliche Weise durch die einzelnen Knoten
eines XML-Dokuments navigieren [W3C99]. Dazu stehen verschiedene Möglichkeiten zur
Verfügung, von denen in Abbildung 4 nur ein für diese Arbeit wesentlicher Auszug vorgestellt
wird.
Achse
Beschreibung
/
Selektiert von dem Wurzelknoten ausgehend
//
Selektiert alle Knoten des Dokuments, die der weiteren Selektion
entsprechen, egal wo sie sich befinden
.
Selektiert den aktuellen Knoten
..
Selektiert den Elternknoten des aktuellen Knotens
@
Selektiert einen Attributknoten
Abbildung 4: Beschreibung wesentlicher XPath-Ausdrücke [W3S11b]
23
3 Grundlagen
Durch einen Knotentest können abhängig von der Achsendefinition die gesuchten Elemente
noch näher beschrieben werden. Die einfachste Form ist dabei die Angabe eines Knotennamens.
Wird ein solcher verwendet, dann wird innerhalb der Knotenmenge, die sich durch die aktuelle
Achsendefinition ergibt, nach Knoten gesucht, die exakt diesen Namen besitzen. Das Resultat
ist entsprechend eine spezielle Knotenteilmenge. [W3C99]
Prädikate, fortan auch Filterprädikate genannt, erlauben es, die durch die Achsendefinition
und den Knotentest resultierende Knotenteilmenge weiter einzuschränken. Dazu lassen sich
innerhalb von eckigen Klammern „[“ und „]“ nahezu beliebige XPath-Ausdrücke verwenden,
die insbesondere Operatoren wie beispielsweise die in dieser Arbeit verwendeten AND- und
OR-Operatoren enthalten können. [W3C99]
Nähere Details zur XPath-Spezifikation sind für die folgenden Ausführungen dieser Arbeit nicht
wesentlich und sollen daher nicht diskutiert werden. Weiterführende Informationen finden sich
in [W3C99].
Mittlerweile existieren verschiedene auf der Abfragesprache XPath 1.0 aufbauende Standards,
wie beispielsweise die Spezifikationen XPath 2.0 [W3C10b] oder XQuery 1.0 [W3C10c]. DB2
for z/OS Version 9 unterstützt im Gegensatz zu der Produktlinie DB2 for LUW6 keine der
genannten Erweiterungen. Jedoch orientiert sich die dortige Umsetzung der „XPath 1.0“Spezifikation bereits am Datenmodell und Typsystem der Spezifikationen XPath 2.0 und
XQuery 1.0. Ausführlichere Informationen dazu liefert [IBM10e].
3.2
DB2-Infrastruktur in der DATEV
DB2 for z/OS ist das zentralste Datenbankmanagementsystem in der IT-Landschaft7 der
DATEV. Die Installation dort umfasst mehrere Data Sharing Groups (siehe Abschnitt 5.2.2),
sodass mit zunehmend produktiverem Charakter zwischen
6
DB2 for LUW bietet in Version 9 Unterstützung für die „XQuery 1.0“-Spezifikation.
7
Darüber hinaus werden in der DATEV aber auch andere Datenbankmanagementsysteme wie beispiels-
weise Microsoft SQL Server oder auch Oracle betrieben.
24
3 Grundlagen
Test,
Entwicklung,
Qualitätsmanagement und
Produktion
unterschieden wird. Die in dieser Auflistung enthaltene Entwicklungsumgebung ist auch die
Ebene, auf der die in der vorliegenden Arbeit untersuchten Performance-Messreihen durchgeführt wurden. Eine detaillierte Beschreibung der Kenndaten dieser Umgebung erfolgt in
Abschnitt 3.2.2 in speziellem Bezug zum Subsystem Mem1 und zu den Objekten, die zu den
einzelnen Messreihen verwendet wurden. Allgemein gehaltene Informationen zu DB2 for z/OS
werden in Abschnitt 3.2.1 beschrieben.
3.2.1
DB2 for z/OS
DB2 [IBM11x] ist ein von IBM entwickeltes und vertriebenes relationales Datenbankmanagementsystem, das für verschiedene Plattformen verfügbar ist. Die verbreitetsten Produktlinien sind dabei das in dieser Arbeit betrachtete DB2 for z/OS (aktuelle Version: 10) [IBM11o]
und DB2 for Linux, UNIX and Windows (DB2 for LUW, aktuelle Version: 9.7) [IBM11p]. In
seinen Ursprüngen geht DB2 auf den in den 1970er Jahren entwickelten Prototypen „System R“
[Ley11] zurück, aus dem dann SQL/DS8 als erstes relationales Produkt von IBM entstand. DB2
ist erstmalig 1983 als Datenbankmanagementsystem für das Betriebssystem Multiple Virtual
Storage (MVS) [IBM78] veröffentlicht worden. Aus diesem entwickelte sich das heutige z/OSBetriebssystem [IBM11q] der modernen IBM-Mainframe-Architektur „System z“. [Mil11]
Die umgangssprachlich auch als Dinosaurier betitelten Großrechner (Mainframes) galten lange
Zeit als vom „Aussterben“ bedroht. Aufgrund ihrer Eigenschaft, hohe Anforderungen an
Skalierbarkeit, Verfügbarkeit und Sicherheit erfüllen zu können, nehmen sie jedoch auch heute
noch eine wichtige Rolle in der IT-Landschaft zahlreicher Großunternehmen ein [Pic09]. In den
vergangenen Jahren hat sich in der Industrie sogar eine steigende Tendenz gezeigt, den Mainframe wieder vermehrt zu verwenden und die IT-Landschaft dahingehend zu konsolidieren.
IBM hat diesen Trend gefördert und investiert daher fortwährend in die Weiterentwicklung der
Plattform „System z“. DB2 for z/OS wurde und wird dabei ebenfalls permanent modernisiert
8
heute DB2 Server for VSE & VM [IBM11r]
25
3 Grundlagen
und um neue Features, wie beispielsweise die native Speicherung und Verarbeitung von XMLDaten, erweitert. Diese bildet den Kern der hier erbrachten Ausarbeitung. Im weiteren Verlauf
der Arbeit wird DB2 for z/OS verkürzt als DB2 bezeichnet. Verweise auf andere DB2Produktlinien sind dagegen explizit vermerkt. [Com07]
Wie bereits in Abschnitt 2.4 erwähnt, wird DB2 innerhalb der DATEV momentan in Version 9.1
(„new-function mode“) eingesetzt. Sofern nicht anders kenntlich gemacht, beziehen sich alle
weiteren Erwähnungen stets auf diese DB2-Version.
3.2.2
Entwicklungsumgebung
Im folgenden Abschnitt sind allgemeine Kennzahlen zu der DB2-Entwicklungsumgebung der
DATEV zusammengetragen. Dieser sind die zwei Subsysteme Mem1 und Mem29 zugeordnet.
Da die zu der vorliegenden Arbeit durchgeführten Messungen auf dem zuerst genannten System
ausgeführt wurden, beziehen sich auch die in diesem Abschnitt aufgelisteten Kenndaten auf das
System Mem1. Dabei wird einerseits auf allgemeine Informationen
zur verwendeten zSeries,
der darauf installierten Betriebssystemsversion und
dem benutzten Storage-System
eingegangen. Andererseits sollen hier aber auch die speziellen Strukturen beschrieben werden,
die mit den einzelnen Messreihen verbunden sind. Dazu zählen
die verschiedenen Tablespaces,
die Bufferpools BP4 und BP16K1
und die für das Subsystem Mem1 definierten Parameter TBSBPXML, LOBVALA, LOBVALS.
Da innerhalb der vorliegenden Arbeit zusätzliche Erklärungen zu den einzelnen Aspekten an
passender Stelle gegeben werden, erfolgt die anschließende Präsentation der Kenndaten in
stichpunktartiger Form.
9
Die Bezeichnung der DB2-Subsysteme wurde aus Datenschutzgründen verfremdet.
26
3 Grundlagen
Allgemeine Informationen
zSeries = z196 (neueste Generation) [IBM11y]
Betriebssystemversion = z/OS 1.12 [IBM10b]
Storage-System = Hitachi Data Systems (HDS) – Virtual Storage Platform (VSP) mit
12 Terabyte Speicherkapazität
Verwendete Objekte (inklusive Parametrisierung)
Tablespaces
Tablespaces der Basistabellen
STORAGEGROUP = STASPD01
LOCKSIZE = ANY
BUFFERPOOL = BP4
LOCKMAX = SYSTEM
CODED CHARACTER SET IDENTIFIER (CCSID) =
EBCDIC beziehungsweise UNICODE (nur Abschnitt 6.1.3)
LOB-Tablespaces
DATA SET SIZE (DSSIZE) = 4G
BUFFERPOOL = BP16K1
STORAGEGROUP = STASPD01
LOCKSIZE = ANY
LOCKMAX = SYSTEM
XML-Tablespaces
STORAGEGROUP = STASPD01
LOCKSIZE = ANY
BUFFERPOOL = BP4
LOCKMAX = SYSTEM
CODED CHARACTER SET IDENTIFIER (CCSID) = UNICODE
Bufferpools (Snapshot-Betrachtung bezüglich Nutzung)
BP4
USE COUNT = 547
BUFFERPOOL SIZE = 6857 (4K Pages)
BUFFERS AUTOSIZE = NO
BUFFERS ACTIVE = 6857
ALLOCATED = 6857
PAGE STEALING METHOD = LRU
VP SEQUENTIAL STEAL THRESHOLD (VPSEQT) = 80
DEFERRED WRITE THRESHOLD (DWQT) = 50
VERTICAL DEFERRED WRITE THRESHOLD (VDWQT) = 10, 0
BP16K1
USE COUNT = 11
BUFFERPOOL SIZE = 1000 (16K Pages)
BUFFERS AUTOSIZE = NO
BUFFERS ACTIVE = 1000
ALLOCATED = 1000
PAGE STEALING METHOD = LRU
VP SEQUENTIAL STEAL THRESHOLD (VPSEQT) = 80
DEFERRED WRITE THRESHOLD (DWQT) = 50
VERTICAL DEFERRED WRITE THRESHOLD (VDWQT) = 10, 0
27
3 Grundlagen
Subsystem-Parameter
TBSBPXML = BP16K1 (siehe oben)
LOBVALA = 40.960 Kilobyte
LOBVALS = 6.144 Megabyte
3.3
Performance-Zeiten: Elapsed- und CPU-Zeit
Bei der DB2-spezifischen Performance-Analyse wird auf oberster Ebene zwischen der
Response-Zeit und den von DB2 erfassten Elapsed-Zeiten unterschieden. Die Response-Zeit ist
die Zeit, die insgesamt von dem Initiieren einer gewissen Verarbeitung bis zur Präsentation des
Ergebnisses beim Nutzer vergeht. Dementsprechend umfasst sie sämtliche Kosten (Zeitanteile),
die sowohl innerhalb als auch außerhalb von DB2 entstehen. Dazu gehören insbesondere auch
die Elapsed-Zeiten. Diese lassen sich in drei Klassen unterteilen, die nun näher beschrieben
werden. [IBM00]
Class 1 Elapsed-Zeit
Die Class 1 Elapsed-Zeit, auch „Application Elapsed“-Zeit genannt, umfasst die
Zeit, die innerhalb von DB2 und im Front-End zur Abarbeitung einer speziellen
Aktion benötigt wird. Damit ist insbesondere die Class 2 Elapsed-Zeit ein Teil
der Class 1 Elapsed-Zeit.
Class 2 Elapsed-Zeit
Die Class 2 Elapsed-Zeit setzt sich aus der DB2-CPU-Zeit und der Class 3
Elapsed-Zeit zusammen. Sie beschreibt die komplette Zeit, die für die DB2interne Abarbeitung einer Aktion gebraucht wird.
Class 3 Elapsed-Zeit
Die Class 3 Elapsed-Zeit ist ein Teil der Class 2 Elapsed-Zeit und setzt sich aus
verschiedenen einzelnen Zeiten zusammen, zu denen unter anderem die Zeiten
für I/O Suspension, Lock/Latch Suspension, Asynchronous Read, Service Task
und Archive Log (Quiesce) gehören.
28
3 Grundlagen
Die betrachteten Elapsed-Zeiten sind mit ihren Anteilen und Abhängigkeiten zueinander in
Abbildung 5 veranschaulicht. In die Darstellung einbezogen ist ebenfalls die CPU-Zeit. Diese
bezeichnet die reine Rechenzeit, die auf den CPUs der zSeries zur Abarbeitung einzelner
Aktionen benötigt wird. Sie stellt die konstanteste und somit aussagekräftigste Maßzahl dar.
Deshalb liegt der Fokus der in dieser Arbeit durchgeführten Performance-Analysen primär auf
der Messdatenerhebung zur CPU-Zeit.
Abbildung 5: Klassifizierung der Elapsed-Zeiten [IBM00]
Während die Class 3 Elapsed-Zeit im Wesentlichen dazu dient, bei auftretenden PerformanceEngpässen gezielt deren Ursache ermitteln zu können, hat sich die Class 2 Elapsed-Zeit in der
Praxis als eine geeignete Maßzahl zum Einstieg in die Performance-Analyse etabliert. Deshalb
stützen sich die hier durchgeführten Untersuchungen neben der CPU-Zeit auch auf die Datenerhebung zur Class 2 Elapsed-Zeit, die weiterhin verkürzt nur als Elapsed-Zeit bezeichnet wird.
3.4
Toolumfeld
Im Rahmen der hier durchgeführten Untersuchungen sind diverse Tools eingesetzt worden.
Während sich für die meisten Tätigkeiten das IBM Data Studio [IBM11m] als geeignete (Tool-)
Umgebung auszeichnete, erwies sich der CA Detector [CAT11] für den speziellen Kontext der
Messdatenerfassung als das geeignete Werkzeug. Die genannten Tools sollen im weiteren
Verlauf des Abschnitts näher beschrieben werden. Dabei wird insbesondere auf das bis zuletzt
noch eigenständige Produkt Visual Explain [IBM11k] eingegangen, das es ermöglicht,
Zugriffspläne zu persistieren und anschließend zu visualisieren.
29
3 Grundlagen
3.4.1
IBM Data Studio
Das IBM Data Studio [IBM11m] ist ein von IBM entwickeltes und vertriebenes Datenbanktool,
das auf der Eclipse-Plattform [Ecl11] aufbaut. Es soll Entwickler und Administratoren bei der
Arbeit mit IBM-Datenbanksoftware wie beispielsweise DB2 unterstützen. Die Funktionalitäten
des IBM Data Studios lassen sich in die folgenden vier Kernbereiche einteilen [IBM12a].
Design
Entwicklung
Administration
Tuning
Bislang wurden für diese Bereiche von IBM unter anderem die Tools DB2 Control Center
[IBM11i], Optimization Service Center (OSC) [IBM11j] und Visual Explain [IBM11k] empfohlen. Mit der Einführung des IBM Data Studios galten diese als veraltet („deprecated“). Speziell
die Funktionalitäten des bis dahin eigenständigen Produkts Visual Explain sind nun offiziell
Bestandteil des IBM Data Studios. Ein großer Vorteil dieses Tools ist seine Eigenschaft, innerhalb einer Eclipse-basierten Umgebung gleichzeitig Werkzeuge zur Anwendungsentwicklung
und zur Umsetzung von Datenbankprojekten zur Verfügung zu stellen. So lassen sich zum
Beispiel Java-Applikationen parallel zu den darin eingebetteten SQL-Anfragen verwalten,
entwickeln und testen. [IBM12a]
Das IBM Data Studio gibt es in den zwei Versionen „Administration Client“ („Integrated
Development Environment (IDE)“) und „Full Client“ („Stand Alone“) [IBM11n]. Beide sind in
ihren Basisausführungen (ohne Upgrades10) kostenfrei verfügbar. Sie unterscheiden sich nur in
dem Umfang der integrierten Datenmodellierungs- und Anwendungsentwicklungsmodule.
Während die „Administration Client“-Version alle verfügbaren Basisfunktionalitäten umfasst,
ist für die „Full Client“-Version gezielt auf einzelne Module verzichtet worden [IBM11l].
In der DATEV erfolgt momentan die Untersuchung der aktuellen „Full Client“-Version 3.1 des
IBM Data Studios. Neben den verschiedenen Komponenten des Tools wird dabei auch betrachtet, für welche grundlegenden Aufgaben die Verwendung des IBM Data Studios denkbar wäre.
Im Rahmen dieser Arbeit sind dabei unter anderem die folgenden Funktionalitäten betrachtet
worden.
10
IBM Optim Query Tuner [IBM11f], Optim pureQuery Runtime [IBM10d], etc.
30
3 Grundlagen
SQL-Skripte erstellen und ausführen
Abfrage von Strukturen und Inhalten aus dem Datenbankkatalog
„Data Definition Language (DDL)“-Generierung für Datenbankobjekte
Verarbeitung clientseitiger XML-Dokumente
Erstellung von SQL-Anfragen und -Zugriffsplänen
Abfrage von Subsystem-Parametern
Als eines der (noch) wenigen Tools ist das IBM Data Studio in der Lage, mit dem nativen
XML-Datentyp in DB2 umzugehen und aus dessen Strukturen abgefragte Daten darzustellen.
Diese Eigenschaft ist der Hauptgrund, weshalb das IBM Data Studio für die Untersuchungen,
die im Rahmen der hier erbrachten Arbeit stattfanden, als Toolumgebung verwendet wurde.
3.4.2
Visual Explain
IBM Visual Explain [IBM11k] ist ein kostenfreies Tool, dessen Kernfunktionalität in der
Visualisierung von Zugriffsplänen besteht. Der Vorgang der Externalisierung von Zugriffsplaninformationen nennt sich in DB2 „Explain“. Dabei wird für ein bestimmtes SQL-Statement der
dazu vom Optimizer berechnete Zugriffsplan in einer PLAN_TABLE persistiert. Visual Explain
ist in der Lage, sowohl den Explain-Prozess anzustoßen als auch dessen Ergebnis aus der
PLAN_TABLE als Baumdiagramm zu visualisieren. Ein Beispiel für einen auf diese Weise
aufbereiteten Zugriffsplan findet sich mit zusätzlichen Informationen in Abschnitt 8.1.3. Weitere
Abbildungen folgen im Anhang zu Kapitel 8.
Neben der Fähigkeit, Zugriffpläne zu persistieren und zu visualisieren, bietet das Tool Visual
Explain unter anderem noch folgende Funktionalitäten, auf die hier aber nicht näher eingegangen und auf [Bos06] verwiesen werden soll.
Abfrage und Analyse des Dynamic Statement Cache
Abfrage und Analyse von Zugriffsplänen in Packages [IBM09d]
Abfrage von Subsystem-Parametern
Import/Export von Zugriffsplänen
Service SQL/Query Environment Capture
31
3 Grundlagen
Seit der Einführung von DB2 Version 9 gilt das eigenständige Tool Visual Explain als
„deprecated“. Dessen oben aufgeführte Funktionalitäten sind allerdings vollständig als „Visual
Explain“-Modul in das IBM Data Studio und die darauf aufbauenden Produkte Optim Query
Tuner for DB2 for z/OS und Optim Query Workload Tuner for DB2 for z/OS integriert worden.
[IBM11k]
3.4.3
CA Detector
Der CA Detector [CAT11] ist ein Tool zur Performance-Analyse für „DB2 for z/OS“Anwendungen. Mit seiner Hilfe ist es zum Beispiel möglich, die bei der Ausführung von
beliebigen SQL-Statements und Programmen tatsächlich angefallenen Kosten der CPU- und
Elapsed-Zeit (siehe Abschnitt 3.3) detailliert aufgeschlüsselt anzeigen zu lassen [CAT11]. Dabei
kann der Aufwand speziell auf der Ebene von Nutzer, Member, Prozedur oder anderen zusammengefasst ausgewiesen werden. Diese Funktionalität wurde unter anderem für die Anfertigung
der in der vorliegenden Arbeit durchgeführten Performance-Analysen verwendet. Näheres dazu
findet sich in Abschnitt 5.3.
Darüber hinaus führt der CA Detector auch Protokoll über die aufgetretenen SQLCODEs. Somit
lässt sich mithilfe dieses Tools beispielsweise bei der Ausführung bestimmter Anwendungen/Programme nachträglich eine gezielte Fehleranalyse anschließen. Alle Informationen,
die der CA Detector sowohl zur Performance- als auch zur Fehleranalyse sammelt, können
mithilfe dazu vorgesehener Export-Mechanismen in spezielle DB2-Tabellen weggeschrieben
werden. Für weitere Besonderheiten und Funktionalitäten des CA Detectors wird an dieser
Stelle auf [CAT11] verwiesen.
32
4 Aktueller Kenntnisstand zu Performance-Kennzahlen
4 Aktueller Kenntnisstand zu Performance-Kennzahlen
Eingangs dieser Arbeit ist bereits darauf eingegangen worden, dass auch IBM selbst diverse
Performance-Messungen zur pureXML-Implementierung in DB2 durchgeführt und deren
Ergebnisse veröffentlicht hat. Die wesentlichsten der dabei evaluierten Testszenarien werden
in Abschnitt 4.1 in einem Überblick mit entsprechenden Literaturquellen dargestellt. Auf
konkrete Resultate wird dabei aus Umfangsgründen verzichtet. Der Überblick beinhaltet auch
„standardisierte“ Ergebnisse, die mithilfe des TPOX-Benchmarks [NGXS11] erhoben wurden.
Dieser Benchmark wird in Abschnitt 4.2 näher betrachtet.
4.1
Veröffentlichte Messergebnisse
Aktuell existieren verschiedene Performance-Analysen von IBM zu der Implementierung der
pureXML-Technologie. Unter diesen befinden sich auch zahlreiche Untersuchungen, die sich
speziell auf die native XML-Verarbeitung und -Speicherung in DB2 for z/OS Version 9
beziehen. Der folgende Abschnitt soll einen Überblick über die analysierten Szenarien geben
und zur vertiefenden Auseinandersetzung auf die dazugehörigen Literaturquellen verweisen.
Dabei ist anzumerken, dass die von IBM durchgeführten Untersuchungen in unterschiedlichem
Umfang in diversen Publikationen veröffentlicht wurden. Die zwei umfangreichsten Quellen
bilden [IBM07] und [IBM10c], aus denen die nun folgenden Auflistungen der einzelnen
Performance-Analysen erstellt worden sind.
Manipulationen von XML-Daten
INSERT [IBM07, IBM10c]
INSERT mit Indexen [IBM07, IBM10c]
INSERT mit und INSERT ohne Schemavalidierung [IBM07]
INSERT, INSERT mit Schemavalidierung, Dekomposition [IBM07, IBM10c]
INSERT – XML, XML mit Index und CLOB [IBM10c]
UPDATE, DELETE + INSERT [IBM07]
LOAD [IBM10c]
33
4 Aktueller Kenntnisstand zu Performance-Kennzahlen
Zugriff auf XML-Daten
FETCH [IBM07, IBM10c]
Verwendung von User-Defined-XML-Indexen [IBM07, IBM10c]
User-Defined-XML-Index CREATE und REBUILD [IBM10c]
Sonstiges
Kompression (auf Tabellenebene) [IBM10c]
Kompression (per STRIP WHITESPACE) [IBM07]
TPOX-Benchmark [IBM10c]
Unterstützung z/OS-Spezialprozessor (zAAP) [IBM10c]
An dieser Stelle soll erläutert werden, weshalb trotz der zahlreichen veröffentlichten Messergebnisse im Rahmen dieser Arbeit noch weitere Performance-Analysen durchgeführt wurden.
Generell begründet sich dies durch die (zu) allgemeinen Kontexte, auf die sich die Untersuchungen von IBM beschränken. Das heißt, detaillierte Performance-Betrachtungen wie
beispielsweise
zu den einzelnen, bei der DATEV-spezifischen Migration notwendigen Prozessen,
zu dem von der indexierten Knotenanzahl abhängigen Indexpflegeaufwand
zu unterschiedlichen Konzepten zur Schemavalidierung oder
zu den Vorteilen der nativen XML-Verarbeitung hinsichtlich des Datenzugriffs
sind nicht auf eine Art und Weise veröffentlicht worden, wie es die Analysen dieser Arbeit
beabsichtigen. Ähnliches gilt auch für die hier ausführlich untersuchten Vergleichskriterien der
Strukturiertheit und der Zusammensetzung von XML-Dokumenten. Zu diesen sind ebenfalls
keine Performance-Analysen publiziert worden.
4.2
Der TPOX-Benchmark
Der Benchmark Transaction Processing over XML (TPOX) [NGXS11] wurde ursprünglich von
IBM entwickelt [Loe09]. Er zielt darauf ab, ein Instrument darzustellen, das zur PerformanceAnalyse der XML-Verarbeitung in Datenbankmanagementsystemen genutzt werden kann. Dabei
orientiert sich der TPOX-Benchmark an einem einfachen Modell einer typischen Finanzanwendung und legt seinen Schwerpunkt auf die Aspekte XQuery, SQL/XML, XML-Speicherung,
34
4 Aktueller Kenntnisstand zu Performance-Kennzahlen
XML-Indexierung, XML-Schema-Unterstützung, XML UPDATEs, Logging und Nebenläufigkeit. Zu dem Benchmark zählen die folgenden fünf Komponenten. [NGXS11]
Tools zur effizienten Generierung von wohlgeformten XML-Testdokumenten mit
dokumentübergreifender referentieller Integrität
XML-Schemas zu allen Dokumenten
Eine Sammlung von Transaktionen zu den Testdaten mit sowohl XQuery- und
SQL/XML-Abfragen als auch INSERT-, UPDATE- und DELETE-Statements
Einen Workload-Erzeuger, der in einzelnen Threads beliebig viele gleichzeitige
Nutzer simuliert, die einen Transaktionsmix aus der obigen Sammlung ausführen
Dokumentationen zu den einzelnen aufgeführten Bestandteilen
Nähere Details zu dem TPOX-Benchmark finden sich in [NGXS11]. Wie in Abschnitt 4.1
erwähnt, sind für die XML-Unterstützung von DB2 for z/OS in Version 9 bereits Messdaten
zum TPOX-Benchmark veröffentlicht worden [IBM10c]. Des Weiteren liefert ein solcher
Benchmark ebenfalls „nur“ allgemeingültige Aussagen. Aus diesen Gründen erfolgte im
Rahmen der vorliegenden Arbeit keine erneute Ausführung dieses Benchmarks innerhalb des
DATEV-Entwicklungssystems.
35
5 Vorbetrachtungen zur Messdatenerhebung
5 Vorbetrachtungen zur Messdatenerhebung
Die vorliegende Diplomarbeit betrachtet drei Themenschwerpunkte aus PerformancePerspektive:
Migration und Parsen (siehe Kapitel 6),
XML-Schema-Management (siehe Kapitel 7) und
Query Performance (siehe Kapitel 8).
Zu jedem der Bereiche sind verschiedene Messreihen durchgeführt worden, denen diverse
grundlegende Vorüberlegungen gemeinsam sind. Diese sollen in dem folgenden Kapitel zentral
gebündelt werden.
Eingangs werden in Abschnitt 5.1 die ausgewählten Vergleichskriterien für die durchgeführten
Messreihen beschrieben. Dabei handelt es sich um ein kombiniertes Kriterium der Größe und
Anzahl, um das Kriterium der Strukturiertheit und um das Kriterium der Zusammensetzung von
XML-Dokumenten. Von dieser Einteilung leitet sich auch die Auswahl der Testdaten ab, deren
Beschreibung ebenfalls in diesem Abschnitt erfolgt.
In Abschnitt 5.2 ist der Fokus auf die Einflussfaktoren gerichtet, die messreihenübergreifend
wirken. Speziell die Themen Bufferpool-Management, Data Sharing, Zugriffsart und Transaktionslänge werden dabei näher betrachtet.
Um Aussagen zu erhalten, die unabhängig von den Faktoren aus Abschnitt 5.2 sind, gilt es,
deren Einflüsse auf die Messreihen zu beseitigen. Dahingehend stellt Abschnitt 5.3 eine Verfahrensweise zur Messdatenerhebung vor, mit der der Ausschluss dieser Faktoren möglich ist
und welche dann auch für die durchgeführten Messungen genutzt wurde.
Leider ist es nicht realisierbar, die Einflüsse sämtlicher Randbedingungen zu beseitigen
beziehungsweise diese überhaupt zu erfassen. Aus diesem Grund wird in Abschnitt 5.4 auf
bekannte Schwankungen und Diskrepanzen näher eingegangen.
36
5 Vorbetrachtungen zur Messdatenerhebung
5.1
Generelle Vergleichskriterien
XML-Dokumente können sich in ihrem Aufbau voneinander in vielfältiger Weise unterscheiden. Im Wesentlichen lassen sich dabei Unterschiede in den Merkmalen Größe und
Struktur feststellen, von denen sich auch die Vergleichskriterien für die in dieser Arbeit
betrachteten Messreihen ableiten. Bei der Auswahl der Testdaten sind daher drei verschiedene
Kriterien betrachtet worden.
Größe und Anzahl
Strukturiertheit
Zusammensetzung
Während das Kriterium der Größe und Anzahl auf eine mengenmäßige Betrachtung abzielt,
steht bei der Strukturiertheit die inhaltliche Struktur im Vordergrund. Das Kriterium der
Zusammensetzung beschreibt sich als eine Art Mischform aus den beiden erstgenannten Vergleichskriterien. Nähere Details finden sich jeweils in den weiteren Abschnitten.
5.1.1
Größe und Anzahl
Die Idee des Kriteriums der Größe und Anzahl liegt darin begründet, festzustellen, ob bei
gleichem Gesamtdatenvolumen die Größe der zu verarbeitenden Dokumente einen Einfluss auf
die Performance der Verarbeitung hat. In diesem Zusammenhang sind die Faktoren Größe und
Anzahl somit voneinander abhängig. Sie müssen stets so gewählt werden, dass ein einheitliches
Gesamtdatenvolumen entsteht. Dies ist für die durchgeführten Messreihen auf 100M festgelegt
worden.
An dieser Stelle sei mit einem Einschub auf die in der vorliegenden Arbeit an die SQL-Syntax
der SQL-Reference [IBM11a] angelehnte Schreibweise der Mengenbezeichnungen verwiesen.
Entsprechend kürzen sich die einzelnen Mengenbezeichner wie folgt ab. „K“ bezeichnet Kilobyte. „M“ bezeichnet Megabyte und „G“ bezeichnet Gigabyte.
Weiterhin gilt für die folgenden Betrachtungen zu dem Kriterium der Größe und Anzahl,
dass sie die Verarbeitung von VARCHAR-, CLOB- und XML-Daten vergleichen. Die beiden
37
5 Vorbetrachtungen zur Messdatenerhebung
erstgenannten Speicherformen resultieren aus den in der DATEV verwendeten und in [Koc11]
beschriebenen Möglichkeiten der nicht-nativen XML-Speicherung.
Ausgehend von dem definierten Gesamtdatenvolumen von 100M sind für die durchgeführten
Messreihen die Merkmalsausprägungen 200B x 500.000, 1K x 100.000, 10K x 10.000, 100K x
1.000, 1M x 100 und 10M x 10 (jeweils in der Form Dokumentgröße x Dokumentanzahl)
gewählt worden. Um bereits einen Eindruck zu bekommen, inwieweit sich diese Ausprägungen
in den später folgenden Diagrammen wiederfinden und wie jene zu verstehen sind, zeigt
Abbildung 6 ein zufällig gewähltes Beispieldiagramm. Hier wird der Einfluss der Größe und
Anzahl auf die Performance des Parse-Prozesses beim INSERT gezeigt. Dabei erfolgte
beispielsweise bei dem roten Punkt ganz links gemäß der horizontalen Achse der INSERT von
insgesamt 500.000 je 200B großen XML-Dokumenten. Dieser Vorgang benötigte an CPU-Zeit
in Summe 40 Sekunden. Die weiteren Punkte zu den Merkmalsausprägungen sind analog dazu
zu verstehen. Mehr Details zu diesem Messergebnis folgen in Abschnitt 6.1.4. In Hinblick auf
die weiteren Messreihen ist zu beachten, dass nicht immer Messwerte zu allen Merkmalsausprägungen ermittelt werden können. Beispielsweise existiert für den VARCHAR-Datentyp
eine Längenbeschränkung von maximal 32K [Koc11], weshalb bei einer auf VARCHAR-Daten
basierenden Messreihe nur Messungen bis zur Ausprägung 10K x 10.000 durchgeführt werden
können. Auf weitere Einschränkungen dieser Art wird jeweils gesondert verwiesen.
140
120
Sekunden
100
80
60
ELAPSED
40
CPU
20
0
200B x
1K x
10K x
500.000 100.000 10.000
100K x
1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 6: Beispieldiagramm – Größe und Anzahl
38
5 Vorbetrachtungen zur Messdatenerhebung
Bei der Auswahl der Testdatensätze zu den oben beschriebenen Merkmalsausprägungen
konnten in allen Fällen Originaldaten11 aus der DATEV-Entwicklungsumgebung verwendet
werden. Dabei handelt es sich um Datensätze des Projekts Belegwesen. Dort werden unter
anderem Scans von Dokumenten verarbeitet, die zuvor per „Optical Character Recognition
(OCR)“-Software zu XML-Daten aufbereitet wurden. Diese XML-Dokumente sind heute als
CLOB-Daten nicht-nativ in DB2 abgespeichert. Größenmäßig betrachtet decken sie das gesamte
benötigte Spektrum von 200B bis hin zu 10M ab und gehen teilweise sogar noch darüber
hinaus. Hierbei ist allerdings zu erwähnen, dass sich unter diesen Daten keine Dokumente
befinden, die exakt den gewünschten Merkmalsausprägungen entsprechen. Daher ist für die
folgenden Tests zum Kriterium der Größe und Anzahl stets jeweils das Dokument gewählt
worden, das am ehesten einer der Ausprägungen entsprach. Die tatsächliche Abweichung von
den Richtwerten konnte dadurch in allen Fällen geringer als zwei Prozent gehalten werden, was
für die Korrektheit der Messergebnisse aufgrund der in Abschnitt 5.4 dargelegten allgemeinen
Schwankungen von fast zehn Prozent tolerierbar ist.
Um mithilfe der einzelnen ausgewählten Dokumente den gesamten Testdatenbestand zu
generieren, wurden diese bis zu der gewünschten Anzahl hin repliziert. Hinsichtlich der in
Abschnitt 8.2 durchgeführten Messungen, bei der die Selektivität der Daten von großer Bedeutung ist, wurde pro Merkmalsausprägung jeweils ein Dokument leicht verändert. Die dabei
vorgenommene Anpassung lässt sich zum Teil aus den Abfragen des Abschnitts 8.2 ableiten, ist
aber für die weitere Arbeit nicht von Bedeutung. Wichtiger ist es, ein grobes Verständnis von
dem Aufbau dieser Dokumente zu bekommen. Zur Einfachheit sei daher angenommen, dass
sich die gescannten, teils mehrseitigen Dokumente aus einer Vielzahl von Textblöcken zusammensetzen. Die verwendete OCR-Software hat diese Blöcke erkannt und mit entsprechenden
Zusatzinformationen wie beispielsweise ihrer Position, der Schriftart oder auch der Schriftgröße
des Texts und anderen Eigenschaften verarbeitet. Weiterhin sei dabei vereinfacht angenommen,
dass sich die zusätzlichen Informationen als Attribute über den Pfad „/seite/textblock@xyz“ von
der Dokumentwurzel ausgehend erreichen lassen. Abbildung 7 visualisiert den auf diese Weise
angenommenen Dokumentaufbau an einem Beispiel. Auch wenn die Struktur der Testdaten in
Wirklichkeit komplexerer Art ist, genügt die hier betrachtete Vereinfachung der Nachvollziehbarkeit und Verständlichkeit der in dieser Arbeit vorgestellten Messreihen.
11
nach erfolgter Prüfung des Datenschutzes und Bewilligung durch die verantwortlichen Anwendungs-
entwickler
39
5 Vorbetrachtungen zur Messdatenerhebung
<?xml version="1.0" encoding="UTF-8"?>
<seite id="seite1">
<textblock id="textblock1" posx="50" posy="50"
schriftart="arial" schriftgroesse="14" ...>
DATEV eG, Paumgartner Straße 6-14, 90329 Nürnberg
</textblock>
...
<textblock id="textblock10" posx="50" posy="800"
schriftart="arial" schriftgroesse="12" ...>
Mit freundlichen Grüßen
</textblock>
</seite>
Abbildung 7: Beispieldokument – Größe und Anzahl
5.1.2
Strukturiertheit
Das XML-Format ist ein hierarchisch strukturiertes Datenformat. Dementsprechend stellt jedes
wohlgeformte XML-Dokument einen Baum mit diversen Knoten dar (siehe Abschnitt 3.1).
Innerhalb von XML-Dokumenten findet die eigentliche Informationsspeicherung hauptsächlich
in den Knotentypen Attribut, Element und Text statt. Aus dieser Tatsache und der
hierarchischen Struktur der Knoten (tief, flach oder balanciert) resultieren diverse grobe
Strukturmuster, denen ein XML-Dokument entsprechen kann. Ausgehend von diesen Überlegungen erfolgt die Generierung der Testdaten für die Messreihen zu dem Kriterium der Strukturiertheit der XML-Dokumente. Im Detail ergeben sich dabei 15 verschiedene Testdatenbestände, die analog zu den Bemerkungen aus Abschnitt 5.1.1 aus einem mehrfach replizierten
Musterdokument bestehen. Genauere Details zur Struktur dieser Testdokumente werden später
in diesem Abschnitt beschrieben.
Hinter dem Vergleichskriterium der Strukturiertheit und dem dazugehörigen Testdatenbestand
verbirgt sich die Idee, den Einfluss der Strukturiertheit auf die Performance der XMLVerarbeitung zu ermitteln. Aus den Resultaten der folgenden Messungen lassen sich
anschließend teilweise Rückschlüsse und Empfehlungen für die Modellierung der Dokumente
und der dazugehörigen Schemas ableiten. Hierbei ist jedoch anzumerken, dass für die
40
5 Vorbetrachtungen zur Messdatenerhebung
XML-Modellierung bereits zahlreiche Richtlinien existieren [Ora11a, Aue10] und diese, wie
auch im relationalen Kontext, nie primär an der Performance festgemacht werden sollten.
Bereits weiter oben ist erwähnt worden, dass der Testdatenbestand auch für das hier betrachtete
Vergleichskriterium jeweils aus einem mehrfach replizierten Dokument besteht. Für jedes von
diesen ist eine Größe von stets 100K und für die Gesamtdatenmenge wiederum 100M gewählt
worden. Das entspricht also einer Anzahl von insgesamt 1.000 Dokumenten. Die Dokumentgröße von 100K bietet den Vorteil, dass sie zum einen eine aussagekräftige Basis für die Strukturiertheit der Dokumente bildet. Zum anderen entspricht diese Größe gleichzeitig dem Median
der Merkmalsausprägungen bei dem Kriterium der Größe und Anzahl (siehe Abschnitt 5.1.1).
Auf der anderen Seite schränkt die Verwendung der Dokumentgröße von 100K aber auch die
Wahl der für die Messungen betrachteten Datentypen ein. Da für den VARCHAR-Datentyp eine
Längenbeschränkung von 32K gilt [Koc11], ist dieser von den Strukturiertheitsmessungen
ausgeschlossen. Dementsprechend findet in den Messreihen der vorliegenden Arbeit lediglich
ein Vergleich von Messungen mit den Datentypen CLOB und XML statt. Dies ist aber für die
Ergebnissicherung nicht weiter hinderlich, da mit den betrachteten Datentypen bereits je ein
Vertreter für die nicht-native und für die native XML-Speicherung in DB2 berücksichtigt ist.
Die Unterschiede zwischen den Datentypen der nicht-nativen XML-Speicherung VARCHAR
und CLOB liegen allenfalls in dem Kriterium der Größe und Anzahl. Dies beweist auch die in
Abschnitt 6.1.1 durchgeführte Messreihe zur Strukturiertheit. Für eine zusätzliche Begründung
wird daher auf diesen Abschnitt verwiesen.
Da die verschiedenen Merkmalsausprägungen für das Kriterium der Strukturiertheit jeweils eine
sehr spezielle Struktur der Testdaten voraussetzen, wurden für den Aufbau der hierzu nötigen
Datenbestände künstliche Dokumente verwendet. Deren Erstellung erfolgte skriptbasiert mittels
der Java-Umgebung des Tools IBM Data Studio, über das sie auch anschließend in DB2 in
separate Tabellen (aufgrund der Merkmalsausprägungen 15 Stück) eingefügt wurden. Die
detaillierte Struktur der einzelnen Dokumente ist in Abbildung 8 zu sehen. Dabei beschreibt
„Titel“ die Bezeichnung der jeweiligen Testdatenstruktur, die sich später auch in den Diagrammen zur Messdatenauswertung wiederfindet. Die darunter abgebildete Grafik visualisiert das
jeweilige Strukturmuster der XML-Testdaten. Die Inhalte unter dem Punkt „Knoten“ geben
Aufschluss auf den konkreten Anteil an Element-, Attribut- und Textknoten im Dokument. Der
Aspekt „Struktur“ beschreibt die hierarchische Struktur der Knoten bildlich gesprochen in der
Form tief, flach oder balanciert.
41
5 Vorbetrachtungen zur Messdatenerhebung
Dokumentwurzel
Titel
Elementknoten (E)
Attributknoten (A)
Textknoten (T)
E (tief)
E (flach)
E (balanciert)
T
1 Dokumentwurzel
1 Dokumentwurzel
1 Dokumentwurzel
1 Dokumentwurzel
4.096 Elementknoten
4.096 Elementknoten
4.096 Elementknoten
1 Textknoten
tief
flach
balanciert
-
A
A, T
E, T (tief)
E, T (flach)
Grafik
Knoten
Struktur
Titel
Grafik
Knoten
Struktur
Titel
1 Dokumentwurzel
4.096 Attributknoten
1 Dokumentwurzel
1 Dokumentwurzel
1 Dokumentwurzel
2.048 Attributknoten
2.048 Elementknoten
2.048 Elementknoten
1 Textknoten
2.048 Textknoten
2.048 Textknoten
-
-
tief
flach
E, T (balanciert)
A, E (tief)
A, E (flach)
A, E (balanciert)
Grafik
Knoten
Struktur
Titel
1 Dokumentwurzel
1 Dokumentwurzel
1 Dokumentwurzel
1 Dokumentwurzel
2.048 Elementknoten
2.048 Attributknoten
2.048 Attributknoten
2.048 Attributknoten
2.048 Textknoten
2.048 Elementknoten
2.048 Elementknoten
2.048 Elementknoten
balanciert
tief
flach
-
A, E, T (tief)
A, E, T (flach)
A, E, T (balanciert)
Grafik
Knoten
Struktur
1 Dokumentwurzel
1 Dokumentwurzel
1 Dokumentwurzel
1.366 Attributknoten
1.366 Attributknoten
1.366 Attributknoten
1.366 Elementknoten
1.366 Elementknoten
1.366 Elementknoten
1.366 Textknoten
1.366 Textknoten
1.366 Textknoten
tief
flach
balanciert
Abbildung 8: Merkmalsausprägungen des Kriteriums der Strukturiertheit
42
5 Vorbetrachtungen zur Messdatenerhebung
Allgemein lassen sich noch folgende Anmerkungen zu den Merkmalsausprägungen
beziehungsweise zu der obigen Abbildung formulieren. Wenn eine Testdatenstruktur mehrere
Knotentypen kombiniert, dann ist die Informationsmenge stets so verteilt, dass diese pro
Knotentyp gleich gewichtet ist. Beispielsweise enthält daher bei der Merkmalsausprägung
„A, T“ der eine Textknoten genauso viele Informationen wie die Gesamtheit der 2.048 Attributknoten. Weiterhin ist zu erwähnen, dass die Daten der als „tief“ bezeichneten Merkmalsausprägung nicht exakt so gradlinig konstruiert sind, wie es die Grafik suggeriert. Da DB2 die
Restriktion besitzt, dass ein XML-Dokument maximal eine Tiefe von 128 Level haben kann
[IBM11a], ist es beispielsweise nicht möglich, im Fall der Ausprägung „E (tief)“ alle 1.024
Elemente wie dargestellt miteinander als lineare Liste zu verknüpfen. In einem solchen Fall ist
die tatsächliche Form der Testdaten generell so gewählt, dass sie die maximal mögliche Tiefe
auf balancierte Weise – also in Anlehnung an beispielsweise die Merkmalsausprägung
„E (balanciert)“ – ausnutzen.
Auf den ersten Blick scheint die Einteilung in fünfzehn verschiedene Testdatenbestände unvollständig, da für bestimmte Kombinationen die verschiedenen Strukturmöglichkeiten nicht
betrachtet wurden. Da aber nur Elementknoten ineinander verschachtelt werden können, sind
für die Merkmalsausprägungen
„A“ (nur Attributknoten),
„T“ (nur Textknoten) und
„A, T“ (nur Attribut- und Textknoten)
keine weiteren Variationen in der Struktur möglich.
Aus der Tatsache, dass für die Testdaten zu dem Kriterium der Strukturiertheit künstliche Daten
generiert wurden, ergibt sich eine unvermeidbare Einschränkung für die in Kapitel 8
betrachteten Szenarien. Dort wird in den Messreihen Selektiver Zugriff, Indexunterstützter
Zugriff und Komplexe Prädikate versucht, die möglichen Effizienzgewinne der nativen XMLSpeicherung an realitätsnahen und XML-spezifischen Abfragen aufzuzeigen. Die für das Kriterium der Strukturiertheit generierten Testdaten sind jedoch künstlicher Art und eignen sich
demzufolge für die erwähnten Szenarien nicht. Abgesehen davon weisen sie ihrem Zweck
entsprechend große Strukturunterschiede auf, weshalb bereits dahingehend ein Vergleich mithilfe der in den Messreihen verwendeten einheitlichen XPath-Pfadausdrücken nicht möglich wäre.
43
5 Vorbetrachtungen zur Messdatenerhebung
Im Rahmen der Messreihe „Komplettzugriff“ aus Kapitel 8 findet das Kriterium der
Strukturiertheit dagegen Anwendung. Dementsprechend werden auch für den XMLSerialisierungsprozess von der Strukturiertheit abhängige Kennzahlen ermittelt. Nähere Details
dazu finden sich in Abschnitt 8.2.1.
Zusammensetzung
5.1.3
Das Kriterium der Zusammensetzung ist vereinfacht formuliert eine Art Mischkriterium aus
dem Kriterium der Größe und Anzahl und dem der Strukturiertheit. Es dient prinzipiell dazu, zu
ermitteln, ob es effizienter ist, mehrere Entitätsausprägungen innerhalb eines XML-Dokuments
zu kumulieren oder jede Entitätsausprägung in einem einzelnen XML-Dokument zu führen.
Die erste Merkmalsausprägung und gleichzeitig die Basis für den hierbei verwendeten Testdatenbestand bildet ein 1K großes Dokument, das fortan auch Basisdokument genannt wird.
Dieses entspricht symbolisch einer Entitätsausprägung. Die nächste Ausprägung entspricht
einem 10K großen Dokument, das durch das Kumulieren des Basisdokuments mit neun
weiteren jeweils 1K großen XML-Dokumenten entsteht. Diese Dokumente müssen dabei ebenfalls eine Entitätsausprägung beschreiben, die von der gleichen Entität abgeleitet ist, wie auch
das Basisdokument. Da aber davon auszugehen ist, dass zwischen zwei Ausprägungen einer
Entität eine große Ähnlichkeit besteht, wird der Einfachheit halber das Basisdokument auch für
die neun weiteren Dokumente verwendet. Die nächste Merkmalsausprägung bildet dann analog
zu dem Messkriterium der Größe und Anzahl ein 100K großes Dokument, das sich dann aus
insgesamt 100 Einzeldokumenten der Größe 1K zusammensetzt. Auf die gleiche Weise
definieren sich auch die folgenden Ausprägungen in 10er-Potenzen bis zur Merkmalsausprägung von 10M (siehe Abbildung 9).
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
1K
…
1K
…
1K
…
1K
1K
10 x 1K
10K
100 x 1K
100K
1.000 x 1K
1M
Abbildung 9: Merkmalsausprägungen des Kriteriums der Zusammensetzung
44
10.000 x 1K
10M
5 Vorbetrachtungen zur Messdatenerhebung
In weiterer Analogie zum Kriterium der Größe und Anzahl wurde auch das Gesamtdatenvolumen für die jeweiligen Merkmalsausprägungen stets auf 100M fixiert. Dementsprechend
müssen für die weiteren Messreihen die einzelnen Dokumente abhängig von ihrer Größe so oft
repliziert werden, bis die gesamte Datenmenge in jeder Ausprägung dem genannten Gesamtdatenvolumen entspricht.
Bei dem Kriterium der Zusammensetzung handelt es sich, wie bereits eingangs dieses
Abschnitts erwähnt, um eine Art Mischkriterium aus dem Kriterium der Größe und Anzahl und
dem der Strukturiertheit. Die Parallelen zu dem Kriterium der Größe und Anzahl (siehe
Abschnitt 5.1.1) sind bereits durch die weiter oben angefügten Bemerkungen aufgezeigt worden.
Hierbei ist noch anzumerken, dass das gewählte Basisdokument demselben Dokument
entspricht, das auch bei dem Kriterium der Größe und Anzahl für die Merkmalsausprägung 1K
verwendet wurde. Somit handelt es sich bei dem für das Kriterium der Strukturiertheit verwendeten Testdatenbestand ebenfalls um realitätsnahe Daten aus der Entwicklungsumgebung.
Weiterhin ist noch der Zusammenhang mit dem Kriterium der Strukturiertheit (siehe
Abschnitt 5.1.2) zu erklären. Durch das wiederholte Kumulieren von einer wachsenden Anzahl
von jeweils 1K großen Dokumenten entstehen neue XML-Dokumente, die im Wesentlichen in
ihrer Baumstruktur nur in der Breite wachsen. Dies lässt sich auch anhand der in Abbildung 9
grafisch dargestellten Zusammensetzung der kumulierten Dokumente erkennen. Verglichen mit
dem Basisdokument besitzen die kumulierten Dokumente (10K, 100K, 1M und 10M) in
Relation zu ihrer Größe eine zunehmend flachere Struktur. Da eine detaillierte Untersuchung
der verschiedensten Strukturmuster bereits mit dem Kriterium der Strukturiertheit erfolgt, zeigt
sich durch diese Abflachung der Zusammenhang des Kriteriums der Zusammensetzung zu dem
der Strukturiertheit.
Im weiteren Verlauf der Arbeit wird sich die offensichtliche Annahme bestätigen (siehe
Abschnitt 6.1.1), dass die Strukturiertheit von XML-Dokumenten keinen Einfluss auf die
Performance der nicht-nativen Verarbeitung dieser Dokumente hat. Daher werden bezüglich des
Kriteriums der Zusammensetzung nur Messreihen unter Berücksichtigung der nativen
XML-Verarbeitung detailliert betrachtet. Darin eingeschlossen ist somit auch die Analyse der
Performance des XML-Parse-Prozesses (siehe Abschnitt 6.1.4).
45
5 Vorbetrachtungen zur Messdatenerhebung
5.2
Einflussfaktoren
Durch vielfältige Technologien und dazugehörige Mechanismen ist DB2 ein komplexes und
zugleich mächtiges Datenbankmanagementsystem. Dem geschuldet ist jedoch beispielsweise
auch eine erhöhte Sorgfalt, mit der unter anderem Messungen erhoben und ausgewertet werden
müssen. Dies gilt auch für die in dieser Arbeit erbrachten Messreihen zum Aspekt Performance.
Durch die Komplexität von DB2 ergeben sich verschiedene Einflussgrößen und Randbedingungen, die auf die Messungen einwirken. Dabei lassen sich im Wesentlichen die Faktoren
Bufferpool-Management,
Data Sharing,
Zugriffsart und
Transaktionslänge
benennen, die in den weiteren Abschnitten näher beschrieben werden.
5.2.1
Bufferpool-Management
Ein zentraler Einflussfaktor auf die Performance-Messungen resultiert aus dem BufferpoolManagement des DB2. Bei einem Bufferpool handelt es sich um einen Cache im Hauptspeicher
des Systems. Dieser dient dazu, aufwändige Input/Output-Vorgänge (I/O-Vorgänge) möglichst
zu vermeiden und so die große Differenz zwischen Prozessorgeschwindigkeit und langsamen
Plattenzugriffen zu reduzieren. Standardmäßig besitzt DB2 mehrere Bufferpools und ermöglicht
es dem Administrator, zusätzlich eigene Bufferpools zu definieren oder vorhandene zu
modifizieren.
Daten speichert DB2 aufgrund seiner Eigenschaft als relationales Datenbankmanagementsystem
in Relationen (Tabellen). Physisch werden diese in Tablespaces abgelegt, wobei DB2 dabei
zwischen verschiedenen Typen von Tablespaces unterscheidet, für die auf [Fav07] verwiesen
wird. Zusätzlich gibt es noch Indexspaces, in denen jeweils genau ein Index physisch abgelegt
ist. Als Synonym wird für beide Formen dieser Spaces auch der Begriff Pageset verwendet. Der
Bezeichnung entsprechend enthält ein Pageset eine Menge von Pages. Bei diesen Pages handelt
es sich um 4K bis 32K große Datenseiten, die wiederum physisch in so genannten Datasets
(Dateien) gespeichert sind. Jedes dieser Datasets kann viele Pages enthalten. Abbildung 10
46
5 Vorbetrachtungen zur Messdatenerhebung
veranschaulicht die beschriebenen, zueinander in Beziehung stehenden Datenbankobjekte. Der
Übersichtlichkeit halber ist dabei auf die Illustration der Datasets verzichtet worden. [IBM09a]
Datenbank
Pagesets
Tablespaces
Indexspaces
Tabellen (1 - n)
Index (1)
Pages
Pages
Abbildung 10: Beziehungen zwischen den Datenbankobjekten
Die Zuordnung eines Bufferpools findet auf Pageset-Ebene statt. Ein Pageset kann stets genau
einem Bufferpool zugeordnet werden. Umgekehrt können verschiedene Pagesets denselben
Bufferpool verwenden. Als Granulat nutzt jeder Bufferpool in DB2 die Page, um Daten vom
Sekundärspeicher im Primärspeicher zu cachen und dort für weitere Zugriffe bereitzustellen. Im
Fall eines erfolglosen Getpage Requests (Cache Miss), das heißt wenn eine angeforderte Seite
nicht im Bufferpool aufgefunden wird, führt DB2 einen oder mehrere I/O-Vorgänge aus und
lädt dabei die gewünschten Daten aus dem Sekundärspeicher nach. Dabei werden aus Gründen
der Performance in der Regel mehrere Pages gemeinsam nachgeladen. Auf diese Weise können
durch gezieltes Prefetching zum Teil aufwändige zusätzliche I/O-Vorgänge vermieden werden.
Das Bufferpool-Management ist aber noch komplexer als die hier beschriebenen Grundzüge.
Auf nähere Details zu verschiedenen Ersetzungsstrategien, diversen Mechanismen oder zur
Einteilung der möglichen Zugriffe (Lesen oder Schreiben, synchron oder asynchron) wird an
dieser Stelle verzichtet und auf die Literatur [IBM09a] verwiesen. Teilweise werden aber auch
in Abschnitt 5.2.4 noch zusätzliche Informationen gegeben.
47
5 Vorbetrachtungen zur Messdatenerhebung
Auf den Aspekt der Performance-Messung bezogen, ergeben sich je nach aktuellem Inhalt der
Bufferpools unterschiedliche Resultate. Sollten also vor dem Start eines Messlaufs bereits zu
verarbeitende Daten im entsprechenden Bufferpool enthalten sein, dann ist zu erwarten, dass die
Messreihe wesentlich schneller abläuft, als wenn keine dieser Daten im Bufferpool liegen.
Leider ist es nur schwer bis gar nicht möglich, den aktuellen Inhalt des Bufferpools zu ermitteln
beziehungsweise vorherzusagen. Aus diesem Grund sind die Messreihen dieser Arbeit stets so
gestaltet, dass zuvor generell alle in den jeweiligen Messungen zu verarbeitenden Daten aus
dem Bufferpool entfernt werden. Genaueres zu der dazu verwendeten Verfahrensweise findet
sich in Abschnitt 5.2.4.
Einen weiteren Einfluss auf die Messreihen hat auch das Verdrängen von zuvor geänderten
Daten aus dem jeweils genutzten Bufferpool auf den Sekundärspeicher. Für die Entwicklungsumgebung ist davon auszugehen, dass die Bufferpools stets gefüllt sind. Daher
entsteht in diesem Fall für das Verdrängen der geänderten Daten ein Zusatzaufwand, der
kontinuierlich und quasi linear abläuft. Vor allem aber aufgrund der asynchronen Charakteristik
des Verdrängungsprozesses – nähere Details dazu finden sich in Abschnitt 5.2.4 – ist dieser
Aufwand für die weiteren Betrachtungen nicht von Bedeutung.
Abschließend sei angefügt, dass die zu vergleichenden Messreihen auch jeweils mit demselben
Bufferpool arbeiten sollten. Das heißt, dass beispielsweise der XML-Tablespace und der LOBTablespace einen gemeinsamen Bufferpool benutzen. Allgemein formuliert, ist für die in
dieser Arbeit durchgeführten Messungen stets folgende Verwendung der in Abschnitt 3.2.2
beschriebenen Bufferpools vorgesehen worden.
BP4 (Bufferpool mit Pagesize 4K)
Tablespaces der Basistabellen
BP16K1 (Bufferpool mit Pagesize 16K)
LOB-Tablespaces
XML-Tablespaces
Die Zuordnung der Bufferpools wurde dabei bewusst getroffen. Dahingehend entspricht
der Bufferpool BP4 dem in dem DATEV-Entwicklungssystem Mem1 standardmäßig verwendeten Bufferpool mit der Default Pagesize 4K. Die native XML-Speicherung ist in DB2 aber
zwingend an die Pagesize 16K gebunden [Zha08]. Da die Erstellung der XML-Tablespaces
stets implizit erfolgt, nutzt DB2 dazu den per Subsystem-Parameter TBSBPXML festgelegten
48
5 Vorbetrachtungen zur Messdatenerhebung
16K-Bufferpool [Zha08]. In dem DATEV-Entwicklungssystem Mem1 ist dazu der Bufferpool
BP16K1 definiert. Um die Messreihen der LOB-Daten mit denen der XML-Daten vergleichbar
zu machen, ist für die LOB-Tablespaces ebenfalls der 16K-Bufferpool BP16K1 verwendet
worden.
5.2.2
Data Sharing
Eine der wertvollsten Funktionen des DB2 besteht im Data Sharing. Dieses ist ausschließlich in
der Produktlinie des DB2 for z/OS implementiert, besteht aber in ähnlicher Form als pureScaleTechnologie beispielsweise auch im DB2 for LUW. Die Bedeutung des Data Sharings leitet
sich von den zahlreichen Vorteilen ab, die durch diese ermöglicht werden. Dazu zählen unter
anderem höhere Datenverfügbarkeit, erweiterte Skalierbarkeit und auch erhöhte Datendurchsatzraten. Im Detail wird auf diese und weitere Vorteile in [IBM06a] eingegangen.
Die für das Data Sharing benötigte Architektur setzt auf der „Parallel Sysplex“-Technologie
[IBM11b] auf und basiert auf dem Ansatz Shared Data. Dabei handelt es sich um eine parallele
Datenbankarchitektur. Alternativen dazu wären beispielsweise das „Shared Nothing“- oder auch
das „Shared Disk“-Modell. Nähere Informationen zu diesen Ansätzen sind in [IBM06a] zu
finden. Fortan soll lediglich die für das Data Sharing relevante Struktur des „Shared Data“Modells beschrieben werden.
Der Name Shared Data lässt bereits darauf schließen, dass es sich bei diesem Modell um eine
Architektur mit einem gemeinsam genutzten Datenbestand handelt. Wie in Abbildung 11
dargestellt, bilden die verschiedenen Datenquellen bei dem „Shared Data“-Modell einen
gemeinsamen Datenpool. Auf diesen lässt sich von allen Knoten ausgehend zugreifen. Bei den
Knoten handelt es sich um DB2-Subsysteme, die fortan als Member bezeichnet werden. Die
Gesamtheit aller Member, die einen gemeinsamen Datenbestand teilen, bildet eine Data Sharing
Group. Ein Member kann nur zu genau einer solchen Gruppe gehören. Innerhalb der Data
Sharing Group werden von den einzelnen Membern neben dem gemeinsamen Datenpool auch
der DB2-Datenbankkatalog und das DB2 Directory geteilt. [IBM06a]
49
5 Vorbetrachtungen zur Messdatenerhebung
Abbildung 11: „Shared Data“-Architektur [IBM06a]
Die Herausforderung bei der „Shared Data“-Architektur liegt in der Koordination der einzelnen
Member. Hierzu wird eine so genannte Coupling Facility benutzt, die beispielsweise im „Shared
Disk“-Ansatz nicht vorgesehen ist. Diese unterstützt bei der Kontrolle der Nebenläufigkeit und
der Kohärenz. Dazu verwaltet sie an einer zentralen Stelle sowohl Sperr- als auch Cachestrukturen und ermöglicht auf diese Weise eine effiziente Datenverarbeitung im RechnerCluster. Für eine ausführlichere Abhandlung der Arbeitsweise der Coupling Facility wird auf
[IBM06a] verwiesen. Fortan soll der Bezug des Data Sharings zu den in dieser Arbeit durchgeführten Messreihen hergestellt werden. [IBM06a]
In der Entwicklungsumgebung der DATEV existiert eine Data Sharing Group, die wiederum
zwei Member (Mem1 und Mem2) enthält. Innerhalb dieser Data Sharing Group ist das Data
Sharing so konfiguriert, dass bei dem Verbindungsaufbau zu DB2 abhängig von der
aktuellen Systemlast ein konkretes Member für die anschließende Verarbeitung ausgewählt
wird12. Obwohl die Member in der Entwicklungsumgebung identisch konfiguriert sind, haben
sich bei der Ausführung von gleichen Messreihen unterschiedliche Laufzeiten13 zwischen dem
Mem1 und dem Mem2 gezeigt. Damit also die Messreihen der weiteren PerformanceMessungen miteinander vergleichbar sind, muss sichergestellt sein, dass sie stets auf demselben
Member – quasi lokal – ausgeführt werden. Dazu ist ohne besonderen Hintergrund das Mem1
gewählt worden, dessen Kennzahlen in Abschnitt 3.2.2 ersichtlich sind. Da die einzelnen
Member gegenüber externen Zugriffen auf das DB2 transparent sind, kann eine gezielte
Memberauswahl auf einfache Weise nicht gewährleistet werden. Abschnitt 5.3 zeigt aber
12
Im Produktivsystem der DATEV erfolgt dagegen die Lastverteilung dynamisch zwischen den zwei
dazugehörigen Membern.
13
besonders die Elapsed-Zeit betreffend
50
5 Vorbetrachtungen zur Messdatenerhebung
zusammen mit der Verfahrenweise zur Messdatenerhebung eine Möglichkeit auf, wie dennoch
eine Betrachtung auf Memberebene möglich ist.
5.2.3
Zugriffsart
Bei der Ausführung von SQL-Statements ist in DB2 zwischen statischem SQL und
dynamischem SQL zu entscheiden. Abhängig von der gewählten Methode ergibt sich eine
unterschiedliche interne Statement-Ausführung, die sich auch auf deren Performance auswirkt.
In dem folgenden Abschnitt sollen die Konzepte statisches SQL und dynamisches SQL primär
anhand ihrer Besonderheiten beschrieben werden. Für ausführliche Details – beispielsweise zu
dem Compile- oder Bind-Prozess – wird auf die Literatur [IBM11c] verwiesen.
Die Verwendung von statischem SQL bedeutet, dass der Compile- und Bind-Prozess14
unabhängig und zeitlich vorgelagert zur Statementausführung „einmal“ stattfindet. Dies hat
zwar den Nachteil, dass bei einer grundlegenden Änderung der Statistiken der innerhalb des
Statements verwendeten Datenbankobjekte ein REBIND [IBM11g] angeraten ist. Auf der
anderen Seite bringt es aber Performance-mäßig betrachtet auch den großen Vorteil, dass für die
spätere, vielfache Ausführung der SQL-Statements die Kosten für das Kompilieren und Binden
(inklusive der Optimierung) entfallen. Dafür müssen die auszuführenden Statements allerdings
bereits zum Compile-Zeitpunkt vollständig fixiert sein. Das heißt, dass ein Zusammenbauen von
Statements abhängig vom aktuellen Anwendungskontext für statisches SQL nicht möglich ist.
Hier bleibt lediglich die Möglichkeit, Host-Variablen zu verwenden. Durch diese lässt sich
ein Statement für verschiedene Werte wiederverwenden und muss infolgedessen nur einmal
kompiliert und gebunden werden.
Ein weiterer großer Vorteil von statischem SQL liegt in dem Aspekt der Rechtevergabe. Für ein
statisch gebundenes Statement wird in DB2 ein Package erzeugt. Auf diesem lassen sich
ähnlich wie auch auf anderen Objekten in der Datenbank gezielt Berechtigungen definieren.
Dadurch ist es bei statischem SQL beispielsweise möglich, einzelne Nutzer zur Ausführung
eines Statements zu berechtigen, obwohl diese unter Umständen keinerlei Rechte auf den darin
verwendeten Tabellen besitzen. Ohne Packages, beispielsweise im Fall von dynamischem SQL,
14
Im Bind-Prozess erfolgen unter anderem die Zugriffsplanermittlung und die Validierung der Objekte
[IBM09b].
51
5 Vorbetrachtungen zur Messdatenerhebung
ist ein ähnliches Vorgehen nur umständlich durch die Verwendung von Stored Procedures oder
Funktionsusern [IBM11d] möglich.
Bei dynamischem SQL erfolgt der Bind-Prozess – auch PREPARE [IBM11a] genannt –
dynamisch zur Laufzeit. Dementsprechend werden stets die aktuellsten Statistiken genutzt.
Zusätzlich ergibt sich durch den späten Zeitpunkt des Bindens die Möglichkeit, ein auszuführendes Statement erst während der Laufzeit aus einzelnen Zeichenketten zusammenzubauen.
Trotz dieser vielen Vorzüge ist auch dynamisches SQL nicht frei von Nachteilen. Da der BindProzess stets direkt vor der Ausführung eines neuen Statements stattfindet, verlängert sich
durch diesen Performance-mäßig betrachtet auch die Gesamtlaufzeit. Dem Effekt wird aber
durch den Dynamic Statement Cache entgegengewirkt. Bei der erstmaligen Ausführung eines
dynamischen Statements wird es, wie oben erklärt, gebunden und das Ergebnis dieses Prozesses
im Dynamic Statement Cache verzeichnet. Erfolgt eine erneute Statementausführung, dann kann
der „gecachte“ Zugriffsplan direkt ohne zusätzliches Binden wiederverwendet werden. Hierbei
ist jedoch zu beachten, dass die Inhalte des Dynamic Statement Caches unter anderem abhängig
von dessen Füllgrad auch wieder aus diesem verdrängt werden können. Verglichen mit den
Host-Variablen bei statischem SQL gibt es bei dynamischem SQL Parametermarker, mit deren
Hilfe sich ebenfalls die Wiederverwendbarkeit eines (gecachten) Zugriffsplans erhöhen lässt.
Aufgrund der beschriebenen Unterschiede zwischen statischem SQL und dynamischen SQL ist
auch deren Einfluss auf die Ergebnisse der Messreihen dieser Arbeit geprüft worden. Hierbei
zeigten sich aber keine wesentlichen Differenzen. Dies resultiert aus der Tatsache, dass für die
durchgeführten Messreihen stets jeweils ein Statement benutzt wird. Durch die Verwendung
der Parametermarkertechnik ist dafür nur ein Bind- beziehungsweise PREPARE-Prozess
notwendig. Dieser ist kostenmäßig betrachtet verschwindend gering im Vergleich zu den
tatsächlichen Statementausführungen, weshalb auf eine separate Betrachtung der Zugriffsart in
den weiteren Messreihen verzichtet wird
Abbildung 12 zeigt zur besseren Nachvollziehbarkeit ein Beispiel aus Abschnitt 6.1.4. Hierbei
werden aus einer Quelltabelle 100.000 1K große nicht-native XML-Dokumente ausgelesen
(FETCH), die anschließend in einem zuvor PREPAREten INSERT-Statement (EXECUTE)
konvertiert, geparst und in eine Zieltabelle eingefügt werden. Das Auslesen der Daten aus
der Quelltabelle erfolgt über einen deklarierten Cursor, der eingangs geöffnet (OPEN) und
am Ende der Verarbeitung wieder geschlossen (CLOSE) wird. Wichtig in diesem Zusammenhang sind die in Abbildung 12 aufgeführten Kosten der einzelnen Prozesse, anhand deren sich
52
5 Vorbetrachtungen zur Messdatenerhebung
der Einfluss des einmalig (siehe SQL_COUNT) ausgeführten PREPARE-Statements ableiten
lässt. Dieser ist wie bereits allgemein oben erwähnt verglichen mit dem wesentlichen Prozedurablauf äußerst geringfügig und daher vernachlässigbar.
ELAPSED_TIME
CPU_TIME
(in Sekunden)
(in Sekunden)
100.000
42,388315
10,700842
FETCH
100.000
62,131371
4,629180
PREPARE
1
0,001322
0,001016
OPEN
1
0,000116
0,000054
CLOSE
1
0,000002
0,000002
SQL_CALL
SQL_COUNT
EXECUTE
Abbildung 12: Beispiel – Anteil des PREPARE-Prozesses
5.2.4
Transaktionslänge
Die Ausführung von SQL-Statements wird in DB2, wie in fast allen Datenbankmanagementsystemen, über Transaktionen gesteuert. Dabei handelt es sich um Folgen von zusammengehörigen Operationen, die im Kontext der relationalen Datenbanken den SQL-Anweisungen
entsprechen. Für die Ausführung von Transaktionen gelten besondere Regeln. Zu diesen zählen
die Prinzipien Atomarität, Konsistenz, Isolation und Dauerhaftigkeit, die aufgrund ihrer
englischsprachigen Bezeichnung auch als ACID-Regeln bezeichnet werden. Für nähere
Informationen hierzu wird auf [HR01] verwiesen.
Eine Transaktion beginnt in DB2 implizit und endet mit einem expliziten COMMIT-Befehl.
Eine Besonderheit bildet hierbei der Autocommit-Modus. Ist dieser aktiviert, wird automatisch
nach jedem ausgeführten SQL-Statement ein COMMIT durchgeführt. Der Anwender hat in
diesem Fall keinen Einfluss auf die Länge einer Transaktion. Bei deaktiviertem AutocommitModus kann er durch die manuelle Ausführung des COMMIT-Befehls die in einer Transaktion
zu bündelnden SQL-Anweisungen selbst bestimmen. Sollte eine Transaktion während ihres
Ablaufs abgebrochen werden, ist dies per ROLLBACK-Befehl möglich.
Aufgrund der erwähnten ACID-Eigenschaften werden sämtliche von einer Transaktion betroffenen Daten erst zu deren Ende, also bei erfolgreich durchgeführtem COMMIT-Befehl, in
der Datenbank festgeschrieben. Zwischenzeitlich befinden sich diese Daten in der Regel zu
53
5 Vorbetrachtungen zur Messdatenerhebung
großen Teilen im Bufferpool des DB2 (siehe Abschnitt 5.2.1). In diesem Kontext gilt es
verschiedene Strategien zu unterscheiden.
Steal oder No Steal [Stö01]
Diese Strategiealternative regelt den Umgang mit im Bufferpool befindlichen
veränderten Datenseiten während einer Transaktion. Diese können sich im Fall
der Steal-Strategie aus dem Bufferpool in den Sekundärspeicher „wegstehlen“.
No Steal bedeutet dementsprechend, dass geänderte Daten frühestens erst dann
auf den Sekundärspeicher weggeschrieben werden dürfen, wenn eine Transaktion per COMMIT-Befehl abgeschlossen wird.
Force oder No Force [Stö01]
Mithilfe dieser Strategiealternative lässt sich der Umgang mit im Bufferpool befindlichen veränderten Datenseiten am Ende einer Transaktion regeln. Sofern
Force definiert ist, müssen bei einem COMMIT alle veränderten Daten auf den
Sekundärspeicher weggeschrieben werden. Im Fall von No Force kann diese
Aktion auch zu einem späteren Zeitpunkt – quasi asynchron – durchgeführt
werden.
Aus Performance-Perspektive betrachtet bieten die jeweiligen Strategien Steal und No Force
den größten Sparvorteil bezogen auf die Laufzeit eines SQL-Statements. Dies resultiert aus dem
dabei vorgesehenen asynchronen Wegschreiben von Daten aus dem Bufferpool während und
nach der Transaktion. Im Grunde sind also Schreiboperationen hier in ihren Durchführungszeitpunkten von Transaktionen „entkoppelt“ und können dadurch auf weniger ausgelastete
Zeitslots verlagert werden. Bei den vorangehenden Überlegungen ist jedoch der Abbruch per
ROLLBACK-Befehl außer Acht gelassen. Schließlich wäre beispielsweise das Zurücknehmen
von bereits auf den Sekundärspeicher geschriebenen Änderungen aufwändiger, als das Zurücknehmen von geänderten Daten, die sich noch im Bufferpool befinden.
Die zuletzt betrachtete Strategiekombination (Steal und No Force) nutzt zu großen Teilen auch
DB2. Dahingehend verwendet es verschiedene pro Bufferpool definierbare Schwellwerte15, mit
denen das Wegschreiben veränderter Daten aus dem Bufferpool in den Sekundärspeicher
gesteuert wird. Zusätzlich gibt es hier noch Checkpoints, die ebenfalls dafür sorgen, dass alle
15
unter anderem VPSEQT, DWQT und VDWQT [IBM09a]
54
5 Vorbetrachtungen zur Messdatenerhebung
geänderten Daten regelmäßig aus dem Bufferpool in den Sekundärspeicher weggeschrieben
werden. Auf deren detaillierte Funktionsweise wird in dieser Arbeit nicht näher eingegangen
und auf [IBM11d] verwiesen. Aus den Ausführungen folgt allerdings, dass der Zeitpunkt des
COMMIT-Befehls in DB2 keine direkten Auswirkungen auf das Wegschreiben von Daten aus
dem Bufferpool in den Sekundärspeicher hat.
Die vorangehenden Betrachtungen machen deutlich, dass die Art und Weise der Transaktionsstruktur ein zu beachtender Einflussfaktor für die weiteren Performance-Messungen ist. Dies
gilt speziell für die Messreihen aus Kapitel 6 und Kapitel 7, da diese jeweils Datenänderungen
umfassen. Im Rahmen der vorliegenden Arbeit wurde anhand ausgewählter Messungen der
Einfluss der Transaktionslänge auf die weiteren Performance-Betrachtungen ermittelt. Auf eine
ausführliche Abhandlung dieser Untersuchungen wird allerdings aus Umfangsgründen verzichtet. Stattdessen sollen die dabei gewonnenen Erkenntnisse anhand der folgenden drei
Szenarien zusammengefasst beschrieben werden.
Einmalige COMMIT-Ausführung am Ende einer einzelnen Messung
Blockweise COMMIT-Ausführung nach der Verarbeitung einer Datenmenge von 1M
Autocommit-Modus
Für die in dieser Arbeit durchgeführten datenverändernden Messreihen zeigte sich stets ein
gemeinsames Muster. Die Ergebnisse unterschieden sich zwischen den mit einmaligem
COMMIT und den mit blockweisem COMMIT durchgeführten Messreihen kaum. Die Laufzeiten der Messungen mit aktiviertem Autocommit-Modus waren stets die langsamsten, wobei
hier eine größere Differenz zu den anderen betrachteten Szenarien festzustellen war.
Diese Differenz resultiert wahrscheinlich aus dem Zusatzaufwand (Overhead), den eine einzelne
Transaktion verursacht und der nicht zur direkten Abarbeitung des Statements beiträgt. Dazu
zählt zum Beispiel das (synchrone) Schreiben von COMMIT-Log-Records. Auf diesen und
weitere zum Overhead beitragende Prozesse soll nicht näher eingegangen werden. Wichtiger ist
in dem Zusammenhang, dass der besagte Overhead im Autocommit-Fall aufgrund der großen
Transaktionsanzahl besonders groß ist. Dementsprechend wirkt er sich auch relativ stark auf die
Laufzeit aus. Daraus leitet sich für den Fall der blockweisen COMMIT-Ausführung ein
ebenfalls vorhandener Overhead ab. Bedingt durch die wesentlich kleinere Transaktionsanzahl
fällt dieser aber deutlich geringer aus und ist aufgrund der in Abschnitt 5.4 beschriebenen
Schwankungen nicht messbar.
55
5 Vorbetrachtungen zur Messdatenerhebung
Die performanteste Variante für die Messreihen der vorliegenden Arbeit stellt folglich die
einmalige COMMIT-Ausführung am Ende jeder Messung dar. Deshalb ist diese Methode auch
generell für alle weiteren Messreihen verwendet worden. Hier muss aber erwähnt werden, dass
lange Transaktionen, allgemein gesprochen, auch Nachteile unter anderem hinsichtlich der
Sperrverwaltung oder der Log-Bereiche besitzen. Derartige Negativeffekte treten jedoch
aufgrund der geschilderten Konzeption des Testdatenbestands hier nicht auf.
Verfahrensweise zur Messdatenerhebung
5.3
Anlehnend an die im vorangehenden Abschnitt 5.2 beschriebenen Einflussfaktoren ergibt sich
eine fixe Verfahrensweise, die bei der weiteren Messdatenerhebung verwendet wurde. Diese
schlüsselt sich in die folgenden Einzelschritte auf, die anschließend näher betrachtet werden.
Vorbereitung
Testdatenbestand (und Zielstrukturen) erzeugen
Messprozeduren (und Trigger) anlegen
Durchführung
Member Mem1 „auswählen“
Bufferpool leeren
Messprozeduren aufrufen
Auswertung
Vorbereitung
Die Vorbereitung der Messreihen umfasst die Erzeugung des Testdatenbestands, der Messprozeduren und mit Ausnahme der Analyse der Query Performance auch das Anlegen der
Zielstrukturen. Ersterer ist bereits in Abschnitt 5.1 ausführlich betrachtet worden. Hierzu ist
eine ergänzende Anmerkung zu treffen. Sämtliche zu einer Merkmalsausprägung gehörenden
Testdaten sind stets in einer eigenen Tabelle innerhalb eines eigenen Tablespaces bereitgestellt.
Die jeweiligen Strukturen sind unfragmentiert. Außerdem liegen in DB2 aktuelle Statistiken
(siehe Abschnitt 8.1.2) zu den Objekten vor.
56
5 Vorbetrachtungen zur Messdatenerhebung
Weiterhin müssen, abgesehen von der Untersuchung der Query Performance in Kapitel 8, die
Zielstrukturen angelegt werden. Dies geschieht auf ähnliche Weise wie bei den Testdaten. Pro
Merkmalsausprägung wird eine einzelne Tabelle innerhalb eines eigenen Tablespaces erzeugt.
Die Objekte sind, abgesehen von eventuellen messreihenbedingten Änderungen16, vollständig
strukturgleich zu denen des Testdatenbestands. Der Einfachheit halber befinden sich alle
erzeugten Strukturen in einer gemeinsamen Datenbank. Für die Analyse der Query Performance
genügt das Auslesen (FETCH) der Daten in eine Host-Variable. Daher werden hier keine
weiteren (Ziel-)Strukturen benötigt.
Ebenfalls zur Vorbereitung zählt die bereits erwähnte Erstellung der Messprozeduren. Dabei
handelt es sich um datenbankseitige Stored Procedures, die pro Merkmalsausprägung für
jede Messreihe erstellt werden. Mit ihnen lassen sich einzelne Messreihen unabhängig von
Kommunikationsaufwendungen direkt in DB2 serverseitig durchführen. Das bietet den Vorteil,
dass die Ergebnisse von weiteren Einflüssen durch eine externe Umgebung, wie beispielsweise
einem Java-Programm, isoliert betrachtet werden können. Die folgenden drei Abbildungen
zeigen nacheinander jeweils eine Prozedur beziehungsweise einen Trigger aus den Themenschwerpunkten Migration und Parsen, XML-Schema-Management und Query Performance.
Vorab ist jeweils eine kurze Beschreibung des Objekts beigefügt.
Abbildung 13 zeigt ein Beispiel für eine Prozedur aus Abschnitt 6.1.4. Im Detail werden hier in
Form einer FOR-Schleife alle Daten aus der zu der Merkmalsausprägung 100K gehörenden
Tabelle „TCLOB_100K“ ausgelesen. Bei den Daten handelt es sich speziell um nicht-native, im
EBCDIC-Zeichensatz kodierte und als CLOB gespeicherte XML-Dokumente. Für jedes auf
diese Weise zugegriffene Dokument wird im Body der Schleife dann je ein INSERT mit
integriertem XML-Parse-Prozess in die Tabelle „TXML_XMLPARSE_100K“ ausgeführt. Für
diesen Parseprozess ist stets die standardmäßige Option des STRIP WHITESPACE verwendet
worden, die das Entfernen von unnötigen Füllzeichen während des Parsens bewirkt. Damit sind
beispielsweise Leerzeichen und Umbrüche bezeichnet, die zwar aus Formatierungsgründen zur
besseren Lesbarkeit im Dokument enthalten sind, aber keine inhaltliche Bedeutung haben. Die
Alternative zu dieser Option wäre PRESERVE WHITESPACE, bei der alle Füllzeichen unverändert übernommen werden. Am Ende der Prozedur findet abschließend noch ein COMMIT der
Transaktion statt.
16
beispielsweise die Verwendung des XML-Datentyps anstatt des CLOB-Datentyps bei der Messung der
XML-Parse-Performance in Abschnitt 6.1.4
57
5 Vorbetrachtungen zur Messdatenerhebung
CREATE PROCEDURE T24431A.SP_XMLPARSE_100K()
LANGUAGE SQL
BEGIN
FOR V AS
C CURSOR FOR
SELECT NNXML_DOC AS CUR_DOC FROM T24431A.TCLOB_100K
DO
INSERT INTO T24431A.TXML_XMLPARSE_100K(XML_DOC)
VALUES(XMLPARSE(DOCUMENT CUR_DOC STRIP WHITESPACE));
END FOR;
COMMIT;
END
Abbildung 13: Beispielprozedur – Migration und Parsen
Die folgende Abbildung 14 stellt einen Trigger aus Abschnitt 7.3 dar, mit dem sich ein Automatismus zur Schemavalidierung erstellen lässt. In der Produktlinie z/OS von DB2 Version 9
wird der XML-Datentyp in Triggern nicht unterstützt [Zha09]. So ist es beispielsweise nicht
möglich, im Trigger-Body (in einer Transition Variable [IBM11a]) den XML-Datentyp zu
verwenden. Daher lässt sich ein Automatismus zur Schemavalidierung hier nur umständlich
realisieren. DB2 for LUW beispielsweise besitzt die genannte Einschränkung für den speziellen
Fall der Schemavalidierung nicht und kann diese auf einfache Weise als eine Art Vorverarbeitung in einem BEFORE-Trigger automatisieren [NK09]. Für DB2 for z/OS besteht lediglich die Möglichkeit eines „nachträglichen“, per AFTER-Trigger initiierten Validierungsautomatismus. Um die Validierungslogik nicht für jeden Trigger neu implementieren zu müssen,
wurde sie in eine parametrisierte Stored Procedure „SP_SCHEMA_VALIDATION_AUTO“
ausgelagert. Diese wird mit den zutreffenden Parametern, wie in Abbildung 14 zu sehen, vom
Trigger aufgerufen. Nähere Details zum Aufbau und zur Funktionsweise der Prozedur finden
sich in Abschnitt 7.3.
CREATE TRIGGER T24431A.TR_XML_1K
AFTER INSERT ON T24431A.TXML_1K
REFERENCING NEW AS NEW_ROW
FOR EACH ROW MODE DB2SQL
BEGIN ATOMIC
CALL T24431A. SP_SCHEMA_VALIDATION_AUTO('T24431A', 'TXML_1K', 'XML_DOC',
NEW_ROW.DB2_GENERATED_DOCID_FOR_XML, ‚MY_XML_SCHEMA');
END
Abbildung 14: Beispiel-Trigger – XML-Schema-Management
58
5 Vorbetrachtungen zur Messdatenerhebung
Abbildung 15 zeigt eine Prozedur aus Abschnitt 8.2.2. Vereinfacht formuliert handelt es sich
dabei um die Deklaration eines Cursors. Dieser wird anschließend geöffnet, einmalig in eine
zuvor deklarierte (temporäre) Variable ausgelesen und daraufhin wieder geschlossen. Die
einmalige Ausführung des FETCH-Statements genügt zum vollständigen Zugriff auf die
Ergebnismenge des SELECT-Statements, da in diesem die Funktion COUNT(*) verwendet
wird. Sie liefert, sofern keine Gruppierung stattfindet, stets genau eine Ergebniszeile. Weiterhin
umfasst das an den Cursor gebundene SELECT-Statement ein XMLEXISTS-Prädikat. Dieses
schließt einen XPath-Pfadausdruck ein, für den in einem der Testszenarien ein User-DefinedXML-Index (siehe Abschnitt 8.1.1) auf der Tabelle „TXML_1K“ besteht. Dieser Index kann
auch für das angeführte Statement abhängig von den vorliegenden Statistiken verwendet
werden.
CREATE PROCEDURE T24431A.SP_XML_INDEX_1K()
LANGUAGE SQL
BEGIN
DECLARE TMP INTEGER;
DECLARE C1 CURSOR FOR
SELECT COUNT(*) FROM T24431A.TXML_1K
WHERE XMLEXISTS('$x/seite/textblock[@id="muster_textblock1"]'
PASSING XML_DOC AS "x");
OPEN C1;
FETCH C1 INTO TMP;
CLOSE C1;
END
Abbildung 15: Beispielprozedur – Query Performance
Durchführung
Zur Durchführung einer Messung sind abhängig von den in Abschnitt 5.2 beschriebenen
Einflussfaktoren verschiedene Schritte nötig. Zuerst ist es wichtig, eine Verbindung zu dem
gewählten Subsystem Mem1 herzustellen. Das IBM Data Studio erlaubt es nicht, dies auf
einfache Art und Weise zu realisieren. Weil es aber eine einmal aufgebaute Verbindung für alle
weiteren im Tool initiierten Prozesse wiederverwendet, genügt es, beim Verbinden zu DB2
durch Probieren das richtige Subsystem zu treffen. Ob dies der Fall ist, lässt sich über das in
Abschnitt 3.4.3 vorgestellte Tool CA Detector prüfen. Eine einfachere Möglichkeit existiert
hierfür leider nicht.
59
5 Vorbetrachtungen zur Messdatenerhebung
Nachdem die Verbindung zum speziellen DB2-Subsystem aufgebaut ist, besteht der nächste
Schritt gemäß den Ausführungen in Abschnitt 5.2.1 im Leeren des Bufferpools. Dies lässt sich
unter anderem durch ein STOP- und ein anschließendes START-Kommando der Testdatenbank
realisieren. Die Kommandos können beispielsweise über den DB2 Command Line Processor
(CLP) ausgeführt werden. Über einen Umweg ist dies aber auch im Tool IBM Data Studio
möglich. Dort lässt sich mithilfe des SQL-Editors ein Kommando durch den parametrisierten
Aufruf (CALL) der Prozedur SYSPROC.ADMIN_COMMAND_DB2 ausführen. Detaillierte
Informationen dazu sind in [IBM11d] zu finden.
Sobald die Datenbank wieder gestartet ist, kann auf analoge Weise per CALL-Statement auch
der Aufruf einer einzelnen Testprozedur erfolgen. Wichtig ist dabei, dass bevor eine weitere
Testprozedur ausgeführt wird, zur Vergleichbarkeit stets der Bufferpool erneut geleert werden
muss. Sofern exakt die gleiche Messprozedur erneut ausgeführt werden soll, sind zusätzlich
auch die Zielstrukturen neu anzulegen, um wieder eine einheitlich bereinigte Ausgangssituation
herzustellen.
Auswertung
Im Anschluss an die Durchführung der Messungen lassen sich über den CA Detector (siehe
Abschnitt 3.4.3) die detaillierten Laufzeiten der einzelnen in den Messprozeduren enthaltenen
Statements ermitteln. Dazu kann über das gewählte Subsystem Mem1 und anschließend
den Nutzer T24431A Einsicht in die Laufzeiten der von ihm durchgeführten Prozeduren
genommen werden. Abbildung 16 zeigt am Beispiel einer Prozedur aus Abschnitt 8.2.2, wie der
CA Detector die davon eingeschlossenen Statements aufgliedert. Dabei zeigen INDB2_TIME
und INDB2_CPU jeweils die zur gesamten Ausführung benötigte Elapsed-Zeit (Class 2) und
CPU-Zeit (siehe Abschnitt 3.3). Diese Zeiten sind auch für die weiteren Betrachtungen der
vorliegenden Arbeit herangezogen worden. Während OPEN und CLOSE die Kosten für das
Öffnen und Schließen des Cursors ausweisen, gibt FETCH über die Laufzeit des SELECTStatements Aufschluss.
60
5 Vorbetrachtungen zur Messdatenerhebung
SQL_CALL
-------FETCH
OPEN
CLOSE
INDB2_TIME
-----------00:00.201656
00:00.000063
00:00.000008
INDB2_CPU
-----------00:00.004255
00:00.000062
00:00.000008
Abbildung 16: Beispielausgabe des CA Detectors
Eine Alternative zum CA Detector bei der Erfassung der Messdaten wäre der in Abschnitt 5.2.3
erwähnte Dynamic Statement Cache. Dieser listet zwar ebenfalls die Laufzeiten der einzelnen
Statements ausführlich auf. Dabei ist er aber nur für dynamische Statements verwendbar und
erreicht zudem nicht den Detailgrad des CA Detectors. Aus diesem Grund wurde ausschließlich
letzterer für die Auswertung der Messreihen verwendet.
5.4
Schwankungen und Diskrepanzen
In den vorangehenden Abschnitten wurden bereits grundlegende Einflussfaktoren beschrieben
und Wege aufgezeigt, um deren Auswirkungen zu mindern beziehungsweise ganz zu vermeiden. Dennoch wirken auch weitere Randfaktoren auf die Messreihen ein. Diese lassen sich
in die zwei Kategorien Schwankungen und Diskrepanzen (im mathematischen Sinn) einteilen.
Dabei sind Schwankungen als sporadische Abweichungen und Diskrepanzen hingegen als
konstante Abweichungen zu verstehen.
Verantwortlich für die auftretenden Schwankungen der Elapsed- als auch der CPU-Zeit
(geringeres Ausmaß) ist im Wesentlichen die Charakteristik der Entwicklungsumgebung.
Sämtliche DB2-Anwender und DB2-Administratoren in der DATEV nutzen diese Umgebung
zur Durchführung diverser Testszenarien. Darin eingeschlossen sind sowohl am Tage ablaufende Applikationstests also auch nächtliche Batchabläufe. Auf dem in der Entwicklungsumgebung befindlichen Entwicklungssystem Mem1 befindet sich demzufolge stets eine gewisse
Workload, die im Verlauf eines Tages stark schwanken kann. Beobachtungen haben ergeben,
dass diese Workload durchschnittlich am frühen Morgen und gegen den späten Nachmittag
abflacht und um die Mittagszeit herum ihren Peak erreicht. Da die einzelnen Testszenarien
dabei jedoch kontinuierlich wechseln, ist es nicht möglich, eine konkrete Aussage zu deren
Einfluss auf die betrachteten Messreihen zu treffen.
61
5 Vorbetrachtungen zur Messdatenerhebung
Der durch die erwähnten Testszenarien resultierende Einfluss lässt sich an verschiedenen
Aspekten aufzeigen. Im Wesentlichen resultiert er aus der gemeinsamen Verwendung des
Datenbankkatalogs, der Bufferpools (siehe Abschnitt 5.2.1) und aus anderen Mechanismen
der Nebenläufigkeit, wie beispielsweise dem Locking. Die gemeinsame Verwendung des
gleichen Datenbankkatalogs scheint auf den ersten Blick vielleicht etwas unschlüssig. Schließlich befinden sich der gesamte Testdatenbestand und auch die dazugehörigen Zielstrukturen
innerhalb einer abgeschlossenen Datenbank. Da sich aber, anders als beispielsweise in der
Produktlinie DB2 for LUW17, in DB2 for z/OS der Datenbankkatalog auf Subsystemebene
befindet, nutzen alle Datenbanken eines Subsystems denselben Katalog (siehe Abschnitt 5.2.2).
Im Gegensatz zum zuletzt betrachteten Aspekt wäre das Beseitigen des aus der gemeinsamen
Bufferpool-Nutzung resultierenden Einflusses rein technisch betrachtet möglich gewesen. Dies
hätte sich durch die Verwendung von zuvor neu zu erstellenden, dedizierten Bufferpools
realisieren lassen. Da es sich aber bei dem Mem1, wie bereits erwähnt, um ein Entwicklungssystem für alle DATEV-DB2-Entwickler handelt, werden das System betreffende Änderungen
als äußerst kritisch eingestuft. Im konkret betrachteten Fall hätte die Erstellung neuer
Bufferpools eine veränderte Verteilung der in DB2 verfügbaren Ressourcen zur Folge. Somit
wären auch bereits vorhandene Bufferpools indirekt betroffen, wodurch sich das gesamte
Systemverhalten, wenn auch nur geringfügig, verändern würde. Auf die Beseitigung des hier
betrachteten Einflusses wurde daher verzichtet.
Die Gesamtheit an weiteren vorhandenen Einflüssen auf die Messreihen hat diverse
Schwankungen bei den Ergebnissen zur Folge. Diese erstrecken sich bei der Elapsed-Zeit auf
eine Spanne von teilweise bis zu ungefähr +-25 Prozent und bei der CPU-Zeit auf immerhin fast
+-10 Prozent. Abbildung 17 stellt ein Beispieldiagramm mit prozentualen Differenzen zu den
tatsächlich verwendeten Messergebnissen18 dar. Dieses zeigt exemplarisch die beobachteten
maximalen Abweichungen bei der mehrmaligen Ausführung einer Messreihe zu unterschiedlichen Zeitpunkten.
17
in DB2 for LUW besitzt jede Datenbank ihren eigenen Katalog
18
das tatsächliche Ergebnis entspricht dem Median aus drei Einzelmessreihen (siehe nächste Seite)
62
5 Vorbetrachtungen zur Messdatenerhebung
30
Differenz (in Prozent)
20
10
0
ELAPSED
-10
CPU
-20
-30
200B x
1K x
500.000 100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 17: Beispieldiagramm – Prozentuale Schwankungen
Während die erwähnten +-10 Prozent der CPU-Zeit noch tolerierbar sind, entsprechen die
+-25 Prozent einer zu großen Abweichung, um fundierte Erkenntnisse aus den Messresultaten
ableiten zu können. Für die Darstellung der Messergebnisse dieser Arbeit gilt daher: Die
weiteren Schlussfolgerungen und Ausführungen beziehen sich ausschließlich auf die
gemessenen CPU-Zeiten, sämtliche Betrachtungen zu den Elapsed-Zeiten sind im Anhang
dieser Arbeit zu finden.
Unabhängig von CPU- und Elapsed-Zeit liegt den Messauswertungen der statistische Lageparameter Median zugrunde. Dieser hat verglichen mit der einfachen Durchschnittsbildung den
Vorteil, dass er robuster gegenüber Ausreißern ist. Auf die Auswertung der Messreihen bezogen
bedeutet es, dass extreme Schwankungen, wie sie zuvor beispielhaft in Abbildung 17 gezeigt
wurden, verhindert werden können. In diesem Zusammenhang erfolgte die Durchführung der
einzelnen Messreihen stets dreimalig. Das tatsächliche Ergebnis ergibt sich daraufhin durch die
Bildung des Medians dieser drei Werte.
Neben den betrachteten Schwankungen lässt sich aber auch gemäß der obigen Kategorisierung
eine Diskrepanz anführen. Hierbei ist beispielsweise die Größe der Testdaten zum Vergleichskriterium Größe und Anzahl und davon abgeleitet zum Kriterium der Zusammensetzung zu
nennen. Wie bereits im Abschnitt 5.1.1 erwähnt, handelt es sich bei diesen Daten um
eine gezielte Auswahl von bereits vorhandenen Dokumenten aus der Entwicklungsumgebung.
Da die Dokumente nicht exakt den Größen der Merkmalsausprägungen entsprechen, sind
gewisse Abweichungen vorhanden, die sich auch konstant geringfügig auf die Messergebnisse
auswirken.
63
6 Migration und Parsen
6 Migration und Parsen
Die mit DB2 Version 9 eingeführte pureXML-Technologie verspricht durch die native
Speicherung von XML-Dokumenten viele Vorteile. Die wesentlichen Vorzüge liegen dabei
in dem performanten Zugriff auf die Daten und den zusätzlichen XML-spezifischen Funktionalitäten. Dem gegenüber stehen jedoch auch neue Problematiken, die besonders unter dem
Aspekt der Performance von Bedeutung sind. Einen zentralen Stellenwert nimmt dabei der
Prozess des XML-Parsens ein. Damit die Vorzüge der nativen XML-Speicherung genutzt werden können, müssen nicht-native XML-Dokumente stets durch einen solchen Prozess in die
native Ablageform überführt werden. Dies gilt insbesondere für neu in die Datenbank einzufügende Dokumente. DB2 besitzt hierzu die XMLPARSE-Funktion, welche das Parsen in den
nativen XML-Datentyp ermöglicht.
Die Untersuchungen aus der Studienarbeit [Koc11] haben gezeigt, dass die Migration von
bestehenden nicht-nativen XML-Dokumenten in der Datenbank in den nativen XML-Datentyp
komplexerer Natur ist. Das heißt, neben dem Parsen sind noch weitere Prozesse zur
Überführung nötig, die entweder implizit stattfinden oder explizit ausgeführt werden müssen.
Zusammen mit der Variante der Neueinfügung stellt Abbildung 18 eine – mit Verweisen auf die
folgenden Abschnitte versehene – Übersicht über die Abläufe der verschiedenen Szenarien dar.
Eine kurze Beschreibung der Prozesse folgt in Abschnitt 6.1 und Abschnitt 6.2, wobei der Fokus
dabei stets auf den Performance-Aspekt gerichtet ist. Nähere Details zur Notwendigkeit und
VARCHAR/
CLOB
(6.1.2)
Konkatenation
(6.1.4)
XML-Parsen
Input
UnicodeKonvertierung
(6.1.3)
INSERT
Vorverarbeitung
XML
Abbildung 18: Überblick der betrachteten INSERT-Szenarien
64
Neueinfügung (6.2)
Migration (6.1)
Umsetzung einzelner Abläufe sind in [Koc11] zu finden.
6 Migration und Parsen
An dieser Stelle sei darauf hingewiesen, dass die Vorverabeitungsprozesse19 in den folgenden
Ausführungen außer Acht gelassen werden. Dies begründet sich durch ihre Position in der
abgebildeten Prozesskette einer Migration. Da sich die Vorverabeitungsprozesse nicht auf dem
kritischen Pfad befinden, können sie unabhängig von dem restlichen Migrationsvorhaben
abgearbeitet werden. Dabei ist zusätzlich anzumerken, dass eine Vorverarbeitung auch nur in
speziellen Fällen notwendig wird, weshalb ihr Einfluss auf die Migration insgesamt vernachlässigbar ist.
Um XML-Daten in DB2 einzufügen, bietet das Datenbankmanagementsystem, ähnlich wie für
LOB-Daten, sowohl die Möglichkeiten des direkten INSERTs [IBM11a] als auch den Utilitybasierten LOAD-Mechanismus [IBM08a]. Letzterer wird besonders in Migrationsszenarien
verwendet, bei denen der Schwerpunkt auf zeitkritischer Massendatenverarbeitung liegt.
Gegenüber der transaktionalen Einzelverarbeitung beim INSERT erreicht das LOAD-Utility
seine Performance-Gewinne dadurch, dass es die zum Einfügen notwendigen Prozesse innerhalb dafür optimierter LOAD-Phasen20 gebündelt ausführt. Da zum aktuellen Zeitpunkt aber
keine Anforderungen geplant sind, die das LOAD-Utility notwendig machen, konzentrieren sich
die weiteren Untersuchungen dieser Arbeit auf die Verwendung von INSERT-Statements.
Von großer Relevanz für die Performance ist das Thema „Indexe“. Dies gilt nicht nur für die im
Kapitel 8 zu betrachtende Query Performance, sondern auch für die INSERT-Performance. Mit
dem nativen XML-Datentyp wurden in DB2 gleichsam neue XML-spezifische Indexierungsmöglichkeiten implementiert. Eine Abhandlung zu deren Struktur und weiteren Besonderheiten
ist in Abschnitt 8.1.1 zu finden. Für XML-Indexe ergeben sich aus Perspektive der INSERTPerformance zwei zentrale Fragestellungen. Zum einen ist es wichtig, Kennzahlen zu dem
parallel beim INSERT stattfindenden Pflegeaufwand der Indexe zu ermitteln. Auf der anderen
Seite muss auch betrachtet werden, ob eine Indexerstellung im Falle einer Migration erst nachträglich erfolgen sollte, um den parallelen Pflegeaufwand zu unterbinden. Eine ausführliche
Betrachtung dieser Aspekte liefert Abschnitt 6.3.
19
beispielsweise die Bereinigung der nicht-nativen XML-Dokumente von ungültigen Zeichen [Koc11]
20
UTILINIT, RELAOD, SORT, BUILD, SORTBLD, INDEXVAL, ENFORCE, DISCARD, REPORT,
UTILTERM [IBM08a]
65
6 Migration und Parsen
Der Parseprozess ist nicht nur beim INSERT relevant, sondern auch ein wichtiger Teil des
UPDATEs. Daher und aufgrund der Implementierung dieser Funktionalität für XML-Daten
wird abschließend in diesem Kapitel in Abschnitt 6.4 noch ein kurzer Exkurs zum Thema
UPDATE von XML-Dokumenten angefügt. Hierbei soll neben der Ist-Situation in DB2
Version 9 vor allem auch ein Ausblick auf die Möglichkeiten in der Nachfolgeversion 10 von
DB2 gegeben werden.
6.1
Analyse der INSERT-Performance im Migrationsfall
Analog zu den Ausführungen in Abschnitt 3.1.1 charakterisiert sich die Migration von nichtnativen XML-Dokumenten in den nativen XML-Datentyp mit fest vorgegebener UnicodeCodepage (UTF-8) aktuell in der DATEV durch folgende Besonderheiten. Den Ausgangspunkt
bilden Quelldokumente, die als VARCHAR- oder CLOB-Dokument jeweils in der EBCDICCodepage und zum Teil über mehrere Tupel hinweg gesplittet datenbankseitig gespeichert sind.
Diese Art der Verteilung ist für die CLOB-Ablage eher selten, bei der nicht-nativen
VARCHAR-Speicherung hingegen sehr häufig anzutreffen. Grund dafür sind systemseitige
Beschränkungen, auf die hier nur kurz eingegangen und für nähere Details auf [Koc11]
verwiesen werden soll.
Durch die angeführten Vorbemerkungen erklärt sich die Aufteilung der Migrationsprozesse in
die Konkatenation der gesplittet gespeicherten Teilstücke, die Konvertierung der Dokumente
von der EBCDIC- in die Unicode-Codepage und den anschließenden Parse-Prozess (siehe
Abbildung 18). Das Ziel der Untersuchungen dieses Abschnitts ist die Erfassung der jeweiligen
Kosten der einzelnen Prozesse in Anlehnung an die Vorbetrachtungen und Vergleichskriterien
aus Kapitel 5. Weiterhin gilt es, die Anteile der Vorgänge an dem gesamten Migrationsvorgang
zu ermitteln, sodass im Anschluss daran eine Einschätzung über besonders zeitkritische
Prozesse abgegeben werden kann.
Den anschließenden Messungen liegt folgende Idee zu Grunde. Durch sukzessive Erfassung der
INSERT-Kosten von dem einfachen Kopieren von Dokumenten hin zur kompletten Migrationsfolge lassen sich schrittweise die Anteile der einzelnen Prozesse durch Differenzbildung
ermitteln. Dabei sind die auf diese Weise berechneten Anteile jedoch nur als Abschätzungen zu
verstehen, da sie zusätzliche Nebenbedingungen nicht einbeziehen. Eine Ausnahme bildet dabei
66
6 Migration und Parsen
die Messreihe zum Konkatenationsprozess. Da dieser nicht unmittelbar innerhalb des INSERTStatements stattfindet, werden seine Kosten auf direktem Weg bestimmt.
Abbildung 19 fasst zur Übersichtlichkeit die notwendigen Messreihen vorab tabellarisch
zusammen. Dabei betitelt die Spalte „Messreihe“ die jeweils durchgeführte Messreihe. Unter
„Differenz“ ist die Berechnungsvorschrift aufgeführt, die angewandt wird, um einen gewünschten Kostenanteil zu ermitteln. Dieser ist in der Spalte „Ergebnis“ beschrieben und wird
in den angegebenen folgenden Abschnitten ausführlich diskutiert. Sofern sich kein Eintrag in
der Spalte „Differenz“ befindet, kann aus der Messreihe direkt auf das abgezielte Messresultat
in der Spalte „Ergebnis“ geschlossen werden.
Messreihe
Differenz
Ergebnis
(1) Einfaches Kopieren
Kosten für das einfache Kopieren (6.1.1)
(2) Konkatenation (optional)
Kosten für die Konkatenation (6.1.2)
(3) Unicode-Konvertierung
(3) – (1)
Kostenanteil der Konvertierung (6.1.3)
(4) XML-Parsen
(4) – (3)
Kostenanteil des XML-Parsens (6.1.4)
Abbildung 19: Messreihen zur INSERT-Performance im Migrationsfall
6.1.1
„Einfaches Kopieren“
Die erste Messreihe erfasst die Kosten für den INSERT von nicht-nativen XML-Dokumenten in
eine Tabelle mit der Codepage EBCDIC. Dabei werden die Dokumente selbst zuvor aus einer
strukturell identischen Tabelle gelesen, wodurch sich wesentliche Zwischenschritte ausschließen lassen. Der auf diese Weise realisierte Prozess lässt sich daher als „einfaches
Kopieren“ der Dokumente bezeichnen. Er dient der Ermittlung einer Kosten-Baseline, die später
herangezogen wird, um durch gezielte Differenzbildung die Kostenanteile der Folgeprozesse zu
ermitteln. Abbildung 20 stellt den Ablauf der aktuellen Testreihe in der bereits bekannten
Überblicksgrafik dar.
67
6 Migration und Parsen
VARCHAR/
CLOB
Konkatenation
XML-Parsen
Input
UnicodeKonvertierung
INSERT
Vorverarbeitung
VARCHAR/
CLOB
(EBCDIC)
XML
Abbildung 20: Überblicksgrafik – „Einfaches Kopieren“
Zu dem hier betrachteten Prozess „Einfaches Kopieren“ sind folgende, den Vorbetrachtungen
aus Kapitel 5 unterliegende Messungen und Variationen durchgeführt worden.
Größe und Anzahl (CLOB und VARCHAR)
Strukturiertheit (CLOB)
Zusammensetzung (CLOB)
In den nachstehenden Abschnitten werden die Ergebnisse analysiert. Zusätzliche Informationen
zum konkreten Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen und zu den
Messwerten der Elapsed-Zeit sind dabei aus Umfangsgründen und gemäß den Bemerkungen aus
Kapitel 5 in den Anhang dieser Arbeit ausgelagert.
Größe und Anzahl (CLOB und VARCHAR)
Der Kurvenverlauf (siehe Abbildung 21) zur Messung des INSERTs von als EBCDIC kodierten
CLOB-Daten in eine Tabelle mit definierter EBCDIC-Codepage zeigt, dass die insgesamt
benötigte CPU-Zeit bei zunehmender Dokumentgröße abnimmt. Das heißt, bei gleichem
Gesamtdatenvolumen ist das Kopieren weniger großer Dokumente weitaus zeitgünstiger als das
vieler kleiner Dokumente. Dieser Abfall flacht allerdings ab einer Dokumentgröße von 10K
stark ab, sodass sich die CPU-Zeit von dort an nur minimal weiter verringert und folglich relativ
gut skaliert.
68
6 Migration und Parsen
40
35
Sekunden
30
25
20
15
CPU - VARCHAR
10
CPU - CLOB
5
0
200B x 1K x
10K x 100K x
500.000 100.000 10.000 1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 21: Messergebnis – „Einfaches Kopieren“ – Größe und Anzahl – CPU-Zeit
Übertragen auf den VARCHAR-Datentyp resultiert ein sehr ähnlicher Kurvenverlauf (siehe
ebenfalls Abbildung 21). Hierbei lässt sich jedoch erkennen, dass die CPU-Zeit bei den
Merkmalsausprägungen unter 10K wesentlich geringer ausfällt als bei der CLOB-Messung.
Zu den weiteren Merkmalsausprägungen konnten aufgrund der Längenbeschränkung des
VARCHAR-Datentyps keine Messungen durchgeführt werden (siehe Abschnitt 5.1.1).
Anhand der betrachteten Messergebnisse lassen sich also insgesamt zwei wesentliche Besonderheiten aufzeigen. Zum einen erfolgt das mengenmäßig gleiche „Kopieren“ von wenigen
großen im EBCDIC-Zeichensatz kodierten Dokumenten schneller als das von vielen kleinen
Dokumenten. Zum anderen dauert die Verarbeitung von CLOB-Daten besonders für XMLDokumente, die kleiner als 10K sind, länger als die von VARCHAR-Daten, wobei diese
Differenz aber mit zunehmender Dokumentgröße abnimmt.
Die obigen Beobachtungen sind wahrscheinlich das Ergebnis mehrerer sich überlagernder
Effekte. Dabei ist zum einen anzumerken, dass jedes Statement, egal ob es sich um statisches
oder dynamisches SQL handelt, eine gewisse Zeit (Overhead) zur Befehlsverarbeitung benötigt,
die noch nicht zur Abarbeitung beiträgt (siehe Abschnitt 5.2.3). Da in den hier verwendeten
Messprozeduren pro Dokument stets ein INSERT ausgeführt wird, ist der gesamte Overhead für
das Einfügen vieler kleiner Dokumente (100.000-mal 1K große Dokumente) erheblich größer,
als der für das Einfügen weniger großer Dokumente (10-mal 10M große Dokumente).
69
6 Migration und Parsen
Der zuletzt betrachtete Sachverhalt bietet jedoch keine Erklärung für den deutlichen Werteunterschied zwischen der CLOB- und der VARCHAR-Messung bis zur Merkmalsausprägung
10K. Hierfür ist vermutlich eine andere Tatsache verantwortlich. DB2 besitzt die Restriktion,
dass es innerhalb einer Page nur maximal ein LOB-Objekt speichern kann [IBM06b]. Daraus
ergibt sich aufgrund der definierten Pagesize von 16K für kleine Dokumentgrößen (bis 10K) ein
sehr geringer Füllgrad für die Datenseiten. Dieser beträgt beispielsweise bei der Messung von
500.000-mal 200B großen Dokumenten in 16K-Seiten ungefähr ein Prozent, was für die
Gesamtdatenmenge von 100M zu einer zumindest theoretisch unnötigen Allokation von fast 8G
führt. Das Anfordern und Wegschreiben von Seiten verursacht stets I/O-Vorgänge und diese
wiederum sowohl das Steigen der CPU- als auch das der Elapsed-Zeit. Damit lässt sich also
eine Erklärung für den Werteunterschied zwischen der CLOB- und der VARCHAR-Messkurve
geben.
Zu einem wesentlichen Teil trägt aber auch die Art der internen Speicherung der Datentypen zu
dem betrachteten Werteunterschied bei. Während es sich bei dem CLOB-Datentyp in DB2
ausschließlich um einen Outline-Datentyp handelt, ist der VARCHAR-Datentyp ein reiner
Inline-Datentyp. Die genauen Bedeutungen dieser Begrifflichkeiten und die damit verbundenen
Strukturen werden in [Koc11] ausführlich beschrieben. An dieser Stelle bleibt lediglich
erwähnenswert, dass die Outline-Speicherung durch den notwendigen Umgang mit zusätzlichen
Objekten stets etwas ineffizienter arbeitet als ihr Pendant die Inline-Speicherung. Unter anderem
aus diesem Grund wurde in der Nachfolgeversion 10 des in dieser Arbeit betrachteten DB2
Version 9 auch das „inline LOB“-Feature implementiert. Dieses erlaubt zusätzlich zu dem
bisherigen Outline-Datentyp LOB auch die Deklaration von LOB-Objekten als Inline-Datentyp.
Näheres dazu findet sich in [IBM11v].
Strukturiertheit (CLOB)
Die herkömmliche, auf Character-Strings basierende, nicht-native Speicherung von XMLDokumenten nutzt keine Semantik über deren Inhalt und behandelt sie als eine Art Black Box.
Aus diesem Grund liegt bereits vor der Auswertung der strukturellen Messreihe die Vermutung
nahe, dass die Strukturiertheit der XML-Dokumente keinen Einfluss auf die INSERTPerformance der nicht-nativen XML-Speicherung hat. Unter Berücksichtigung der in Abschnitt
5.4 näher beschriebenen Schwankungen bestätigt sich diese Annahme durch Abbildung 22.
Somit lässt sich in allen untersuchten Testfällen bei der CPU-Zeit eine konstante Ausprägung
70
6 Migration und Parsen
von ungefähr 0,2 Sekunden für das „einfache Kopieren“ der Gesamtdatenmenge von 100M
erkennen. Da die Testdokumente für die strukturelle Messreihe stets 100K groß sind, entspricht
diese Zeit gleichzeitig dem Wert der weiter oben durchgeführten Messung für 100K große
Dokumente. Dementsprechend lässt sich formulieren, dass die Strukturiertheit, wie vermutet,
keinen Einfluss auf die INSERT-Performance von nicht-nativen XML-Dokumenten als
EBCDIC-Daten hat.
0,25
Sekunden
0,2
0,15
0,1
0,05
CPU
0
Strukturiertheit
Abbildung 22: Messergebnis – „Einfaches Kopieren“ – Strukturiertheit – CPU-Zeit
Zusammensetzung (CLOB)
Aufgrund der im vorherigen Punkt ermittelten Ergebnisse ist für die Prozesskette „Einfaches
Kopieren“ von der Präsentation weiterer Ergebnisse zum Einfluss der Zusammensetzung der
Dokumente abgesehen worden. Die Erklärung dazu liefert die oben betrachtete Strukturiertheitsmessung. Da sich die Strukturiertheit der Dokumente nicht auf die INSERT-Performance
innerhalb einer EBCDIC-Umgebung auswirkt, gilt dies folglich auch für die Zusammensetzung
der Dokumente. Dahingehende Messungen würden somit lediglich die bereits zuvor betrachteten größenmäßigen Charakteristika aufzeigen und keine zusätzlichen Erkenntnisse liefern.
Trotzdem lässt sich daraus folgern, dass das „einfache Kopieren“ für kumulierte XMLDokumente wesentlich schneller abläuft, als für über viele Dokumente verteilt gespeicherte
Entitätsausprägungen.
71
6 Migration und Parsen
6.1.2
Konkatenation
In DB2 werden zur nicht-nativen Speicherung von XML-Dokumenten vorwiegend die Datentypen VARCHAR und CLOB verwendet. Dabei sind auf diese Weise abgelegte Daten in der
maximalen Zeichenlänge beschränkt. Abhängig von der verwendeten Pagesize kann ein als
VARCHAR gespeichertes Dokument höchstens eine Länge von 32K (vielen Zeichen) besitzen.
Für CLOB-Dokumente gilt eine Längenbeschränkung von maximal 2G. Hierbei ist aber zu
beachten, dass durch die Subsystem-Parameter LOBVALA und LOBVALS noch weitere
größenmäßige Restriktionen für CLOB-Daten existieren. [Koc11]
Aufgrund der dargelegten Beschränkungen werden in der DATEV bisher XML-Dokumente zum
Teil über mehrere Tupel hinweg gespeichert. Durch dieses Vorgehen lassen sich die oben
beschriebenen Restriktionen/Längenbeschränkungen überwinden. Abbildung 23 zeigt das
Prinzip der Aufteilung an einem Beispiel. Weitere Details hierzu finden sich in [Koc11].
nicht-natives XML
(„zerhackt“)
<customerinfo id="1001">
<name>
Mustermann
</name>
<phone type="work">
408-555-1358
</phone>
</customerinfo>
Tupel 1
<customerinfo id="100
1"><name>Mustermann</
Tupel 2
name><phone type="wor
k">408-555-1358</phon
Tupel 3
e></customerinfo>
Abbildung 23: Verteilung über mehrere Tupel [Koc11]
Im Rahmen einer Migration der nicht-nativen XML-Dokumente in den nativen XML-Datentyp
müssen die einzelnen Teile der Dokumente wieder zusammengefügt werden. Dies lässt sich
mithilfe der CONCAT-Funktion [IBM11a] des DB2 realisieren. [Koc11] betrachtet dabei zwei
verschiedene Szenarien – die Konkatenation mittels Stored Procedure und die Konkatenation
per Recursive SQL [IBM04a]. Da der weitere Fokus auf der Performance des Konkatenationsprozesses liegt, soll für die den Varianten zugrunde liegenden Überlegungen auf [Koc11]
verwiesen werden.
72
6 Migration und Parsen
Die Konkatenation mittels Recursive SQL ist genau wie die Variante per Stored Procedure
kostenmäßig betrachtet nicht unmittelbar der INSERT-Performance zuzuordnen. Vielmehr trägt
der Prozess zum vorangehenden SELECT-basierten Zugriff auf die Daten bei, weshalb
demzufolge keine Differenzbildung mit der in Abschnitt 6.1.1 erfassten Kosten-Baseline durchgeführt wird. Stattdessen werden die ermittelten Ergebnisse mit denen eines normalen
SELECTs der Daten verglichen. Die diesem gegenüber entstehenden höheren Kosten sind als
Zusatzaufwand zu verstehen, der resultiert, wenn die Konkatenation von verteilt („zerhackt“)
abgelegten nicht-nativen XML-Dokumenten innerhalb des Migrationsablaufs notwendig ist.
Das am Ende des Konkatenationsprozesses wieder vollständig zusammengefügte nicht-native
XML-Dokument wird innerhalb einer CLOB-Variablen gespeichert. Der Grund dafür ist die,
verglichen mit dem VARCHAR-Datentyp, größere maximale Länge des CLOB-Datentyps, die
es erlaubt, nahezu beliebig große XML-Dokumente abbilden zu können. Bei der Messung der
Zusatzkosten im Konkatenationsfall sind somit stets die Kosten für den SELECT von CLOBDaten als verrechnete Referenzwerte gewählt. Der Ablauf der durchgeführten Testreihe gestaltet
sich wie im Überblick in Abbildung 24 dargestellt.
VARCHAR/
CLOB
Konkatenation
XML-Parsen
Input
UnicodeKonvertierung
INSERT
Vorverarbeitung
XML
Abbildung 24: Überblicksgrafik – Konkatenation
Zur Erfassung des aus der Konkatenation entstehenden Zusatzaufwands ist folgende
Vorgehensweise verwendet worden. Den Ausgangspunkt bilden stets 100.000 1K große XMLDokumentteile. Diese werden entsprechend den Merkmalsausprägungen des Kriteriums der
Größe und Anzahl blockweise konkateniert. Auf diese Weise erfolgt zum Beispiel zur
Bestimmung der Messwerte für die Merkmalsausprägung „100K x 1.000“ die 1.000-fache
Wiederholung der Konkatenation von jeweils 100 1K großen Dokumentteilen zu je einem 100K
großen Gesamtdokument. In Anlehnung an die einzelnen Konkatenationsabläufe ist zur
einfacheren Verständlichkeit die Bezeichnung der Merkmalsausprägungen erweitert worden.
73
6 Migration und Parsen
Daher betitelt zum Beispiel fortan „100 x 1K x 1.000“ die zuvor betrachtete Ausprägung (siehe
Abbildung 25). Die Herleitung der weiteren Bezeichnungen erfolgt in Analogie dazu.
100
x
1K
x
Zusammensetzung
eines
Ergebnisdokuments
1000
Anzahl an
Ausführungen
Abbildung 25: Beispiel für die Bezeichnung einer Merkmalsausprägung
In dem Ablauf der hier beschriebenen Messreihe zeigen sich viele Parallelen zu den Ausführungen des Kriteriums der Zusammensetzung (Abschnitt 5.1.3). Vereinfacht gesprochen
wurde der dazu verwendete Testdatenbestand ebenfalls durch die Konkatenation einer gewissen
Anzahl von 1K großen Dokumenten erzeugt. Den für die Messreihe der Konkatenation
verwendeten Messprozeduren liegt gemäß den obigen Ausführungen eine ähnliche Verfahrensweise zugrunde. Dementsprechend ließen sie sich durch geringfügige Modifizierungen auch für
die Erzeugung des Testdatenbestands zum Kriterium der Zusammensetzung nutzen, was jedoch
in dieser Arbeit nicht von weiterer Bedeutung sein wird.
Zu dem hier betrachteten Prozess der Konkatenation sind folgende, den Vorbetrachtungen aus
Kapitel 5 unterliegende Messungen und Variationen durchgeführt worden.
Größe und Anzahl (CLOB und VARCHAR)
Zusammensetzung (CLOB)
In den nachstehenden Abschnitten werden die Ergebnisse analysiert. Zusätzliche Informationen
zum konkreten Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen und zu den
Messwerten der Elapsed-Zeit sind dabei aus Umfangsgründen und gemäß den Bemerkungen aus
Kapitel 5 in den Anhang dieser Arbeit ausgelagert.
74
6 Migration und Parsen
Größe und Anzahl (CLOB und VARCHAR)
Weiter oben ist bereits erwähnt worden, dass die folgenden Ausführungen der Ermittlung des
Zusatzaufwands dienen, der durch die Konkatenation der einzelnen Dokumentteile entsteht. Zu
dessen Bestimmung müssen den folgenden Messergebnissen als Referenzwerte die Kosten für
den einfachen SELECT von CLOB-Dokumenten gegengerechnet werden. Aus Kompaktheitsgründen ist die Ermittlung dieser Differenz bereits direkt in die folgende Diagrammdarstellung
integriert worden, sodass stets die Zusatzkosten abgebildet sind.
Gemäß den Vorbemerkungen werden in den anschließenden Ausführungen die Varianten Konkatenation per Stored Procedure und Konkatenation mithilfe von Recursive SQL betrachtet. Für
die zuletzt genannte Variante ergeben sich dabei abhängig vom verwendeten Datentyp
Einschränkungen. Es ist nicht möglich, nicht-nativ als VARCHAR gespeicherte XMLDokumentteile rekursiv zu konkatenieren. Die Ursache dafür liegt in der bereits erwähnten
Längenbeschränkung des VARCHAR-Datentyps. Eine ausführliche Begründung zu diesem
Sachverhalt liefert [Koc11]. Die Konkatenation mittels Recursive SQL ist aber auch für die
Verarbeitung von nicht-nativ als CLOB abgelegten XML-Dokumentteilen nicht uneingeschränkt realisierbar. Hier stößt DB2 ab der Merkmalsausprägung „1.000 x 1K x 100“ an die
Grenze der gleichzeitig im virtuellen Speicher verarbeitbaren LOB-Datenmenge. Diese wird
durch den Subsystem-Parameter LOBVALS spezifiziert, wobei der Parameter LOBVALA auf
ähnliche Weise die LOB-Verarbeitung limitiert. Nähere Informationen dazu finden sich in
[Koc11].
Abbildung 26 zeigt unter Berücksichtigung der zuvor erwähnten Einschränkungen das Ergebnis
sämtlicher zur Konkatenation durchgeführter Messreihen. Dabei weicht die gewählte
logarithmische21 Skalierung der Zeitachse bewusst von den bislang betrachteten Diagrammen
ab. Dies begründet sich durch den zum Teil großen Werteunterschied zwischen den einzelnen
Messergebnissen, auf die nun im Detail eingegangen werden soll.
21
Logarithmus zur Basis 10
75
6 Migration und Parsen
10000
Sekunden
1000
100
CPU - CLOB - SP
10
CPU - VARCHAR - SP
CPU - CLOB - RSQL
1
Größe und Anzahl
Abbildung 26: Messergebnis – Konkatenation – Größe und Anzahl – CPU-Zeit
Bei der Auswertung der Messreihen kann zuerst einmal festgehalten werden, dass sich die
Messergebnisse der Konkatenation per Stored Procedure (SP) für die unterschiedliche
Ausgangsform der Teile eines XML-Dokuments (einerseits als VARCHAR- und andererseits
als CLOB-Dokument) fast nicht unterscheiden. Dafür verantwortlich ist sehr wahrscheinlich die
in beiden Fällen zur Speicherung des Zwischenergebnisses verwendete CLOB-Variable. Die
Ausgangsform der Daten hat demnach kaum Einfluss auf den hier betrachteten Konkatenationsvorgang. Dementsprechend lässt sich für die Konkatenation per Stored Procedure generell
feststellen, dass die CPU-Zeit von einer Merkmalsausprägung zu nächst größeren stets ungefähr
um den Faktor zehn ansteigt. Dieses Kurvenwachstum ist in Analogie zu der gleichermaßen
kontinuierlich zehnfach zunehmenden Dokumentgröße zu sehen, die als Ergebnis des jeweiligen
Konkatenationsprozesses entsteht. Da aber die CONCAT-Funktion entsprechend der obigen
Betrachtungen stets 100.000-fach ausgeführt wird, lässt sich formulieren, dass die „Stored
Procedure“-basierte Konkatenation von großen Dokumenten wesentlich aufwändiger ist, als die
von kleinen Dokumenten.
Für die Konkatenation mittels Recursive SQL (RSQL) trifft die zuletzt angeführte Aussage
nicht zu. Hier ist in der CPU-Zeit bei allen Merkmalsausprägungen ein nahezu konstanter
Konkatenationsaufwand erkennbar, der weit über den Kosten der Konkatenation per Stored
Procedure liegt. Die Ursache dafür lässt sich in der Art und Weise des rekursiven Vorgehens
vermuten, das in [Koc11] näher beschrieben wird. Auf eine ausführliche Betrachtung
dieses Zusammenhangs soll daher verzichtet werden. Wichtiger ist die Erkenntnis, dass die
76
6 Migration und Parsen
Konkatenation von XML-Dokumentteilen per Recursive SQL wesentlich uneffizienter ist als
die Variante mittels Stored Procedure. Letztere ist zudem auch uneingeschränkt22 einsetzbar,
sodass sich eine klare Empfehlung hinsichtlich dieser Variante aussprechen lässt.
Zusammensetzung (CLOB) (und Strukturiertheit (CLOB))
Die CONCAT-Funktion in DB2 ist eine Funktion zur Verknüpfung von Character-Strings.
Diese bestehen jeweils aus einer beliebigen Folge von Zeichen, deren Aneinanderreihung aber
keinen Einfluss auf ihre Verarbeitung hat. Die als Character-String in verteilter Form abgelegten
nicht-nativen XML-Dokumente werden mithilfe der CONCAT-Funktion demnach ohne
Betrachtung ihres Inhalts konkateniert. Für das Kriterium der Strukturiertheit ergeben sich daher
keine neuen Erkenntnisse. Die Messreihe zur Zusammensetzung der Dokumente liefert
erwartungsgemäß die gleichen Ergebnisse wie die Messreihe zum Kriterium der Größe und
Anzahl, sodass die inhaltliche Zusammensetzung der Dokumente ebenfalls keinen Einfluss auf
die Resultate hat. Für eine ausführlichere Begründung soll hier – wegen der bestehenden
Analogie – auf Abschnitt 6.1.1 verwiesen werden.
6.1.3
Unicode-Konvertierung
Der native XML-Datentyp ist in DB2 Version 9 ausschließlich als Outline-Datentyp realisiert
[Koc11]. Dementsprechend nutzt DB2 für die Datenablage unter anderem zusätzliche XMLTablespaces und darin enthaltene XML-Auxiliary-Tabellen [Koc11]. Diese Strukturen werden
stets implizit von DB2 angelegt, wobei als Codepage generell der Unicode-Zeichensatz definiert
wird. Im Detail betrachtet handelt es sich bei der nativen Ablage von XML-Dokumenten um die
Zeichenkodierung UTF-8. Somit ist in DB2 eine auf der EBCDIC-Codepage basierende
Speicherung von XML-Dokumenten nicht möglich.
Aus den obigen Sachverhalten ergibt sich, dass für die Migration von nicht-nativen XMLDokumenten in den nativen XML-Datentyp ein Konvertierungsprozess notwendig ist. Dieser
muss, wie eingangs des Abschnitts 6.1 geschildert, die vorhandenen EBCDIC-Dokumente in die
22
für alle Datentypen und für alle Merkmalsausprägungen
77
6 Migration und Parsen
Unicode-Codepage UTF-8 überführen. Damit die Kosten für diesen Schritt separat vom
anschließenden XML-Parse-Prozess erfasst werden können, liegt der hierzu durchgeführten
Messreihe die folgende Idee zugrunde. Wie in Abbildung 27 ersichtlich wird die Prozesskette
der Migration dabei nur bis zum Schritt des XML-Parsens ausgeführt. Dies geschieht durch das
Einfügen der Dokumente in eine CLOB- beziehungsweise VARCHAR-Spalte mit zugrunde
liegender Unicode-Codepage UTF-8. Somit wird zwar der Prozess der Unicode-Konvertierung
ausgeführt, jedoch nicht der des XML-Parsens. Durch die in Abschnitt 6.1 bereits beschriebene
Differenzbildung mit der Kosten-Baseline aus Abschnitt 6.1.1 lässt sich eine Aufwandsabschätzung für den Performance-Anteil des Konvertierungsprozesses berechnen.
VARCHAR/
CLOB
Konkatenation
XML-Parsen
Input
UnicodeKonvertierung
INSERT
Vorverarbeitung
VARCHAR/
CLOB
(Unicode)
XML
Abbildung 27: Überblicksgrafik – Unicode-Konvertierung
Zu dem hier betrachteten Prozess der Unicode-Konvertierung sind folgende, den Vorbetrachtungen aus Kapitel 5 unterliegende Messungen und Variationen durchgeführt worden.
Größe und Anzahl (CLOB und VARCHAR)
Strukturiertheit (CLOB)
Zusammensetzung (CLOB)
In den nachstehenden Abschnitten werden die Ergebnisse analysiert. Zusätzliche Informationen
zum konkreten Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen und zu den
Messwerten der Elapsed-Zeit sind dabei aus Umfangsgründen und gemäß den Bemerkungen aus
Kapitel 5 in den Anhang dieser Arbeit ausgelagert.
78
6 Migration und Parsen
Größe und Anzahl (CLOB und VARCHAR)
In den Vorbetrachtungen dieses Abschnitts ist insbesondere auf die Differenzbildung mit der
Kosten-Baseline aus Abschnitt 6.1.1 hingewiesen worden, die durchgeführt werden muss, um
den konkreten (Zusatz-)Aufwand der Unicode-Konvertierung abschätzen zu können. Die dazu
notwendige Berechnung ist aus Kompaktheitsgründen bereits direkt in die in Abbildung 28
dargestellten Messresultate einbezogen worden. Dementsprechend sind hier nur die Kosten
abgebildet, die zusätzlich zu den Kosten für das „einfache Kopieren“ durch die UnicodeKonvertierung der Daten entstehen.
4,5
4
3,5
Sekunden
3
2,5
2
CPU - VARCHAR
1,5
CPU - CLOB
1
0,5
0
200B x 1K x
10K x 100K x
500.000 100.000 10.000 1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 28: Messergebnis – Unicode-Konvertierung – Größe und Anzahl – CPU-Zeit
Bei der Betrachtung der Messergebnisse aus Abbildung 28 fällt auf, dass bei der Konvertierung
von kleinen Dokumenten (bis zu 10K) ein relativ großer Unterschied zwischen der CLOB- und
der VARCHAR-Messung besteht. So benötigt beispielsweise die Konvertierung von EBCDIC
nach Unicode für 500.000 VARCHAR-Dokumente der Größe 200B ungefähr 0,4 Sekunden.
Demgegenüber entsteht für die gleiche Konvertierung von CLOB-Dokumenten ungefähr der
zehnfache Aufwand, sodass für die CPU-Zeit hier rund 4 Sekunden gemessen werden konnten.
Während für die Konvertierung von nicht-nativen als VARCHAR gespeicherten XMLDokumenten in die Unicode-Codepage über alle betrachteten Merkmalsausprägungen hinweg
ein konstanter Zusatzaufwand bezogen auf die CPU-Zeit besteht, ist dies für CLOB-Daten nicht
79
6 Migration und Parsen
der Fall. Hier ist bis zu der Ausprägung „10K x 10.000“ eine abnehmende Kurve zu sehen, die
sich mit zunehmender Dokumentgröße immer mehr der VARCHAR-Kurve annähert, bis sie
sich letztendlich fast treffen. Ab der Ausprägung „10K x 10.000“ bleiben dann auch die
Messwerte der CLOB-Messung relativ konstant. Eine Betrachtung zu diesen Merkmalsausprägungen für die Konvertierung von VARCHAR-Daten ist leider aus den in Abschnitt 5.1.1
genannten Gründen (Längenbeschränkung des VARCHAR-Datentyps) nicht möglich. Die
Vermutung liegt aber nahe, dass sich die Werte ab der Ausprägung „10K x 10.000“ nahezu
identisch verhalten würden.
Der verglichen mit den anderen Ergebnissen erhöhte Zusatzaufwand für die Verarbeitung
kleiner XML-Dokumente im CLOB-Fall ist bereits in Abschnitt 6.1.1 zu beobachten gewesen.
In jenem Abschnitt ist davon ausgegangen worden, dass dieser Aufwand aus der Art und Weise
resultiert, wie DB2 LOB-Objekte verarbeitet (speichert). Es ist lediglich zulässig, maximal ein
LOB-Objekt in einer Page zu verwalten, was für beispielsweise 200B kleine LOB-Dokumente
bei einer Pagesize von 16K einen sehr geringen Seitenfüllgrad (ungefähr ein Prozent der
Bruttodaten) bedeutet. Aus diesem Grund werden in den Messungen bei den Merkmalsausprägungen bis einschließlich „10K x 10.000“ weitaus mehr Seiten verarbeitet als in den
verbleibenden Fällen, woraus demzufolge auch ein erhöhter Aufwand resultiert. Dies trifft
gleichermaßen auch auf den in diesem Abschnitt betrachteten Zusatzaufwand der UnicodeKonvertierung zu. Schließlich befinden sich die zu konvertierenden Daten unabhängig von ihrer
Größe ebenfalls in 16K großen Seiten und werden anschließend auch wieder in diese zurückgeschrieben. Für detailliertere Ausführungen dazu wird auf Abschnitt 6.1.1 verwiesen.
Strukturiertheit (CLOB) und Zusammensetzung (CLOB)
Die Konvertierung von EBCDIC-Dokumenten in die Unicode-Codepage ist genau wie auch die
in den vorangehenden Abschnitt 6.1.2 betrachtete CONCAT-Funktion unabhängig von deren
Inhalt. Demzufolge ergeben sich bei der Messreihe zum Kriterium der Strukturiertheit über alle
Merkmalsausprägungen hinweg auch hier konstante CPU-Zeiten. Die Messreihe zum Kriterium
der Zusammensetzung liefert ebenfalls keine neuen Erkenntnisse und zeigt demnach das gleiche
Resultat wie auch die Untersuchung zum Kriterium der Größe und Anzahl. Demnach macht es
aber für die Unicode-Konvertierung kaum einen Unterschied, ob die Dokumente in zusammengesetzter Form oder einzeln verarbeitet werden. Eine (erneute) Begründung der Ergebnisse soll
80
6 Migration und Parsen
an dieser Stelle nicht erfolgen. Dazu wird wegen der bestehenden Analogie auf die Ausführungen der vorangehenden Abschnitte verwiesen.
6.1.4
XML-Parsen der Dokumente
Das XML-Parsen der nicht-nativen XML-Dokumente in den nativen XML-Datentyp ist der
letzte wesentliche Schritt der Migration. Hier wird die Transformation der Dokumente in eine
native binäre Ablageform durchgeführt, in der die Daten letztendlich auch physisch in DB2
abgelegt werden. Ausführliche Informationen zum Prozess des XML-Parsens finden sich in
Abschnitt 3.1.2. Den hier nun komplett betrachteten Ablauf einer Migration stellt Abbildung 29
dar.
VARCHAR/
CLOB
Konkatenation
XML-Parsen
Input
UnicodeKonvertierung
INSERT
Vorverarbeitung
XML
Abbildung 29: Überblicksgrafik – XML-Parsen der Dokumente
Ähnlich zu der Vorgehensweise bei der Ermittlung des Aufwands für die UnicodeKonvertierung ist auch zur Abschätzung des reinen Parse-Aufwands eine Differenzbildung
nötig. Wie bereits in Abschnitt 6.1 beschrieben und in Abbildung 19 gezeigt, müssen dazu die
Gesamtkosten des vorangehenden Ablaufs bis einschließlich zur Konvertierung von den hier
ermittelten Messergebnissen subtrahiert werden. Diese Differenzbildung wird aus Kompaktheitsgründen direkt in die weiteren Diagrammdarstellungen dieses Abschnitts einbezogen.
Dementsprechend verstehen sich die aufgeführten Ergebnisse als zusätzlicher Zeitaufwand, der
für das Parsen von nicht-nativen XML-Dokumenten in den nativen XML-Datentyp resultiert.
Zu dem hier betrachteten Prozess des XML-Parsens sind folgende, den Vorbetrachtungen aus
Kapitel 5 unterliegende Messungen und Variationen durchgeführt worden.
81
6 Migration und Parsen
Größe und Anzahl (CLOB und VARCHAR)
Strukturiertheit (CLOB)
Zusammensetzung (CLOB)
In den nachstehenden Abschnitten werden die Ergebnisse analysiert. Zusätzliche Informationen
zum konkreten Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen und zu den
Messwerten der Elapsed-Zeit sind dabei aus Umfangsgründen und gemäß den Bemerkungen aus
Kapitel 5 in den Anhang dieser Arbeit ausgelagert.
Größe und Anzahl (CLOB und VARCHAR)
Bei den durch Differenzbildung errechneten Kosten für den XML-Parse-Prozess zeigt sich
hinsichtlich des Kriteriums der Größe und Anzahl anders als bei den zuvor betrachteten
Messergebnissen diesmal für die VARCHAR-Messung ein erhöhter Aufwand bei der Verarbeitung kleiner XML-Dokumente (siehe Abbildung 30). Demgegenüber ist bei der Messreihe,
die nicht-native als CLOB gespeicherte XML-Dokumente in das native XML-Format parst, eine
bis zur Merkmalsausprägung „10K x 10.000“ steigende Kurve der CPU-Zeit zu beobachten,
die ab diesem Punkt jedoch konstant bleibt. Gemäß den einführenden Anmerkungen aus
Abschnitt 6.1 dürfen die hier beschriebenen Resultate nicht eins-zu-eins als Kosten für den
XML-Parse-Prozess interpretiert werden. Vielmehr stellen sie die Zusatzkosten dar, die bei der
in Abbildung 19 aufgezeigten Differenzbildung für den Parse-Prozess entstehen.
14
12
Sekunden
10
8
6
CPU - VARCHAR
4
CPU - CLOB
2
0
200B x 1K x
10K x 100K x
500.000 100.000 10.000 1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 30: Messergebnis – XML-Parsen – Größe und Anzahl – CPU-Zeit
82
6 Migration und Parsen
Bei den hier durchgeführten Messreihen besteht erstmalig ein wesentlicher struktureller
Unterschied zwischen Ausgangs- (VARCHAR beziehungsweise CLOB) und Zieldatentyp
(XML). Dabei sind alle der drei genannten Datentypen VARCHAR, CLOB und XML in DB2
unterschiedlich implementiert. Eine ausführliche Betrachtung ihrer zugehörigen Strukturen
findet sich in [Koc11]. An dieser Stelle ist lediglich die Bemerkung wichtig, dass sich anhand
der Umsetzung der Datentypen unterschiedliche Vor- und Nachteile ergeben und diese unter
anderem auch Einfluss auf die Performance der jeweils zu verarbeitenden Daten haben.
Ein wesentlichster Unterschied zwischen den drei hier betrachteten Datentypen ist die Art
und Weise, wie effizient sie sich in Datenbankseiten verwalten lassen. Hier zeigt sich bei der
Verarbeitung von LOB-Daten ein erhebliches Defizit, das weder für den VARCHAR-, noch für
den XML-Datentyp besteht. Wie oben erwähnt, ist es lediglich möglich, pro Page ein LOBObjekt zu verwalten – egal wie klein dieses ist. Da bei den hier durchgeführten Messreihen die
Seitengröße für den LOB-Tablespace auf 16K festgelegt wurde, ergibt sich für die nicht-native
CLOB-Verarbeitung von kleinen XML-Dokumenten ein entsprechend kleiner Füllgrad der
Seiten (siehe Abschnitt 6.1.1). Dieses „Problem“ ergibt sich für den ansonsten in DB2 ähnlich
zu den LOB-Datentypen implementierten nativen XML-Datentyp nicht. Verglichen mit diesem
Datentyp ist dementsprechend die Verarbeitung von kleinen, im CLOB-Datentyp vorliegenden
XML-Dokumenten aufwändiger.
In Anlehnung an den dargestellten Sachverhalt wird also in der obigen Messauswertung der
CLOB-Kurve der für kleine Dokumente aufwändige CLOB-INSERT von dem in Relation dazu
günstigeren XML-INSERT mit darin eingeschlossenem Parse-Aufwand subtrahiert23. Das
Ergebnis dieser Differenz entspricht somit nicht den gewünschten „reinen“ Kosten des XMLParse-Prozesses. Stattdessen zeigt das Resultat der CLOB-Messreihe den Parse-Aufwand
vermindert um die Einsparung durch die Verwendung des XML-Datentyps.
Das zuletzt betrachtete „Seitenfüllgradproblem“ äußert sich nur bei dem CLOB-Datentyp, bei
den beiden anderen hier betrachteten Datentypen XML und VARCHAR nicht. Demnach kann
die ermittelte Kurve der CPU-Zeit bezogen auf die VARCHAR-Messung als eine geeignetere
Abschätzung für den Aufwand des XML-Parse-Prozesses angesehen werden. Die bereits oben
23
In beiden Betrachtungen sind zusätzlich auch die Kosten für die Unicode-Konvertierung enthalten, die
sich aber durch die Differenzbildung aufheben.
83
6 Migration und Parsen
angesprochene bis zur Merkmalsausprägung „10K x 10.000“ abnehmende CPU-Zeit bei der
VARCHAR-Messreihe resultiert vermutlich in Analogie zu Abschnitt 6.1.1 durch eine gewisse
Art an Overhead bei der Statement-Verarbeitung. Dieser fällt entsprechend für die vielfache
Initiierung des XML-Parse-Prozesses in den z/OS XML System Services [IBM12b] bei vielen
kleinen zu parsenden Dokumenten stärker ins Gewicht, als für die wenigen Parse-Prozesse bei
einer geringen Anzahl großer Dokumente.
Da der als „Seitenfüllgradproblem“ betitelte Effekt ab einer Dokumentgröße von 10K entfällt,
kann davon ausgegangen werden, dass die ab diesem Punkt abgebildeten Resultate der
CLOB-Messung wieder als Kennwerte zur Abschätzung des Parse-Aufwands geeignet sind.
Dies begründet sich auch durch die Wertegleichheit der beiden Messreihen VARCHAR und
CLOB in der Merkmalsausprägung „10K x 10.000“.
Strukturiertheit (CLOB)
Entgegen den vorangehenden Messungen zum Kriterium der Strukturiertheit zeigen sich bei der
Untersuchung der Performance des XML-Parse-Prozesses erhebliche, in diesem Ausmaß nicht
erwartete Unterschiede in den einzelnen Merkmalsausprägungen. Abbildung 31 veranschaulicht
die Resultate der durchgeführten Messreihe, wobei auch hier die eingangs von Abschnitt 6.1
beschriebene Differenzbildung bereits in die einzelnen Ergebniswerte eingerechnet wurde.
Anhand der dargestellten Resultate lassen sich zwei generelle Tendenzen ableiten. Einerseits ist
der Parse-Aufwand von flachen XML-Dokumenten größer als von tiefen und nochmals größer
als von balancierten Dokumenten. Zum anderen besteht auch ein Unterschied in der Effizienz,
mit der einzelne Knoten eines XML-Dokuments geparst werden. So hat sich im Wesentlichen
herausgestellt, dass das Parsen von Attributknoten am meisten Zeit in Anspruch nimmt. Darauf
folgt die Verarbeitung von Elementknoten. Textknoten wiederum lassen sich am schnellsten
parsen. Die Ursache der beschriebenen Effekte liegt in der Art und Weise begründet, wie der
Parse-Prozess für XML-Dokumente durch die z/OS XML System Services durchgeführt wird.
Genaue Details zu deren Implementierung sind allerdings nicht veröffentlicht worden.
84
6 Migration und Parsen
140
Sekunden
120
100
80
60
40
20
CPU
0
Strukturiertheit
Abbildung 31: Messergebnis – XML-Parsen – Strukturiertheit – CPU-Zeit
Aus den ermittelten Resultaten können hinsichtlich der Parse-Performance folgende Richtlinien/Empfehlungen zur Modellierung von XML-Dokumenten abgeleitet werden. Elementknoten sollten der Verwendung von Attributknoten vorgezogen werden. An geeigneter Stelle
macht es auch Sinn, Attributknoten durch Textknoten zu ersetzen. Diese haben jedoch den
Nachteil, dass sie unstrukturiert sind und ein Elementknoten nur maximal einen Textknoten
enthalten kann. Bezogen auf die Hierarchie von XML-Dokumenten empfiehlt es sich, diese
möglichst tief – im Idealfall allerdings balanciert – zu modellieren. Es sei aber hier nochmals
auf die Aussage aus Abschnitt 5.1.2 verwiesen, die besagt, dass die Modellierung von XMLDokumenten nie primär an deren Performance festgemacht werden sollte. Zudem ist der Prozess
des Parsens nicht „alles“, weshalb an dieser Stelle auch der Hinweis auf die PerformanceErgebnisse zum Kriterium der Strukturiertheit aus Abschnitt 8.2.1 anzuführen ist.
Zusammensetzung (CLOB)
Bei der Untersuchung der XML-Parse-Performance zeigt sich für das Kriterium der Zusammensetzung ein Kurvenlauf, der diesmal nicht nur von der Größe der XML-Dokumente (siehe oben)
abhängt. Demzufolge lässt sich in Abbildung 32 ab der Merkmalsausprägung „10K x 10.000“
eine kontinuierliche Abnahme des Parse-Aufwands in der CPU-Zeit erkennen. Die erste
Ausprägung „1K x 100.000“ weicht dabei von dem restlichen Kurvenverlauf ab. Unter
Einbeziehung der bereits oben zum Kriterium der Größe und Anzahl erwähnten Überlegungen
zum „Seitenfüllgradproblem“ ist diese Abweichung aber auf die unterschiedliche Verarbeitungsform der hier involvierten Datentypen CLOB und XML zurückführbar. Eine ausführliche
85
6 Migration und Parsen
Begründung dazu ist bereits geliefert worden. Dabei sei besonders auf die bei dem Kriterium
der Größe und Anzahl „realistischere“ Kurve der VARCHAR-Messreihe hingewiesen, die einen
erheblichen Abfall zeigt. Dieser lässt sich in analoger Begründung auf die in Abbildung 32
dargestellten Ergebnisse übertragen, sodass auch hier von einem insgesamt abfallenden
Aufwand – die CPU-Zeit betreffend – die Rede sein kann.
4
3,5
Sekunden
3
2,5
2
1,5
CPU
1
0,5
0
1K
10K
(x 100.000) (x 10.000)
100K
(x 1.000)
1M
(x 100)
10M
(x 10)
Zusammensetzung (und Anzahl)
Abbildung 32: Messergebnis – XML-Parsen – Zusammensetzung – CPU-Zeit
Obwohl die Betrachtung zur Strukturiertheit gezeigt hat, dass das Parsen von flacheren XMLDokumenten mehr Zeit in Anspruch nimmt, als das von Dokumenten mit tieferer Struktur, kann
hier trotzdem die Aussage getroffen werden, dass kumulierte und somit in Relation zu ihrer
Größe flachere XML-Dokumente sich generell schneller parsen lassen als einzelne Dokumente.
Das bedeutet, dass aus Sicht der Parse-Performance für die Modellierung von XMLDokumenten die Empfehlung gegeben werden kann, mehrere Entitätsausprägungen innerhalb
eines einzigen Dokuments zu beschreiben. Hier muss jedoch wiederholt angemerkt werden,
dass die Modellierung von XML-Dokumenten nicht primär von der (Parse-)Performance
abhängig gemacht werden sollte.
86
6 Migration und Parsen
6.1.5
Zusammenfassung und Verteilung der Kosten
Nachdem in den vorangehenden Abschnitten die Performance der einzelnen Prozesse betrachtet
wurde, die für eine Migration von nicht-nativen XML-Daten in die native Speicherform
notwendig sind, sollen die dabei gewonnenen Ergebnisse in diesem Abschnitt zusammengefasst
werden. Zusätzlich erfolgt hier auch die Betrachtung der Kostenanteile, die jeder Prozess am
Gesamtaufwand einer Migration hat. Dabei stützen sich die weiteren Ausführungen primär auf
die Ergebnisse zum Kriterium der Größe und Anzahl. Anhand dieser Resultate lassen sich
anschließend auch Aussagen zur Kostenverteilung bei den ebenfalls untersuchten Kriterien
Strukturiertheit und Zusammensetzung treffen.
Größe und Anzahl
Bei der Untersuchung des Kriteriums der Größe und Anzahl zeigt sich für die Prozesskette vom
„einfachen Kopieren“ über die Unicode-Konvertierung bis hin zum XML-Parsen die in
Abbildung 33 veranschaulichte Kostenverteilung. Die Betrachtung des Kostenanteils der
Konkatenation erfolgt separat weiter unten. Unter Einbeziehung der Überlegungen zum „Seitenfüllgradproblem“ aus dem vorangehenden Abschnitt lässt sich in Abbildung 33 erkennen, dass
das Parsen der XML-Dokumente unter den hier betrachteten Prozessen der aufwändigste ist.
45
40
CLOB-INSERT
35
30
Sekunden
VARCHAR-INSERT
25
CLOB-INSERT
(inklusive Unicode-Konvertierung)
20
15
VARCHAR-INSERT
(inklusive Unicode-Konvertierung)
10
XML-INSERT
(inklusive Unicode-Konvertierung
und XML-Parsen)
5
0
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 33: Gegenüberstellung der Prozessketten zur Migrationsuntersuchung
87
6 Migration und Parsen
Der bezogen auf die gemessenen CPU-Zeiten kostenmäßig betrachtete Unterschied verschärft
sich in Abbildung 33 zudem weiterhin bei wachsender Dokumentgröße und gleich bleibendem
Gesamtdatenvolumen. Allerdings sinken mit zunehmender Dokumentgröße die Gesamtkosten
der Migration drastisch. Die „übrig bleibenden“ (geringen) Kosten sind dann weitgehend jene
Parse-Kosten.
Abbildung 33 zeigt aber auch, dass gerade wegen des „Seitenfüllgradproblems“ – also der
Einschränkung, dass DB2 in einer Page nur maximal ein LOB-Objekt verwalten kann –
besonders bei kleiner Dokumentgröße die gesamte Migration von nicht-nativen XMLDokumenten nicht merklich mehr Zeit in Anspruch nimmt als das „einfache Kopieren“ von
CLOB-Daten. Die Verarbeitung von VARCHAR-Dokumenten ist hier allerdings um ein Vielfaches schneller. Die Gründe hierfür sind bereits in den vorangehenden Abschnitten ausführlich
diskutiert worden.
Für die Performance des Prozesses der Unicode-Konvertierung zeigen sich in Abbildung 33
keine besonderen Ergebnisse24. Wie bereits in Abschnitt 6.1.3 veranschaulicht wurde, besteht
abgesehen von dem „Seitenfüllgradproblem“ durch die Unicode-Konvertierung ein in allen
Merkmalsausprägungen nahezu konstanter Zusatzaufwand, der bezogen auf die obige Darstellung in Relation zu den Gesamtkosten der Migration gering ist. Auf zusätzliche Schlussfolgerungen, die sich aus Abbildung 33 ziehen lassen würden, soll aus Umfangsgründen
weiterhin nicht eingegangen werden. Insgesamt lässt sich für die hier diskutierte Kostenverteilung formulieren, dass es speziell in Anbetracht der Performance der VARCHARMessungen wünschenswert wäre, den XML-Parse-Prozess weiter zu optimieren.
Gemäß der obigen Anmerkung soll nun noch der Anteil betrachtet werden, den der Prozess
der Konkatenation von nicht-nativen XML-Dokumentteilen einnehmen würde, sofern dieser
im Migrationskontext notwendig ist. Die dazu folgenden Betrachtungen orientieren sich
ausschließlich an der in Abschnitt 6.1.2 empfohlenen Variante der Konkatenation per Stored
Procedure25. Um deren Kostenanteil geeignet darstellen zu können, veranschaulicht Abbildung
34 die Gesamtkosten für eine Migration mit auf diese Weise eingeschlossener Konkatenation in
24
da fixer Aufwand pro Konvertierung eines Characters
25
Die Unterscheidung zwischen den Ausgangsdatentypen VARCHAR und CLOB ist entsprechend der
nahezu identischen Ergebnisse aus Abschnitt 6.1.2 hier nicht notwendig.
88
6 Migration und Parsen
jeder Merkmalsausprägung mit je 100 Prozent. Dabei ist der Anteil, den der Prozess des
Zusammenfügens einnimmt, separat (rot) ausgewiesen.
100%
Sekunden (in Prozent)
90%
80%
70%
Zusatzkosten für
Konkatenation
(per Stored Procedure)
60%
50%
40%
30%
XML-INSERT
(inklusive UnicodeKonvertierung
und XML-Parsen)
20%
10%
0%
1K x
10K x
100.000 10.000
100K x
1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 34: Kostenanteil der Konkatenation an einer XML-Migration
Anhand Abbildung 34 lässt sich erkennen, dass der Konkatenationsprozess äußerst aufwändig
ist. Bereits ab der Merkmalsausprägung „100K x 1.000“ benötigt er im Rahmen einer Migration
den Hauptanteil an CPU-Zeit für sich. Dahingehend muss aber erwähnt sein, dass nicht-native
XML-Dokumente in der DATEV zum aktuellen Zeitpunkt stets auf weniger als 100 Teile
beziehungsweise Tupel verteilt in DB2 gespeichert sind. Die extremen Kostenanteile der
Konkatenation bei den Merkmalsausprägungen rechts von „100K x 1.000“ finden sich somit
nach momentanem Kenntnisstand (glücklicherweise) nur in den hier durchgeführten künstlichen
Messreihen wieder. Für die zur Konkatenation in DB2 verwendete CONCAT-Funktion besteht
aber dennoch entsprechend der diskutierten Ergebnisse Verbesserungsbedarf. In diesem
Zusammenhang ist bei IBM ein Marketing Request (MR0727113519) eröffnet worden.
Strukturiertheit und Zusammensetzung
Bei der Untersuchung der Kriterien Strukturiertheit und Zusammensetzung zeigten sich erst bei
der Messreihe zur XML-Parse-Performance neue Erkenntnisse. Dementsprechend gelten für
deren Kostenanteile mit wenigen Anmerkungen ebenfalls die oben diskutierten Ergebnisse.
89
6 Migration und Parsen
Diese sollen hier nicht nochmals ausführlich beschrieben werden, sodass im Folgenden
lediglich auf deren Abweichungen eingegangen wird.
Für das Kriterium der Zusammensetzung sind die zuvor erwähnten und in Abbildung 33
dargestellten Resultate prinzipiell als identisch anzusehen. Hier zeigt sich lediglich eine
Abweichung in der Messreihe zum XML-INSERT. Die dazu abgebildeten CPU-Zeiten flachen
bei der Untersuchung zum Kriterium der Zusammensetzung bei zunehmender Dokumentgröße
weiter ab. Diese Unterschiede sind aber so minimal, dass sie sich nicht sichtbar auf das Ergebnis
von Abbildung 34 auswirken.
Auch bei der Betrachtung der Kostenanteile der einzelnen Prozesse beim Kriterium der
Strukturiertheit ergeben sich die zuletzt erwähnten Analogien. Hier zeigen sich ausschließlich
die bereits in Abschnitt 6.1.4 beschriebenen Unterschiede abhängig von der Strukturiertheit der
XML-Dokumente. Daher ist auch hier insgesamt ein hoher Anteil für den Aufwand des XMLParse-Prozesses festzustellen. Ebenfalls stark ins Gewicht fällt in dem Zusammenhang ähnlich
zu Abbildung 33 auch der Konkatenationsprozess.
6.2
Analyse der INSERT-Performance bei Neueinfügungen
Das Einfügen neuer Dokumente in den nativen XML-Datentyp ist dem Migrationsfall sehr
ähnlich. Beide Prozessketten haben, wie in Abbildung 35 dargestellt, den abschließenden Schritt
des XML-Parsens gemeinsam. Bei der Neueinfügung („rechte Seite“ der Prozessgrafik) ergibt
sich jedoch abhängig von der Beschaffenheit der einzufügenden Dokumente ein Unterschied bei
der vorangehenden Konvertierung. Je nachdem in welchem Zeichensatz die neuen Daten
anwendungsseitig vorliegen, müssen diese analog zu den Bemerkungen aus Abschnitt 6.1.3 in
die Unicode-Codepage UTF-8 konvertiert werden. Dabei ist es aber (auch in der DATEV) nicht
unwahrscheinlich, dass die einzufügenden Dokumente bereits als UTF-8 kodiert sind. In diesem
Fall ist eine weitere Konvertierung unnötig und wird von DB2 nicht durchgeführt. Daher ist auf
die Angabe des Zwischenschritts der Konvertierung in der Übersicht in Abbildung 35 verzichtet
worden. Der Prozess der Konkatenation findet naheliegenderweise für Neueinfügungen generell
nicht statt, da die Dokumente als Ganzes „angeliefert“ werden.
90
6 Migration und Parsen
VARCHAR/
CLOB
Konkatenation
XML-Parsen
Input
UnicodeKonvertierung
INSERT
Vorverarbeitung
XML
Abbildung 35: Überblicksgrafik – Neueinfügungen
Für die Version 10 des DB2 ist in diesem Zusammenhang eine zusätzliche Anmerkung zu
treffen. Dort ist es mit der „Binary XML“-Technologie [IBM10a] möglich, XML-Dokumente
beispielsweise per JDBC-Treiber in binär geparster Form zwischen Anwendung und Datenbank
zu kommunizieren. Sollte also ein neu einzufügendes XML-Dokument anwendungsseitig
bereits in geparster Form vorliegen, kann es demnach auch ohne einen vollumfänglichen
datenbankseitigen (erneuten) Parse-Prozess in DB2 eingefügt werden. Bei der in dieser Arbeit
betrachteten Version 9 des DB2 gibt es diese Möglichkeit nicht.
Aus der weiter oben angesprochenen strukturellen Ähnlichkeit zum Migrationsablauf resultieren
auch enge Parallelen, was die Performance-Messungen betrifft. Abhängig von dem Zeichensatz
in dem die neu einzufügenden Dokumente anwendungsseitig vorliegen, müssen entsprechende
Konvertierungsschritte durchgeführt werden. Für den Fall, dass es sich dabei um eine Konvertierung von EBCDIC nach Unicode handelt, können für eine Neueinfügung die gleichen
Gesamtkosten wie für den INSERT während der Migration von nicht-nativen XMLDokumenten ohne vorangehende Konkatenation angenommen werden. Hierzu wird auf die
Ausführungen in Abschnitt 6.1 verwiesen. Die Betrachtung anderer möglicher UnicodeKonvertierungen (beispielsweise UTF-16 nach UTF-8, CP1252 nach UTF-8 und weitere) wird
aus Umfangsgründen hier nicht durchgeführt.
Sollten die neu einzufügenden Dokumente anwendungsseitig bereits im Zeichensatz UTF-8
vorliegen, dann entfällt der Konvertierungsaufwand komplett. Folglich ergeben sich für die
INSERT-Performance dann ebenfalls die für den gesamten in Abschnitt 6.1 betrachteten Migrationsablauf aufgeführten Kosten vermindert um den Konvertierungsanteil aus Abschnitt 6.1.3.
91
6 Migration und Parsen
Da sich die Ergebnisse für die betrachteten Fälle der Neueinfügungen komplett aus den
Resultaten der vorherigen Abschnitte ableiten lassen, würden sich durch die Präsentation
weiterer Messreihen keine neuen Erkenntnisse ergeben. Daher wird an dieser Stelle auf
zusätzliche Messergebnisse und dazugehörige Diagramme verzichtet.
6.3
Pflege von User-Defined-XML-Indexen
Das zentrale Instrument zum Tuning von selektiven SQL-Abfragen sind ganz generell Indexe.
Diese erlauben es, durch eine Art Verzeigerung über separate Strukturen effizient auf zuvor
indexierte Datensätze zuzugreifen. Neben „herkömmlichen“ Indexen bietet DB2 auch für XMLDaten spezielle Indexierungsmöglichkeiten. Dabei verwendet es verschiedene Indextypen, zu
denen auch die vom Nutzer selbst definierbaren User-Defined-XML-Indexe zählen. Während
eine detaillierte Betrachtung des XML-Indexierungskonzepts von DB2 später in Abschnitt 8.1.1
erfolgt, soll an dieser Stelle bereits ein anderer, daran angelehnter Sachverhalt diskutiert
werden.
Neben den erwähnten Effizienzgewinnen verursacht die Indexverwendung stets aber auch
Defizite. Getreu dem Motto „nichts ist für umsonst“ ist mit jedem Index auch ein erhöhter
Pflegeaufwand verbunden, sobald Manipulationen (beispielsweise INSERT, UPDATE oder
DELETE) an indexierten Daten erfolgen. Sollte ein Index also keine Effizienzgewinne im
Rahmen des kontextspezifischen Datenzugriffs (der anliegenden Workload also) bedingen, so
ist er für die Gesamt-Performance eines Systems nur hinderlich. Die Erstellung von Indexen
muss demzufolge gut überlegt sein.
Die weitere Zielstellung im vorliegenden Abschnitt besteht darin, den angesprochenen Pflegeaufwand bei der Erstellung und Wartung von User-Defined-XML-Indexen im Rahmen des
INSERTs von XML-Dokumenten zu quantifizieren. Dazu wird zwischen zwei Vorgehensweisen unterschieden. Die zuerst betrachtete Variante besteht in der automatisch parallel zur
Datenmanipulation stattfindenden Indexpflege. Diese ist immer dann anzutreffen, wenn ein
User-Defined-XML-Index bereits vor der erwähnten Manipulation besteht.
Beispielsweise im Rahmen einer Migration oder bei einer anderen Form des MassendatenINSERTs macht aber auch die Betrachtung der nachträglichen Indexerstellung Sinn. Diese
92
6 Migration und Parsen
zweite Variante dient der Ermittlung von Kennzahlen, die Aussage darüber geben, wie aufwändig es ist, eine Indexerstellung erst nachträglich auszuführen, um somit zum Beispiel
während der angesprochenen Migration den parallelen Zusatzaufwand der Indexpflege
einzusparen. Vorab ist allerdings bereits anzumerken, dass die nachträgliche Indexerstellung
generell nur dann Sinn macht, wenn ein zu erstellender Index in größerem Umfang noch nicht
zuvor besteht26. Damit ist gemeint, dass ein vorhandener User-Defined-XML-Index vor einer
Massendatenverarbeitung nicht extra entfernt werden sollte, wenn er bereits eine größere Menge
an Daten indexiert hat. Schließlich müssten diese am Ende unnötig neu indexiert werden, was
ebenfalls einen hohen Aufwand nach sich ziehen würde.
Die zu den verschiedenen Varianten untersuchten Tests sind stets mithilfe der Testdaten des
Kriteriums der Größe und Anzahl (siehe Abschnitt 5.1.1) durchgeführt worden. Dies begründet
sich zum einen durch ihren realitätsnahen und produktionsähnlichen Charakter. Zum anderen
ermöglicht es die Verwendung dieser Daten auch, eine Aussage darüber zu gewinnen, inwieweit
die Anzahl zu indexierender Knoten sich auf die Gesamt-Performance des Pflegeaufwands eines
User-Defined-XML-Indexes niederschlägt. Schließlich unterliegen die Daten der einzelnen
Merkmalsausprägungen hier einem gemeinsamen Schema (siehe Abschnitt 7.3.2), weshalb sich
die verwendeten User-Defined-XML-Indexe für alle Ausprägungen auf die gleiche Weise
definieren lassen.
Zur Untersuchung des Pflegeaufwands von User-Defined-XML-Indexen sind für die weiter
unten analysierten Messreihen insgesamt drei Indexe benutzt worden. Diese indexieren,
bezogen auf das vereinfachte Modell der Daten aus Abschnitt 5.1.1 und Abbildung 7, jeweils die
Werte der Attribute „id“, „posx“ und „posy“ der „textblock“-Elemente. Gemäß den obigen
Bemerkungen zur Anzahl indexierter Knoten zeigt Abbildung 36, wie viele Knoten pro
Merkmalsausprägung von jedem Index jeweils pro Dokument und insgesamt indexiert wurden
beziehungsweise zu indexieren sind. Dabei lässt sich speziell bei der Merkmalsausprägung
„200B x 500.000“ erkennen, dass hier für jeden Index stets null Knoten indexiert sind
beziehungsweise indexiert werden müssen. Der Grund dafür liegt in der äußerst geringen Größe
und dem damit verbundenen kaum vorhandenen Inhalt der zu jener Ausprägung gehörenden
Testdaten. Diese enthalten bezogen auf das vereinfachte Datenmodell aus Abschnitt 5.1.1 keine
„textblock“-Elemente und demnach auch keine zu indexierenden Knoten.
26
primär für den in Abschnitt 6.2 betrachteten Fall der Neueinfügung relevant
93
6 Migration und Parsen
Index_id
Merkmalsausprägung
Index_posx
Index_posy
pro
Dokument
insgesamt
pro
Dokument
insgesamt
pro
Dokument
insgesamt
200B x 500.000
0
0
0
0
0
0
1K x 100.000
3
300.000
3
300.000
3
300.000
10K x 10.000
86
860.000
86
860.000
86
860.000
100K x 1.000
880
880.000
880
880.000
880
880.000
1M x 100
9.079
907.900
9.079
907.900
9.079
907.900
10M x 10
94.149
941.490
94.149
941.490
94.149
941.490
Abbildung 36: Anzahl indexierter Knoten je Index
Damit die Ergebnisse der fortan betrachteten Messreihe mit denen des INSERTs ohne parallelen
Aufwand zur Indexpflege verglichen werden können, orientiert sich der Ablauf zur Messdatenerhebung an dem aus Abschnitt 6.1.4 bekannten Vorgehen. Demzufolge kann auch die dort
genutzte Messprozedur für die Messreihe zur automatischen Indexpflege wiederverwendet
werden. Zuvor müssen lediglich die Indexe für jede, zu einer Merkmalsausprägung gehörende
Tabelle erstellt worden sein. Abbildung 37 veranschaulicht27 die dazu nötigen Statements
beispielhaft anhand der Ausprägung 100K. Nähere Details zur Syntax dieser SQL-Statements
finden sich in Abschnitt 8.1.1.
CREATE INDEX T24431A.IDX_ID_TXML_100K ON T24431A.TXML_100K(XML_DOC)
GENERATE KEY USING XMLPATTERN '/seite/textblock/@id'
AS SQL VARCHAR(20);
CREATE INDEX T24431A.IDX_POSX_TXML_100K ON T24431A.TXML_100K(XML_DOC)
GENERATE KEY USING XMLPATTERN '/seite/textblock/@posx'
AS SQL DECFLOAT;
CREATE INDEX T24431A.IDX_POSY_TXML_100K ON T24431A.TXML_100K(XML_DOC)
GENERATE KEY USING XMLPATTERN '/seite/textblock/@posy'
AS SQL DECFLOAT;
Abbildung 37: Beispiel-Statements zur Indexerstellung
27
Die veranschaulichte Indexerstellung orientiert sich dabei ebenfalls an dem vereinfachten Datenmodell
aus Abschnitt 5.1.1 und Abbildung 7.
94
6 Migration und Parsen
Die Betrachtung der nachträglichen Indexerstellung orientiert sich dagegen direkt an der Laufzeit, die für die Statements zur Indexerstellung resultiert, wenn sie erst nach der angesprochenen
Messprozedur ausgeführt werden.
In Abhängigkeit zu den geschilderten Vorbetrachtungen erfolgt nun die Auswertung der
einzelnen Messreihen. Die dazu benutzte Darstellungsform wurde so gewählt, dass sie die
Kosten der Indexerstellung anhand ihres prozentualen Anteils gegenüber dem INSERT ohne
sofortige Indexpflege ausweist. Letztere werden demnach als 100 Prozent angesehen. Abbildung
38 veranschaulicht die auf diese Weise berechneten Ergebnisse. Dabei beziehen sich alle
Messreihen mit Ausnahme der letzten (hellblauen) Messreihe auf die Pflege von User-DefinedXML-Indexen während des INSERTs. Die letzte Messreihe stellt den Gesamtaufwand einer
nachträglichen Erstellung aller drei Indexe dar.
800%
Sekunden (in Prozent)
700%
INSERT (bei 0 Indexen)
600%
500%
INSERT (bei 1 Index)
400%
INSERT (bei 2 Indexen)
300%
200%
INSERT (bei 3 Indexen)
100%
0%
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
nachträgliche Erstellung aller 3 Indexe
+ Kosten für INSERT (bei 0 Indexen)
Größe und Anzahl
Abbildung 38: Messergebnis – Pflege von User-Defined-XML-Indexen – CPU-Zeit
Anhand der Ergebnisse aus Abbildung 38 lassen sich mehrere Aussagen für den Pflegeaufwand
von User-Defined-XML-Indexen ableiten. Zum einen fällt auf, dass die Dokumentgröße nur
indirekt, bezogen auf die Anzahl an zu indexierenden Knoten, Einfluss auf die Performance der
Indexpflege hat. Dahingehend bleibt die CPU-Zeit für die Merkmalsausprägungen „10K x
10.000“ bis „10M x 10“ genau wie auch die dazugehörige Anzahl an zu indexierenden Knoten
(siehe Abbildung 36) nahezu konstant. Ebenso fällt der Aufwand für die Indexerstellung bei den
Merkmalsausprägungen links von „10K x 10.000“ auch entsprechend der hier weniger zu
indexierenden Knoten geringer aus.
Weiterhin lässt sich anhand der Messergebnisse auch erkennen, dass die CPU-Zeit erwartungsgemäß hinsichtlich der Anzahl an zu pflegenden User-Defined-XML-Indexen skaliert und pro
95
6 Migration und Parsen
Index ungefähr gleichermaßen zunimmt. Hier ist aber anzufügen, dass die automatische Indexpflege im XML-Kontext insgesamt sehr aufwändig ist. Schließlich entsteht beispielsweise
bei den hier durchgeführten Messreihen ein Zusatzaufwand von 600 Prozent. In diesem
Zusammenhang soll deshalb nochmals auf die weiter oben erwähnten Anmerkungen verwiesen
werden, dass ein Index nur dann erstellt und gepflegt werden sollte, wenn er auch PerformanceVorteile bezüglich des Datenzugriffs mit sich bringt.
Zuletzt soll noch auf den Vergleich der beiden untersuchten Varianten zur Indexpflege
eingegangen werden. Hier stellt sich die nachträgliche Indexerstellung eindeutig als effizienter
heraus. In Relation zu der parallelen Indexpflege beim INSERT ist diese Variante fast drei mal
schneller. Sofern also gemäß der weiter oben angefügten Bemerkung sinnvollerweise die
Möglichkeit besteht, einen Index erst nachträglich zu erstellen, ist es aus PerformancePerspektive ratsam, diese Variante der parallelen Indexpflege beim INSERT vorzuziehen.
Aufgrund der im nächsten Abschnitt aufgezeigten Analogie des INSERTs zum UPDATE lässt
sich selbige Aussage auch auf diese Form der Datenmanipulation übertragen.
6.4
Exkurs: UPDATE von XML-Dokumenten
Neben dem zuvor betrachteten INSERT von XML-Daten bildet der Prozess des XML-Parsens
ebenfalls einen zentralen Teil bei dem UPDATE der Daten. In diesem Zusammenhang
ermöglicht es DB2, XML-Daten auf die gleiche Weise abzuändern wie auch beispielsweise
LOB-Daten. Das heißt, sobald ein UPDATE erfolgt, wird der alte Wert eines Tupels vollständig
durch den geänderten neuen Wert, wie eine Art DELETE mit anschließendem INSERT, überschrieben28. Für die Verarbeitung von XML-Dokumenten ergeben sich aber aufgrund ihres
(semi-)strukturierten Aufbaus Anforderungen, die über diesen Mechanismus hinausgehen.
Demnach sollte es möglich sein, einzelne Teile eines XML-Dokuments gezielt ändern zu
können, ohne dazu das gesamte Dokument überschreiben zu müssen. Diese Forderung wird
nachfolgend „in-document“-UPDATE genannt und soll weiterhin anhand eines einfachen
Beispiels begründet werden.
28
Genau genommen schreibt DB2 den neuen Wert eines LOB-Dokuments in einen anderen Speicherbe-
reich, sodass der Bereich des alten Werts zum Zeitpunkt des UPDATEs „nur“ deallokiert wird.
96
6 Migration und Parsen
Dazu sei angenommen, dass die in Abschnitt 5.1.1 beschriebenen Datensätze einen Fehler
enthalten. Beispielweise möge die OCR-Software bei der Erkennung der einzelnen Dokumente
fälschlicherweise dem letzten Textblock ein falsches „id“-Attribut zugeordnet haben. Eine
nachträgliche Prüfung deckt diesen Fehler auf und leitet dessen Behebung ein. Dazu verwendet
es die oben beschriebene herkömmliche UPDATE-Funktionalität. Alle Dokumente, die von
dem Fehler betroffen sind, müssen also geeignet korrigiert und anschließend komplett
überschrieben werden. Der daraus resultierende Aufwand steht besonders für die großen
Dokumente (1M oder 10M) in einem unangemessenen Verhältnis zur durchgeführten Änderung
des „kleinen“ Attributwerts. Unter Umständen wäre hier anstatt des kompletten Ersetzens eine
Änderung im Promillebereich ausreichend. Obwohl sich der Fehler pro Dokument nur bei
einem einzigen Attribut zeigte, müsste stets der mit hohem Aufwand verbundene UPDATE des
gesamten Dokuments29 ausgeführt werden.
Nun sei weiterhin angenommen, dass datenbankseitig eine Funktionalität, wie sie zuvor als
„in-document“-UPDATE bezeichnet wurde, vorhanden ist. Mit deren Hilfe wäre es in dem
beschriebenen Beispielfall möglich, die fehlerhaften Attributwerte gezielt zu korrigieren, ohne
dass dazu jeweils die kompletten XML-Dokumente überschrieben werden müssen. Der
Aufwand der aus diesem Vorgehen resultiert, wäre, verglichen mit der oben beschriebenen
Verfahrensweise, verschwindend gering. Abbildung 39 stellt die geschilderten Abläufe grafisch
gegenüber.
„in-document“UPDATE
UPDATE
XMLDokument
(fehlerhaft)
XML
Korrektur
(UPDATE)
XML
XMLDokument
(korrigiert)
XML
XMLDokument
(fehlerhaft)
Korrektur
(„in-document“UPDATE)
XML
1 Attributwert
XMLDokument
(korrigiert)
XML
Abbildung 39: Beispiel zum Vergleich von UPDATE und „in-document“-UPDATE
29
Davon wären eventuell vorhandene User-Defined-XML-Indexe ebenfalls betroffen.
97
6 Migration und Parsen
Zu dem diskutierten Beispiel soll noch angemerkt sein, dass ein „in-document“-UPDATE von
XML-Dokumenten nicht nur im Rahmen von Fehlerbehandlungen Sinn macht. Änderungen
zählen in XML-Dokumenten genauso zum Tagesgeschäft, wie dies auch in der herkömmlichen
relationalen Welt der Fall ist. Unter anderem ändern Personen ihre Anschrift oder die DATEV
die Gehälter ihrer Mitarbeiter. Sollten diese Daten in Form von XML-Dokumenten gespeichert
sein, besteht beispielsweise konkreter Bedarf nach einer Funktionalität des „in-document“UPDATEs.
DB2 Version 9 bietet zur Umsetzung der zuletzt genannten Funktionalität leider keine
Unterstützung, dafür allerdings dessen Nachfolgeversion 10. Hier existiert eine skalare Funktion
namens XMLMODIFY [IBM11s], mit der es möglich ist, gezielte Änderungen innerhalb von
XML-Dokumenten durchzuführen. Auf nähere Details zu dieser Funktion soll, da sie wie
erwähnt erst in Version 10 von DB2 verfügbar ist, an dieser Stelle verzichtet werden. Hierzu
finden sich in [IBM11s] weiterführende Informationen.
Zuletzt sei noch auf die bereits in Abschnitt 4.1 erwähnten Messergebnisse von IBM zum
UPDATE von XML-Dokumenten [IBM07] in DB2 Version 9 hingewiesen. Dort zeigt sich
entgegen der oben geführten kritischen Betrachtung, dass der UPDATE von XML-Dokumenten
dennoch etwas effizienter ist, als die gemeinsame Ausführung eines DELETEs mit anschließendem INSERT der gleichen Daten.
98
7 XML-Schema-Management
7 XML-Schema-Management
Genau wie im relationalen Kontext ist die Datenmodellierung auch eine wesentliche Aufgabe
im Umgang mit XML-Daten. Hierzu haben sich im Laufe der Zeit verschiedene Möglichkeiten
entwickelt, von denen bereits die DTD [W3C06b, W3C08] und das XML-Schema [W3C04a,
W3C04b, W3C04c] in Abschnitt 3.1 Erwähnung fanden. Darüber hinaus existieren noch weitere
so genannte Schemasprachen wie beispielsweise RELAX NG [Van03] oder auch Schematron
[ISO06].
Vom W3C-Consortium empfohlen und am weitesten verbreitet von den genannten Schemasprachen ist das XML-Schema. Dieses lässt sich anhand der folgenden Eigenschaften [NK09]
charakterisieren.
Variabel (bezogen auf den Grad der Modellierung)
Zwar unterliegt der Aufbau eines XML-Schemas verschiedenen Regeln
[W3C04a], diese erlauben es aber, unterschiedlich „harte“ XML-Schemas zu
definieren. Daher kann ein XML-Schema zum einen so gestaltet sein, dass es
sehr flexible Dokumente erlaubt. Auf der anderen Seite ist es aber auch
möglich, diese Flexibilität beliebig weit einzuschränken. Jene Eigenschaft wird
im Rahmen der XML-Spezifikation auch als Semi-Strukturiertheit bezeichnet.
Optional
Zu einem XML-Dokument muss kein XML-Schema vorhanden sein. Dementsprechend kann ein solches Dokument auch ohne die Definition eines
zugehörigen Schemas gültig sein. In Abschnitt 3.1 ist bereits darauf verwiesen
worden, dass in jenem Fall ein wohlgeformtes XML-Dokument automatisch
auch gültig ist.
Dokument-intern
Ein XML-Schema ist stets auf die interne Beschreibung von Dokumenten
ausgerichtet. Mithilfe dieses Konzepts lassen sich daher keine Dokumentübergreifenden Integritäten definieren.
99
7 XML-Schema-Management
Das Management von XML-Schemas bildet zusammen mit dem dazugehörigen Prozess der
Schemavalidierung den Kern der in diesem Kapitel folgenden Ausführungen. Dabei ist es nicht
die Zielstellung, das Konzept selbst ausführlich zu beschreiben. Vielmehr sollen dessen
Möglichkeiten anhand der sicherzustellenden Integrität der Daten aufgezeigt werden (siehe
Abschnitt 7.1).
Nach diesen Ausführungen folgt in Abschnitt 7.2 eine Auflistung von Anforderungen, die an das
XML-Schema-Management und speziell an den Aspekt der XML-Schemavalidierung gestellt
sind. Diese werden in Abschnitt 7.3 aufgegriffen und im speziellen Kontext von DB2 betrachtet.
Hier soll vor allem im Vordergrund stehen, in welchem Ausmaß und in welcher Qualität die
Anforderungen in DB2 bereits umgesetzt beziehungsweise noch umzusetzen sind.
Abschließend werden in Abschnitt 7.4 die weiteren eingangs erwähnten Konzepte DTD,
Schematron und Relax NG beschrieben, wobei die Betrachtung speziell auf deren Besonderheiten gegenüber dem XML-Schema-Konzept ausgerichtet ist.
7.1
Integrität der Daten
Unter der Integrität von Daten versteht sich deren semantische Korrektheit. Sofern diese
gegeben ist, werden Daten auch als konsistent bezeichnet. Die Begrifflichkeiten Integrität und
Konsistenz stehen somit eng zueinander in Beziehung. Um die Integrität von Daten zu gewährleisten, lassen sich in Datenbankmanagementsystemen Integritätsbedingungen definieren.
Je nach System ist es möglich, mit deren Hilfe einheitliche Wertebereiche, Eindeutigkeiten oder
auch Fremdschlüsselbeziehungen und „mehr“ festzulegen. In Bezug auf die Integrität von XMLDokumenten ist noch die Sicherstellung einer einheitlichen Dokumentstruktur anzufügen.
Während die einzelnen Integritätsbedingungen im relationalen Kontext im Wesentlichen durch
Constraints [IBM11a] hergestellt werden, lässt sich dies für XML-Dokumente mithilfe der
XML-Schemas realisieren. Deren Möglichkeiten sollen in den weiteren Abschnitten anhand der
genannten Integritäten aufgezeigt werden. [HR01]
100
7 XML-Schema-Management
7.1.1
Dokumentstruktur
Jedes XML-Dokument setzt sich aus verschiedenen, hierarchisch miteinander verknüpften
Knoten zusammen (siehe Abschnitt 3.1). Dabei bestehen vielfältigste Möglichkeiten hinsichtlich
der Anordnung oder auch Benennung der einzelnen Knoten. Diese Flexibilität kann mithilfe von
XML-Schemas bewusst eingeschränkt und eine einheitliche Dokumentstruktur sichergestellt
werden. Dahingehend lassen sich beispielsweise die folgenden Vorgaben definieren [NK09].
Zulässige Elemente und Attribute (sowie deren Verknüpfung miteinander)
Zwingendes oder optionales Vorhandensein von Elementen und Attributen
Minimales und maximales Vorkommen von Elementen und Attributen
Exklusive Auswahl aus verschiedenen Elementen
Ein XML-Schema-Dokument ist selbst stets auch ein wohlgeformtes XML-Dokument. Demzufolge lässt sich anhand des Schemas bereits auf einfache Art und Weise die Struktur der
zugeordneten Dokumente erkennen beziehungsweise auf umgekehrte Weise anhand der
Dokumente ein gemeinsames XML-Schema ableiten. Hierbei ist jedoch zu beachten, dass es
verschiedene Strukturmuster gibt, an die der Aufbau eines XML-Schemas angelehnt sein kann.
Dazu zählen beispielsweise der „Russian Doll“- oder der „Salami Slice“-Stil. Für nähere Details
dazu und weitere Muster wird auf [HS04] verwiesen.
An dieser Stelle sollen anhand eines beispielhaften XML-Schemas einzelne, die Dokumentstruktur bestimmende Bestandteile des Schema-Konzepts aufgezeigt werden. Dazu zeigt
Abbildung 40 ein XML-Schema für das Beispieldokument aus Abbildung 7.
101
7 XML-Schema-Management
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="seite">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="textblock">
<xs:complexType>
<xs:attribute name="id" type="xs:string" />
<xs:attribute name="posx" type="xs:int" />
<xs:attribute name="posy" type="xs:int" />
<xs:attribute name="schriftart" type="xs:string" />
<xs:attribute name="schriftgroesse" type="xs:int" />
...
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:schema>
Abbildung 40: Beispiel für ein XML-Schema
Abgesehen von der optionalen XML-Deklaration in der ersten Zeile werden sämtliche Deklarationen eines XML-Schemas innerhalb eines gleichnamigen „schema“-Elements beschrieben.
Dieses kann verschiedene Attribute besitzen, die allgemeine Informationen zum XML-Schema
in sich tragen. In dem obigen Beispiel ist nur die zwingend notwendige Angabe des XMLSchema-Namespaces angeführt. Erst durch deren Verwendung lässt sich ein XML-Schema von
einem „normalen“ XML-Dokument unterscheiden. Innerhalb des „schema“-Elements findet die
eigentliche Beschreibung des XML-Schemas ihren Platz. Das oben dargestellte Beispiel enthält
dabei die im Folgenden beschriebenen Elemente.
„complexType“ (<xs:complexType>)
Mithilfe eines „complexType“-Elements lässt sich ein neuer komplexer Datentyp deklarieren. Dieser ergibt sich durch die Verknüpfung von weiteren Knotentypen – beispielsweise Elementen oder Attributen. Soll ein solcher Datentyp
mehrfach in einem Schema-Dokument30 verwendet werden, macht es Sinn,
diesen separat im Dokument mit einem Namensattribut zu deklarieren. Über
30
Schema-Dokument-übergreifende Wiederverwendung ist durch Einbinden (include [W3C04a]) oder
Importieren (import [W3C04a]) von XML-Schemas ebenfalls möglich
102
7 XML-Schema-Management
den Namen lässt er sich dann anschließend wie ein herkömmlicher Datentyp
einem beliebigen Element zuordnen.
„sequence“ (<xs:sequence>)
Ein „sequence“-Element leitet eine Sequenz von mehrfach aufeinander
folgenden Elementen ein. Dabei lässt sich deren minimales beziehungsweise
maximales
Vorhandensein
im
XML-Dokument
mittels
der
Attribute
„minOccurs“ und „maxOccurs“ festlegen. Dies ist beispielsweise für das im
nächsten Punkt betrachtete „element“-Element der Fall.
„element“ (<xs:element maxOccurs="unbounded" name="textblock">)
Die Angabe eines „element“-Elements setzt für die dem Schema zugeordneten
XML-Dokumente voraus, dass diese an der jeweiligen Stelle ein Element mit
dem entsprechenden Namen – in unserem Fall „textblock“ – besitzen. Das
hier zusätzlich definierte Attribut „maxOccurs“ bezieht sich auf die oben
beschriebene Sequenz und regelt das maximale Vorhandensein des Elements im
XML-Dokument.
„attribute“ (<xs:attribute name="id" type="xs:string" />)
Ähnlich zu dem „element“-Element beschreibt ein „attribut“-Element das
notwendige Vorhandensein eines Attributs an einer bestimmten Stelle in den
XML-Dokumenten, die dem XML-Schema zugeordnet sind. Dieses Attribut
definiert sich anhand des Namensattributs – in unserem Fall „id“. Die „type“Angabe legt den Datentyp fest, dem das Attribut entsprechen muss (siehe
Abschnitt 7.1.2).
Weitere Elemente des XML-Schema-Konzepts werden anhand der anderen Integritäten in den
nachfolgenden Abschnitten beschrieben.
7.1.2
Werteintegrität
Als Werteintegrität wird die Einhaltung von definierten Wertebereichen verstanden. Sie lässt
sich bei dem XML-Schema-Konzept durch die Verwendung verschiedenster Datentypen
gewährleisten. Diese können sowohl zur Definition von Attributwerten als auch für die
103
7 XML-Schema-Management
Festlegung von Werten einfacher Elemente31 genutzt werden. Im Detail wird dabei zwischen
insgesamt 44 verschiedenen vordefinierten Datentypen unterschieden (siehe Abbildung 41), von
denen wiederum 19 als primitive Typen bezeichnet werden. Letztere sind Datentypen, die nicht
aus anderen Typen definiert werden. Die restlichen Datentypen (abgeleiteter und komplexer
Datentyp) ergeben sich demzufolge aus den bereits bestehenden Typen.
Abbildung 41: Vordefinierte Datentypen bei dem XML-Schema-Konzept [W3C04c]
31
Einfache Elemente sind Elemente, die lediglich einen Textknoten enthalten [W3S11a].
104
7 XML-Schema-Management
Die Bildung der abgeleiteten Datentypen basiert auf dem gleichen Prinzip, wie auch vom
Modellierer selbst simple Datentypen definiert werden können. Hierzu sieht die XML-SchemaSpezifikation die Möglichkeiten der Einschränkung (mittels des Elements „restriction“) und die
der Auflistung (mittels des Elements „list“ oder „union“) bereits bestehender Datentypen vor.
Nähere Informationen dazu finden sich in [W3C04c] oder in zusammengefasster Form in
[WK03]. Weiterhin lassen sich aber auch komplexe Datentypen definieren, die sich als eine Art
Objekt aus verschiedenen anderen Knotenstrukturen zusammensetzen. Dazu findet sich in
Abschnitt 7.1.1 ein Beispiel. Für detailliertere Ausführungen wird erneut auf [W3C04c] und
[WK03] verwiesen.
7.1.3
Entitätsintegrität
Im Relationenmodell werden Constraints (UNIQUE- oder Primärschlüssel-Constraints) zur
Sicherstellung der Eindeutigkeit jeder Zeile verwendet. Übertragen auf den XML-Kontext und
speziell auf das Konzept der XML-Schemas existieren auch hier Mechanismen zur Definition
von Eindeutigkeiten und Primärschlüsseln. Dazu stehen die speziellen Elemente
„unique“ (Eindeutigkeit) und
„key“ (Primärschlüssel)
zur Verfügung, die im Folgenden näher beschrieben werden. Auf das ebenfalls zu diesen
Mechanismen in Verbindung stehende Element „keyref“ (Fremdschlüsselverweis) wird in
Abschnitt 7.1.4 näher eingegangen.
Mithilfe des „unique“-Elements lässt sich die Eindeutigkeit – Duplikatfreiheit – von Daten in
XML-Dokumenten gewährleisten. Dabei bietet es den Vorteil, sowohl kontextsensitive als auch
kombinierte Eindeutigkeiten definieren zu können. Zu deren Spezifikation werden die (Kind-)
Elemente „selector“ und „field“ verwendet, welche per XPath-Pfadausdruck (siehe Abschnitt
3.1.3) zu speziellen Dokumentteilen hinführen. Auf diese Weise bestimmt das Element
„selector“ den Kontext, in dem die Eindeutigkeit zu gewährleisten ist. Gleichsam spezifiziert
auch das Element „field“, welche Attribute oder Kindelemente innerhalb des Kontext-Elements
eindeutig sein sollen. [Pag04b]
Abbildung 42 zeigt ein Beispiel für die Verwendung des „unique“-Elements. Hier wird unter
dem Namen „Textblock-ID“ die Eindeutigkeit der „id“ für alle „textblock“-Elemente innerhalb
105
7 XML-Schema-Management
eines gemeinsamen Elternknotens sichergestellt. Dabei bezieht sich der dargestellte SchemaAusschnitt auf das in Abbildung 7 gezeigte Beispieldokument zum Kriterium der Größe und
Anzahl.
<xs:unique name="Textblock-ID">
<xs:selector xpath=".//textblock"/>
<xs:field xpath="@id"/>
</xs:unique>
Abbildung 42: Anwendungsbeispiel für das „unique“-Element
An dieser Stelle soll noch auf zwei weitere Aspekte hingewiesen werden. Einerseits ist jedes
„unique“-Element mit einem eindeutigen Namensattribut zu versehen. Zum anderen muss sich
die Angabe des „unique“-Elements stets am Ende desjenigen Elements befinden, in dessen
„complexType“-Deklaration auch die weiteren als eindeutig zu definierenden Elemente
enthalten sind. Diese beiden Bemerkungen gelten auch für die nachfolgend betrachtete
Schlüsseldefinition per „key“-Element.
Das „key“-Element, das zur eindeutigen Identifizierung von Elementen dient, ähnelt dem
„unique“-Element aber nicht nur in den zuletzt betrachteten Aspekten. Prinzipiell ist die
Konzeption beider Elemente nahezu identisch. Dementsprechend sieht auch das „key“-Element
die mit der gleichen Bedeutung verbundene Definition der (Kind-)Elemente „selector“ und
„field“ vor. Der einzige Unterschied zwischen den Elementen „key“ und „unique“ liegt in deren
Verarbeitung durch den XML-Parser. Im Fall eines „unique“-Elements prüft er lediglich die
Eindeutigkeit der auf diese Weise deklarierten Daten. Bei der Verwendung des „key“-Elements
behält sich der Parser noch zusätzliche Information vor, die er für einen späteren Abgleich mit
den „keyref“-Elementen benötigt (siehe Abschnitt 7.1.4). Demzufolge zeigt sich für die
beispielhafte Schlüsseldeklaration in Abbildung 43 kaum ein Unterschied zu der Eindeutigkeitsdeklaration in Abbildung 42.
<xs:key name="Textblock-ID">
<xs:selector xpath=".//textblock"/>
<xs:field xpath="@id"/>
</xs:key>
Abbildung 43: Anwendungsbeispiel für das „key“-Element
106
7 XML-Schema-Management
7.1.4
Referentielle Integrität
Eine weitere Integrität ist die Referentielle Integrität. Diese dient der Gewährleistung der
datenbankseitigen Abbildung von zueinander in Beziehung stehenden Entitäten. Ähnlich wie
zur Sicherung der Entitätsintegrität (siehe Abschnitt 7.1.3) werden dazu im relationalen Kontext
(Fremdschlüssel-)Constraints verwendet. Diese ermöglichen es, tabelleninterne oder tabellenübergreifende Beziehungen zwischen einzelnen Spalten zu definieren. Übertragen auf die
Verarbeitung von XML-Dokumenten ist dies mithilfe des XML-Schema-Konzepts nur in
eingeschränkter Form möglich. Hier ist die Verwendung des bereits in Abschnitt 7.1.3
erwähnten „keyref“-Elements vorgesehen, das im Folgenden näher beschrieben wird. Auf die
angesprochene Beschränkung wird weiter unten eingegangen.
Das „keyref“-Element besitzt eine große Ähnlichkeit mit den in Abschnitt 7.1.3 beschriebenen
„unique“- und „key“-Elementen. So umfasst es ebenfalls ein Namensattribut und die (Kind-)
Elemente „selector“ und „field“. Letztere bestimmen zum einen den Kontext und zum anderen
die Kombination der mit dem referenzierten Schlüssel abzugleichenden Daten. Der Unterschied
zu den beiden zuvor betrachteten Elementen liegt daher ausschließlich in dem zusätzlichen
Attribut „refer“ des „keyref“-Elements. Dieses verweist auf den Namen des referenzierten, per
„key“-Element definierten Schlüssels.
Abbildung 44 zeigt die Deklaration eines „keyref“-Elements in Anlehnung an die Darstellungen
aus Abschnitt 7.1.3. In diesem Zusammenhang wäre es beispielsweise denkbar, dass ein Textblock, wie eventuell eine Kopfzeile, auf allen Seiten identisch ist. So könnte sich auf den Folgeseiten an Stelle des mehrmaligen vollständigen Kopfzeilen-Textblocks auch ein Verweis auf
den entsprechenden Block der ersten Seite finden.
<xs:key name="Textblock-REFID" refer="Textblock-ID">
<xs:selector xpath=".//textblock_wiederholung"/>
<xs:field xpath="@id"/>
</xs:key>
Abbildung 44: Anwendungsbeispiel für das „keyref“-Element
Obwohl es den Anschein erweckt, dass das „keyref“-Element des XML-Schema-Konzepts eine
ähnliche Mächtigkeit besitzt, wie die Fremdschlüssel-Constraints im relationalen Kontext, ist
dies nicht zutreffend. Wie bereits eingangs in Kapitel 7 erwähnt, lassen sich aufgrund der
107
7 XML-Schema-Management
Charakteristika des XML-Schema-Konzepts keine dokumentübergreifenden Integritäten
definieren. Demzufolge können auch mithilfe der hier beschriebenen „keyref“-Elemente nur
Verweise innerhalb eines XML-Dokuments hergestellt werden. Sämtliche Daten in einem
XML-Dokument zu speichern ist aber aus praktischer Sicht undenkbar. Daher eignet sich das
Konzept der XML-Schemas nur ansatzweise zur Modellierung von Beziehungen zwischen den
Daten. An dieser Stelle sei aber darauf hingewiesen, dass das XML-Format ursprünglich „nur“
als Datenaustauschformat und demnach nicht zur Umsetzung von datenbankseitigen Spezifika
konzipiert wurde.
Aufgrund der beschriebenen Einschränkung für die XML-Schema-basierte Sicherstellung der
Referentiellen Integrität haben sich im Laufe der Zeit verschiedene andere „Verlinkungstechniken“ entwickelt. Dazu zählen beispielsweise die Konzepte XLink [W3C10], XInclude
[W3C06a] oder XPointer [W3C02], die anhand ihrer Besonderheiten in [Joc06] zusammengefasst sind. Da DB2 über die Möglichkeiten des XML-Schema-Konzepts hinaus keine
Unterstützung bezüglich Referentieller Integrität bietet, sollen die zuvor genannten Konzepte in
dieser Arbeit nicht näher vorgestellt werden. Es bleibt aber anzumerken, dass IBM die Herausforderung einer umfangreichen Unterstützung der Referentiellen Integrität für XML-Daten
erkannt hat und diese in zukünftigen Versionen von DB2 weiter ausbauen will.
7.2
Anforderungen an das XML-Schema-Management
Das XML-Schema-Konzept ist so gestaltet, dass es die im vorangehenden Abschnitt
beschriebenen Datenintegritäten durch die Validierung von XML-Dokumenten gegen bestimmte
XML-Schemas gewährleistet. Aus dieser Tatsache heraus ergeben sich bestimmte Anforderungen, die an das XML-Schema-Management und speziell an den Aspekt der Schemavalidierung gestellt und in den weiteren Abschnitten näher beschrieben werden.
108
7 XML-Schema-Management
7.2.1
Verknüpfung von XML-Dokument und XML-Schema
In der rein relationalen Welt wird pro Tabelle stets ein eigenes Tabellenschema definiert32.
Übertragen auf die Verarbeitung von XML-Dokumenten gestaltet sich die Zuordnung ähnlich.
Hier wird ein XML-Schema für eine gemeinsame Art von XML-Dokumenten festgelegt.
Dementsprechend sind alle einem Schema zugeordneten Dokumente erst dann gültig, wenn sie
sich erfolgreich gegen dieses validieren lassen. Dabei wäre es aber auch denkbar, Dokumente
gegen verschiedene XML-Schemas auf Gültigkeit zu prüfen33. Dieser Fall wird für die weiteren
Betrachtungen allerdings außer Acht gelassen. Im Folgenden wird daher von einer (0,1 : 0,n)Beziehung zwischen XML-Schema und XML-Dokument ausgegangen, die sich auch aufgrund
der Optionalität der XML-Schemas ergibt.
Eine Anforderung an das XML-Schema-Management ist es daher, die oben beschriebene
Zuordnung von XML-Dokumenten zu ihrem XML-Schema datenbankseitig zu erfassen. Dabei
ist es im Kontext der weiteren Betrachtungen eher unwichtig, ermitteln zu können, welche
XML-Dokumente zu einem gemeinsamen XML-Schema gehören. Vielmehr muss es auf diesem
Weg möglich sein, Auskunft darüber zu erhalten, zu welchem XML-Schema ein bestimmtes
XML-Dokument gehört beziehungsweise gegen welches Schema ein XML-Dokument validiert
wurde oder validiert werden soll. Abbildung 45 visualisiert durch gerichtete Kanten, wie diese
Verknüpfung datenbankseitig zu realisieren ist.
XMLDokumente
XMLSchemas
Abbildung 45: Verknüpfung von XML-Dokument und XML-Schema
32
33
In objektrelationalen Systemen wird durch entsprechende Erweiterungen zum Teil davon abgewichen.
verschiedene Szenarien denkbar: beispielsweise XML-Dokument genügt mindestens einem XML-
Schema oder gleichzeitig mehreren XML-Schemas
109
7 XML-Schema-Management
7.2.2
Transparenz zur Anwendung
Um die Integrität der Daten im Datenbankmanagementsystem zu gewährleisten, ist die
Validierung der XML-Dokumente gegen zuvor definierte XML-Schemas unabdingbar. Dabei ist
es jedoch wichtig, dass diese möglichst transparent zur Anwendung stattfindet. Dementsprechend muss zum einen die Verknüpfung von XML-Dokumenten und XML-Schemas
datenbankseitig vermerkt sein (siehe Abschnitt 7.2.1). Zum anderen sind aber auch Automatismen nötig, die parallel zu einem herkömmlichen INSERT beziehungsweise UPDATE von
XML-Dokumenten automatisch deren Validierung anstoßen, ohne dass damit eine Änderung in
der Anwendung verbunden ist. Infolgedessen muss mithilfe datenbankseitiger Mechanismen
sichergestellt werden, dass beispielsweise während des INSERTs von XML-Dokumenten
transparent deren Gültigkeit bezogen auf ein XML-Schema validiert wird (siehe Abbildung 46).
INSERT
XMLDokument
Validierung
XMLSchema
Tabelle
Abbildung 46: Transparente Schemavalidierung
In Zusammenhang mit der oben beschriebenen Transparenz ist aber zu vermerken, dass eine
automatische Schemavalidierung immer zusätzliche Kosten bezogen auf die Laufzeit verursachen wird. Dies ist zwar nicht außergewöhnlich, da bereits im relationalen Kontext jede
Integritätssicherung mit einem erhöhten Prüfaufwand verbunden ist. Für die Schemavalidierung
von XML-Dokumenten ist dieser Aufwand verglichen mit der „nicht-validierenden“ Verarbeitung allerdings verhältnismäßig hoch (siehe Abschnitt 7.3.2). Dementsprechend muss auch
eine Möglichkeit vorgesehen sein, die vorhandenen Automatismen bei Performance-Engpässen
wieder deaktivieren zu können.
110
7 XML-Schema-Management
7.2.3
Umgang mit ungültigen XML-Dokumenten
Eine wichtige Fragestellung besteht darin zu klären, wie mit ungültigen XML-Dokumenten
umzugehen ist. Damit sind Dokumente gemeint, die sich nicht erfolgreich gegen das ihnen
zugeordnete XML-Schema validieren lassen. Eine Lösung wäre natürlich, ungültige Dokumente
im Rahmen einer Datenmodifikation (INSERT oder UPDATE) einfach mit einem Fehler
(negativer SQLCODE) zurückzuweisen (siehe Abbildung 47 – linker Teil). Hier lässt sich aber
keine generelle Vorgehensweise fixieren. Schließlich hat es unter Umständen durchaus Vorteile,
auch ungültige XML-Dokumente mit einem speziellen Vermerk (siehe Abbildung 47 – rechter
Teil) datenbankseitig zu speichern. Auf diese Weise könnten nachträglich noch die „Fehler“
innerhalb der XML-Dokumente analysiert und korrigiert werden, sodass die darin gespeicherten
Informationen nicht durch das weiter oben beschriebene Abweisen der Dokumente (vorerst)
verloren gehen. Eventuell liegt der Fehler ja auch im zu restriktiven XML-Schema und nicht in
den Dokumenten. Gemäß diesen Überlegungen muss das Datenbankmanagementsystem in der
Lage sein, verschiedene Verfahrensweisen anzubieten, die den Umgang mit ungültigen XMLDokumenten regeln. Abbildung 47 veranschaulicht die diskutierten Varianten am Beispiel eines
INSERTs.
Dokument mit
Vermerk versehen
Dokument zurückweisen
INSERT
XMLDokument
INSERT
XMLDokument
SQLCODE
Validierung
(nicht erfolgreich)
XMLSchema
Validierung
(nicht erfolgreich)
XMLSchema
XML
Tabelle
Tabelle
SQLCODE ≙ Fehler
≙ spezieller „Ungültigkeitsvermerk“
Abbildung 47: Alternativer Umgang mit ungültigen XML-Dokumenten
111
7 XML-Schema-Management
7.2.4
Auskunft über Gültigkeit von XML-Dokumenten
Unter Einbeziehung der Überlegungen aus dem vorangehenden Abschnitt 7.2.3 ergeben sich
insgesamt die drei Zustände
gültig,
ungültig und
nicht validiert,
in denen sich ein XML-Dokument (datenbankseitig) befinden kann. Von diesen ist bislang nur
der Zustand „nicht validiert“ noch nicht näher betrachtet worden. In ihm befinden sich alle
XML-Dokumente, die noch nicht gegen ein XML-Schema validiert worden sind. Dies kann
verschiedene Gründe haben. Entweder die XML-Dokumente besitzen kein ihnen zugeordnetes
XML-Schema oder es handelt sich um jene Dokumente, die ohne die (automatische)
Validierung gegen das ihnen zugeordnete Schema in die Datenbank eingefügt worden sind.
Unabhängig von dem jeweiligen Zustand eines XML-Dokuments muss es möglich sein, diesen
auf einfache Weise von dem Datenbankmanagementsystem zu erfahren. Die Gründe dafür sind
vielfältig. Besonders wichtig ist es in diesem Zusammenhang, sicherstellen zu können, dass alle
XML-Dokumente erfolgreich gegen das ihnen zugeordnete Schema validiert worden sind und
sich keine Dokumente mehr im Zustand „nicht validiert“ befinden. Sofern ungültige Dokumente
mit in der Datenbank gespeichert sind, müssen auch diese zwingend in irgendeiner Art
kenntlich gemacht werden, da sie sonst nicht von den anderen Dokumenten zu unterscheiden
wären. Abbildung 48 zeigt beispielhaft eine solche Klassifikation von XML-Dokumenten.
✓
✓
✓
XML
XML
XML
✓
XML
✓ gültig
ungültig
XML
XML
XML
✓
✓
XML
✓ XML
XML
nicht validiert
✓
XML
XML
XML
✓
XML
XML
Abbildung 48: Auskunft über Gültigkeit von XML-Dokumente
112
7 XML-Schema-Management
7.2.5
Nachträgliche Schemavalidierung
Aus dem betrachteten Zustand „nicht validiert“ lässt sich bereits schließen, dass es datenbankseitig eine Möglichkeit geben muss, XML-Dokumente nachträglich gegen ein XML-Schema zu
validieren. Die Gründe dafür sind bereits in den vorangehenden Abschnitten aufgezeigt worden.
Der noch folgende Abschnitt 7.2.6 wird eine weitere Notwendigkeit für die Möglichkeit zur
nachträglichen Validierung liefern. An dieser Stelle sollen sich die Ausführungen daher auf die
folgende zusammenfassende Auflistung der angesprochenen Gründe beschränken.
Performance-Engpässe bei einer automatischen Schemavalidierung
Ungültige XML-Dokumente müssen (nach Änderung) erneut validiert werden
Notwendige Validierung von bislang noch nicht validierten XML-Dokumenten
Schemaevolution34 benötigt eine Möglichkeit zum „Nachvalidieren“
7.2.6
Unterstützung bei Schemaevolution und nachträgliche Validierung
Genau wie im relationalen Kontext nachträgliche Änderungen am Tabellenschema zum Tagesgeschäft gehören, lassen sich auch XML-Schemas auf einfache Art und Weise an ein geändertes
Datenmodell anpassen. Dahingehende Möglichkeiten zur Modifizierung von bestehenden
XML-Schemas sollen in dieser Arbeit nicht näher betrachtet werden. Problematischer ist hier
die Frage, wie mit XML-Dokumenten umgegangen werden soll, die bereits gegen das Original
eines abzuändernden XML-Schemas validiert worden sind. Das sofortige „Nachvalidieren“
dieser Dokumente gegen das modifizierte XML-Schema ist allein schon aus PerformancePerspektive betrachtet viel zu aufwändig. Schließlich könnten davon Millionen und noch
mehr XML-Dokumente betroffen sein. Realistischer erscheint es, diese Dokumente über einen
längeren Zeitraum sukzessive gegen das veränderte XML-Schema gemäß der Anforderung
aus Abschnitt 7.2.5 nachzuvalidieren oder unter Umständen auf diesen Prozess gänzlich zu
verzichten.
Im Rahmen der obigen Betrachtung wäre die einfache Veränderung eines Schemas aber noch
mit einem anderen Problem verbunden. Sobald das originale XML-Schema verändert wird,
muss auf irgendeine Art sichergestellt werden, dass die noch gegen das Original validierten
34
ist die Änderung eines bereits bestehenden XML-Schemas
113
7 XML-Schema-Management
XML-Dokumente für das neue Schema den Zustand „nicht validiert“ einnehmen (siehe
Abschnitt 7.2.4). Auch hierfür müssten unter Umständen die Zustände für eine erhebliche
Anzahl von Dokumenten aktualisiert werden, was gemäß der obigen Ausführung nicht
beziehungsweise nur mit immensem Aufwand zu realisieren ist.
Demzufolge macht hier ein anderes Konzept Sinn, nämlich die Versionierung von XMLSchemas. Auf diese Weise werden alte, noch verwendete XML-Schemas bei einer Schemaevolution nicht gelöscht, sondern veränderte Schemas parallel zu diesen als so gesehen „neue
Version“ in dem Datenbankmanagementsystem hinterlegt. Dies hat den Effekt, dass sämtliche
„alten“ gespeicherten XML-Dokumente weiterhin korrekt sind – hinsichtlich jener Schemaversion, unter der sie eingefügt wurden. Die Dokumente können dann nach und nach gegen das
neue XML-Schema validiert werden, bis keines mehr das Originalschema verwendet. Erst dann
kann dieses aus dem Datenbankmanagementsystem entfernt werden. Abbildung 49 visualisiert
die Abfolge einer solchen Vorgehensweise, für die keine spezielle Unterstützung durch das
Datenbankmanagementsystem notwendig ist. Hier sei aber nochmals darauf hingewiesen, dass
es praktisch durchaus denkbar wäre, gänzlich von einem „Nachvalidieren“ der XMLDokumente abzusehen.
(1) Neue Version des XML-Schemas registriert
XMLDokumente
XML-Schema
(Original)
XML-Schema
(neue Version)
(2) Sukzessives „Nachvalidieren“
XMLDokumente
XML-Schema
(Original)
XML-Schema
(neue Version)
114
7 XML-Schema-Management
(3) „Nachvalidieren“ vollständig abgeschlossen
XMLDokumente
XML-Schema
(Original)
XML-Schema
(neue
(Original)
Version)
XMLDokumente
X
(4) Original des XML-Schemas entfernen
XML-Schema
(Original)
XML-Schema
(neue
(Original)
Version)
Abbildung 49: Vorgehensweise bei Schemaevolution
7.3
XML-Schema-Management in DB2
Zusammen mit der Einführung der pureXML-Technologie ist in DB2 auch das XML-SchemaKonzept implementiert worden. Neben den anderen zu Beginn dieses Kapitels genannten
Alternativen zu diesem Konzept ist XML-Schema die einzige Schemasprache, die von DB2
unterstützt wird. Inwieweit diese Unterstützung hinsichtlich der Anforderungen aus Abschnitt
7.2 und speziell auch hinsichtlich des Preformance-Aspekts realisiert wurde, soll im weiteren
Verlauf dieses Abschnitts aufgezeigt werden.
Da sich XML-Schemas, wie oben erwähnt, durch spezielle XML-Dokumente beschreiben,
müssen diese, bevor sie später zur Validierung benutzt werden können, zuerst einmal im Datenbankmanagementsystem hinterlegt werden. DB2 nutzt hierzu ein so genanntes XML Schema
Repository (XSR), das sich aus mehreren Tabellen des Datenbankkatalogs zusammensetzt.
In diesem werden XML-Schemas in binär geparster Form zusammen mit einer automatisch
generierten Schema-ID abgespeichert [NK09]. Für die Registrierung eines neuen Schemas im
115
7 XML-Schema-Management
XSR – damit ist der Vorgang des Einfügens bezeichnet – stehen verschiedene Wege zur
Verfügung.
Registrierung von XML-Schemas mithilfe des DB2 Command Line Processors
„Stored Procedure“-basierte Registrierung von XML-Schemas
Registrierung von XML-Schemas per Java-Applikation (über JDBC-Treiber)
Auf nähere Details zu dem Registrierungsprozess und den damit verbundenen Varianten soll
in dieser Arbeit nicht eingegangen werden. Dies gilt auch für Einzelheiten zur internen Ablage
von XML-Schemas in DB2. In beiden Fällen liefert die Literatur [NK09] umfassende Informationen.
Der weitere Fokus dieses Abschnitts richtet sich primär auf das Thema der Schemavalidierung.
Dazu existiert in DB2 die Funktion DSN_XMLVALIDATE [IBM11a], die sich allerdings nicht
wie eine gewöhnliche Funktion gebrauchen lässt. Diesbezüglich ist sie nur als Argument der in
Abschnitt 3.1.2 betrachteten XMLPARSE-Funktion [IBM11a] verwendbar, was wiederum bedeutet, dass eine Schemavalidierung von XML-Dokumenten in DB2 nur zusammen mit dem
gleichzeitigen Parsen35 dieser Dokumente möglich ist [NK09]. Näheres dazu findet sich aber in
Abschnitt 7.3.1.
Syntaktisch besitzt die Funktion DSN_XMLVALIDATE zwei beziehungsweise drei Argumente
(siehe Abbildung 50). Das erste Argument dient der Übergabe des zu validierenden
XML-Dokuments. Es erwartet als Input einen Character-String oder einen Binary-String36, in
dem das (folglich) nicht-native XML-Dokument enthalten ist. Die Übergabe eines nativen
XML-Dokuments ist nicht möglich, woraus sich ein Nachteil für die nachträgliche Schemavalidierung ergibt, auf den in Abschnitt 7.3.1 näher eingegangen wird.
Abbildung 50: Syntaxdiagramm der Funktion DSN_XMLVALIDATE [IBM11a]
35
Auch wenn die Dokumente bereits in geparster Form vorliegen, müssen sie zur Schemavalidierung
trotzdem ein weiteres Mal geparst werden.
36
Ein Graphic-String [IBM11a] wäre ebenfalls zulässig, wird aber bei der DATEV nicht verwendet.
116
7 XML-Schema-Management
Das zweite (und dritte) Argument, das der Funktion DSN_XMLVALIDATE übergeben werden
muss, dient der Identifikation eines XML-Schemas, gegen das das Dokument validiert werden
soll. Dieses Schema lässt sich auf zwei Arten referenzieren. Zum einen ist die Angabe des
Schemanamens möglich, unter dem es im XSR hinterlegt wurde. Die andere Variante, das
Schema anzugeben, benötigt zwei Argumente, weshalb die Funktion DSN_XMLVALIDATE
eingangs auch mit „zwei beziehungsweise drei Argumenten“ beschrieben wurde. Bei diesen
zwei Argumenten handelt es sich um die Attribute „targetNamespace“ und „schemaLocation“
eines XML-Schemas, Details dazu finden sich in [IBM11a]. Über die zuletzt betrachtete
Variante lässt sich ein XML-Schema allerdings nur dann referenzieren, wenn die Kombination
der genannten Attribute innerhalb des XSR eindeutig ist. In der z/OS-Produktlinie von DB2 ist
es leider nicht möglich, anhand der Attribute „targetNamespace“ und „schemaLocation“ eines
XML-Dokuments direkt auf das ihm zugehörige XML-Schema zu schließen37. Aus diesem
Grund wird in den weiteren Betrachtungen dieses Abschnitts stets mit der Variante gearbeitet,
ein XML-Schema anhand seines im XSR hinterlegten Namens zu referenzieren.
Verglichen mit den vorangehenden Betrachtungen zu DB2 Version 9 sind die oben beschriebenen Möglichkeiten zur Schemavalidierung in DB2 Version 10 wesentlich erweitert
worden. Hier ist es zum einen realisierbar, auch native Dokumente mithilfe der
DSN_XMLVALIDATE-Funktion gegen ein XML-Schema zu validieren. Zum anderen wird
aber die Verwendung dieser Funktion nahezu unnötig, da in DB2 Version 10 einer Spalte vom
XML-Datentyp direkt per XML-type-modifer ein XML-Schema zugeordnet ist. Sämtliche
Dokumente, die dort in eine XML-Spalte eingefügt oder darin verändert werden sollen, werden
dann beim INSERT, UPDATE oder LOAD automatisch gegen das angegebene Schema
validiert. [Nic10]
7.3.1
Umsetzung der Anforderungen
In Anlehnung an die Ausführungen in Abschnitt 7.2 ergeben sich zwei verschiedene Wege, auf
denen eine Validierung von XML-Dokumenten gegen ein XML-Schema durchführbar sein muss.
Zum einen ist es aufgrund der Transparenz (siehe Abschnitt 7.2.2) zur Anwendung wichtig, die
Validierung möglichst automatisch während der jeweiligen Datenmanipulation – also im
Datenbankmanagementsystem – durchzuführen. Auf der anderen Seite muss es aber vor allem
37
In DB2 for LUW ist eine Referenzierung des XML-Schemas auf die genannte Weise möglich [NK09].
117
7 XML-Schema-Management
gemäß den Ausführungen in Abschnitt 7.2.5 auch die Möglichkeit einer nachträglichen
Validierung geben. Unabhängig von diesen beiden Varianten sind noch die Anforderungen
Verknüpfung von XML-Dokument und XML-Schema
Umgang mit ungültigen XML-Dokumenten
Auskunft über Gültigkeit von XML-Dokumenten
von DB2 zu erfüllen. Die Unterstützung von Schemaevolutionen braucht in diesem Kontext
nicht weiter untersucht zu werden, da die in Abschnitt 7.2.6 betrachtete, ideale Vorgehensweise
ohne zusätzliche spezielle datenbankseitige Mechanismen realisierbar ist.
Leider bietet DB2 Version 9 über die manuelle Anwendung der bereits betrachteten Funktion
DSN_XMLVALIDATE hinaus keinerlei Unterstützung hinsichtlich der genannten Anforderungen. Dennoch ist es mit deren Hilfe und anderen datenbankseitigen Mechanismen möglich,
sämtliche fehlende Funktionalitäten „nachzubauen“. Auf welche Weise dies realisierbar ist, soll
nun genauer betrachtet werden. In Abschnitt 7.3.2 folgt anschließend eine Untersuchung, wie
effizient diese Workarounds arbeiten.
Zur Realisierung der beschriebenen Anforderungen ist in dieser Arbeit ein generisches Konzept
gewählt worden. Das heißt, sowohl für den Fall der automatisierten als auch für den der
nachträglichen Schemavalidierung ist im Wesentlichen jeweils eine parametrisierte Stored
Procedure verantwortlich. Diese zwei Prozeduren können durch entsprechende Parameterübergabe zur Validierung beliebiger XML-Dokumente gegen ein beliebiges XML-Schema
genutzt werden. Auf Details zu den benötigten Parametern soll hier nicht näher eingegangen
werden. Wichtig ist nur, dass sie sowohl die zu validierenden Daten als auch das zur
Validierung zu verwendende XML-Schema identifizieren.
Da sich eine Stored Procedure nicht von selbst, etwa Event-gesteuert, aufrufen kann, werden für
den Automatismus zur Schemavalidierung noch Trigger benötigt. Diese übernehmen, wie
bereits in Abbildung 14 beispielhaft zu sehen war, den Aufruf der Validierungsprozedur
SP_SCHEMA_VALIDATION_AUTO bei einem INSERT oder UPDATE von XML-Dokumenten. Dazu muss für jede zu validierende XML-Spalte ein Trigger auf der ihr zugehörigen Tabelle erstellt werden. Dies hat den Vorteil, dass es möglich ist, einzelne Trigger wieder gezielt zu
entfernen, sofern die automatische Validierung gemäß der Anforderung aus Abschnitt 7.2.2
nicht mehr gewünscht ist. Auf der anderen Seite hat diese Vorgehensweise aber auch einen
bereits in Abschnitt 5.3 erwähnten großen Nachteil. Da DB2 es nicht zulässt, (native)
118
7 XML-Schema-Management
XML-Daten im Trigger-Body zu verarbeiten, kann eine Schemavalidierung von XMLDokumenten nicht vorangestellt innerhalb eines BEFORE-Triggers, wie beispielsweise in DB2
for LUW [NK09], durchgeführt werden. Stattdessen ist es lediglich möglich, die Schemavalidierung der Dokumente mittels eines AFTER-Triggers nachträglich zu initiieren.
Aus dem zuletzt erwähnten Aspekt und der Konzeption der Funktion DSN_XMLVALIDATE in
DB2 ergibt sich aber noch ein weiteres Defizit. Diese Funktion lässt, wie bereits erwähnt, als
Input-Parameter nur nicht-native XML-Dokumente zu. Daher müssen die zum Zeitpunkt der
Ausführung des AFTER-Triggers bereits eingefügten und somit in die native Form überführten
XML-Dokumente vor der Validierung wieder serialisiert werden. Diese Verfahrensweise ist
nicht nur umständlich, sondern verursacht auch erhöhte (eigentlich unnötige) Laufzeitkosten.
Abbildung 51 visualisiert den diskutierten Ablauf am Beispiel eines INSERT-Statements und
stellt dabei zudem einen Vergleich zur möglichen Vorgehensweise in der Produktlinie DB2 for
LUW dar. Eine Alternative zu dem beschriebenen Verfahren, die gemäß der Anforderung aus
Abschnitt 7.2.2 ebenfalls transparent zur Anwendung hin ist, existiert für die automatische
Schemavalidierung in DB2 Version 9 nicht. Der hier angesprochene Nachteil ergibt sich im
Übrigen auch für die nachträgliche Validierung von XML-Dokumenten. Da sich diese ebenfalls
bereits nativ gespeichert in DB2 befinden, müssen auch sie zum Zweck der Schemavalidierung
(unnötig) serialisiert werden.
DB2 for LUW
DB2 for z/OS
INSERT
INSERT
XMLDokument
XMLDokument
Validierung
und Parsen
Validierung und Parsen
(Before-Trigger)
XMLSchema
(After Trigger)
XML?
XMLParsen
Tabelle
XML
Serialisieren
Tabelle
?
? ≙ Schemainformationen
Abbildung 51: Vorgehensweise zur automatisierten Schemavalidierung in DB2
119
XMLSchema
7 XML-Schema-Management
Der Aufbau der beiden zuvor genannten Validierungsprozeduren für den Automatismus zur
Schemavalidierung (SP_SCHEMA_VALIDATION_AUTO) und für die nachträgliche
Schemavalidierung (SP_SCHEMA_VALIDATION_AFTER) ist sehr ähnlich. Der Hauptunterschied besteht in der Anzahl an zu verarbeitenden Daten. Während die Prozedur
SP_SCHEMA_VALIDATION_AUTO stets nur ein Dokument38 validiert, wird in der Prozedur
SP_SCHEMA_VALIDATION_AFTER die Validierung für eine beliebige Menge von Dokumenten durchgeführt. Auch wenn es gemäß den Betrachtungen aus Abschnitt 7.2 aus Aufwandsgründen in produktiven Kontexten unrealistisch ist, wird für die in Abschnitt 7.3.2 durchgeführten Performance-Untersuchungen folgende Vereinfachung angenommen. Die zuletzt
genannte Prozedur SP_SCHEMA_VALIDATION_AFTER validiert stets den kompletten
XML-Datenbestand einer Spalte gegen ein XML-Schema. Auf eine Berücksichtigung der
bereits im Voraus gegen ein XML-Schema auf Gültigkeit geprüften XML-Dokumente wird
demnach ebenfalls verzichtet. Diese zwei Aspekte sind bei einer späteren Verwendung der
Prozeduren in produktiven Kontexten zu beachten, da sie dort durchaus Einfluss auf die
Performance der Schemavalidierung haben können. Für die in Abschnitt 7.3.2 vorgestellten
Messungen sind sie allerdings irrelevant.
Weiterhin soll der Fokus auf die in den Prozeduren befindliche Logik zur Umsetzung der
verbleibenden Anforderungen gerichtet sein. Dabei wird zuerst die Art und Weise geklärt, wie
die Verknüpfung von XML-Dokument und XML-Schema sichergestellt werden kann.
Das in dieser Arbeit vorgestellte Verfahren greift dazu die Idee von [NK09] auf und arbeitet
mit einer zusätzlichen Spalte (XML_SCHEMA_INFO) vom Datentyp BIGINT [IBM11a]. Die
(Zusatz-)Spalte muss einer Tabelle pro XML-Spalte hinzugefügt werden. Bei dem INSERT
oder UPDATE von XML-Dokumenten kann dann automatisiert in die zusätzlich mitgeführte
Spalte, in unserem Fall XML_SCHEMA_INFO, die ID des XML-Schemas eingefügt werden,
gegen das das Dokument während der Datenmanipulation validiert wurde.
Mithilfe der oben angesprochenen Zusatzspalte XML_SCHEMA_INFO lassen sich gleichermaßen auch die Anforderungen nach Auskunft auf Gültigkeit von XML-Dokumenten und
Umgang mit ungültigen XML-Dokumenten umsetzen. Sollte sich ein XML-Dokument
bezogen auf das ihm zugeordnete XML-Schema als ungültig erweisen, so wäre es denkbar, statt
38
Damit ist das Dokument gemeint, für dessen Änderung der jeweilige Trigger aktiv wurde und die
Prozedur aufgerufen hat.
120
7 XML-Schema-Management
der ID des Schemas dessen Negation, also beispielsweise „-1000“ statt „1000“ in die Spalte
XML_SCHEMA_INFO einzufügen. Ist die Schemavalidierung eines XML-Dokuments noch
nicht durchgeführt worden, so bliebe dieser Eintrag einfach NULL. Auf diese Weise
könnte jederzeit nachvollzogen werden, in welchem Zustand sich ein XML-Dokument hinsichtlich seiner Schemavalidierung befindet. Die andere Möglichkeit bestünde natürlich wie in
Abschnitt 7.2.3 beschrieben darin, ungültige XML-Dokumente einfach zurückzuweisen.
Ungeklärt ist zu diesem Zeitpunkt noch, wie die Sonderbehandlung von ungültigen XMLDokumenten innerhalb einer Stored Procedure realisiert werden kann. Sollte sich ein Dokument
im Rahmen eines XML-Parse-Prozesses mit eingeschlossener Schemavalidierung als ungültig
erweisen, so wird es mit dem SQLSTATE 2201R („The XML document is not valid.“)
[IBM08c] abgewiesen. Stored Procedures erlauben allerdings über Conditions [IBM08b]
eine interne Fehlerbehandlung. Mit deren Hilfe lässt sich dann gezielt für den genannten
SQLSTATE die negierte ID des XML-Schemas in die Zusatzspalte einfügen. Somit könnte der
Inhalt einer Tabelle mit enthaltener XML-Spalte dann wie in Abbildung 52 dargestellt aussehen.
ID
XML
SCHEMA_INFO
1
XML
1000
2
XML
-1000
3
XML
1000
4
✓
XML
1000
5
XML
NULL
✓
✓
Abbildung 52: Beispielinhalt einer Tabelle mit Zusatzspalte zur Gültigkeitsauskunft
7.3.2
Performance der Schemavalidierung
Nachdem im vorangehenden Abschnitt zwei Verfahrensweisen zur Schemavalidierung herausgearbeitet wurden, sollen diese nun hinsichtlich ihrer Effizienz untersucht werden. Dazu sind
die zuvor erläuterten Konzepte im Rahmen dieser Arbeit implementiert und an einem der
in Abschnitt 5.1 vorgestellten Testdatensätze getestet worden. Hierbei ist die Wahl auf die
121
7 XML-Schema-Management
Testdaten39 des Kriteriums der Größe und Anzahl (siehe Abschnitt 5.1.1) gefallen. Diese
haben zum einen den Vorteil, dass es sich dabei um realitätsnahe, produktionsähnliche XMLDokumente handelt. Andererseits existiert zu diesen Daten bereits ein vorgefertigtes XMLSchema, was die Aussagekraft der weiter unten aufgeführten Messergebnisse nochmals bekräftigt.
An dieser Stelle sei noch angefügt, dass in den weiteren Tests die Messausprägungen
„200B x 500.000“ und „10M x 10“ nicht betrachtet wurden. Der Grund dafür liegt in den dazugehörigen XML-Dokumenten. Diese sind im Fall der Messausprägung „200B x 500.000“ zu
minimalistisch hinsichtlich ihres Umfangs, da sie neben der XML-Deklaration (siehe
Abschnitt 3.1) kaum zusätzlichen Inhalt umfassen. Demnach eignen sich die Dokumente nicht
dafür, verwertbare Aussagen zur Performance der Schemavalidierung gewinnen zu können.
Im Fall der Merkmalsausprägung „10M x 10“ ist die Größe der XML-Dokumente in anderer
Hinsicht problematisch. Bereits in Abschnitt 6.1.2 ist erwähnt worden, dass es für die Verarbeitung von LOB-Daten in DB2 neben dem allgemein gültigen Limit von 2G noch weitere
Beschränkungen gibt. Diese definieren sich durch die Subsystem-Parameter LOBVALA und
LOBVALS, welche unter anderem die maximale Menge an LOB-Daten festlegen, die gleichzeitig im virtuellen Speicher verarbeitet werden darf. Die aktuelle Konfiguration der genannten
Parameter im Entwicklungssystem Mem1 lässt es nicht zu, 10M große Dokumente mit den
vorliegenden Konzepten zur Validierung zu verarbeiten. Da eine Anpassung dieser Parameter
aber nicht aufwandsgemäß ist, wird für die weiteren Ausführungen auch auf die Betrachtung der
Merkmalsausprägung „10M x 10“ verzichtet.
In Abschnitt 6.4 ist aufgezeigt worden, dass sich die Verarbeitung des UPDATEs von
XML-Dokumenten in DB2 nur kaum von der des INSERTs unterscheidet. Infolgedessen und
hinsichtlich späterer Vergleiche zu den Laufzeiten des „nicht-validierenden“ INSERTs
beschränken sich die Ausführungen zum Konzept der automatisierten Schemavalidierung auf
die Betrachtung des INSERTs von XML-Dokumenten.
Für das Verfahren der nachträglichen Schemavalidierung sei an dieser Stelle nochmals auf
eine Anmerkung aus Abschnitt 7.3.1 hingewiesen. Die zur Performance-Messung genutzte
39
CLOB-Variante dieser Daten, um Merkmalsausprägungen bis unter anderem auch 10M betrachten zu
können (siehe Abschnitt 5.1.1)
122
7 XML-Schema-Management
Messprozedur ist vereinfacht so implementiert worden, dass sie mit einer einmaligen Ausführung den gesamten Inhalt einer XML-Spalte gegen ein definiertes XML-Schema validiert
(siehe Abschnitt 7.3.1).
Im weiteren Verlauf des Abschnitts erfolgt nun die Performance-Betrachtung der zuvor
beschriebenen Verfahren der automatischen und nachträglichen Schemavalidierung. Nachdem
kurz auf die jeweiligen Einzelmessreihen Bezug genommen wird, konzentrieren sich die
weiteren Ausführungen auf den Vergleich der beiden Verfahren in Relation zum „nichtvalidierenden“ INSERT. Zusätzliche Informationen zum konkreten Aufbau der jeweils verwendeten Messprozeduren, zu den einzelnen Ergebnistabellen und insbesondere zu den
Messwerten der Elapsed-Zeit finden sich gemäß den Bemerkungen aus Kapitel 5 im Anhang
dieser Arbeit.
Betrachtung der Einzelmessreihen zu den Verfahren
Aus der Durchführung der Messreihen zur nachträglichen Schemavalidierung resultiert ein
ähnlicher Kurvenverlauf der CPU-Zeit wie bereits bei der Betrachtung des „nichtvalidierenden“ INSERTs in Abschnitt 6.1.4. Für die automatische Schemavalidierung gilt dies
mit einer geringfügigen Abweichung ebenso. Diese besteht in einer bezogen auf die vertikale
Achse leichten Streckung des Kurvenverlaufs. Aufgrund der genannten Ähnlichkeiten soll auf
eine ausführliche Begründung für das gezeigte Verhalten verzichtet und stattdessen auf die
analogen Ausführungen aus Abschnitt 6.1.4 verwiesen werden. Eine detaillierte Gegenüberstellung der Messergebnisse zu beiden Verfahren schließt sich im nächsten Absatz an.
Vergleich der Verfahren mit „nicht-validierendem“ INSERT
Die folgenden Betrachtungen dienen der Veranschaulichung des prozentualen Zusatzaufwands,
den eine Schemavalidierung bezogen auf einen „nicht-validierenden“ INSERT (siehe Abschnitt
6.1.4) benötigt. Dazu werden dessen Kosten für jede Merkmalsausprägung jeweils als
Ausgangspunkt mit 100 Prozent fixiert. Anhand dieser Werte ist dann die Bemessung
der Gesamtkosten der jeweiligen Validierungsverfahren ausgerichtet. Da eine nachträgliche
Validierung erst stattfinden kann, wenn zuvor ein INSERT der Daten erfolgt ist, sind zur besseren Vergleichbarkeit der Verfahren die Kosten eines INSERTs auf die Messwerte zur
123
7 XML-Schema-Management
nachträglichen Schemavalidierung hinzuaddiert worden. Abbildung 53 veranschaulicht den auf
diese Weise beschriebenen Vergleich der Verfahren mit einem INSERT ohne eingeschlossene
Schemavalidierung.
900%
Sekunden (in Prozent)
800%
700%
INSERT (ohne
Schemavalidierung)
600%
500%
400%
INSERT (mit
Schemavalidierung)
300%
200%
nachträgliche
Schemavalidierung
(+ Kosten für INSERT)
100%
0%
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
Größe und Anzahl
Abbildung 53: Vergleich der CPU-Zeiten mit „nicht-validierendem“ INSERT
Bei der Betrachtung der prozentualen Verhältnisse fällt auf, dass der angesprochene Unterschied
zwischen der automatischen und der nachträglichen Schemavalidierung (inklusive den
INSERT-Kosten) deutlicher ist, als zuerst angenommen wurde. Bei der nachträglichen Schemavalidierung lässt sich ein konstanter Zusatzaufwand erkennen, der ungefähr dem Vierfachen der
Kosten für den „nicht-validierenden“ INSERT entspricht. Im Gegensatz dazu zeigt sich
mit zunehmender Dokumentgröße und bei gleich bleibendem Gesamtdatenvolumen für die
automatische Schemavalidierung ein linear abnehmender Zusatzaufwand. Während er in der
Merkmalsausprägung „1K x 100.000“ noch fast dem Achtfachen der Kosten eines INSERTs
ohne Schemavalidierung entspricht, bemisst der Zusatzaufwand bei der Ausprägung „1M x
100“ knapp das Vierfache dieser Kosten.
Obwohl beide Validierungsverfahren den gleichen, in Abbildung 47 visualisierten Ablauf nutzen, zeigen sich erhebliche Unterschiede in deren Effizienz. Wie kann das sein? Der Grund
dafür ergibt sich aus dem in Abschnitt 7.3.1 angesprochenen Unterschied der Verfahren. Die
automatische, Trigger-gesteuerte Schemavalidierung prüft pro Initiierung stets ein XMLDokument gegen ein XML-Schema. Dieses Dokument wird gemäß den Vorüberlegungen aus
Abschnitt 7.3.1 erst in die dazugehörige XML-Spalte eingefügt und muss anschließend zur
124
7 XML-Schema-Management
Validierung wieder mittels eines SELECT-Statements aus dieser ausgelesen werden. Das
Statement wird demnach pro Dokument einmal ausgeführt.
Bei der nachträglichen Schemavalidierung ist dies nicht der Fall. Hier findet der Zugriff auf
die XML-Dokumente mithilfe eines einzigen SELECT-Statements statt, das Cursor-basiert nach
und nach alle Tupel der XML-Spalte ausliest, validiert und daraufhin die nötigen Schemainformationen verifiziert. Da der weitere Ablauf der beiden Validierungsverfahren analog ist,
muss demnach die vielfache Ausführung des SELECT-Statements für die unterschiedlichen
Kurvenverläufe verantwortlich sein. Dies begründet sich auch durch die Tatsache, dass die
Kurve der automatischen Schemavalidierung bei abnehmender Dokumentanzahl (von 100.000
Dokumenten hin zu 100 Dokumenten) abflacht und sich zum Ende hin der Performance der
nachträglichen Schemavalidierung annähert.
Unabhängig von dem betrachteten Verfahren ist die Validierung von XML-Dokumenten gegen
ein XML-Schema ein sehr aufwandsintensiver Prozess (siehe Abschnitt 7.2.2), der in dem hier
betrachteten Kontext gemäß den Kennwerten aus Abbildung 53 mindestens ungefähr viermal so
teuer ist wie ein „nicht-validierender“ INSERT. Diese enormen Zusatzkosten resultieren aus den
verschiedenen Schritten, die während der unterschiedlichen Verfahren durchgeführt werden.
Die Prozesse lassen sich wie folgt zusammenfassen.
XML-Serialisieren der nativen XML-Dokumente in die nicht-native Form (CLOB)
Anschließendes XML-Parsen der Dokumente mit integrierter Schemavalidierung
UPDATE der Zusatzspalte mit Informationen zum Ergebnis der Validierung
Nähere Details zu den einzelnen Prozessen wurden bereits in Abschnitt 7.3.1 beschrieben und
grafisch in Abbildung 51 visualisiert. Auf eine Ermittlung der Kostenanteile dieser Prozesse,
wie sie beispielsweise in Abschnitt 6.1 bei der Betrachtung der einzelnen Schritte einer
Migration mittels INSERT durchgeführt wurde, ist hier verzichtet worden, da sich die vorgestellten Validierungskonzepte nur durch die Gesamtheit der aufgeführten Prozesse realisieren
lassen. Einzelbetrachtungen sind somit unnötig, wurden aber im Rahmen dieser Arbeit dennoch
beispielsweise für den Prozess des XML-Parsens (siehe Abschnitt 6.1.4) oder später für den
Prozess der Serialisierung (siehe Abschnitt 8.2.1) zum Teil in anderen Kontexten durchgeführt.
Entsprechend den durch die angefügten Messreihen gewonnenen Erkenntnissen lässt sich
formulieren, dass es in Performance-intensiven Anwendungsszenarien durchaus sinnvoll ist, auf
eine automatische Schemavalidierung zu verzichten. Auf diese Weise ist eine nachträgliche
125
7 XML-Schema-Management
Validierung in dem hier betrachteten Kontext nicht nur für den Moment der Datenmanipulation,
sondern auch insgesamt gesehen effizienter als ihr Pendant die automatische Schemavalidierung. Hier darf aber der Nachteil einer nachträglichen Validierung nicht außer Acht
gelassen werden. Ein permanenter „Schutz“ vor Inkonsistenzen kann letztendlich nur durch eine
direkt zur Datenmanipulation stattfindende Validierung gewährleistet werden.
Abschließend sei noch einmal darauf hingewiesen, dass sich in weiteren Tests auch ein Einfluss
der Komplexität eines XML-Schemas auf die Performance der Schemavalidierung verifizieren
ließ. Je umfangreicher und komplexer ein XML-Schema ist, umso mehr Zeit benötigt DB2 zur
Validierung von XML-Dokumenten gegen dieses Schema. Genauere Ausführungen sollen
hierzu aber aus Umfangsgründen nicht angefügt werden.
7.4
Alternative Konzepte
Das XML-Schema-Konzept ist nur eine der vielen Schemasprachen, die sich rund um das
Thema XML entwickelt haben. Zu Beginn des Kapitels sind bereits alternative Ansätze erwähnt
worden, die anschließend näher vorgestellt werden sollen. Dazu zählen die DTD, RELAX NG
und auch Schematron. Vorab sei nochmals erwähnt, dass DB2 von den genannten Konzepten
lediglich das XML-Schema unterstützt.
7.4.1
DTD
Einer der ersten Ansätze zur Festlegung und Prüfung der Struktur von XML-Dokumenten ist
die Document Type Definition (DTD) [W3C06b, W3C08]. Diese Variante basiert auf der
Definition von Dokumenttypen, denen eine gewisse Klasse ähnlicher XML-Dokumente
zugeordnet ist. Analog zu dem XML-Schema-Konzept kann durch DTDs ebenfalls die Struktur
von XML-Dokumenten beschrieben werden. Dementsprechend lassen sich beispielsweise
zwingend vorhandene Elemente, deren Attribute oder auch deren Verknüpfung miteinander
definieren. [WK03]
Der mögliche Definitionsumfang bei DTDs ist allerdings verglichen mit dem XML-SchemaKonzept wesentlich geringer. Als Beispiel dafür lässt sich die in Abschnitt 7.1.3 beschriebene
126
7 XML-Schema-Management
Entitätsintegrität aufführen. Für DTDs besteht hier lediglich die Möglichkeit die Eindeutigkeit
beziehungsweise Schlüsseleigenschaft dokumentweit festzulegen [Pag04b]. Auf einen
spezifischen Kontext lässt sich dabei wie im Falle des XML-Schema-Konzepts nicht einschränken. Ein als eindeutig definiertes Attribut, das eventuell „id“ heißt, müsste demnach
innerhalb eines gesamten Dokuments eindeutig sein, egal ob es sich dabei wie im Beispieldokument aus Abbildung 7 um das „id“-Attribut der Seite oder das des Textblocks handelt.
Abbildung 54 greift den aus diesem Dokument relevanten Ausschnitt nochmals auf.
<?xml version="1.0" encoding="UTF-8"?>
<seite id="seite1">
<textblock id="textblock1" ...>
</textblock>
...
</seite>
Abbildung 54: DTD basierte Eindeutigkeitsdefinition – gültiges Dokument
Sollten die „id“-Attribute allerdings wie in Abbildung 55 vergeben sein, wäre die Eindeutigkeit
der DTD-basierten Definition verletzt.
<?xml version="1.0" encoding="UTF-8"?>
<seite id="1">
<textblock id="1" ...>
</textblock>
...
</seite>
Abbildung 55: DTD basierte Eindeutigkeitsdefinition – ungültiges Dokument
Ein weiterer Kritikpunkt an der DTD ist, dass ihre Beschreibung von der XML-Syntax
abweicht. Dadurch ergeben sich viele Nachteile. Zum einen wird zur Editierung von DTDs ein
spezieller DTD-Editor benötigt. Zum anderen muss für deren Verarbeitung auch im Parser ein
zusätzliches Modul integriert sein. Allgemein können Programme, die XML-Dokumente
verarbeiten, nicht automatisch mit DTDs umgehen. Im Fall von XML-Schema-Dokumenten ist
dies hingegen der Fall. An dieser Stelle würden sich auch noch zahlreiche andere Nachteile der
DTDs aufführen lassen. Darauf soll allerdings verzichtet und auf die übersichtliche Darstellung
in [Pag04a] verwiesen werden.
127
7 XML-Schema-Management
7.4.2
RELAX NG
Die Regular Language Description for XML New Generation (RELAX NG) [Van03] ist das
gemeinsame Resultat der beiden Initiativen RELAX [Mak00] und TREX [Cla01] zur Entwicklung von Schemasprachen. Analog zu dem XML-Schema-Konzept liegt ihr ein grammatikorientierter Ansatz zugrunde. Somit sind nur die Konstrukte erlaubt, die sich anhand der
Produktionsregeln der Grammatik von RELAX NG ableiten lassen. Dieser Ansatz wird auch als
geschlossener Schemaformalismus bezeichnet. Demgegenüber steht der offene Schemaformalismus, den das in Abschnitt 7.4.3 vorgestellte Schematron-Konzept verfolgt. [KST02]
Die Idee hinter RELAX NG liegt in der Konstruktion einer kompakten, einfach verständlichen
Sprache zur Validierung der Struktur von XML-Dokumenten [WK03]. Daher besitzt
diese Sprache einen geringeren Funktionsumfang wie das XML-Schema-Konzept. Dies ist
aber nicht unbedingt als Nachteil zu verstehen. RELAX NG wurde nicht etwa als eine Art
Modellierungssprache entwickelt, sondern soll ausschließlich der strukturellen Beschreibung
von XML-Dokumenten dienen. Dementsprechend behandelt es die in Abschnitt 7.1 angesprochenen Aspekte Entitätsintegrität und Referentielle Integrität nicht.
Auch die Sicherstellung der Werteintegrität ist nur teilweise durch RELAX NG abgedeckt.
Diese Sprache verfügt selbst nicht über komplexe Datentypen, sie bietet allerdings die Möglichkeit solche über externe Typbibliotheken einzubinden. Auf diesem Weg stehen unter anderem
die Datentypen des XML-Schema-Konzepts (siehe Abschnitt 7.1.2) in RELAX NG zur Verfügung. Eine Modifikation der Typen ist innerhalb dieser Sprache jedoch nicht möglich. [WK03]
Bezüglich der strukturellen Beschreibung von XML-Dokumenten ist RELAX NG dem XMLSchema-Konzept ebenbürtig. Hier zeigen sich im Wesentlichen lediglich syntaktische Unterschiede. So wird bei RELAX NG beispielsweise der Ansatz verfolgt, sämtliche Strukturbeschreibungen auf der Ebene von Elementen zu definieren [KST02].
Insgesamt gesehen liegt der große Vorteil von RELAX NG in seiner Einfachheit. Damit
verbunden existieren Tools, die die Konvertierung von nahezu jedem „RELAX NG“-Schema in
ein herkömmliches XML-Schema und umgekehrt ermöglichen [Van03]. Auf diesem Weg
könnten somit die Vorteile beider Welten vereint werden – die einfache initiale Beschreibung in
RELAX NG und die nachträgliche Anreicherung eines Schemas mit zusätzlichen Konstrukten
des XML-Schema-Konzepts.
128
7 XML-Schema-Management
7.4.3
Schematron
Anders als alle zuvor betrachteten Schemasprachen verfolgt Schematron [ISO06] keinen grammatikorientierten, sondern einen regelbasierten Ansatz. Während bislang nur die Konstrukte
zulässig waren, die sich anhand einer speziellen Grammatik ableiten ließen, ist dies bei dem
vorliegenden offenen Schemaformalismus nicht der Fall. Hier sind prinzipiell alle Konstrukte
gültig, die nicht explizit verboten wurden. Das sukzessive Ausschließen von Unzulässigkeiten
wird in Schematron über Regeln gesteuert. So kann beispielsweise sichergestellt werden, dass
ein bestimmtes Element nur zusammen mit ausgewählten Attributen oder speziellen Kindelementen im XML-Dokument enthalten sein darf. [WK03]
Zur Definition der Regeln werden drei verschiedene Elementtypen benutzt. Eines dieser
Elementtypen ist das „rule“-Element, das beliebig viele Elemente der weiteren zwei Typen
„assert“ und „report“ in sich tragen kann. Die beiden letzteren Elementtypen beschreiben
jeweils eine Reaktion, die auf einen per „test“-Attribut definierten Test ausgeführt werden soll.
Dabei wird der Inhalt dieser Elemente bei den „assert“-Elementen ausgegeben, wenn der Test
fehlschlägt. Bei „report“-Elementen erfolgt die Ausgabe im Fall eines positiven Tests. Der
Kontext, in dem diese Tests stattfinden, wird innerhalb des „context“-Attributs des „rule“Elements definiert. Hierfür sind komplexe Muster in XSLT-Syntax erlaubt. [WK03]
Mithilfe dieser Regeln lassen sich neben den oben beschriebenen syntaktischen Prüfungen aber
auch wesentlich umfangreichere Zusammenhänge sicherstellen. Beispielsweise könnte auch auf
inhaltliche Abhängigkeiten zwischen Attributen und/oder Elementen geprüft werden. Weitere
Möglichkeiten von Schematron finden sich zusammen mit verschiedenen Beispielen in [Pag07]
und [WK03].
Gemäß den oben angefügten Spezifika von Schematron ist es nur mit großem Aufwand
möglich, bei seiner Verwendung alle strukturellen Zusammenhänge in einem XML-Dokument
zu beschreiben. Schließlich müssten sämtliche ungewollten Fälle durch separate Regeln ausgeschlossen werden. Infolgedessen ist Schematron weniger als eigenständige Schemasprache,
sondern vielmehr als Ergänzung einer der zuvor genannten grammtikorientierten Sprachen zu
verstehen. Denn die Mächtigkeit, mit der Schematron komplexe Zusammenhänge zwischen
XML-Daten prüfen kann, besitzt keine der anderen genannten Alternativen.
129
8 Query Performance
8 Query Performance
IBM vermarktet die pureXML-Technologie als eine hocheffiziente Art der Verarbeitung von
XML-Daten innerhalb des Datenbankmanagementsystems DB2. Nachdem sich diese Aussage
durch die Performance-Untersuchungen in den vorangehenden Kapiteln nur bedingt verifizieren
ließ, soll in dem aktuellen Kapitel auf den womöglich größten Vorteil der nativen XMLSpeicherung und -Verarbeitung eingegangen werden: die effiziente Art und Weise mit der es in
DB2 möglich ist, auf nativ gespeicherte XML-Daten zuzugreifen. Wie performant solche
Zugriffe tatsächlich erfolgen, wird dabei, verglichen mit den in der DATEV aktuell verwendeten
nicht-nativen XML-Speicherformen VARCHAR und CLOB, in diesem Kapitel unter dem Titel
Query Performance evaluiert.
Die Ausführungen gliedern sich wie folgt. Eingangs wird in Abschnitt 8.1 aus theoretischer
Sicht auf zentrale Aspekte eingegangen, die im Zusammenhang mit der Query Performance,
bezogen auf den nativen XML-Datentyp, von Relevanz sind. Anschließend erfolgt in
Abschnitt 8.2 eine Performance-Analyse des nativen XML-Datenzugriffs anhand ausgewählter
Szenarien. Diese orientieren sich wie bereits in Kapitel 5 geschildert, an den dort vorgestellten
Vergleichskriterien und der an jener Stelle ebenfalls ausführlich beschriebenen Verfahrensweise
zur Messdatenerhebung.
8.1
Performance-relevante Aspekte
Ähnlich wie bei den traditionellen relationalen Strukturen sind in Hinblick auf das Thema
Query Performance auch für die native XML-Verarbeitung zugriffsoptimierende Strukturen in
DB2 implementiert worden. Dazu zählen im Wesentlichen spezielle XML-Indexe (siehe
Abschnitt 8.1.1), erweiterte Statistiken (siehe Abschnitt 8.1.2) und neue Operatoren, die sich in
den Zugriffsplänen wiederfinden (siehe Abschnitt 8.1.3). Auf all diese Aspekte soll in den
anschließenden Ausführungen näher eingegangen werden.
130
8 Query Performance
8.1.1
XML-Indexe
Die zu dem nativen XML-Datentyp gehörenden Strukturen umfassen im Kern implizite XMLTablespaces, spezielle darin befindliche XML-Auxiliary-Tabellen und drei verschiedene Typen
von Indexen:
der DocID-Index,
der NodeID-Index und
der User-Defined-XML-Index.
Eine ausführliche Beschreibung der einzelnen Indexformen und die Art und Weise wie sie
miteinander interagieren ist in [Koc11] zu finden. Hierzu lässt sich zusammenfassend formulieren, dass es sich sowohl bei DocID-, als auch bei NodeID-Indexen um implizit erstellte Objekte
handelt, die zur internen Verwaltung von nativ gespeicherten XML-Dokumenten verwendet
werden. Im Gegensatz dazu sind User-Defined-XML-Indexe vom Nutzer zu erstellende Indexe,
die dazu dienen, den effizienten Zugriff auf einzelne Knoten zu ermöglichen. Sie sollen im
Rahmen dieser Arbeit aus dem Performance-Gesichtspunkt heraus näher betrachtet werden. Für
die anderen beiden Indextypen sei aufgrund ihrer Verwaltungsfunktion und da sie nicht vom
Datenbankadministrator/Nutzer zu „beeinflussen“ sind auf die theoretischen Ausführungen aus
[Koc11] verwiesen.
Die Erstellung von User-Defined-XML-Indexen erfolgt in DB2 mit dem „CREATE INDEX“Statement [IBM11a]. Dabei ist es, genau wie beim Anlegen traditioneller Indexe, möglich,
spezielle UNIQUE [IBM11a] User-Defined-XML-Indexe zu definieren. Diese Sonderform soll
hier nicht weiter betrachtet werden. Ausführliche Informationen dazu finden sich in [NK09].
Analog zu traditionellen Indexen handelt es sich bei User-Defined-XML-Indexen ebenfalls um
B+-Baum-Indexe [NK09]. Diese sind stets balanciert und haben den Vorteil, dass sie sich mit
logarithmischem Aufwand bezogen auf die Anzahl an indexierten Knoten nach einem bestimmten Eintrag durchsuchen lassen [Her09]. Für nähere Details zur Struktur von B+-Bäumen wird
auf [Her09] verwiesen.
Die Unterschiede zwischen der traditionellen Indexerstellung und der Erstellung eines UserDefined-XML-Indexes lassen sich anhand der Details der „CREATE INDEX“-Syntax erläutern.
Dahingehend zeichnet sich ein User-Defined-XML-Index speziell durch die Definition der
XML Index Specification [IBM11a] aus. Diese umfasst eine Namespace-Deklaration, einen
XPath-Ausdruck und einen relationalen Zieldatentyp. Erstere ist optional und soll hier nicht
131
8 Query Performance
weiter berücksichtigt werden. Abbildung 56 veranschaulicht die Bestandteile eines „CREATE
INDEX“-Statements (mit Ausnahme einer konkreten Namespace-Deklaration) in Anlehnung an
die bereits in Abschnitt 6.3 verwendeten Indexe. Der XPath-Ausdruck dient dabei der Angabe
des Pfades, auf dem sich die zu indexierenden Knoten innerhalb der zugehörigen XMLDokumente befinden. Während bei traditionellen Indexen für ein Tupel/Dokument stets genau
ein Wert indexiert wurde, ist es bei User-Defined-XML-Indexen möglich, dass der per XPathAusdruck definierte Pfad zu mehreren XML-Dokumentknoten führt. Sofern dies der Fall ist,
werden folglich auch pro Tupel/Dokument mehrere Werte indexiert. Abbildung 36 hat bereits
beispielhaft gezeigt, wie stark die Dokumentanzahl von der Anzahl an zu indexierenden Werten
abweichen kann. [NK09]
Position für (optionale)
Namespace-Deklaration
CREATE INDEX T24431A.IDX_POSX_TXML_100K
ON T24431A.TXML_100K(XML_DOC)
GENERATE KEY USING XMLPATTERN '/seite/textblock/@posx'
AS SQL DECFLOAT;
XPath-Ausdruck
Zieldatentyp
Abbildung 56: Beispiel-Statement für die Indexerstellung
Hier sei noch erwähnt, dass es sich bei User-Defined-XML-Indexen um Werteindexe handelt
[NK09]. Dementsprechend können beispielsweise Werte von Text- oder Attributknoten (siehe
Abbildung 56) indexiert werden. Die Indexierung von Elementknoten ist ebenfalls möglich.
Hierbei wird allerdings nicht das Element an sich, sondern der gesamte sich innerhalb des
Elements befindliche Textinhalt in konkatenierter Form indexiert. Diese Vorgehensweise macht
nur in sehr wenigen Anwendungsfällen, wie beispielsweise in [NK09] aufgezeigt, Sinn und soll
für die folgenden Ausführungen außer Betracht gelassen werden.
Hinsichtlich der zuvor angesprochenen XML Index Specification verbleibt noch die Klärung
des dabei ebenfalls anzugebenden Zieldatentyps. Da es in DB2 gemäß den Ausführungen aus
Kapitel 7 nicht möglich ist, einer XML-Spalte ein festes XML-Schema zuzuordnen, existieren
datenbankseitig keine Informationen zu dem Datentyp eines zu indexierenden Wertes. Der
Datentyp wird allerdings zur Indexerstellung benötigt und muss daher manuell vom Administrator spezifiziert werden. DB2 unterscheidet hier zwischen zwei möglichen Zieldatentypen – VARCHAR und DECFLOAT. Während der DECFLOAT-Datentyp für Zahlenwerte
vorgesehen ist, lassen sich mithilfe des VARCHAR-Datentyps nahezu beliebige Werte indexieren. [NK09]
132
8 Query Performance
Zusätzlich besteht bei der Definition von User-Defined-XML-Indexen die Möglichkeit, in den
XPath-Ausdrücken so genannte Wildcards zu spezifizieren [NK09]. Diese erlauben es, bestimmte Teilpfade nicht zu spezifizieren (hierfür Wildcards zu nutzen) und an deren Ende
wieder nahtlos anzusetzen, um ausgewählte Knoten zu indexieren. Eine umfassende Darstellung
dazu soll hier nicht gegeben und stattdessen auf [NK09] verwiesen werden. Ebenfalls möglich
ist auch die Verwendung von Filterprädikaten (siehe Abschnitt 3.1.3) innerhalb der XPathAusdrücke. Mit deren Hilfe lässt sich die Menge an zu indexierenden Werten in Abhängigkeit
anderer Knoten gezielt einschränken. Auch hierzu finden sich in [NK09] zusätzliche Informationen.
Obwohl die Möglichkeiten der Indexierung für XML-Dokumente recht vielfältig sind, gilt dies
für deren Verwendung beim Datenzugriff nicht. Es können nur jene SQL-Statements UserDefined-XML-Indexe nutzen, die die zur Dekomposition empfohlene XMLTABLE-Funktion
verwenden oder innerhalb ihrer WHERE-Bedingung das XMLEXISTS-Prädikat nutzen
[NK09]. Voraussetzung ist dabei natürlich immer, dass die darin verwendeten Ziele der XPathAusdrücke auch tatsächlich durch Indexe mit entsprechenden Zieldatentypen indexiert sind.
Unabhängig davon haben SELECT-Statements, die beispielsweise mit der XMLQUERYFunktion auf gezielte Teile eines XML-Dokuments zugreifen wollen, keinen Mehrwert von
eventuell vorhandenen Indexen. Weitere Einschränkungen zur Verwendung von User-DefinedXML-Indexen finden sich in [NK09].
Wegen dieser Restriktionen ist für die in Abschnitt 8.2.2 durchgeführten Messreihen zum
indexunterstützten Zugriff ein Statement mit enthaltenem XMLEXISTS-Prädikat gewählt
worden. Dies gilt ebenfalls für die Messreihen aus Abschnitt 8.2.4 und leicht abgewandelt auch
für die aus Abschnitt 8.2.3. Letztere zielt zwar primär darauf ab, mithilfe einer nicht „indexfähigen“ XMLQUERY-Funktion ein „textblock“-Element mit einem bestimmten „id“Attributwert aus dem Testdatenbestand herauszuselektieren. Durch die Verwendung des
XMLEXISTS-Prädikat ist es aber möglich, die Ergebnismenge zumindest indexunterstützt
soweit einzuschränken, dass mit der XMLQUERY-Funktion anschließend nur noch aus dem
tatsächlich relevanten XML-Dokument das gewünschte „textblock“-Element herausgefiltert
werden muss. Diese Art Workaround kann auch in anderen Szenarien durchaus Sinn machen, in
denen „normalerweise“ kein indexunterstützter Zugriff möglich wäre.
133
8 Query Performance
8.1.2
Statistiken zu XML-Daten
DB2 verwaltet in Form von diversen Katalogtabellen Statistiken zu verschiedenen Objekten auf
unterschiedlichster Ebene. Dazu zählen beispielsweise Statistiken für Tablespaces, Tabellen,
Indexe und Spalten. Alle diese Statistiken können mithilfe des RUNSTATS-Utilities entweder
auf Ebene von Tablespaces oder Indexen gesammelt werden. Dies gilt sowohl für traditionelle
als auch für XML-Statistiken. Allgemein ist bei der Betrachtung von Statistiken zwischen zwei
Arten zu unterscheiden. Zum einen gibt es Statistiken, die vom DB2 Optimizer für die Erstellung von Zugriffsplänen genutzt werden. Um eine möglichst hohe Query Performance zu
erzielen, empfiehlt es sich, diese für neue Objekte zeitnah zu erstellen und für bestehende regelmäßig zu aktualisieren. Die andere Form der Statistiken sind Space-Statistiken. Diese werden
beispielsweise vom Administrator genutzt, um die Speicherverwaltung innerhalb des Datenbankmanagementsystems zu überwachen (Space Monitoring). Die weiteren Betrachtungen
dieses Abschnitts konzentrieren sich, aufgrund ihrer höheren Relevanz für das Thema Query
Performance, ausschließlich auf die zuerst erwähnte Form der für Zugriffspläne relevanten
Statistiken. [Smi07]
Im Gegensatz zu den im letzten Abschnitt betrachteten speziellen XML-Indexen existieren,
bezogen auf die für Zugriffspläne relevanten Statistiken, bislang nur geringfügige XMLspezifische Erweiterungen in DB2. So ist es hier zwar in Relation zu beispielsweise CLOBDaten möglich, derartige Statistiken zu den gespeicherten XML-Dokumenten zu sammeln
[IBM08a]. Die Möglichkeiten dieser Datenerhebung sind allerdings verglichen mit traditionellen Statistiken erheblich geringer. Für das RUNSTATS- Utility resultieren daher diverse
Einschränkungen bei der Statistikerstellung zu den nativen XML-Strukturen. Beispielsweise
lassen sich für das „RUNSTATS TABLESPACE“-Utility auf einem XML-Tablespace die
Optionen COLGROUP, FREQVAL und HISTOGRAM nicht nutzen. Ebenso stehen für die per
„RUNSTATS INDEX“ aktualisierbaren Statistiken zu einem User-Defined-XML-Index oder
implizit erstellten NodeID-Index die Optionen KEYCARD, FREQVAL und HISTOGRAM
nicht zur Verfügung. Genaue Informationen zur deren jeweiliger Bedeutung finden sich in
[IBM08a].
Eine Konsequenz der zuvor beschriebenen Einschränkungen ist beispielsweise, dass für die
Verteilung von in XML-Dokumenten indexierten Werten stets die Gleichverteilung angenommen wird. Das wiederum kann zur Folge haben, dass bei einer großen Anzahl an unterschiedlichen Werten auch für sehr häufige Werte ein Indexzugriff erfolgt und umgekehrt bei
134
8 Query Performance
einem sehr kleinen Wertebereich kein Index bei dem Zugriff auf sehr seltene Werte zu Hilfe
gezogen wird. Der letztere Fall lässt sich bei der „XML (mit 3 Indexen)“-Messreihe zu
Abschnitt 8.2.4 beobachten. Hier wird der Index nur für die Merkmalsausprägung „1K x
100.000“ verwendet, danach nicht mehr. Nähere Details hierzu finden sich in Abschnitt 8.2.4
beziehungsweise in den Abbildungen zu den jeweils verwendeten Zugriffsplänen im Anhang
dieser Arbeit.
Neben den betrachteten Statistiken stellt DB2 seit Version 7 auch Echtzeitstatistiken (Real Time
Statistics) bereit. Dabei handelt es sich um in-memory Statistiken, die in bestimmten Zeitintervallen – per Default alle 30 Minuten – in die Katalogtabellen SYSTABLESPACESTATS und
SYSINDEXSPACESTATS externalisiert werden können. Vom Informationsgehalt her bestehen
Echtzeitstatistiken in DB2 aus den Bestandteilen:
Kenngrößen zur REORG-Notwendigkeit,
Kenngrößen zur RUNSTATS-Notwendigkeit,
Kenngrößen zur „IMAGE COPY“-Notwendigkeit und
globalen Kenngrößen.
Konkrete Details zur Zusammensetzung der Echtzeitstatistiken sollen an dieser Stelle nicht
geschildert werden. Weitere Ausführungen dazu finden sich in [Smi07]. Wichtig ist, dass diese
Echtzeitstatistiken in ihrem vollen Umfang, jedoch ohne spezifische Erweiterungen, auch für
die Strukturen des nativen XML-Datentyps verfügbar sind. Hier gilt es aber anzumerken, dass
DB2 aktuell Echtzeitstatistiken nicht zur Zugriffsplanerstellung verwendet [Smi07]. In Zukunft
soll aber mithilfe dieser Statistiken unter anderem speziell das Ziel verfolgt werden, eine Alternative zu aufwändig per RUNSTATS zu erstellenden Statistiken zu erhalten, die ebenfalls vom
Optimizer zur Generierung von effizienten Zugriffsplänen genutzt werden kann. In der Nachfolgeversion 10 des hier betrachteten DB2 gibt es dahingehend erste Implementierungen, die die
alternative Verwendung von Echtzeitstatistiken bei der Zugriffsplanerstellung erlauben. Nähere
Informationen dazu finden sich in [IBM11t].
135
8 Query Performance
8.1.3
Zugriffspläne
Zugriffspläne beschreiben eine Folge von internen Operationen, die dazu nötig sind, ein spezielles SQL-Statement intern auszuführen. Die genaue Bildung beziehungsweise der Aufbau
eines Zugriffsplans wird vom Optimizer in Abhängigkeit von den aktuell vorliegenden
Statistiken (siehe Abschnitt 8.1.2) kostenbasiert generiert. Hier lässt sich vereinfacht folgende
Regel formulieren: Je aktueller die Statistiken sind, desto optimaler erfolgt die Auswahl des
Zugriffsplans durch den Optimizer und umso genauer sind die durch ihn vorberechneten
Abschätzungen.
Auch wenn die Optimierungen und Abschätzungen des Optimizers in der Regel qualitativ und
genau sind, gibt es Fälle, bei denen ein manuelles Tuning durch den Administrator oder
Performance-Experten angebracht ist. Um diese Aufgaben erfüllen zu können, muss es möglich
sein, den Zugriffsplan eines Statements einzusehen. Dazu gibt es in DB2 die ExplainFunktionalität, die einen Zugriffsplan innerhalb der Tabelle PLAN_TABLE40 datenbankseitig
persistiert [NK09]. Die dort abgespeicherten Informationen können anschließend auf verschiedenen Wegen dargestellt werden. Eine der optisch ansprechendsten Varianten ist dabei die
grafische Darstellungsform der IBM-Komponente Visual Explain. Wie bereits in Abschnitt 3.4.2
beschrieben, ist dieses Tool auch in der Lage, den Explain-Prozess für beliebige SQLStatements auszuführen und somit die PLAN_TABLE auf einfache Weise zu befüllen. Daher
wurde es auch für die Erstellung der zu Abschnitt 8.2 angefertigten Zugriffsplandiagramme
verwendet. Neben dem Einsatz von Visual Explain gibt es noch weitere Möglichkeiten, einen
Zugriffsplan darzustellen. Auf diese soll in den nachfolgenden Betrachtungen aber nicht konkreter eingegangen und auf [IBM11u] verwiesen werden.
Wie bereit eingangs des Abschnitts beschrieben, setzt sich ein Zugriffsplan (mit beteiligten
XML-Strukturen) aus mehreren internen Operatoren zusammen. Hierzu zählen insbesondere
vier spezielle XML-Operatoren, die im Folgenden kompakt anhand [NK09] beschrieben werden.
DIXSCAN (DocID Index Scan)
Bei diesem Zugriff wird abhängig von einer gegebenen DocID über den zugehörigen DocID-Index ein Record Identifier (RID) ermittelt und zurückgegeben.
40
und einigen anderen Tabellen
136
8 Query Performance
XIXAND (XML Index ANDing)
Mithilfe des XIXAND-Operators kann die Schnittmenge aus zwei sortierten
DocID-Listen bestimmt werden.
XIXOR (XML Index ORing)
Der XIXOR-Operator hat eine ähnliche Funktion wie der XIXAND-Operator.
Statt der Schnittmenge bestimmt er allerdings die Vereinigungsmenge von zwei
verschiedenen sortierten DocID-Listen.
XIXSCAN (XML Index Scan)
Dieser Operator beschreibt den Zugriff auf einen User-Defined-XML-Index, bei
dem abhängig von einem gegebenen Schlüsselwert die zugehörigen Paare von
DocID und NodeID zurückgegeben werden.
Die zuvor betrachteten Operatoren stehen alle in direktem oder indirektem Bezug zu den
in Abschnitt 8.1.1 beschriebenen User-Defined-XML-Indexen. Während die DIXSCAN- und
XIXSCAN-Operatoren bei jedem durch einen solchen Index unterstützten Zugriff Verwendung
finden, ist dies für die Operatoren XIXAND und XIXOR nicht der Fall. Letztere werden nur in
Zusammenhang mit speziellen XPath-Ausdrücken benutzt. Eine ausführliche Erklärung dazu
findet sich in [NK09].
An dieser Stelle soll weiterhin die Verwendung der Operatoren DIXSCAN und XIXSCAN
beispielhaft diskutiert werden. Dazu zeigt Abbildung 57 den Zugriffsplan zu der in Abschnitt
8.2.3 beschriebenen Messreihe „XML (mit 3 Indexen)“ für die Merkmalsausprägung „10K x
10.000“. Dieser ist bezüglich der internen Abarbeitungsreihenfolge von unten (links) nach oben
zu lesen. Das Ziel des zu dem Zugriffsplan gehörenden Statements besteht darin, mit der
XMLQUERY-Funktion effizient auf ein „textblock“-Element mit einer bestimmten „id“ zuzugreifen. Dazu wird der gesamte Datenbestand einer XML-Spalte durch ein XMLEXISTSPrädikat auf genau ein relevantes XML-Dokument projiziert und aus diesem dann anschließend
das gewünschte „textblock“-Element herausgesucht. Nähere Details sind für die anschließenden
Betrachtungen nicht nötig. Das komplette Statement findet sich im Anhang zu Abschnitt 8.2.3.
137
8 Query Performance
Abbildung 57: Beispiel für einen Zugriffspfad mit verwendetem User-Defined-XML-Index
Zuerst erfolgt für das XMLEXISTS-Prädikat ein XIXSCAN-Zugriff auf den zu der Tabelle
TXML_10K gehörenden User-Defined-XML-Index IDX_ID_TXML_10K, der insgesamt
860.000 Werte indexiert hat. Anhand der Tupelanzahl der Tabelle TXML_10K (10.000) und der
FIRSTKEYCARD41 (43) werden aufgrund der generell im XML-Kontext angenommenen
Gleichverteilung insgesamt rund 233 (10.000/43) relevante DocIDs abgeschätzt. Zu diesen
ungefähr 233 DocIDs erfolgt daraufhin über den DocID-Index per DIXSCAN-Operator die
Ermittlung von circa 233 RIDs. Anhand dieser RIDs können anschließend die relevanten Tupel
der Tabelle TXML_10K „gefetcht“ werden. Erst jetzt findet für die (Ergebnis-)Tupel die restliche Verarbeitung des Statements inklusive der Anwendung der XMLQUERY-Funktion statt,
wonach dann die Abarbeitung des gesamten SELECTs abgeschlossen ist. Hier soll nochmals
der Nachteil der Gleichverteilung angemerkt werden, welche bei der XML-Verarbeitung stets
angenommenen wird. Im Gegensatz zu dem abgeschätzten Ergebnis von 232 Tupeln besteht das
tatsächliche Resultat aus nur einem Tupel.
41
Die FIRSTKEYCARD entspricht der Anzahl an unterschiedlichen indexierten Werten (der ersten
Spalte) eines Indexes [IBM11a].
138
8 Query Performance
8.2
Analyse der Query Performance
Für die native XML-Speicherung ergeben sich gegenüber der nicht-nativen Ablageform viele
Möglichkeiten, auf spezielle Weise Informationen aus den gespeicherten XML-Dokumenten
auszulesen. Die wichtigsten in diesem Zusammenhang denkbaren Optionen sollen hinsichtlich
ihrer Performance in dem vorliegenden Abschnitt in Form der Szenarien
Komplettzugriff,
Indexunterstützter Zugriff,
Selektiver Zugriff und
Komplexe Prädikate
genauer untersucht werden. Während es sich bei den letzten drei Szenarien tatsächlich um
XML-spezifische Messreihen handelt, gilt dies für die zuerst aufgeführte Variante des Komplettzugriffs nicht. Diese repräsentiert den typischen Zugriff auf XML-Dokumente, wie er zum
aktuellen Zeitpunkt aufgrund der nicht-nativen XML-Speicherform in der DATEV üblich ist. In
dieser Hinsicht soll überprüft werden, ob die Verwendung des nativen XML-Datentyps auch für
solche Anwendungen Effizienzvorteile bietet, die datenbankseitige (noch) keine XMLFunktionalitäten nutzen.
Bereits durch die zuletzt angefügte Bemerkung lässt sich erahnen, dass innerhalb der einzelnen
Szenarien stets verschiedene Formen der XML-Speicherung gegenübergestellt werden. Im
Detail erfolgt die Betrachtung der Vergleichsformen
XML-Speicherung nicht-nativ als CLOB,
XML-Speicherung nicht-nativ als VARCHAR,
native XML-Speicherung und
native XML-Speicherung mit Indexen.
Hierzu sollen in Verbindung mit den oben aufgeführten Szenarien zwei generelle Anmerkungen
getroffen werden. Zum einen können, wie bereits erwähnt, nicht-nativ gespeicherte Dokumente
nicht XML-spezifisch verarbeitet werden42. Sofern eine solche Verarbeitung aber notwendig ist,
wird sie momentan nicht datenbankseitig, sondern innerhalb der DATEV-Anwendungen ausgeführt. Dazu müssen die nicht-nativ gespeicherten XML-Dokumente komplett aus DB2 ausgelesen, anschließend anwendungsseitig geparst und danach wie gewünscht verarbeitet werden.
42
Die Funktionalitäten des DB2-XML-Extenders werden hier gemäß Kapitel 1 nicht betrachtet.
139
8 Query Performance
Für die Gegenüberstellungen in Abschnitt 8.2.2, 8.2.3 und 8.2.4 wird daher für die Vergleichsformen der nicht-nativen Speicherformen stets der Zeitaufwand eines Komplettzugriffs aus
Abschnitt 8.2.1 angenommen. Dazu sind nachträglich die Kosten für den anwendungsseitigen
XML-Parse-Prozess und die anwendungsseitige XML-Verarbeitung hinzu zu addieren. Diese
sind jedoch stark von der Anwendung, den darin verwendeten XML-Parsern und weiteren
Faktoren abhängig, sodass für die anwendungsseitigen Prozesse aufgrund der zu umfangreichen
Einflussfaktoren im Rahmen der vorliegenden Arbeit keine Messdaten erhoben werden können.
Die zweite Anmerkung bezieht sich auf die zur Vergleichsform „Native XML-Speicherung mit
Indexen“ jeweils verwendeten User-Defined-XML-Indexe. Diese sind in Analogie zu den bereits
in Abschnitt 6.3 zum Thema Indexpflege untersuchten Indexen gewählt worden. Insbesondere
für Informationen zu der von den Indexen jeweils indexierten Knotenanzahl oder den zu ihrer
Erstellung notwendigen SQL-Statements wird daher auf Abschnitt 6.3 verwiesen.
In Anlehnung an die Performance-Analysen aus den vorangehenden Kapiteln orientieren sich
auch die hier durchgeführten Messreihen an den Vorbetrachtungen aus Kapitel 5. Bis auf gewisse Einschränkungen werden alle dort vorgestellten Vergleichskriterien in die weiteren Untersuchungen einbezogen. Abstriche sind dabei lediglich für das Kriterium der Strukturiertheit
vorgenommen worden, da sich die dazugehörigen Testdaten aufgrund ihrer starken Strukturunterschiede für die betrachteten speziellen XPath-Abarbeitungen nicht eignen.
In ähnlicher Weise wird, abgesehen von den Messreihen in Abschnitt 8.2.1, bei den anderen
Vergleichskriterien die Merkmalsausprägung „200B x 500.000“ nicht betrachtet. Dies begründet sich durch den kaum vorhandenen Inhalt, den die XML-Dokumente jener Ausprägung über
ihre XML-Deklaration hinaus besitzen. Da sie nämlich kein einziges „textblock“-Element
enthalten, sind sie für die an diesem Knoten ansetzenden Messreihen (aus den Abschnitten 8.2.2,
8.2.3 und 8.2.4) nicht geeignet.
Generell ist bei den Untersuchungen zur Query Performance folgendes zu beachten. Die Kommunikation von XML-Dokumenten zwischen DB2 und externen Anwendungen findet stets in
serialisierter Form statt [IBM07]. Das heißt, unabhängig davon ob XML-Dokumente nativ
oder nicht-nativ in DB2 abgespeichert sind, werden sie stets in nicht-nativer Form nach außen
hin kommuniziert. Daher verstehen sich die zu den nativen Speicherformen erhobenen
Messergebnisse in den Abschnitten 8.2.1 und 8.2.3 inklusive der Kosten für den Prozess der
XML-Serialisierung (siehe Abschnitt 3.1.2). Bei den Messreihen zu den Abschnitten 8.2.2 und
140
8 Query Performance
8.2.4 wird dieser Effekt durch die Verwendung der COUNT-Funktion verhindert. Hier sind im
Ergebnis des SELECT-Statements keine XML-Dokumente enthalten, weshalb demzufolge auch
keine Serialisierung stattfinden muss. DB2 Version 10 ermöglicht in Bezug auf das „Serialisierungsproblem“ teilweise auch die binäre Form der XML-Kommunikation und verzichtet in
diesem Zusammenhang beim externen Datenzugriff auf den Prozess der Serialisierung. Nähere
Details dazu wurden bereits in Abschnitt 6.2 erwähnt.
Abschließend sei noch darauf hingewiesen, dass für die in den weiteren Abschnitten betrachteten Messreihen im Gegensatz zu den bislang durchgeführten Performance-Messungen stets
zusätzlich Diagramme zu den jeweils vom DB2 Optimizer gewählten Zugriffsplänen erstellt
wurden. Sie befinden sich allerdings aus Umfangsgründen mit Ausnahme des bereits in
Abschnitt 8.1.3 diskutierten Zugriffsplans im Anhang dieser Arbeit.
8.2.1
Komplettzugriff
Die Messreihe Komplettzugriff vergleicht, wie bereits eingangs von Abschnitt 8.2 beschrieben,
die native XML-Ablageform mit den nicht-nativen Varianten in Bezug auf die Performance, mit
der auf komplette XML-Dokumente in DB2 zugegriffen werden kann. Diese Gegenüberstellung
basiert auf dem Hintergrund, dass DATEV-Anwendungen zum aktuellen Zeitpunkt (nicht-nativ
gespeicherte) XML-Dokumente stets vollständig auslesen und erst anwendungsseitig weiterverarbeiten.
Hier stellt sich die Frage, ob die native XML-Speicherung auch in diesem Kontext effizienter ist
als die nicht-native Ablage als CLOB- oder VARCHAR-Dokument. Zur Beantwortung
werden in den folgenden Messreihen stets die kompletten Testdatenbestände zu den einzelnen
Kriterien pro Merkmalsausprägung ausgelesen und im Fall der nativen XML-Speicherung
gemäß den obigen Ausführungen zu einem CLOB-Dokument43 serialisiert. Demzufolge
können die zur Messreihe der nativen XML-Verarbeitung ermittelten Ergebnisse gleichzeitig als
Abschätzung für die Effizienz des XML-Serialisierungsprozesses interpretiert werden. Da es
sich bei diesem Vorgang um das „Gegenstück“ zum XML-Parse-Prozess handelt, wird in den
weiteren Ausführungen unter dem Gesichtspunkt Performance speziell auf deren Gemeinsamkeiten und Unterschiede eingegangen.
43
Der CLOB-Datentyp ist aufgrund seiner größeren maximalen Länge notwendig (siehe Abschnitt 6.1.2).
141
8 Query Performance
Zu dem hier betrachteten Szenario sind folgende, den Vorbetrachtungen aus Kapitel 5 unterliegende Messungen und Variationen durchgeführt worden.
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Strukturiertheit (CLOB und XML)
Zusammensetzung (XML)
In den nachstehenden Abschnitten sollen die Ergebnisse analysiert werden. Zusätzliche Informationen zum konkreten Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen
inklusive den Messwerten der Elapsed-Zeit sowie zu den Diagrammen zu den vom DB2
Optimizer jeweils gewählten Zugriffsplänen sind dabei aus Umfangsgründen und gemäß den
Bemerkungen aus Kapitel 5 in den Anhang dieser Arbeit ausgelagert.
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Hinsichtlich des Kriteriums der Größe und Anzahl ergeben sich für die Messreihe zum Szenario
Komplettzugriff die in Abbildung 58 dargestellten Kurvenverläufe. Darin lassen sich zwei
Auffälligkeit bezogen auf die in dieser Arbeit bereits durchgeführten Performance-Analysen
erkennen. Zuerst einmal erinnern die Kurvenverläufe der VARCHAR- und der CLOBMessreihe stark an die diesen Datentypen zugehörigen Ergebnisse aus Abschnitt 6.1.1. Demnach lässt sich vereinfacht feststellen: Je länger ein INSERT von VARCHAR- oder CLOBDokumenten andauert, umso mehr Zeit benötigt auch der anschließende Zugriff auf die Daten.
Für eine ausführliche Deutung dieser beiden Kurvenverläufe wird aus Analogiegründen auf
Abschnitt 6.1.1 verwiesen.
142
8 Query Performance
25
20
Sekunden
CPU - CLOB
15
CPU - VARCHAR
10
CPU - XML
5
CPU - XML
(mit 3 Indexen)
0
200B x 1K x
10K x 100K x
500.000 100.000 10.000 1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 58: Messergebnis – Komplettzugriff – Größe und Anzahl – CPU-Zeit
Die zweite Auffälligkeit besteht in den Kurvenverläufen der beiden Messreihen zur nativen
XML-Verarbeitung. Hier gibt es zwar erwartungsgemäß keine Unterschiede zwischen der
Messreihe mit Indexen und der ohne Index. Dennoch zeigt sich für die Performance des Serialisierungsprozesses im Vergleich zur Performance des quasi „Umkehrprozesses“ XMLParsen eine nur minimal fallende Kurve der CPU-Zeit. Daraus lässt sich schließen, dass die
Performance der Funktion XMLSERIALIZE weniger stark von der Größe der zu verarbeitenden
Dokumente abhängt, als es für den XML-Parse-Prozess der Fall ist (siehe Abschnitt 6.1.4).
Damit in Verbindung steht vor allem die Komplexität der einzelnen Vorgänge. Während der
Serialisierungsprozess auf einfache Weise XML-Dokumente nach bestimmten Regeln von der
internen Struktur in eine textuale Form transformiert, gilt dies für den Vorgang des XMLParsens nicht. Hier finden zusätzlich zur Transformation der XML-Dokumente in ein internes
binäres Format noch weitere Aktionen statt, die pro Parse-Prozess ausgeführt werden und somit
entsprechenden Overhead verursachen. Dazu zählen beispielsweise das Prüfen der XMLDokumente auf Wohlgeformtheit oder, falls spezifiziert, deren Validierung gegen ein definiertes
XML-Schema.
143
8 Query Performance
Strukturiertheit (CLOB und XML)
Das Ergebnis der Strukturiertheitsmessung bei dem Szenario Komplettzugriff zeigt verglichen
mit der Performance-Analyse des Parse-Prozesses interessanterweise eine Gemeinsamkeit und
einen Unterschied auf (siehe Abbildung 59). So lässt sich hier die Aussage aufgreifen, dass
Textknoten schneller als Elementknoten und diese wiederum schneller als Attributknoten serialisiert werden können. Keinen oder zumindest kaum einen Unterschied macht dagegen die Art
der Verknüpfung der Knoten eines XML-Dokuments. Die Serialisierung von tiefen, flachen und
balancierten nativen XML-Dokumenten nimmt ungefähr gleich viel Zeit in Anspruch. Bei der
Untersuchung des Parse-Prozesses hingegen zeigte sich noch ein erhöhter Aufwand für die
Verarbeitung von flachen XML-Dokumenten. Die Ursache für diese Abweichung wird in der
Arbeitsweise der XMLSERIALIZE-Funktion vermutet, zu der jedoch keine näheren Informationen veröffentlicht sind.
30
Sekunden
25
20
15
10
CPU - XML
5
CPU - CLOB
0
Strukturiertheit
Abbildung 59: Messergebnis – Komplettzugriff – Strukturiertheit – CPU-Zeit
In Relation zu dem SELECT der gleichen Dokumente, die nicht-nativ in Form des CLOBDatentyps gespeichert sind, resultiert ein wesentlich höherer Aufwand (siehe Abbildung 59), der
aber insgesamt mit Ausnahme der zwei Spitzen der Merkmalsausprägungen „A“ und „A, T“
immer noch relativ gering ausfällt. Insgesamt gesehen kann durch die hier durchgeführten
Untersuchungen der Modellierungshinweis aus Abschnitt 6.1.4, also Attributknoten an geeigneten Stellen durch Element- oder Textknoten zu ersetzen, bestätigt werden.
144
8 Query Performance
Zusammensetzung (XML)
Bei der Betrachtung des Kriteriums der Zusammensetzung ergeben sich für das Szenario
Komplettzugriff keine wesentlichen neuen Erkenntnisse. Abbildung 60 zeigt einen ähnlichen,
jedoch kontinuierlicher und etwas stärker fallenden Kurvenverlauf der CPU-Zeit als die weiter
oben durchgeführte Analyse zum Kriterium der Größe und Anzahl. Daraus lässt sich ableiten,
dass es analog zu den Ausführungen aus Abschnitt 6.1.4 auch für den Serialisierungsprozess aus
Performance-Perspektive Sinn machen kann, mehrere Entitätsausprägungen in ein gemeinsames
XML-Dokument abzubilden.
5
4,5
4
Sekunden
3,5
3
2,5
2
CPU
1,5
1
0,5
0
1K
10K
(x 100.000) (x 10.000)
100K
(x 1.000)
1M
(x 100)
10M
(x 10)
Zusammensetzung (und Anzahl)
Abbildung 60: Messergebnis – Komplettzugriff – Zusammensetzung – CPU-Zeit
8.2.2
Indexunterstützter Zugriff
Das hier betrachtete Szenario zielt darauf ab, die möglichen Effizienzgewinne aufzuzeigen, die
durch die Verwendung eines User-Defined-XML-Index erzielbar sind. Wie bereits in Abschnitt
8.1.1 erwähnt, kann DB2 solche Indexe nur in Verbindung mit der XMLTABLE-Funktion oder
dem XMLEXISTS-Prädikat nutzen. Für die untersuchten Messreihen ist dabei die zuletzt
erwähnte Variante gewählt worden.
145
8 Query Performance
Bezogen auf die Testdaten aus Abschnitt 5.1.1 oder die davon abgeleiteten Testdaten aus
Abschnitt 5.1.3 wäre beispielsweise folgende Situation denkbar. Angenommen innerhalb des
Datenbestands würde sich genau ein Musterdokument befinden, das demselben XML-Schema
(siehe Abbildung 40) genügt wie die übrigen Dokumente. Der einzige Unterschied des Musterdokuments zu den anderen bestünde in den vergebenen „id“-Attributen der „seite“- und
„textblock“-Elemente. Diesen ist im Fall des Musterdokuments stets der Präfix „muster_“
vorangestellt. Abbildung 61 visualisiert beispielhaft die ersten Zeilen eines derartigen Dokuments.
<?xml version="1.0" encoding="UTF-8"?>
<seite id="muster_seite1">
<textblock id="muster_textblock0" posx="10" posy="20"
schriftart="arial" schriftgroesse="8" ...>
Musterdokument
</textblock>
<textblock id="muster_textblock1" posx="50" posy="50"
schriftart="arial" schriftgroesse="14" ...>
Otto Normalverbraucher, Normweg 1, 00001 Normstadt
</textblock>
...
Abbildung 61: Ausschnitt aus dem „Musterdokument“
Nun soll folgende fachliche Anforderung bestehen. Der Anwender, der den beschriebenen
Datenbestand verwaltet, hat vergessen, wo sich das zu den Daten gehörende Musterdokument
befindet. Er vermutet zwar, dass es zusammen mit den anderen Dokumenten abgelegt ist,
würde dies zur Sicherheit aber gerne nachprüfen. In diesem Szenario seien die „id“Attributknoten der „textblock“-Elemente indexiert. Deshalb kann der Anwender mithilfe einer
gezielten SELECT-Abfrage unter Verwendung des XMLEXISTS-Prädikats alle Dokumente
indexunterstützt effizient auf ein „textblock“-Element mit beispielsweise dem „id“-Attributwert
„muster_textblock1“ durchsuchen. Für die anschließende Messreihe genügt gemäß den
allgemeinen Ausführungen aus Abschnitt 8.2.2 die Anwendung der COUNT-Funktion. Ein
XML-Serialisierungsprozess bleibt somit bei den Messreihen zur nativen XML-Speicherung aus.
Für das vorangehende Beispiel beziehungsweise allgemein für den indexunterstützten Zugriff
stellt sich die Frage, wie groß die Effizienzvorteile von User-Defined-XML-Indexen tatsächlich
gegenüber den anderen Speicherformen ohne derartige Indexunterstützung sind. Um dies zu
klären, wurden zu dem hier betrachteten Szenario folgende, den Vorbetrachtungen aus Kapitel 5
unterliegende Messungen und Variationen durchgeführt.
146
8 Query Performance
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Zusammensetzung (XML)
Im Weiteren sollen die Ergebnisse analysiert werden. Zusätzliche Informationen zum konkreten
Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen inklusive den Messwerten der
Elapsed-Zeit sowie zu den Diagrammen zu den vom DB2 Optimizer jeweils gewählten
Zugriffsplänen sind dabei aus Umfangsgründen und gemäß den Bemerkungen aus Kapitel 5 in
den Anhang dieser Arbeit ausgelagert.
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Die Untersuchungen zu dem Kriterium Größe und Anzahl zeigen, bezogen auf die möglichen
Performance-Vorteile von User-Defined-XML-Indexen, ein eindeutiges Ergebnis. Das hierzu
verwendete SELECT-Statement mit enthaltenem XMLEXISTS-Prädikat wird für die Messreihe
„XML (mit 3 Indexen)“ um ein Vielfaches schneller ausgeführt als für alle anderen betrachteten
Messreihen. Dabei lässt sich in Abbildung 62 für die CPU-Zeit im Gegensatz zu den anderen
Messreihen ein ungefähr konstanter minimaler Zeitaufwand erkennen.
0,6
Sekunden
0,5
0,4
CPU - CLOB
0,3
CPU - VARCHAR
0,2
CPU - XML
0,1
CPU - XML
(mit 3 Indexen)
0
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 62: Messergebnis – Indexunterstützter Zugriff – Größe und Anzahl – CPU-Zeit
147
8 Query Performance
Bei der Betrachtung von Abbildung 62 fällt auf, dass hier keine Messergebnisse zu der Merkmalsausprägung „1K x 100.000“ dargestellt sind. Dies ist bewusst so entschieden worden, da
die in dieser Ausprägung ermittelten Werte speziell für die CLOB-Messreihe (siehe Abschnitt
8.2.1) sehr groß ausfallen. Wären diese in das abgebildete Diagramm einbezogen worden, hätten
sich die Unterschiede in den weiteren Kurvenverläufen nicht mehr deutlich erkennen lassen.
Demgegenüber sind die Messergebnisse in den Wertetabellen im Anhang der vorliegenden
Arbeit vollständig für alle Merkmalsausprägungen verzeichnet.
An dieser Stelle sei nochmals vermerkt (siehe Abschnitt 8.2), dass für die Messreihen der nichtnativen XML-Verarbeitung stets die Kosten des Komplettzugriffs als Vergleichswerte dienen.
Demzufolge muss für die beiden Messreihen CLOB und VARCHAR noch ein zusätzlicher
anwendungsseitiger Aufwand (Parsen und nach Musterdokument suchen) einbezogen werden,
der notwendig ist, um die weiter oben geschilderte Auswertung vornehmen zu können. In
diesem Zusammenhang ist auch die in Abbildung 62 dargestellte Ergebniskurve der Messreihe
„XML“ in Relation zu den „nicht-nativen“ Messergebnissen durchaus als positiv zu bewerten,
obwohl sie sich oberhalb der Kurvenverläufe zu den nicht-nativen Messreihen befindet. Weitere
Details zu den Ergebnissen der einzelnen Messreihe sind der Abbildung 62 zu entnehmen und
sollen hier nicht diskutiert werden.
Zusammensetzung (XML)
Für das Kriterium der Zusammensetzung zeigt sich bezogen auf das aktuell untersuchte Szenario ein ähnlicher Kurvenverlauf wie bereits bei der Betrachtung aus Abschnitt 8.2.1. Mit zunehmender Dokumentgröße fällt bei gleichzeitig konstant bleibendem Gesamtdatenvolumen die
Kurve der CPU-Zeit ab. Aufgrund der angesprochenen Ähnlichkeit wird daher auf ein zusätzliches Diagramm verzichtet und auf Abschnitt 8.2.2 verwiesen. Hervorzuheben bleibt an dieser
Stelle lediglich folgender Unterschied: Die aus den hier ermittelten Messergebnissen resultierende Kurve der CPU-Zeit fällt zu Beginn stärker und bereits ab der Merkmalsausprägung
„1K x 100.000“ schwächer ab als bei der Untersuchung in Abschnitt 8.2.2.
Insgesamt gesehen verursacht der auf diese Weise evaluierte indexunterstützte Zugriff für die
Verarbeitung einer geringen Anzahl großer Dokumente weniger Aufwand als bei der Verarbeitung von vielen Dokumenten mit geringer Größe. Hieraus lässt sich folgern, dass auch für das
aktuell betrachtete Szenario das Bündeln mehrerer Entitätsausprägungen in einem gemeinsamen
148
8 Query Performance
XML-Dokument aus Performance-Perspektive durchaus sinnvoll sein kann. Die Unterschiede
sind aber relativ gering.
8.2.3
Selektiver Zugriff
Das Szenario Selektiver Zugriff evaluiert eine der großen Stärken der nativen XMLVerarbeitung. Mithilfe der XMLQUERY-Funktion ist es möglich, gezielt per XPath-Ausdruck
auf spezifizierte Teile eines XML-Dokuments zuzugreifen, ohne dazu erst das gesamte XMLDokument aus DB2 auslesen zu müssen. Leider ist die Funktion nicht in der Lage, für den
gezielten Datenzugriff vorhandene User-Defined-XML-Indexe zu verwenden. Dieser Sachverhalt fand bereits in Abschnitt 8.1.1 Erwähnung. Dort wurde auch darauf Bezug genommen,
dass es in bestimmten Situationen Sinn machen kann, zusätzlich zur Verwendung der
XMLQUERY-Funktion den zu verarbeitenden Datenbestand zuvor durch das „indexfähige“
XMLEXISTS-Prädikat einzuschränken. Diese Art Workaround wird auch für die hier betrachteten Messreihen verwendet, sodass für die dazugehörigen SELECT-Statements der in
Abschnitt 8.1.3 beispielhaft beschriebene Zugriffsplan resultiert. Abbildung 63 zeigt ein solches
SELECT-Statement für die Merkmalsausprägung „10K x 10.000“.
SELECT XMLQUERY('$x/seite/textblock[@id="muster_textblock1"]'
PASSING XML_DOC AS "x")
FROM T24431A.TXML_10K
WHERE XMLEXISTS('$x/seite/textblock[@id="muster_textblock1"]'
PASSING XML_DOC AS "x");
Abbildung 63: Beispiel eines SELECT-Statements für selektiven Zugriff
Bevor die Auswertung der Messreihen erfolgt, soll analog zu dem vorangehenden Abschnitt
auch hier eine zu dem jeweils verwendeten Statement passende fachliche Anforderung
konstruiert werden. Dazu sei wieder das Vorhandensein eines Musterdokuments (siehe
Abschnitt 8.2.2) angenommen, dass in diesem Fall ein Anwender zur Orientierung benötigt, um
die OCR-Software für das Einscannen neuartiger Dokumente zu kalibrieren. Da er diese
Tätigkeit nicht zum ersten Mal ausführt, sind ihm die meisten Details des Musterdokuments
noch von der letzten Kalibrierung in guter Erinnerung. Bei der Digitalisierung der Adressdaten
der Belege – diese befinden sich stets im ersten „textblock“-Element – ist er jedoch, was
deren Format angeht, etwas unsicher. Deshalb würde er sich gern anhand des entsprechenden
149
8 Query Performance
„textblock“-Elements im Musterdokument vergewissern, ob er dieses Format richtig in
Erinnerung behalten hat. Dazu schreibt er sich ein SELECT-Statement, in dem er mit
der XMLQUERY-Funktion gezielt das „textblock“-Element mit dem „id“-Attributwert
„muster_textblock1“ ausliest. Da ihm die Details der DB2-seitigen Unterstützung von UserDefined-XML-Indexen bekannt sind, verwendet er, um effizienter zu seinem gewünschten
Ergebnis zu gelangen, weiterhin noch ein XMLEXISTS-Prädikat. Dadurch kann er die Ergebnismenge indexunterstützt auf das Musterdokument einschränken und muss anschließend nur
noch in diesem mithilfe der XMLQUERY-Funktion nach dem gewünschten „textblock“Element suchen.
Im Zusammenhang mit dem obigen Beispiel beziehungsweise allgemein für das Szenario
Selektiver Zugriff stellt sich die Frage, welche Effizienzgewinne die native XML-Speicherung
für den Fall des selektiven Zugriffs gegenüber den nicht-nativen Ablageformen bietet. Ebenfalls
zu klären ist, ob und wenn ja in welchem Ausmaß der indexunterstützte Zugriff gegenüber der
nativen XML-Speicherung ohne User-Defined-XML-Index Performance-Vorteile bietet. Um
diese Fragestellungen zu klären sind zu dem hier betrachteten Szenario folgende, den Vorbetrachtungen aus Kapitel 5 unterliegende Messungen und Variationen durchgeführt worden.
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Zusammensetzung (XML)
Anschließend sollen die Ergebnisse analysiert werden. Zusätzliche Informationen zum konkreten Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen inklusive den Messwerten der
Elapsed-Zeit sowie zu den Diagrammen zu den vom DB2 Optimizer jeweils gewählten
Zugriffsplänen sind dabei aus Umfangsgründen und gemäß den Bemerkungen aus Kapitel 5 in
den Anhang dieser Arbeit ausgelagert.
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Die für das Kriterium der Größe und Anzahl durchgeführten Untersuchung zum selektiven
Zugriff auf Inhalte eines XML-Dokuments weichen insgesamt in ihren Ergebnissen nur geringfügig von den Resultaten aus Abschnitt 8.2.2 ab. Deshalb soll für vergleichende Aussagen
zwischen den nicht-nativen und nativen Messreihen auf diesen Abschnitt verwiesen werden.
150
8 Query Performance
Dies gilt auch für die Begründung zu der in Abbildung 64 nicht dargestellten Merkmalsausprägung „1K x 100.000“.
0,6
Sekunden
0,5
0,4
CPU - CLOB
0,3
CPU - VARCHAR
0,2
CPU - XML
0,1
CPU - XML
(mit 3 Indexen)
0
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 64: Messergebnis – Selektiver Zugriff – Größe und Anzahl – CPU-Zeit
Bei genauerer Betrachtung von Abbildung 64 lässt sich für die Messreihen zur nativen XMLVerarbeitung eine Besonderheit gegenüber den in Abschnitt 8.2.2 diskutierten Ergebnissen
erkennen, nämlich eine in fast allen Merkmalsausprägungen mit der Dokumentgröße ansteigende CPU-Zeit. Die Messzeiten zum nicht-nativen XML-Datenzugriff weichen gemäß den
Vorbemerkungen zu Beginn von Abschnitt 8.2 nicht von den zuvor betrachteten Resultaten ab.
Die Ursache für den erwähnten Anstieg bei den Messreihen „XML“ und „XML (mit 3 Indexen)“ lässt sich in der Abarbeitung der XMLQUERY-Funktion vermuten. Bis zu deren Ausführung kann DB2 mithilfe des XMLEXISTS-Prädikats die gesamte Ergebnismenge lediglich auf
das in diesem Beispiel betrachtete Musterdokument einschränken. Anschließend wird dieses
mittels der XMLQUERY-Funktion gezielt auf das gewünschte „textblock“-Element hin ausgewertet. Je größer dabei das Musterdokument ist, umso höher ist demzufolge auch der Aufwand
des erwähnten Suchprozesses. Da die Größe des Musterdokuments aber ebenso wie das Ausmaß
der anderen XML-Dokumente des Testdatenbestands mit jeder nachfolgend abgebildeten Merkmalsausprägung wächst, steigt ebenso auch der Gesamtaufwand des hier untersuchten SELECTStatements. Für die Messreihe „XML (mit 3 Indexen)“ sind die Kosten, die durch die indexbasierte Projektion per XMLEXISTS-Prädikat entstehen, im Übrigen gemäß den Ausführungen
151
8 Query Performance
aus Abschnitt 8.2.2 äußerst geringfügig, sodass der Kurvenverlauf hier (fast) vollständig auf die
nicht „indexfähige“ XMLQUERY-Funktion zurückzuführen ist.
Zusammensetzung (XML)
Die bei der Untersuchung zum Kriterium der Zusammensetzung gewonnenen Ergebnisse zeigen
auch bei dem hier betrachteten Szenario eine durchgehend fallende Messkurve zur CPU-Zeit.
Diese verläuft ebenfalls ähnlich zu der aus Abschnitt 8.2.1 und soll daher nicht durch ein zusätzliches Diagramm dargestellt werden. Stattdessen werden die sich zeigenden Abweichungen
anschließend erläutert.
Es ist anzumerken, dass im Unterschied zu dem Kurvenverlauf der CPU-Zeit in Abschnitt 8.2.1
die hier sichtbare Abflachung der CPU-Zeit sukzessive weniger wird und zum Ende hin bei der
Merkmalsausprägung „10M x 10“ stagniert. Dieser Effekt ist auf den gleichzeitigen Anstieg der
CPU-Zeit bei der vorher beschriebenen Untersuchung zum Kriterium der Größe und Anzahl
zurückzuführen. Er resultierte aus dem erhöhten Aufwand, den die Abarbeitung von immer
größer werdenden Dokumenten durch die XMLQUERY-Funktion in Anspruch nimmt. Da der
Effekt sich gleichermaßen auf die Untersuchung zum Kriterium der Zusammensetzung auswirkt, wird die noch in Abschnitt 8.2.2 sichtbare Abflachung durch die wachsenden Kosten der
XMLQUERY-Funktion immer stärker „gebremst“.
Trotz der vorherigen Anmerkungen lässt sich insgesamt aber auch für das hier betrachtete
Szenario folgendes formulieren. Der selektive Zugriff auf kumulierte XML-Dokumente ist
effizienter als der Zugriff auf über mehrere XML-Dokumente verteilt gespeicherte Entitätsausprägungen.
152
8 Query Performance
8.2.4
Komplexe Prädikate
Die hier durchgeführten Betrachtungen dienen der Untersuchung der Query Performance von
SELECT-Abfragen, die in ihren WHERE-Klauseln44 komplexe Prädikate enthalten. DB2 unterscheidet Prädikate anhand der folgenden Kriterien.
Einfache oder zusammengesetzte Prädikate
Lokale oder Join-Prädikate
Boolean-Ausdruck
Nähere Details sowie eine granularere Einteilung von Prädikaten finden sich in [IBM11u]
und sollen hier nicht betrachtet werden. Für den XML-Kontext ist an dieser Stelle wichtig, dass
für die Statement-Ausführungen, vereinfacht gesprochen, zwischen „teuren“ (Stage 2) und
„günstigen“ (Stage 1) Prädikaten unterschieden wird [IBM11u]. Das XMLEXISTS-Prädikat
zählt dabei in allen möglichen Variationen (bezogen auf die XPath-Ausdrücke) zu den
„Stage 2“-Prädikaten, ist allerdings trotzdem „indexable“ [IBM11u]. Der Begriff „komplexes
Prädikat“ wird von IBM nicht speziell definiert. In dem hier betrachteten Zusammenhang betitelt er die komplexe Verknüpfung mehrerer XPath-Operatoren (AND und OR) zu einem
XMLEXISTS-Prädikat. Dieses ist, wie in Abbildung 65 dargestellt, in das für die weiteren
Untersuchungen verwendete SELECT-Statement integriert worden. Dabei wird mithilfe des
XMLEXISTS-Prädikats der gesamte XML-Datenbestand auf eine dazu passende Teilmenge
projiziert. Um analog zu Abschnitt 8.2.2 zu verhindern, dass bei der Ergebnisbildung zu dem
SELECT-Statement ein XML-Serialisierungsprozess stattfindet, erfolgt auch hier die Anwendung der COUNT-Funktion.
SELECT COUNT(*) FROM T24431A.TXML_100K
WHERE XMLEXISTS(
'$x/seite/textblock[(@pox=20 and @posy=10) or (@posx=10 and @posy=20)]'
PASSING XML_DOC AS "x");
Abbildung 65: SELECT-Statement für das Szenario Komplexe Prädikate
Das in Abbildung 65 dargestellte Statement könnte beispielsweise in der folgend beschriebenen
Situation genutzt werden. Dazu sei wieder die Existenz des in den vorigen Abschnitten beschriebenen Musterdokuments vorausgesetzt. Nun sei angenommen, dass anstatt der typischen
44
Prädikate lassen sich allgemein für die WHERE-, HAVING- oder ON-Klausel spezifizieren.
153
8 Query Performance
Vergabe der „id“-Attribute im Musterdokument nicht das Präfix „muster_“ verwendet wurde,
sodass das Musterdokument in dieser Hinsicht identisch zu den anderen Dokumenten des
Datenbestands konstruiert ist. Da aber ein Musterdokument auch ein einzigartiges erstes
„textblock“-Element (mit dem „id“-Attributwert „textblock0“) beinhaltet (siehe Abbildung 61),
kann es durch dieses noch immer von den anderen XML-Dokumenten unterschieden werden.
Weiterhin sei die gleiche fachliche Anforderung wie in Abschnitt 8.2.2 vorausgesetzt. Somit
besteht die Zielstellung darin, den Datenbestand nach dem Vorhandensein eines Musterdokuments zu durchsuchen. Die an den „id“-Attributwerten orientierte Vorgehensweise aus
Abschnitt 8.2.2 führt nun leider nicht mehr zum gewünschten Ergebnis. Gemäß den obigen
Bemerkungen existiert für die hier getätigten Annahmen kein Dokument, das ein „textblock“Element mit dem „id“-Attributwert „muster_textblock1“ enthält. Glücklicherweise kann sich
der Anwender aber daran erinnern, dass das Musterdokument im Gegensatz zu den anderen
Dokumenten ein einzigartiges erstes „textblock“-Element besitzt. Er weiß auch, dass sich dieses
Element an der Position (10, 20) befindet, ist sich aber mit der Reihenfolge der Koordinaten
nicht ganz sicher, sodass auch die Position (20, 10) in Frage kommt. Daher entscheidet er sich,
einen XPath-Ausdruck zu schreiben, der mit einer OR-Verknüpfung beide Fälle abdeckt. Diesen
bindet er in ein SELECT-Statement mit enthaltenem XMLEXISTS-Prädikat und verwendeter
COUNT-Funktion ein. Dadurch ist es ihm möglich zu überprüfen, ob ein Musterdokument
innerhalb des Datenbestands vorhanden ist.
An dem obigen Beispiel setzen die Performance-Untersuchungen zu dem Szenario Komplexe
Prädikate an. Diese sollen aufzeigen, wie effizient die Abarbeitung von Statements mit einem
komplexen XMLEXISTS-Prädikat bei der nativen XML-Speicherform abläuft und welche
Gewinne gegenüber der nicht-nativen Ablageform bestehen. Dazu sind folgende, den Vorbetrachtungen aus Kapitel 5 unterliegende Messungen und Variationen durchgeführt worden.
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Zusammensetzung (XML)
Anschließend sollen die Ergebnisse analysiert werden. Zusätzliche Informationen zum konkreten Aufbau der Messprozedur, zu den einzelnen Ergebnistabellen inklusive den Messwerten
der Elapsed-Zeit sowie zu den Diagrammen zu den vom DB2 Optimizer jeweils gewählten
Zugriffsplänen sind dabei aus Umfangsgründen und gemäß den Bemerkungen aus Kapitel 5 in
den Anhang dieser Arbeit ausgelagert.
154
8 Query Performance
Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Die Messergebnisse der Messreihen zum Kriterium der Größe und Anzahl zeigen, dass das hier
betrachtete Szenario Komplexe Prädikate, wie aufgrund dessen „Komplexität“ zu vermuten war,
wesentlich höhere Kosten nach sich zieht als die zuvor untersuchten Messreihen. Dabei gilt für
die in Abbildung 66 präsentierten Resultate, dass für die Messreihen zur nicht-nativen XMLSpeicherung wiederum die Kosten für den Komplettzugriff als Referenzwerte verwendet
wurden. Dies basiert auf den Vorbemerkungen von Abschnitt 8.2, welche hier aber nicht nochmals thematisiert werden sollen.
18
16
14
CPU - CLOB
Sekunden
12
10
CPU - VARCHAR
8
6
CPU - XML
4
2
CPU - XML
(mit 3 Indexen)
0
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Größe und Anzahl
Abbildung 66: Messergebnis – Komplexe Prädikate – Größe und Anzahl – CPU-Zeit
In Abbildung 66 zeigt sich bezüglich der Messreihen zur nativen XML-Verarbeitung neben den
insgesamt in Relation zu den zuvor untersuchten Szenarien verhältnismäßig hohen Kosten aber
auch ein ungewöhnlich starker Anstieg der CPU-Zeit von der ersten zur zweiten Merkmalsausprägung. Dieser erklärt sich allerdings bei einem Blick auf die in Abschnitt 6.3 erwähnte
Anzahl an indexierten Knoten. Da genau auf jenen Knoten der innerhalb des hier verwendeten
XMLEXISTS-Prädikats befindliche XPath-Ausdruck ausgewertet wird, ist der dabei resultierende Aufwand umso größer, je mehr Knoten mit OR und AND (siehe Abbildung 65) zu
verknüpfen sind. Hier lässt sich eine gewisse Analogie zu den Kosten der Indexpflege in
Abschnitt 6.3 erkennen. Genau wie dort steigt der Aufwand von der Merkmalsausprägung
155
8 Query Performance
„1K x 100.000“ zur nächsten zusammen mit der Anzahl an indexierten/zu indexierenden
Knoten stark an und verhält sich von dort an nahezu konstant.
Speziell bei der Kurve zur Messreihe „XML (mit 3 Indexen)“ ist für den in Abbildung 66 dargestellten Kurvenverlauf noch eine andere Tatsache verantwortlich. Dazu ist an dieser Stelle ein
Blick auf die sich im Anhang dieses Abschnitts befindlichen Zugriffsplandiagramme notwendig. Hier lässt sich erkennen, dass der DB2 Optimizer bei der aktuell betrachteten Messreihe nur
für die Merkmalsausprägung „1K x 100.000“ die vorhandenen User-Defined-XML-Indexe
verwendet. Für alle anderen Merkmalsausprägungen wählt er einen FULL TABLE SCAN.
Diese Entscheidung ist allerdings ungünstig und resultiert aus der bereits angesprochenen
unvorteilhaften Gleichverteilung, die für die indexierten XML-Knoten generell angenommen
wird. Deshalb schätzt der DB2 Optimizer für die (Zwischen-)Ergebnismenge des XMLEXISTSPrädikats, entgegen dem tatsächlich immer einen Musterdokument, beispielsweise für die
Merkmalsausprägung „10K x 10.000“ insgesamt rund 506 XML-Dokumente ab. Entsprechend
kalkuliert er auch die Kosten für den indexunterstützten Zugriff und entscheidet sich für den
FULL TABLE SCAN. Wie effizient für die weiteren Merkmalsausprägungen in diesem
Zusammenhang die Verwendung der dafür vorgesehenen User-Defined-XML-Indexe wäre,
lässt sich nur erahnen. Trotzdem kann hier aufgrund der Messergebnisse aus der Merkmalsausprägung „1K x 100.000“ vermutet werden, dass der indexunterstützte Zugriff auch für die
Messungen zu den weiteren Ausprägungen wesentliche Effizienzvorteile bieten würde.
Hinsichtlich des Vergleichs der Messreihen der nativen und nicht-nativen XML-Verarbeitung
kann an dieser Stelle keine klare Aussage getroffen werden. Zwar zeigt Abbildung 66 deutlich
höhere Kosten für den Zugriff auf die nativ abgelegten Daten. Hierbei muss aber berücksichtigt
werden, dass die „komplexe“ Verarbeitung der nicht-nativen XML-Dokumente in dem betrachteten Fall erst noch anwendungsseitig inklusive eines zuvor notwendigen Parse-Prozesses
erfolgen muss. Demnach hängt der tatsächliche Effizienzgewinn, den die native XMLSpeicherung in diesem Kontext (vielleicht) hat, stark von der Performance der anwendungsseitigen XML-Verarbeitung ab. Ohne Zusatzmessungen, auf die gemäß den Bemerkungen aus
Abschnitt 8.2 aber verzichtet wurde, sind leider keine konkreteren Aussagen hierzu möglich.
156
8 Query Performance
Zusammensetzung (XML)
Entgegen den Ergebnissen zum Kriterium der Größe und Anzahl zeigen sich für die Untersuchungen zur Zusammensetzung wenig neue Erkenntnisse. Zwar sind auch hier die Kosten
gegenüber den Messreihen aus den vorangehenden Abschnitten deutlich gestiegen. Der gesamte
Kurvenverlauf der CPU-Zeit hebt sich jedoch nur geringfügig von den beispielsweise in
Abschnitt 8.2.1 diskutierten Resultaten ab. Hierbei ist insgesamt ein nur sehr geringfügig
abnehmender Aufwand erkennbar. Aus diesem lässt sich dennoch folgern, dass es, wie auch
bei allen anderen in Abschnitt 8.2 betrachteten Szenarien, durchaus sinnvoll sein kann, zur
Effizienzsteigerung mehrere Entitätsausprägungen innerhalb eines gemeinsamen XMLDokuments zusammenzufassen. Hinsichtlich des Gesamtaufwands sind die PerformanceGewinne aber trotzdem nur von geringfügiger Bedeutung.
157
9 Zusammenfassung und Bewertung von DB2
9 Zusammenfassung und Bewertung von DB2
Das folgende Kapitel dient dazu, einen zusammenfassenden Überblick über die in dieser Arbeit
durchgeführten Performance-Untersuchungen zu geben. Dabei soll kategorisiert nach den drei
Themenschwerpunkten
Migration und Parsen,
XML-Schema-Management und
Query Performance
sowohl auf die Ergebnisse der einzelnen Messreihen als auch auf die zum Teil festgestellten
Schwachstellen der pureXML-Implementierung in DB2 eingegangen werden. Hinzu kommen
an passender Stelle auch Informationen zu den bereits bekannten Verbesserungen in der Nachfolgeversion 10 des hier betrachteten DB2.
Migration und Parsen
Die Untersuchungen zum Themenschwerpunkt Migration und Parsen zeigen zwei wesentliche
Ressourcenkonsumenten. Sowohl der XML-Parse-Prozess (mittels XMLPARSE) als auch der
Konkatenationsprozess (mittels CONCAT) sind sehr aufwändig. Beide Prozesse bilden für
einen Großteil der betrachteten Merkmalsausprägungen mit weitem Abstand den Hauptanteil
der dabei verursachten Kosten. Während der Konkatenationsprozess allerdings nur in Migrationsszenarien Verwendung findet, ist der XML-Parse-Prozess ein dauerhafter Aufwandsfaktor,
der bei jeder Datenmanipulation anzutreffen ist. Daher ist es speziell für letzteren wichtig, ihn
stetig weiter zu optimieren beziehungsweise an geeigneten Stellen unnötig zu machen. Die
Nachfolgeversion 10 des hier betrachteten DB2 versucht der Problematik vor allem durch die
Funktionalitäten Binary XML (siehe Abschnitt 6.2) und XMLMODIFY (siehe Abschnitt 6.4)
gerecht zu werden. Diese erlauben zum einen die binäre Kommunikation von bereits geparsten
XML-Dokumenten und zum anderen „in-Document“-UPDATEs, sodass der Parse-Aufwand hier
auf einen geringen Teil reduziert wird. Ausführliche Analysen dazu finden sich in [IBM11z].
Eine Zusammenfassung der Ergebnisse zur Thematik Migration und Parsen ist Abbildung 67 zu
entnehmen.
158
Migration und Parsen
9 Zusammenfassung und Bewertung von DB2
Messreihe
Ergebnisse/Bemerkungen
„Einfaches Kopieren“
- bei gleichem Gesamtdatenvolumen höherer Aufwand
zum „einfachen Kopieren“ kleiner Dokumente
- „Seitenfüllgradproblem“ bei LOBs
- kein Einfluss der Strukturiertheit und Zusammensetzung
der XML-Dokumente
Konkatenation
- Konkatenation per Stored Procedure wesentlich effizienter als per Recursive SQL
- erheblicher Einfluss, bereits ab 100 zu konkatenierenden
Teilen der Hauptkostenfaktor einer Migration
- kein Einfluss der Strukturiertheit und Zusammensetzung
der XML-Dokumente
UnicodeKonvertierung
- quasi-linearer Aufwand bei dem Kriterium der Größe und
Anzahl
- kein Einfluss der Strukturiertheit und Zusammensetzung
der XML-Dokumente
XML-Parsen
- Hauptanteil der Kosten einer Migration (ohne Konkatenation) von großen XML-Dokumenten (bei konstantem
Gesamtdatenvolumen)
- Struktur hat merklichen Einfluss
- kumulierte (zusammengesetzte) XML-Dokumente lassen
sich etwas schneller parsen als „Einzeldokumente“
Pflege von UserDefined-XML-Indexen
- Indexpflegeaufwand ist stark abhängig von Anzahl
indexierter/zu indexierenden Knoten
- nachträgliche Index-Erstellung ist deutlich effizienter als
automatische Indexpflege
Abbildung 67: Zusammenfassung der Messergebnisse – Migration und Parsen
XML-Schema-Management
Das XML-Schema-Management stellt den größten Schwachpunkt von DB2 hinsichtlich der
XML-Unterstützung dar. Wie bereits erläutert, bietet DB2 kaum Unterstützung zu den in
Abschnitt 7.2 beschriebenen Anforderungen an das XML-Schema-Management. Sämtliche der
gewünschten Funktionalitäten sind derzeit eigenständig „nachzubauen“. Das wiederum wirkt
sich erheblich auf die Performance der Schemavalidierung aus, die beispielsweise gemessen an
einem „nicht-validierenden“ INSERT mindestens das Vierfache an Aufwand benötigt. Dabei ist
es irrelevant, welche Form der Validierung gewählt wird. Die Nachfolgeversion 10 des in dieser
Arbeit betrachteten DB2 bringt allerdings auch hier wesentliche Verbesserungen. Nähere
159
9 Zusammenfassung und Bewertung von DB2
Details dazu wurden bereits in Abschnitt 7.3 erwähnt. Eine Zusammenfassung der Messergeb-
XML-Schema-Management
nisse zur Thematik XML-Schema-Management findet sich in Abbildung 68.
Messreihe
Ergebnisse/Bemerkungen
Automatische
Schemavalidierung
- mit abnehmender XML-Dokumentanzahl bei konstantem
Gesamtdatenvolumen geringer werdender Aufwand zur
Validierung
- in Relation zum „nicht-validierenden“ INSERT hoher
Aufwand
- Aufwand abhängig von der Komplexität des XMLSchemas
Nachträgliche
Schemavalidierung
- effizienter als automatische Schemavalidierung
- konstanter Aufwand zur Validierung
- in Relation zum „nicht-validierenden“ INSERT hoher
Aufwand
- Aufwand abhängig von der Komplexität des XMLSchemas
Abbildung 68: Zusammenfassung der Messergebnisse – XML-Schema-Management
Query Performance
Die Untersuchungen zum Thema Query Performance zeigen entgegen den anderen betrachteten
Themenschwerpunkten durchgehend relativ positive Ergebnisse für die Performance des Datenzugriffs auf nativ gespeicherte XML-Dokumente (siehe Abbildung 69). Besonders hervorzuheben sind dabei die Effizienzvorteile von User-Defined-XML-Indexen und die Möglichkeit des
selektiven Datenzugriffs. Als verbesserungsbedürftig haben sich allerdings die eingeschränkte
Verwendbarkeit der genannten Indexe und die zum Teil unvorteilhaften Abschätzungen des
DB2 Optimizers herausgestellt. So handelt es sich bei den User-Defined-XML-Indexen lediglich um Werteindexe mit generell angenommener Gleichverteilung, die nur in bestimmten
Zusammenhängen (XMLTABLE-Funktion oder XMLEXISTS-Prädikat) verwendbar sind. An
dieser Stelle bietet leider auch die Nachfolgeversion 10 des hier betrachteten DB2 keine grundlegenden Verbesserungen.
160
9 Zusammenfassung und Bewertung von DB2
Query Performance
Messreihe
Ergebnisse/Bemerkungen
Komplettzugriff
- abgesehen vom „Seitenfüllgradproblem“ ist Komplettzugriff von nativen XML-Daten deutlich teurer als von
nicht-nativen
- merklicher Einfluss der Strukturiertheit der XMLDokumente beim Zugriff auf nativ gespeicherte XMLDaten
- kumulierte XML-Dokumente lassen sich schneller auslesen
Indexunterstützter
Zugriff
- gezielte Verwendung von User-Defined-XML-Indexen
kann erhebliche Performance-Vorteile bewirken
- geringfügig effizienterer Zugriff auf kumulierte XMLDokumente
Selektiver Zugriff
- effiziente, nur zum Teil indexunterstützte Möglichkeiten
zum selektiven Datenzugriff
- geringfügig effizienterer Zugriff auf kumulierte XMLDokumente
Komplexe Prädikate
- komplexe Prädikate lassen sich auf Dokumentebene
indexunterstützt auswerten
- zum Teil unvorteilhafte Zugriffsplanauswahl durch den
DB2 Optimizer
- geringfügig effizienterer Zugriff auf kumulierte XMLDokumente
Abbildung 69: Zusammenfassung der Messergebnisse – Query Performance
Abschließend soll an dieser Stelle noch eine kurze Zusammenfassung zu den untersuchten
Kriterien angeführt werden. So sei hinsichtlich des Kriteriums der Größe und Anzahl nochmals an das „Seitenfüllgradproblem“ erinnert, das für die Verarbeitung von kleinen LOB-Daten
erhebliche Performance-Defizite nach sich zieht. Hier besteht großer Verbesserungsbedarf. Die
Nachfolgeversion 10 des hier betrachteten DB2 versucht dieses Problem durch die „inline
LOB“-Technik zu lösen, sodass kleine LOB-Dokumente wie eine Art VARCHAR-Dokument
nicht in Auxiliary-Tabellen, sondern innerhalb der Basistabelle gespeichert werden.
Was die Untersuchungen zum Kriterium der Strukturiertheit betrifft, haben sich vor allem
Unterschiede bei der Verarbeitung der einzelnen Knotentypen aufgezeigt. Die hier betrachteten
Fälle sind allerdings derart „extrem“, dass sie in realen Umgebungen nicht existieren. Die
verbleibenden festgestellten Differenzen zwischen den Strukturen sind geringfügig.
161
9 Zusammenfassung und Bewertung von DB2
Zum Kriterium der Zusammensetzung gilt es anzumerken, dass zwar durchgehend ein abnehmender Performance-Aufwand für kumulierte XML-Dokumente festgestellt wurde. Dieser
ist aber ebenfalls so geringfügig, dass er es nicht rechtfertigt, für die Datenmodellierung von
Relevanz zu sein. Hier muss auch beachtet werden, dass in realen Umgebungen nur selten alle
Informationen eines kumulierten XML-Dokuments benötigt werden. Denn zumeist wird detailliert nach einzelnen Entitätsausprägungen gesucht, sodass der übrige Teil eines kumulierten
Dokuments mitunter unnötig verarbeitet werden würde.
162
10 Schlussbetrachtung
10 Schlussbetrachtung
In der vorliegenden Arbeit sind diverse Performance-Untersuchungen zu den Themenschwerpunkten Migration und Parsen, XML-Schema-Management und Query Performance durchgeführt und in ihren Ergebnissen analysiert worden. Dabei haben sich neben wertvollen Vorteilen
der pureXML-Implementierung in DB2 for z/OS aber auch Schwachstellen gezeigt, an denen es
Optimierungsbedarf gibt. Ein großer Teil davon ist jedoch bereits erkannt und in der Nachfolgeversion 10 des hier betrachteten DB2 verbessert worden.
Nichtsdestotrotz können mithilfe der nativen XML-Speicherung und -Verarbeitung auch in der
vorliegenden DB2 for z/OS Version 9 diverse Anwendungsszenarien optimiert werden. Dazu
sei unter anderem an das eingangs in Abschnitt 1.2 betrachtete Einstiegsbeispiel erinnert. Die
dort angedachten Einsatzszenarien der neuartigen XML-Funktionalitäten könnten allesamt
durch DB2 abgedeckt werden. Besonders große Vorteile sind dabei durch die Möglichkeit des
selektiven, zum Teil indexunterstützten Datenzugriffs zu erwarten. Wie effizient aber beispielsweise die „konstruierte“ datenbankseitige XML-Schemavalidierung gegenüber der anwendungsseitigen arbeitet und ob sich der zusätzliche in Kauf zu nehmende XML-Parse-Aufwand
tatsächlich für die gebotenen Vorzüge der nativen XML-Speicherung lohnt, bleibt zum aktuellen Zeitpunkt noch ungeklärt. Hier besteht ein geeigneter Ansatzpunkt für weiterführende
Untersuchungen, bei denen beispielsweise an einer speziellen Anwendungs-Workload prototypisch die native der nicht-nativen XML-Speicherung und -Verarbeitung gegenübergestellt
werden könnte.
Insgesamt lassen sich anhand der hier gewonnenen Erkenntnisse die Design-Empfehlungen von
IBM zur Speicherung von XML-Daten in DB2 bestätigen [IBM10c]. Abbildung 70 zeigt eine
vereinfachte Darstellung dieser Empfehlungen, worin auch die in der vorliegenden Arbeit nicht
betrachtete (nicht-native) XML-Speicherform der Dekomposition zu relationalen Daten einbezogen ist. Zusammenfassend kann festgehalten werden: Die native Speicherung von XMLDaten bietet genau dann Vorzüge gegenüber nicht-nativen Speicherformen, wenn zum einen die
Anforderung der Suche beziehungsweise des selektiven Zugriffs auf diese Daten besteht und
wenn zum anderen davon auszugehen ist, dass die Daten auch als XML-Dokument wieder
ausgelesen und beispielsweise nicht nur archiviert werden sollen.
163
10 Schlussbetrachtung
?
Suchen
in XML
Nein
nicht-native
XML-Speicherung
Ja
Rückgabe
stets als XML
Ja
Nein
relationale
Speicherung
(Dekomposition)
native
XML-Speicherung
Abbildung 70: Design-Empfehlungen zur XML-Speicherform
Abschließend lässt sich für die weitere XML-Strategie der DATEV folgendes Resümee ziehen.
Obwohl die Möglichkeiten und Performance-Gewinne der nativen XML-Speicherung in DB2 in
speziellen Szenarien klar sichtbar waren, zeigten sich aber auch deutliche Schwachstellen. Da
diese in der Nachfolgeversion 10 des hier betrachteten DB2 zu großen Teilen beseitigt wurden,
kann eine allgemeingültige Empfehlung zur nativen XML-Speicherung und -Verarbeitung erst
nach erfolgreicher Prüfung in DB2 for z/OS Version 10 ausgesprochen werden. Für neue
Projektanwendungen, die intern XML-Daten verarbeiten, ist es aber bereits jetzt sinnvoll, die
Vorteile der nativen XML-Ablage in die Realisierungsplanungen einzubeziehen.
164
Abkürzungs- und Begriffsverzeichnis
Basistabelle
Als Basistabelle werden in dieser Arbeit stets Tabellen bezeichnet, für die
explizit vom Nutzer eine Spalte vom VARCHAR-, LOB- oder XMLDatentyp definiert wurde. Zur Speicherung von LOB- und XML-Daten
werden noch weitere Tabellen benötigt. Diese nennen sich LOB-Auxiliarybeziehungsweise XML-Auxiliary-Tabellen.
BIGINT
BIG INTeger
Der BIGINT-Datentyp ist ein binärer Integer mit einer Genauigkeit von 63
Bits. Er deckt somit die komplette Spanne von -9223372036854775808 bis
+9223372036854775807 ab.
Binary-String
Binary-Strings sind Folgen von Bytes. Verglichen mit Character-Strings sind
sie nicht mit einer CCSID verknüpft. DB2 unterscheidet zwischen den Binary-String-Datentypen BINARY, VARBINARY und BLOB (der maximalen
Länge nach geordnet).
CA Detector
Der CA Detector ist ein Tool zur Performance-Analyse in DB2. Er ermöglicht beispielsweise die gezielte Zuordnung von CPU- und Elapsed-Zeiten auf
Statement-Ebene oder auch die Analyse von aufgetretenen SQLCODEs.
(siehe Abschnitt 3.4.3)
CCSID
Coded Character Set Identifier
Die CCSID ist eine 16-Bit lange Nummer. Sie identifiziert eine Vorschrift,
mit der enkodierte Character-Strings zu interpretieren sind.
Character-String
Ein Character-String ist eine Folge von Bytes zur Speicherung einzelner
Zeichen. Die dazu nötige Umsetzung erfolgt anhand eines Zeichensatzes
(Enkodierschema, „encoding scheme“). Damit dieser bekannt ist, wird auf
Tabellenebene eine CCSID definiert. Zeichensätze für Character-Strings sind
beispielsweise EBCDIC oder Unicode.
165
CLOB
Character Large OBject
Ein CLOB ist eine Form des LOBs. Speziell handelt es sich um einen variabel langen Character-String. Ein CLOB hat maximal eine Länge von
2147483647 Bytes (2 Gigabytes - 1 Byte). Somit dient er der Speicherung
großer Zeichenketten. Im Rahmen dieser Arbeit wird der CLOB-Datentyp
besonders im Zusammenhang mit der nicht-nativen XML-Speicherung
betrachtet.
Constraint
Ein Constraint ist eine Regel (Bedingung), die bei Datenmanipulationen
berücksichtigt wird und die zu manipulierenden Werte einschränkt beziehungsweise überprüft. In DB2 existieren zum Beispiel UNIQUE-, Primärschlüssel-, Fremdschlüssel- oder auch CHECK-Constraints.
CPU-Zeit
„Central Processing Unit“-Zeit
Die CPU-Zeit beschreibt die reine Rechenzeit, die zur Abarbeitung von
Aktionen auf den CPUs der zSeries benötigt wird.
(siehe Abschnitt 3.3)
Data Sharing
Data Sharing ist eine Funktionalität, die mehreren DB2-Subsystemen den
Zugriff auf einen gemeinsamen, konsistent gehaltenen Datenbestand ermöglicht. Dabei setzt sie auf die „Parallel Sysplex“-Technologie und basiert
auf dem Ansatz Shared Data.
(siehe Abschnitt 5.2.2)
Data Sharing Group
Eine Data Sharing Group ist eine Gruppe von DB2-Subsystemen (Membern),
die auf einem gemeinsamen Datenbestand („Shared Data“) arbeiten.
DATEV eG
Die DATEV eG ist ein Unternehmen, das IT-Dienstleistungen für Steuerberater, Wirtschaftsprüfer, Rechtsanwälte sowie deren Mandanten erbringt.
(siehe Kapitel 2)
DB2 for z/OS
DB2 ist eine Familie von relationalen Datenbankmanagementsystemen, die
durch IBM entwickelt und vertrieben wird. Die z/OS-Version des DB2 ist für
den Einsatz auf dem Mainframe und dessen z/OS-Betriebssystem konzipiert
worden.
(siehe Abschnitt 3.2.1)
166
DDL
Data Definition Language
Unter DDL verstehen sich SQL-Anweisungen zur Definition (Erstellen,
Strukturändern und Löschen) von Datenbankobjekten, wie beispielsweise
Tabellen, Indexen oder anderen Strukturen.
DECFLOAT
DECimal FLOATing-Point
DECFLOAT ist ein Datentyp zur Abbildung von Gleitkommazahlen. Er
besitzt eine Genauigkeit von maximal 34 Dezimalstellen. Im Rahmen der
vorliegenden Arbeit wird der DECFLOAT-Datentyp besonders im Zusammenhang mit den User-Defined-XML-Indexen betrachtet.
Dekomposition
Dekomposition bezeichnet das Zerlegen von XML-Dokumenten in relationale Strukturen. Die „xml collection“-Variante des XML-Extenders baut
beispielsweise auf der Dekomposition auf. In der pureXML-Technologie
findet dieses Prinzip bei Bedarf durch die XMLTABLE-Funktion ebenfalls
Verwendung.
DocID
Document IDentifier
Die DocID ist ein eindeutiger Identifikator für jedes einzelne XMLDokument. Sie wird über eine dedizierte Sequence vergeben. Die DocID
findet sich sowohl in der Basistabelle als auch in der XML-Auxiliary-Tabelle
als Spalte wieder. Zu deren Verknüpfung ist sie zusätzlich zentraler Bestandteil aller XML-Indexe.
DocID-Index
DocumentID-Index
Dieser Index ist Teil der implizit für die native XML-Speicherung erzeugten
Strukturen. Er umfasst die DocID-Spalte und dient in Kombination mit den
User-Defined-XML-Indexen der Rückabbildung auf die Basistabelle.
DTD
Document Type Definition
DTDs dienen dazu, die Struktur von XML-Dokumenten zu beschreiben.
Aufgrund verschiedener Nachteile ist das Konzept DTD jedoch zunehmend
durch das später vom W3C-Consortium empfohlene XML-Schema aus der
Praxis verdrängt worden.
167
EBCDIC
Extended Binary Coded Decimals Interchange Code
EBCDIC ist ein Encoding-Schema, das unter anderem auf dem z/OS-System
genutzt wird, um Character-Daten zu repräsentieren. Dieser Zeichensatz
existiert in verschiedenen, teils länderspezifischen Ausführungen. Im Rahmen
der vorliegenden Arbeit wird stets der Zeichensatz EBCDIC 273 betrachtet.
Elapsed-Zeit
Bei der Performance-Analyse gibt es in DB2 verschiedene Klassen von
Elapsed-Zeiten. Sofern nicht anders kenntlich gemacht, bezeichnet ElapsedZeit in dieser Arbeit stets die Class 2 Elapsed-Zeit. Dies ist die Zeit, die
insgesamt für die Abarbeitung von Aktionen innerhalb von DB2 benötigt
wird.
(siehe Abschnitt 3.3)
Explain
Explain betitelt den für die Analyse von Zugriffsplänen nötigen Vorgang zu
deren Externalisierung. Dabei wird der durch den Optimizer berechnete
Zugriffsplan in der PLAN_TABLE persistiert.
I/O-Vorgänge
Input/Output-Vorgänge
Sobald sich angeforderte Datenbankseiten nicht im Bufferpool befinden,
müssen I/O-Vorgänge ausgeführt werden, um diese vom Sekundärspeicher
auszulesen. Umgekehrt sind ebenfalls I/O-Prozesse nötig, um aus dem
Bufferpool verdrängte, geänderte Pages wieder auf den Sekundärspeicher zu
schreiben. Zusätzlich dazu werden I/O-Vorgänge aber auch durch das
Logging verursacht.
IBM Data Studio
Das IBM Data Studio ist ein von IBM entwickeltes und vertriebenes Datenbanktool. Es bietet seinen Anwendern verschiedene Funktionalitäten in den
Bereichen Design, Entwicklung, Administration und Tuning. In seiner Basisversion ist es kostenfrei einsetzbar.
(siehe Abschnitt 3.4.1)
Inline-Datentyp
Als Inline-Datentyp werden Datentypen bezeichnet, die ihre Datensätze
ausschließlich in der Basistabelle ablegen. Damit wird die Größe eines InlineDatentyps durch die maximale Record Size beschränkt. In dieser Arbeit wird
die Bezeichnung zumeist im Zusammenhang mit dem VARCHAR-Datentyp
genannt.
168
JDBC
Java DataBase Connectivity
JDBC stellt eine einheitliche Datenbankschnittstelle – Call Level Interface
(CLI) – auf der Java-Plattform dar. Sie ist speziell auf relationale Datenbankmanagementsysteme ausgerichtet. Um die Verbindung mit einem
solchen System herzustellen, wird ein von diesem abhängiger, spezieller
JDBC-Treiber benötigt.
LOB
Large OBject
LOBs sind, wie der Name schon sagt, große Objekte. Diese werden als
Outline-Datentyp außerhalb der Basistabelle gespeichert. DB2 unterscheidet
speziell zwischen CLOB, DBCLOB und BLOB, wobei ausschließlich der
erstgenannte Datentyp in dieser Arbeit Erwähnung findet.
LOB-Auxiliary-
Eine LOB-Auxiliary-Tabelle ist eine Tabelle, die von DB2 genutzt wird, um
Tabelle
LOB-Daten außerhalb der Basistabelle abzulegen. Dazu muss sie in einem
dedizierten LOB-Tablespace angelegt werden. Weiterhin ist es notwendig,
auf der LOB-Auxiliary-Tabelle einen speziellen Auxiliary-Index zu erstellen,
der den effizienten Zugriff auf deren Inhalte ermöglicht.
LOB-Tablespace
Ein LOB-Tablespace ist ein spezieller Tablespace in DB2. Er wird zur
Verwaltung von LOB-Daten benutzt. Dazu enthält ein LOB-Tablespace
genau eine LOB-Auxiliary-Tabelle mit einem darauf erstellten AuxiliaryIndex. Erst wenn diese Objekte vollständig erstellt sind, können im LOBTablespace Daten abgelegt werden.
Member
DB2-Subsysteme werden innerhalb einer „Data Sharing“-Umgebung auch als
Member bezeichnet. Dabei können ein bis viele Member eine Data Sharing
Group bilden.
nativ
Die native XML-Speicherung entspricht einer „natürlichen“ Ablage. Dabei
werden XML-Dokumente so gespeichert, dass sie direkt aus dem abgelegten
Format ohne zusätzlich notwendiges Parsen verarbeitet werden können. DB2
stellt dafür als ein um XML-Strukturen erweitertes relationales Datenbankmanagementsystem den nativen XML-Datentyp zur Verfügung. Demgegenüber existieren aber auch dedizierte XML-Datenbankmanagementsysteme.
(siehe Abschnitt 3.1.1)
169
nicht-nativ
Im Gegensatz zur nativen XML-Speicherung handelt es sich bei der nichtnativen XML-Ablage um eine „unnatürliche“, abgewandelte Speicherform.
Auf diese Weise abgelegte Dokumente müssen vor ihrer typspezifischen
Verarbeitung stets in das XML-Format geparst werden. In der vorliegenden
Arbeit werden hauptsächlich die Varianten der nicht-nativen XMLSpeicherung als CLOB und VARCHAR betrachtet.
(siehe Abschnitt 3.1.1)
NodeID-Index
Der NodeID-Index ist ein im Rahmen der nativen XML-Speicherung implizit
von DB2 erzeugter Index. Er umfasst die DocID- und die XMLData-Spalte.
Funktional realisiert der NodeID-Index die effiziente Verknüpfung der Tupel
aus der Basistabelle mit den zugehörigen Tupeln der XML-Auxiliary-Tabelle.
OCR
Optical Character Recognition
OCR ist eine Bezeichnung für die automatische Texterkennung innerhalb von
Bildern. In der DATEV wird beispielsweise OCR-Software dazu verwendet,
um eingegangene, gescannte Belege ganz oder teilweise zu digitalisieren.
Outline-Datentyp
Ein Outline-Datentyp ist ein Datentyp, der seine Datensätze außerhalb der
Basistabelle ablegt. Dazu benötigt er zusätzliche Objekte, die entweder
explizit oder implizit erstellt werden müssen. Die LOB-Datentypen und auch
der native XML-Datentyp sind Vertreter der Outline-Datentypen.
Recursive SQL
Unter rekursivem SQL sind SQL-Statements zu verstehen, die über den
UNION-Operator in einem rekursiven Ablauf verschiedene Ergebnismengen
miteinander verknüpfen. Dieser Prozess erfolgt bis zum Eintreten einer
definierten Bedingung, bei der der Vorgang kontrolliert endet.
RELAX NG
Regular Language Description for XML New Generation
RELAX NG ist eine dem XML-Schema ähnliche Schemasprache mit geringerem (Definitions-)Umfang. Sie verfolgt das Ziel, eine kompakte, einfach
verständliche Sprache zur Validierung von XML-Dokumenten zu sein.
Schematron
Schematron ist eine Schemasprache mit regelbasiertem Ansatz. Alternativ zu
dem in dieser Arbeit primär betrachteten XML-Schema können mithilfe von
Schematron ebenfalls XML-Dokumente validiert werden. DB2 bietet dafür
allerdings keine Unterstützung.
170
Stored Procedure
Eine Stored Procedure ist ein datenbankseitig definierbares Anwendungsprogramm, das über ein CALL-Statement aufgerufen werden kann. DB2
unterscheidet dabei zwischen folgenden Prozeduren: externen, SQL (externen) und SQL (nativen) [IBM11a].
TPOX-Benchmark
„Transaction Processing over XML“-Benchmark
Der TPOX-Benchmark ist ein spezieller Benchmark zur PerformanceAnalyse der XML-Verarbeitung in Datenbankmanagementsystemen. Er
besteht aus einem Testdatengenerator (inklusive XML-Schemas), einer
Sammlung von Transaktionen, einem Workload-Treiber und Dokumentationen zu den einzelnen Bestandteilen.
(siehe Abschnitt 4.2)
Transition Variable
Eine Transition Variable ist eine Variable, die den Wert einer Spalte enthält,
für deren zugehörige Zeile ein Trigger aktiv geworden ist. Abhängig vom
Trigger-Typ kann sie den alten Wert vor der dazugehörigen Datenmanipulation oder den neuen geänderten Wert danach annehmen.
Trigger
Bei einem Trigger handelt es sich um ein aktives Objekt nach „ECA (Event
Condition Action)“-Regeln, das bei bestimmten Nutzeraktionen (INSERT,
UPDATE oder DELETE) automatisch eine im Trigger-Body definierte Folge
von Aktionen ausführt. In DB2 ist dabei zusätzlich zwischen den TriggerFormen BEFORE, AFTER und INSTEAD OF zu unterscheiden, die jeweils
auf Tupel- oder Statement-Ebene definierbar sind.
Unicode
Unicode bezeichnet einen internationalen Standard für die Darstellung von
Schriftzeichen. Dieser umfasst unter anderem die in DB2 verfügbare
Zeichenkodierung UTF-8, welche für die native Ablage von XMLDokumenten genutzt wird. Aufgrund des verglichen mit dem EBCDICZeichensatz erweiterten Zeichenumfangs gewinnt der Unicode-Standard in
DB2 zunehmend an Bedeutung.
User-Defined-XML-
Als User-Defined-XML-Indexe sind im Rahmen dieser Arbeit vom Nutzer
Index
explizit anzulegende XML-Indexe bezeichnet. Diese basieren auf einem
definierten XPath-Pfadausdruck und ermöglichen in Kombination mit dem
DocID-Index den effizienten Zugriff auf spezifizierte Teilbäume eines XMLDokuments.
(siehe Abschnitt 8.1.1)
171
VARCHAR
VARying-length CHARacter
Ein VARCHAR ist ein variabel langer Character-String. Da es sich bei ihm
um einen Inline-Datentyp handelt, ist er bezüglich seiner Länge durch die
maximale Record Size limitiert. Diese beträgt in DB2 höchstens 32 Kilobytes. Somit hat ein VARCHAR eine Länge von 1 - 32704 Bytes. Im Rahmen dieser Arbeit wird der VARCHAR-Datentyp besonders im Zusammenhang mit der nicht-nativen XML-Speicherung betrachtet.
Visual Explain
Visual Explain ist ein bis zuletzt eigenständiges Tool zur Zugriffsplananalyse
und -Visualisierung in DB2. Mittlerweile ist Visual Explain in seinem vollen
Funktionsumfang als ein Modul in das Tool IBM Data Studio integriert
worden.
(siehe Abschnitt 3.4.2)
XML
EXtensible Markup Language
XML ist eine erweiterbare Auszeichnungssprache zur Repräsentation von
hierarchischen Daten. Besondere Verbreitung hat es durch seinen Charakter
als universelles Datenaustauschformat erlangt.
(siehe Abschnitt 3.1)
XML-Auxiliary-
Die XML-Auxiliary-Tabelle ist ein implizit erstelltes Verwaltungsobjekt des
Tabelle
nativen XML-Datentyps. Sie dient der Ablage von XML-Dokumenten. In der
XML-Auxiliary-Tabelle befinden sich die Spalten DocID, min_NodeID und
XMLData.
XML-Extender
Der XML-Extender ist eine Erweiterung des DB2, die als ein Zwischenschritt
auf dem Weg der DB2-Entwicklung zur nativen XML-Datenhaltung angesehen werden kann. Er ermöglicht es über zwei verschiedene Ansätze („xml
collection“ und „xml column“), XML-Daten zu verarbeiten. Bei beiden
Varianten handelt es sich um nicht-native XML-Speicherformen.
XML-Parse-Prozess
Der XML-Parse-Prozess dient dazu, ein nicht-natives XML-Dokument in die
native Speicherform zu überführen. Dabei kann abhängig von dem verwendeten XML-Parser beispielsweise auch ein Validierungsvorgang gegen ein
XML-Schema erfolgen.
(siehe Abschnitt 3.1.2)
172
XML-Schema
XML-Schemas dienen der Strukturbeschreibung von XML-Dokumenten. Sie
werden in Form eigener XML-Dokumente definiert. In DB2 sind XMLSchemas im XML Schema Repository abgelegt. Von dort aus können sie zur
Validierung von XML-Dokumenten herangezogen werden.
(siehe Kapitel 7)
XML-Serialisieren
Der Serialisierungsprozess ist das „Gegenstück“ zum XML-Parse-Prozess.
Hier werden die (binär) nativ gespeicherten XML-Dokumente wieder zu
(nicht-nativen) Character-Strings transformiert.
XML-Tablespace
Ein XML-Tablespace ist ein implizit erstellter Tablespace. Er dient der
Verwaltung von nativ gespeicherten XML-Daten. Pro nativer XML-Spalte
wird genau ein XML-Tablespace erzeugt, welcher wiederum genau eine
XML-Auxiliary-Tabelle in sich trägt.
XPath
XML Path Language
XPath ist eine Abfragesprache für XML-Dokumente und dient der Adressierung von hierarchisch repräsentierten Inhalten. Aktuell existieren zwei
Versionen der XPath-Sprachklassifikation: XPath 1.0 [W3C99] und XPath
2.0 [W3C10b].
(siehe Abschnitt 3.1.3)
XQuery
XML Query Language
XQuery ist eine Abfragesprache für XML-Dokumente. Sie bietet gegenüber
der Sprache XPath erweiterte Möglichkeiten, um gezielt auf Dokumentinhalte
zugreifen zu können. In der hier untersuchten Version bietet DB2 keine
Unterstützung für die Abfragesprache XQuery.
XSR
XML Schema Repository
Das XML Schema Repository setzt sich aus verschiedenen Tabellen des
DB2-Katalogs zusammen und dient der datenbankseitigen Speicherung von
XML-Schemas.
173
Abbildungsverzeichnis
Abbildung 1: wohlgeformtes XML-Dokument .......................................................................... 18
Abbildung 2: Beispiel für XML-Parsen und XML-Serialisieren................................................ 21
Abbildung 3: Whitespace in XML-Dokumenten........................................................................ 22
Abbildung 4: Beschreibung wesentlicher XPath-Ausdrücke [W3S11b] .................................... 23
Abbildung 5: Klassifizierung der Elapsed-Zeiten [IBM00]........................................................ 29
Abbildung 6: Beispieldiagramm – Größe und Anzahl................................................................ 38
Abbildung 7: Beispieldokument – Größe und Anzahl................................................................ 40
Abbildung 8: Merkmalsausprägungen des Kriteriums der Strukturiertheit ................................ 42
Abbildung 9: Merkmalsausprägungen des Kriteriums der Zusammensetzung .......................... 44
Abbildung 10: Beziehungen zwischen den Datenbankobjekten................................................. 47
Abbildung 11: „Shared Data“-Architektur [IBM06a]................................................................. 50
Abbildung 12: Beispiel – Anteil des PREPARE-Prozesses........................................................ 53
Abbildung 13: Beispielprozedur – Migration und Parsen........................................................... 58
Abbildung 14: Beispiel-Trigger – XML-Schema-Management ................................................. 58
Abbildung 15: Beispielprozedur – Query Performance.............................................................. 59
Abbildung 16: Beispielausgabe des CA Detectors ..................................................................... 61
Abbildung 17: Beispieldiagramm – Prozentuale Schwankungen ............................................... 63
Abbildung 18: Überblick der betrachteten INSERT-Szenarien.................................................. 64
Abbildung 19: Messreihen zur INSERT-Performance im Migrationsfall .................................. 67
Abbildung 20: Überblicksgrafik – „Einfaches Kopieren“ .......................................................... 68
Abbildung 21: Messergebnis – „Einfaches Kopieren“ – Größe und Anzahl – CPU-Zeit .......... 69
Abbildung 22: Messergebnis – „Einfaches Kopieren“ – Strukturiertheit – CPU-Zeit ............... 71
Abbildung 23: Verteilung über mehrere Tupel [Koc11]............................................................. 72
Abbildung 24: Überblicksgrafik – Konkatenation...................................................................... 73
Abbildung 25: Beispiel für die Bezeichnung einer Merkmalsausprägung ................................. 74
Abbildung 26: Messergebnis – Konkatenation – Größe und Anzahl – CPU-Zeit ...................... 76
Abbildung 27: Überblicksgrafik – Unicode-Konvertierung ....................................................... 78
Abbildung 28: Messergebnis – Unicode-Konvertierung – Größe und Anzahl – CPU-Zeit ....... 79
Abbildung 29: Überblicksgrafik – XML-Parsen der Dokumente............................................... 81
Abbildung 30: Messergebnis – XML-Parsen – Größe und Anzahl – CPU-Zeit......................... 82
Abbildung 31: Messergebnis – XML-Parsen – Strukturiertheit – CPU-Zeit.............................. 85
Abbildung 32: Messergebnis – XML-Parsen – Zusammensetzung – CPU-Zeit ........................ 86
174
Abbildung 33: Gegenüberstellung der Prozessketten zur Migrationsuntersuchung ................... 87
Abbildung 34: Kostenanteil der Konkatenation an einer XML-Migration................................. 89
Abbildung 35: Überblicksgrafik – Neueinfügungen................................................................... 91
Abbildung 36: Anzahl indexierter Knoten je Index.................................................................... 94
Abbildung 37: Beispiel-Statements zur Indexerstellung............................................................. 94
Abbildung 38: Messergebnis – Pflege von User-Defined-XML-Indexen – CPU-Zeit............... 95
Abbildung 39: Beispiel zum Vergleich von UPDATE und „in-document“-UPDATE .............. 97
Abbildung 40: Beispiel für ein XML-Schema .......................................................................... 102
Abbildung 41: Vordefinierte Datentypen bei dem XML-Schema-Konzept [W3C04c] ........... 104
Abbildung 42: Anwendungsbeispiel für das „unique“-Element ............................................... 106
Abbildung 43: Anwendungsbeispiel für das „key“-Element .................................................... 106
Abbildung 44: Anwendungsbeispiel für das „keyref“-Element................................................ 107
Abbildung 45: Verknüpfung von XML-Dokument und XML-Schema ................................... 109
Abbildung 46: Transparente Schemavalidierung...................................................................... 110
Abbildung 47: Alternativer Umgang mit ungültigen XML-Dokumenten ................................ 111
Abbildung 48: Auskunft über Gültigkeit von XML-Dokumente ............................................. 112
Abbildung 49: Vorgehensweise bei Schemaevolution ............................................................. 115
Abbildung 50: Syntaxdiagramm der Funktion DSN_XMLVALIDATE [IBM11a]................. 116
Abbildung 51: Vorgehensweise zur automatisierten Schemavalidierung in DB2.................... 119
Abbildung 52: Beispielinhalt einer Tabelle mit Zusatzspalte zur Gültigkeitsauskunft............. 121
Abbildung 53: Vergleich der CPU-Zeiten mit „nicht-validierendem“ INSERT ...................... 124
Abbildung 54: DTD basierte Eindeutigkeitsdefinition – gültiges Dokument........................... 127
Abbildung 55: DTD basierte Eindeutigkeitsdefinition – ungültiges Dokument....................... 127
Abbildung 56: Beispiel-Statement für die Indexerstellung....................................................... 132
Abbildung 57: Beispiel für einen Zugriffspfad mit verwendetem User-Defined-XML-Index. 138
Abbildung 58: Messergebnis – Komplettzugriff – Größe und Anzahl – CPU-Zeit.................. 143
Abbildung 59: Messergebnis – Komplettzugriff – Strukturiertheit – CPU-Zeit....................... 144
Abbildung 60: Messergebnis – Komplettzugriff – Zusammensetzung – CPU-Zeit ................. 145
Abbildung 61: Ausschnitt aus dem „Musterdokument“ ........................................................... 146
Abbildung 62: Messergebnis – Indexunterstützter Zugriff – Größe und Anzahl – CPU-Zeit .. 147
Abbildung 63: Beispiel eines SELECT-Statements für selektiven Zugriff .............................. 149
Abbildung 64: Messergebnis – Selektiver Zugriff – Größe und Anzahl – CPU-Zeit............... 151
Abbildung 65: SELECT-Statement für das Szenario Komplexe Prädikate.............................. 153
Abbildung 66: Messergebnis – Komplexe Prädikate – Größe und Anzahl – CPU-Zeit........... 155
Abbildung 67: Zusammenfassung der Messergebnisse – Migration und Parsen...................... 159
175
Abbildung 68: Zusammenfassung der Messergebnisse – XML-Schema-Management ........... 160
Abbildung 69: Zusammenfassung der Messergebnisse – Query Performance......................... 161
Abbildung 70: Design-Empfehlungen zur XML-Speicherform ............................................... 164
176
Literaturverzeichnis
[Aue10]
J. Auer. „Design-Entscheidungen zwischen Element und Attribut bei einer eigenen document type definition“, 05.02.2010.
http://www.sql-und-xml.de/xml-lernen/xml-element-attribut-eigene-dtd-design.html
[Bos06]
P. Bossman. „A Guide to using Visual Explain V8“, 13.12.2006.
http://www.bwdb2ug.org/PDF/Visual Explain Guide.pdf
[CAT11]
CA Technologies. „CA Detector® for DB2 for z/OS“, 2011.
http://www.ca.com/~/media/Files/ProductBriefs/1724_detector_cs342_1110.pdf
[Cla01]
J. Clark. „TREX – Tree Regular Expressions for XML“, Sprachspezifikation,
2001.
[Com07]
Computerwoche. „Das Herz der Weltwirtschaft“, Online-Artikel, 30.08.2007.
http://www.computerwoche.de/heftarchiv/2007/35/1220473/
[DAT10]
DATEV. „Mehr Rechenleistung für Cloud-Dienste“, 22.12.2010.
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=109742
[DAT11a]
DATEV. „Sicherung der Wohlfahrt“, Interview, 2011.
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=120356
[DAT11b]
DATEV. „… was Sie über DATEV wissen sollten“, 2011.
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=2155
[DAT11c]
DATEV. „Neu bei DATEV?“, 2011.
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=81681
[DAT11d]
DATEV. „Vorstandsvorsitzender – Professor Dieter Kempf “, 2011.
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=97649
[DAT11e]
DATEV. „DATEV“, Online-Präsenz, 2011.
http://www.datev.de
[DAT11f]
DATEV. „Outsourcing an DATEV“, 2011.
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=104852
177
[DAT11g]
DATEV. „DATEVasp“, Online-Präsenz, 2011.
http://www.datev.de/portal/SelectPage.do?pid=dpi&cid=122774
[DAT11h]
DATEV. „Chronologischer Überblick 1966 bis 1975“, 2011.
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=2185
[Ecl11]
Eclipse Foundation. „Eclipse“, Projekt-Homepage, 2011.
http://www.eclipse.org
[Fav07]
W. Favero. „DB2 9 for z/OS Universal Table Spaces (UTS)“, 15.05.2007. BlogArtikel.
http://it.toolbox.com/blogs/db2zos/db2-9-for-zos-universal-table-spaces-uts-16273
[Hee02]
H. Heeskens. „Was ist XML?“, 04.02.2002.
http://mata.gia.rwth-aachen.de/Vortraege/Hanno_Heeskens/XML/script/node4.html
[Her09]
M. Herschel. „Datenbanksysteme II – Architektur und Implementierung von
Datenbanksystemen – Kapitel 4: Baum-basierte Indizes“, Vorlesungsskript,
Willhelm-Schickard-Institut für Informatik, Eberhard Karls Universität Tübingen, 2009.
http://db.inf.uni-tuebingen.de/files/teaching/ws0910/dbs2/04_treeindex_r1.pdf
[HR01]
T. Härder, E. Rahm. „Datenbanksysteme: Konzepte und Techniken der Implementierung“, Springer Verlag, 2. Auflage, 2001.
[HS04]
M. Hertel, Prof. A. Schätter. „Kleines XML Schema 1x1“, 2004.
http://www.mathertel.de/2004/schemaeinmaleins.aspx
[IBM00]
IBM Corporation. „Tivoli – Performance Reporter for OS/390 System Performance Feature Guide“, 08.2000.
http://publib.boulder.ibm.com/tividd/td/perfrpt/SH19-6818-05/en_US/PDF/SH19-681805.pdf
[IBM04a]
IBM Corporation. „IBM Redbook – DB2 UDB for z/OS Version 8: Everything
You Ever Wanted to Know, ... and More“, 05.2004.
http://www.redbooks.ibm.com/redbooks/pdfs/sg246079.pdf
178
[IBM04b]
IBM Corporation. „DB2 for OS/390 and z/OS library – XML Extender Administration and Programming“, 10.2004.
http://publibfp.dhe.ibm.com/epubs/pdf/dxxxa811.pdf
[IBM06a]
IBM Corporation. „IBM Redbook – DB2 for z/OS: Data Sharing in a Nutshell“,
10.2006.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf
[IBM06b]
IBM Corporation. „IBM Redbook – LOBs with DB2 for z/OS: Stronger and
Faster“, 11.2006.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf
[IBM07]
IBM Corporation. „IBM Redbook – DB2 9 for z/OS Performance Topics“,
09.2007.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247473.pdf
[IBM08a]
IBM Corporation. „DB2 Version 9.1 for z/OS – Utility Guide and Reference“,
12.2008.
http://www.sk-consulting.de/db2manuals/DB2%20V9%20Utility_Guide_dsnugk13.pdf
[IBM08b]
IBM Corporation. „IBM Redbook – DB2 9 for z/OS Stored Procedures: Through
the CALL and Beyond“, 03.2008.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247604.pdf
[IBM08c]
IBM Corporation. „DB2 Version 9.1 for z/OS – Codes“, 12.2008.
http://www.sk-consulting.de/db2manuals/DB2%20V9%20Codes_dsnc1k13.pdf
[IBM09a]
IBM Corporation. „IBM Redpaper – DB2 9 for z/OS: Buffer Pool Monitoring
and Tuning“, 25.10.2009.
http://www.redbooks.ibm.com/redpapers/pdfs/redp4604.pdf
[IBM09b]
IBM Corporation. „The bind process“, 06.2009.
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.db
2.doc.comref%2Fchhpt3.htm
[IBM09c]
IBM Corporation. „IBM Redbook – XML Processing on z/OS“, 12.2009.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247810.pdf
179
[IBM09d]
IBM Corporation. „IBM Redbook – DB2 9 for z/OS: Packages Revisited“,
03.2009.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247688.pdf
[IBM10a]
IBM Corporation. „Extensible Dynamic Binary XML, Client/Server Binary XML
Format (XDBX)“, Spezifikation, 14.07.2010.
http://www-01.ibm.com/support/docview.wss?uid=swg27019354&aid=1
[IBM10b]
IBM Corporation. „z/OS V1R12.0 information center“, 2010.
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp
[IBM10c]
IBM Corporation. „DB2 9 for z/OS pureXML Performance and Best Practices“,
06.2010.
https://www.ibm.com/developerworks/wikis/download/attachments/97321405/DB2_9_z
OS_pureXML_Performance.pps
[IBM10d]
IBM Corporation. „IBM InfoSphere Optim Query Workload Tuner“, 10.2010.
ftp://public.dhe.ibm.com/common/ssi/ecm/en/ims14099usen/IMS14099USEN.PDF
[IBM10e]
IBM Corporation. „DB2 Version 9.1 for z/OS – XML Guide“, 12.2010.
http://publibfp.dhe.ibm.com/epubs/pdf/dsnxgk16.pdf
[IBM11a]
IBM Corporation. „DB2 Version 9.1 for z/OS – SQL Reference“, 03.2011.
http://publib.boulder.ibm.com/epubs/pdf/dsnsqk1a.pdf
[IBM11b]
IBM Corporation. „Parallel Sysplex“, 2011.
http://www-03.ibm.com/systems/z/advantages/pso/sysover.html#Parallel_Sysplex
[IBM11c]
IBM Corporation. „DB2 Version 9.1 for z/OS – Application Programming and
SQL Guide“, 10.2011.
http://publib.boulder.ibm.com/epubs/pdf/dsnapk18.pdf
[IBM11d]
IBM Corporation. „DB2 Version 9.1 for z/OS – Administration Guide“, 12.2011.
http://publib.boulder.ibm.com/epubs/pdf/dsnagk1b.pdf
[IBM11e]
IBM Corporation. „IBM“, Online-Präsenz, 2011.
http://www.ibm.com/us/en/
[IBM11f]
IBM Corporation. „IBM InfoSphere Optim Query Tuner“, 01.2011.
http://public.dhe.ibm.com/common/ssi/ecm/en/ims14103usen/IMS14103USEN.PDF
180
[IBM11g]
IBM Corporation. „DB2 Version 9.1 for z/OS – Command Reference“, 12.2011.
http://publib.boulder.ibm.com/epubs/pdf/dsncrk17.pdf
[IBM11h]
IBM Corporation. „IBM zEnterprise System“, 2011.
http://www-03.ibm.com/systems/de/z/hardware/zenterprise/z196.html
[IBM11i]
IBM Corporation. „Control Center overview“, 2011.
http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.cc.doc/db2_ud
b/intro.htm
[IBM11j]
IBM Corporation. „Optimization Service Center for DB2 for z/OS“, 20.07.2011.
https://www-304.ibm.com/support/docview.wss?uid=swg27017059
[IBM11k]
IBM Corporation. „Visual Explain for DB2 for z/OS“, 04.10.2011.
https://www-304.ibm.com/support/docview.wss?uid=swg27011680
[IBM11l]
IBM Corporation. „Data Studio V3.1 features: by data server and component“,
14.12.2011.
http://www-01.ibm.com/support/docview.wss?uid=swg27022147
[IBM11m]
IBM Corporation. „IBM Data Studio“, Produkt-Homepage, 2011.
http://www-01.ibm.com/software/data/optim/data-studio/
[IBM11n]
IBM Corporation. „IBM Data Studio – Features and benefits“, 2011.
http://www-01.ibm.com/software/data/optim/data-studio/features.html
[IBM11o]
IBM Corporation. „DB2 for z/OS“, Produkt-Homepage, 2011.
http://www-01.ibm.com/software/data/db2/zos/
[IBM11p]
IBM Corporation. „DB2 for Linux, UNIX and Windows“, Produkt-Homepage,
2011.
http://www-01.ibm.com/software/data/db2/linux-unix-windows/
[IBM11q]
IBM Corporation. „IBM System z – Operating System – z/OS“, ProduktHomepage, 2011.
http://www-03.ibm.com/systems/z/os/zos/
[IBM11r]
IBM Corporation. „DB2 Server for VSE & VM“, Produkt-Homepage, 2011.
http://www-01.ibm.com/software/data/db2/vse-vm/
181
[IBM11s]
IBM Corporation. „DB2 10 for z/OS – SQL Reference“, 10.2011.
http://publib.boulder.ibm.com/epubs/pdf/dsnsqm04.pdf
[IBM11t]
IBM Corporation. „DB2 10 for z/OS – Maintaining statistics in the catalog“,
12.2011.
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.db
2z10.doc.perf%2Fsrc%2Ftpc%2Fdb2z_maintaincatalogstatistics.htm
[IBM11u]
IBM Corporation. „DB2 Version 9.1 for z/OS – Performance Monitoring and
Tuning Guide“, 03.2011.
http://publib.boulder.ibm.com/epubs/pdf/dsnpfk1a.pdf
[IBM11v]
IBM Corporation. „DB2 10 for z/OS – What’s New?“, 12.2011.
http://publib.boulder.ibm.com/epubs/pdf/dsnwnm04.pdf
[IBM11w]
IBM Corporation. „DB2 pureXML – Intelligent XML database management
ALT“, Produkt-Homepage, 2011.
http://www-01.ibm.com/software/data/db2/xml/
[IBM11x]
IBM Corporation. „DB2“, Produkt-Homepage, 2011.
http://www-01.ibm.com/software/data/db2/
[IBM11y]
IBM Corporation. „IBM zEnterprise System“, 08.2011.
http://public.dhe.ibm.com/common/ssi/ecm/en/zsd03020usen/ZSD03020USEN.PDF
[IBM11z]
IBM Corporation. „IBM Redbook – DB2 10 for z/OS Performance Topics“,
06.2011.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247942.pdf
[IBM12a]
IBM Corporation. „Getting started with IBM Data Studio for DB2“, 01.2012.
http://public.dhe.ibm.com/software/dw/db2/express-c/wiki/Getting_Started_with_IBM_
Data_Studio_v31.pdf
[IBM12b]
IBM Corporation. „z/OS – XML System Services User's Guide and Reference “,
01.2012.
http://www-03.ibm.com/systems/resources/gxlza151.pdf
[IBM78]
IBM Corporation. „OS/VS2 MVS Overview“, Produkt-Homepage, 06.1978.
http://www.prycroft6.com.au/misc/download/GC28-0984-0_MVSoverview_
Jun78OCR2009.pdf
182
[IES98]
Internet Engineering Steering Group (IESG). „Uniform Resource Identifiers
(URI): Generic Syntax“, Memo, 08.1998.
http://www.ietf.org/rfc/rfc2396.txt
[ISO06]
International Organization for Standardization (ISO). „Information technology –
Document Schema Definition Languages (DSDL) –Part 3: Rule-based validation
– Schematron“, 01.06.2006. International Standard. ISO/IEC 19757-3 :2006(E).
[Joc06]
B. Jockman. „Don’t Break the Link: Avoid Four Costly Pitfalls in Linking and
Reuse“, 2006. White Paper.
http://xml.coverpages.org/InnodataJockmanLinkManagement2006.pdf
[Koc11]
C. Koch. „XML-Speicherstrukturen in DB2 for z/OS Version 9.1 und Überführungskonzepte für nicht-native XML-Speicherformen“, Studienarbeit, Fakultät für
Mathematik und Informatik, Friedrich-Schiller-Universität Jena, 08.2011.
[KST02]
W. Kazakos, A. Schmidt, P. Tomczyk. „Datenbanken und XML: Konzepte,
Anwendungen, Systeme“, Springer Verlag, 1. Auflage, 26.03.2002.
[Ley11]
M. Ley. „System R“, 2011.
http://www.informatik.uni-trier.de/~ley/db/systems/r.html
[Loe09]
H. Loeser. „XML Database Benchmarks, TPoX, and DB2 pureXML“, BlogArtikel, 10.02.2009.
http://blog.4loeser.net/2009/02/xml-database-benchmarks-tpox-and-db2.html
[Mak00]
M. Makoto. „Regular language description for xml (relax): Relax core.“, JIS
Technical Report, 2000.
[Mic11]
Microsoft Corporation. „Microsoft SQL Server“, Produkt-Homepage, 2011.
http://www.microsoft.com/sqlserver/en/us/default.aspx
[Mil11]
R. Miller. „DB2 History“, 25.04.2011.
http://www.dbisoftware.com/db2nightshow/20110425-Z01-roger-miller.pdf
183
[Mül08]
T. Müller. „Verfahren zur Verarbeitung von XML-Werten in SQL-Anfrageergebnissen“, Dissertation, Fakultät für Mathematik und Informatik, FriedrichSchiller-Universität Jena, 02.04.2008.
http://deposit.ddb.de/cgi-bin/dokserv?idn=990512835&dok_var=d1&dok_ext=pdf&
filename=990512835.pdf
[NGXS11]
M. Nicola, A. Gonzalez, K. Xie, B. Schiefer. „An XML Database Benchmark:
"Transaction Processing over XML (TPoX)"“, Spezifikation, 07.2011.
http://tpox.svn.sourceforge.net/viewvc/tpox/TPoX/documentation/TPoX_BenchmarkPro
posal_v2.1.pdf
[Nic10]
M. Nicola. „New XML Features in DB2 10 for z/OS !“, Blog-Artikel, 18.11.2010.
http://nativexmldatabase.com/2010/11/18/new-xml-features-in-db2-10-for-zos/
[NK09]
M. Nicola, P. Kumar-Chatterjee. „DB2 pureXML Cookbook“, IBM Press, 1.
Auflage, 08.2009.
[Ora11a]
Oracle Corporation. „Designing an XML Data Structure“, Tutorial, 2011.
http://docs.oracle.com/javaee/1.4/tutorial/doc/IntroXML4.html
[Ora11b]
Oracle Corporation. „Oracle Database“, Produkt-Homepage, 2011.
http://www.oracle.com/de/products/database/index.html
[Pag04a]
Pagina. „Grenzen der DTD-Technologie“, 02.2004.
http://www.pagina-online.de/xml-hintergruende/pagina-daskompendium/themenkomplex-ii-xml/xml-schema-als-dtd-alternative/grenzen-der-dtdtechnologie/
[Pag04b]
Pagina. „Uniqueness und Keys“, 02.2004.
http://www.pagina-online.de/xml-hintergruende/pagina-daskompendium/themenkomplex-ii-xml/xml-schema-als-dtd-alternative/uniqueness-undkeys/
[Pag07]
Pagina. „Schematron – Der neue Freund des Lektorats“, 05.2007.
http://www.pagina-online.de/xml-hintergruende/pagina-daskompendium/themenkomplex-ii-xml/schematron-der-neue-freund-des-lektorats/
[Päß07]
M. Päßler. „Datenbanken und XML – Passt das?“, 04.07.2007.
http://inka.htw-berlin.de/datenverwaltung/docs/Paessler.pdf
184
[Pic09]
H.-J. Picht. „Wie ein Pinguin und ein Dinosaurier helfen können, Platz, Wartungskosten und Strom zu sparen“, 06.10.2009.
http://www-05.ibm.com/at/symposium/pdf/11_Wie_ein_Pinguin_und_ein_Dinosaurier.
pdf
[Rod08]
V. Rodrigues. „Static SQL vs Dynamic SQL“, 14.01.2008. Blog-Artikel.
http://www.vitorrodrigues.com/blog/2008/01/14/static-sql-vs-dynamic-sql/
[Smi07]
B. F. Smith. „IBM DB2 RUNSTATS Utility and Real-time Statistics“, 10.2007.
ftp://ftp.boulder.ibm.com/software/systemz/pdf/Dec_4_Telecon_RUNSTATS_Utility_an
d_Real-time_Statistics.pdf
[Stö01]
U. Störl. „Backup und Recovery in Datenbanksystemen. Verfahren, Klassifikation, Implementierung und Bewertung“, Teubner Verlag, 1. Auflage, 11.04.2001.
[Van03]
E. Van der Vlist. „RELAX NG“, O'Reilly Media, 1. Auflage, 07.2003.
[Von05]
H. Vonhoegen. „Einstieg in XML“, Galileo Computing, 3.Auflage, 03.2005.
[W3C02]
World Wide Web Consortium (W3C). „XML Pointer Language (XPointer)“,
W3C Working Draft, 16.08.2002.
http://www.w3.org/TR/xptr/
[W3C04a]
World Wide Web Consortium (W3C). „XML Schema Part 0: Primer Second
Edition“, W3C Recommendation, 28.10.2004.
http://www.w3.org/TR/xmlschema-0/
[W3C04b]
World Wide Web Consortium (W3C). „XML Schema Part 1: Structures Second
Edition“, W3C Recommendation, 28.10.2004.
http://www.w3.org/TR/xmlschema-1/
[W3C04c]
World Wide Web Consortium (W3C). „XML Schema Part 2: Datatypes Second
Edition“, W3C Recommendation, 28.10.2004.
http://www.w3.org/TR/xmlschema-2/
[W3C06a]
World Wide Web Consortium (W3C). „XML Inclusions (XInclude) Version 1.0
(Second Edition)“, W3C Recommendation, 15.11.2006.
http://www.w3.org/TR/xinclude/
185
[W3C06b]
World Wide Web Consortium (W3C). „Extensible Markup Language (XML) 1.1
(Second Edition)“, W3C Recommendation, 16.08.2006.
http://www.w3.org/TR/2006/REC-xml11-20060816/
[W3C08]
World Wide Web Consortium (W3C). „Extensible Markup Language (XML) 1.0
(Fifth Edition)“, W3C Recommendation, 26.11.2008.
http://www.w3.org/TR/2008/REC-xml-20081126/
[W3C10]
World Wide Web Consortium (W3C). „XML Linking Language (XLink) Version
1.1“, W3C Recommendation, 06.05.2010.
http://www.w3.org/TR/xlink11/
[W3C10b]
World Wide Web Consortium (W3C). „XML Path Language (XPath) 2.0 (Second Edition)“, W3C Recommendation, 14.12.2010.
http://www.w3.org/TR/xpath20/
[W3C10c]
World Wide Web Consortium (W3C). „XQuery 1.0: An XML Query Language
(Second Edition)“, W3C Recommendation, 14.12.2010.
http://www.w3.org/TR/xquery/
[W3C11]
World Wide Web Consortium (W3C). „W3C“, Online-Präsenz, 2011.
http://www.w3.org
[W3C99]
World Wide Web Consortium (W3C). „XML Path Language (XPath) Version
1.0“, W3C Recommendation, 16.11.1999.
http://www.w3.org/TR/xpath/
[W3S11a]
W3Schools. „XSD Simple Elements“, 2011.
http://www.w3schools.com/schema/schema_simple.asp
[W3S11b]
W3Schools. „XPath Syntax“, 2011.
http://www.w3schools.com/xpath/xpath_syntax.asp
[WK03]
H. Wittenbrink, W. Köhler. „XML“, Teia Lehrbuch Verlag, 1. Auflage, 2003.
[Zha08]
G. Zhang. „DB2 pureXML® Podcast Series © IBM 2008: Part 2. Getting Started
with pureXML in DB2 9 for z/OS“, 2008.
http://www.ibm.com/developerworks/wikis/download/attachments/97321405/pureXML_
Podcast2_Getting_Started.pdf
186
[Zha09]
G. Zhang. „DB2 9 for z/OS pureXML® FAQs“, 05.01.2009.
http://www.ibm.com/developerworks/wikis/download/attachments/97321405/DB2_9_for
_zOS_pureXML_FAQs_V08.pdf
Sämtliche Verweise auf Webseiten und online verfügbare Dokumentationen beziehen sich auf
den Stand vom 17.01.2012 und wurden zu diesem Zeitpunkt letztmalig geprüft.
187
Anhang
A.1
„Einfaches Kopieren“ (Abschnitt 6.1.1)
Messprozeduren
Exemplarisch am Beispiel
Messreihe: Größe und Anzahl (CLOB)
Merkmalsausprägung: „10K x 10.000“
CREATE PROCEDURE T24431A.SP_CLOB_KOPIEREN_10K()
LANGUAGE SQL
BEGIN
FOR V AS
C CURSOR FOR
SELECT NNXML_DOC AS CUR_DOC
FROM T24431A.TCLOB_10K
DO
INSERT INTO T24431A.TCLOB_EBCDIC_10K(NNXML_DOC)
VALUES(CUR_DOC);
END FOR;
COMMIT;
END
Messergebnisse
Messreihe: Größe und Anzahl (CLOB und VARCHAR)
Merkmalsausprägung
CLOB
Elapsed
200B x 500.000
VARCHAR
CPU
Elapsed
CPU
254,40
33,65
56,81
6,09
1K x 100.000
55,42
5,72
18,14
1,43
10K x 10.000
9,41
0,64
9,50
0,56
100K x 1.000
5,28
0,20
-
-
1M x 100
5,01
0,14
-
-
10M x 10
6,59
0,13
-
-
188
Messreihe: Strukturiertheit (CLOB)
Merkmalsausprägung
CLOB
Elapsed
CPU
E (tief)
5,88
0,20
E (flach)
5,34
0,18
E (balanciert)
5,99
0,20
T
5,61
0,19
A
5,46
0,18
A, T
5,19
0,21
E, T (tief)
5,19
0,19
E, T (flach)
4,89
0,18
E, T (balanciert)
4,89
0,19
A, E (tief)
6,32
0,21
A, E (flach)
5,59
0,22
A, E (balanciert)
5,87
0,21
A, E, T (tief)
5,44
0,18
A, E, T (flach)
5,23
0,21
A, E, T (balanciert)
5,33
0,21
189
Messreihe: Zusammensetzung (CLOB)
Merkmalsausprägung
CLOB
Elapsed
CPU
1K x 100.000
57,35
5,83
10K x 10.000
9,73
0,60
100K x 1.000
5,19
0,21
1M x 100
5,03
0,13
10M x 10
6,23
0,12
190
A.2
Konkatenation (Abschnitt 6.1.2)
Messprozeduren
Stored Procedure – exemplarisch am Beispiel
Messreihe: Größe und Anzahl (CLOB)
Merkmalsausprägung: „10 x 1K x 10.000“
CREATE PROCEDURE T24431A.SP_CLOB_CONCAT_SP_10K()
LANGUAGE SQL
BEGIN
DECLARE CUR_DOC CLOB(2G) CCSID EBCDIC;
SET CUR_DOC = '';
FOR V AS
C CURSOR FOR
SELECT NNXML_DOC FROM T24431A.TCLOB_1K
FETCH FIRST 10 ROWS ONLY
DO
SET CUR_DOC = CONCAT(CUR_DOC, NNXML_DOC);
END FOR;
INSERT INTO T24431A.TCLOB_EBCDIC_10K(NNXML_DOC)
VALUES (CUR_DOC);
COMMIT;
END
191
Recursive SQL – exemplarisch am Beispiel
Messreihe: Größe und Anzahl (CLOB)
Merkmalsausprägung: „10 x 1K x 10.000“
CREATE PROCEDURE T24431A.SP_CLOB_CONCAT_RSQL_10K()
LANGUAGE SQL
BEGIN
FOR V AS
C CURSOR FOR
WITH RPL (LEVEL, CUR_DOC) AS (
SELECT 1 AS LEVEL, NNXML_DOC AS CUR_DOC
FROM T24431A.TCLOB_1K WHERE ID = 1
UNION ALL
SELECT PARENT.LEVEL + 1, CONCAT(
PARENT.CUR_DOC,
CHILD.NNXML_DOC) AS CUR_DOC
FROM RPL AS PARENT,
T24431A.TCLOB_1K AS CHILD
WHERE PARENT.LEVEL < 10 AND
CHILD.ID = 1 + PARENT.LEVEL
) SELECT CUR_DOC FROM RPL ORDER BY LEVEL DESC
FETCH FIRST 1 ROW ONLY
DO
INSERT INTO T24431A.TCLOB_EBCDIC_10K(NNXML_DOC)
VALUES (CUR_DOC);
END FOR;
COMMIT;
END
Messergebnisse
Messreihe: Größe und Anzahl (CLOB und VARCHAR)
Merkmalsausprägung
CLOB
(Stored Procedure)
CLOB
(Recursive SQL)
VARCHAR
(Stored Procedure)
Elapsed
CPU
Elapsed
Elapsed
CPU
CPU
10 x 1K x 10.000
2413,22
1,93
36505,59
9128,15
2247,34
1,78
100 x 1K x 1.000
436,60
8,42
32484,58
9083,87
484,99
7,90
1.000 x 1K x 100
288,20
92,48
-
-
272,83
95,08
10.000 x 1K x 10
2248,57
1860,64
-
-
2231,74
1949,15
192
Messreihe: Zusammensetzung (CLOB)
Merkmalsausprägung
CLOB
Elapsed
CPU
10 x 1K x 10.000
2153,39
1,84
100 x 1K x 1.000
492,20
9,16
1.000 x 1K x 100
259,11
88,23
10.000 x 1K x 10
2192,93
1912,23
193
A.3
Unicode-Konvertierung (Abschnitt 6.1.3)
Messprozeduren
Exemplarisch am Beispiel
Messreihe: Größe und Anzahl (CLOB)
Merkmalsausprägung: „10K x 10.000“
CREATE PROCEDURE T24431A.SP_CLOB_UNICODE_10K()
LANGUAGE SQL
BEGIN
FOR V AS
C CURSOR FOR
SELECT NNXML_DOC AS CUR_DOC
FROM T24431A.TCLOB_10K
DO
INSERT INTO T24431A.TCLOB_UNICODE_10K(NNXML_DOC)
VALUES(CUR_DOC);
END FOR;
COMMIT;
END
Messergebnisse
Messreihe: Größe und Anzahl (CLOB und VARCHAR)
Merkmalsausprägung
CLOB
Elapsed
200B x 500.000
VARCHAR
CPU
Elapsed
CPU
302,73
37,63
74,45
6,43
1K x 100.000
71,26
7,46
25,71
1,79
10K x 10.000
12,97
1,13
10,95
0,91
100K x 1.000
6,47
0,43
-
-
1M x 100
6,29
0,46
-
-
10M x 10
6,71
0,41
-
-
194
Messreihe: Strukturiertheit (CLOB)
Merkmalsausprägung
CLOB
Elapsed
CPU
E (tief)
6,69
0,42
E (flach)
5,14
0,41
E (balanciert)
6,67
0,41
T
6,38
0,40
A
5,21
0,41
A, T
5,29
0,40
E, T (tief)
5,44
0,39
E, T (flach)
5,15
0,40
E, T (balanciert)
4,99
0,41
A, E (tief)
6,26
0,41
A, E (flach)
6,46
0,39
A, E (balanciert)
5,87
0,39
A, E, T (tief)
6,37
0,41
A, E, T (flach)
5,06
0,42
A, E, T (balanciert)
5,17
0,42
195
Messreihe: Zusammensetzung (CLOB)
Merkmalsausprägung
CLOB
Elapsed
CPU
1K x 100.000
67,26
7,59
10K x 10.000
12,79
1,06
100K x 1.000
6,54
0,41
1M x 100
6,19
0,44
10M x 10
6,33
0,40
196
A.4
XML-Parsen der Dokumente (Abschnitt 6.1.4)
Messprozeduren
Exemplarisch am Beispiel
Messreihe: Größe und Anzahl (CLOB)
Merkmalsausprägung: „10K x 10.000“
CREATE PROCEDURE T24431A.SP_XMLPARSE_10K()
LANGUAGE SQL
BEGIN
FOR V AS
C CURSOR FOR
SELECT NNXML_DOC AS CUR_DOC
FROM T24431A.TCLOB_10K
DO
INSERT INTO T24431A.TXML_XMLPARSE_10K(XML_DOC)
VALUES(XMLPARSE(
DOCUMENT CUR_DOC STRIP WHITESPACE));
END FOR;
COMMIT;
END
Messergebnisse
Messreihe: Größe und Anzahl (CLOB und VARCHAR)
Merkmalsausprägung
CLOB
Elapsed
200B x 500.000
VARCHAR
CPU
Elapsed
CPU
130,11
39,10
98,00
19,02
1K x 100.000
42,39
10,70
40,63
7,94
10K x 10.000
24,81
5,57
24,79
5,24
100K x 1.000
20,54
4,92
-
-
1M x 100
22,82
5,05
-
-
10M x 10
23,70
4,80
-
-
197
Messreihe: Strukturiertheit (CLOB)
Merkmalsausprägung
CLOB
Elapsed
E (tief)
CPU
24,27
6,89
174,85
88,72
10,63
2,75
T
6,92
0,90
A
279,43
128,80
A, T
90,53
33,92
E, T (tief)
16,70
4,34
E, T (flach)
60,47
23,63
E, T (balanciert)
10,26
2,04
A, E (tief)
16,64
4,48
A, E (flach)
63,33
23,94
A, E (balanciert)
10,37
2,30
A, E, T (tief)
17,34
3,52
A, E, T (flach)
33,99
11,53
A, E, T (balanciert)
12,26
2,09
E (flach)
E (balanciert)
198
Messreihe: Zusammensetzung (CLOB)
Merkmalsausprägung
CLOB
Elapsed
CPU
1K x 100.000
43,47
10,44
10K x 10.000
18,43
4,78
100K x 1.000
14,00
3,86
1M x 100
15,01
3,81
10M x 10
17,42
3,51
199
A.5
Pflege von User-Defined-XML-Indexen (Abschnitt 6.3)
Messprozeduren
Analog zu A.4 XML-Parsen der Dokumente (Abschnitt 6.1.4)
Messergebnisse
Messreihe: Sofortige Indexpflege und nachträgliche Indexerstellung
Merkmalsausprägung
INSERT
(bei 1 Index)
INSERT
(bei 2 Indexen)
INSERT
(bei 3 Indexen)
nachträgliche
Erstellung aller
3 Indexe
(exklusive Kosten
für den INSERT)
Elapsed
CPU
Elapsed
CPU
Elapsed
CPU
Elapsed
CPU
144,98
43,09
165,63
44,59
185,88
46,83
6,76
1,02
1K x 100.000
47,70
16,00
57,21
19,59
60,75
22,40
34,78
3,38
10K x 10.000
35,36
13,84
81,09
24,89
87,26
37,53
133,39
7,73
100K x 1.000
37,77
13,15
89,513
22,81
108,21
35,21
132,15
8,32
1M x 100
40,34
13,83
95,92
24,69
115,93
35,96
153,84
8,71
10M x 10
45,71
13,17
93,11
24,27
113,63
33,78
152,39
9,86
200B x 500.000
200
A.6
Performance der Schemavalidierung (Abschnitt 7.3.2)
Messprozeduren
Automatische Schemavalidierung
CREATE PROCEDURE T24431A.SP_SCHEMA_VALIDATION_AUTO(
IN TABLE_SCHEMA VARCHAR(1000),
IN TABLE_NAME VARCHAR(1000),
IN XML_COLUMN VARCHAR(1000),
IN DOCID BIGINT,
IN SCHEMA_NAME VARCHAR(1000))
LANGUAGE SQL
BEGIN
DECLARE CUR_DOC CLOB(2G);
DECLARE CUR_SCHEMA_OBJECTID BIGINT;
DECLARE SCHEMA_FULL_QUALIFIER VARCHAR(1000);
DECLARE INVALID_DOCUMENT CONDITION FOR '2201R';
DECLARE INVALID_STMT_SQL VARCHAR(10000);
DECLARE VALID_STMT_SQL VARCHAR(10000);
DECLARE SELECT_STMT_SQL VARCHAR(10000);
DECLARE INVALID_STMT STATEMENT;
DECLARE VALID_STMT STATEMENT;
DECLARE SELECT_STMT STATEMENT;
DECLARE CUR1 CURSOR FOR SELECT_STMT;
DECLARE CUR2 CURSOR FOR
SELECT XSROBJECTID FROM SYSIBM.XSROBJECTS
WHERE XSROBJECTNAME = SCHEMA_NAME AND
XSROBJECTSCHEMA = 'SYSXSR';
DECLARE CONTINUE HANDLER FOR INVALID_DOCUMENT
BEGIN
EXECUTE INVALID_STMT USING CUR_SCHEMA_OBJECTID;
END;
SET SELECT_STMT_SQL = 'SELECT XMLSERIALIZE(' ||
XML_COLUMN || ' AS CLOB(2G)) AS DOC FROM ' ||
TABLE_SCHEMA || '.' || TABLE_NAME ||
' WHERE DB2_GENERATED_DOCID_FOR_XML = ?' ||
' FOR UPDATE OF XML_SCHEMA_INFO';
PREPARE SELECT_STMT FROM SELECT_STMT_SQL;
SET VALID_STMT_SQL = 'UPDATE ' || TABLE_SCHEMA ||
'.' || TABLE_NAME ||
' SET XML_SCHEMA_INFO = ? WHERE CURRENT OF CUR1';
PREPARE VALID_STMT FROM VALID_STMT_SQL;
201
SET INVALID_STMT_SQL = 'UPDATE ' || TABLE_SCHEMA ||
'.' || TABLE_NAME ||
' SET XML_SCHEMA_INFO = (-1) * ?' ||
' WHERE CURRENT OF CUR1';
PREPARE INVALID_STMT FROM INVALID_STMT_SQL;
SET SCHEMA_FULL_QUALIFIER = 'SYSXSR' || '.' || SCHEMA_NAME;
-- SCHEMA_OBJECTID ERMITTELN
OPEN CUR2;
FETCH CUR2 INTO CUR_SCHEMA_OBJECTID;
CLOSE CUR2;
OPEN CUR1 USING DOCID;
FETCH CUR1 INTO CUR_DOC;
-- OPTIMISTISCHE ANNAHME: DOKUMENT IST „GÜLTIG“
-- FALLS NICHT,
-- DANN KORRIGIERT CONDITION ZU „FEHLERHAFT“
EXECUTE VALID_STMT USING CUR_SCHEMA_OBJECTID;
SET CUR_DOC = XMLSERIALIZE(
XMLPARSE(DOCUMENT SYSFUN.DSN_XMLVALIDATE(
CUR_DOC, SCHEMA_FULL_QUALIFIER))
AS CLOB(2G));
CLOSE CUR1;
COMMIT;
END
Nachträgliche Schemavalidierung
CREATE PROCEDURE T24431A.SP_SCHEMA_VALIDATION_AFTER(
IN TABLE_SCHEMA VARCHAR(1000),
IN TABLE_NAME VARCHAR(1000),
IN XML_COLUMN VARCHAR(1000),
IN SCHEMA_NAME VARCHAR(1000))
LANGUAGE SQL
BEGIN
DECLARE SQLCODE INTEGER DEFAULT 0;
DECLARE CUR_DOC CLOB(2G);
DECLARE CUR_SCHEMA_OBJECTID BIGINT;
DECLARE SCHEMA_FULL_QUALIFIER VARCHAR(1000);
DECLARE INVALID_DOCUMENT CONDITION FOR '2201R';
DECLARE INVALID_STMT_SQL VARCHAR(10000);
DECLARE VALID_STMT_SQL VARCHAR(10000);
DECLARE SELECT_STMT_SQL VARCHAR(10000);
DECLARE INVALID_STMT STATEMENT;
DECLARE VALID_STMT STATEMENT;
DECLARE SELECT_STMT STATEMENT;
DECLARE CUR1 CURSOR FOR SELECT_STMT;
202
DECLARE CUR2 CURSOR FOR
SELECT XSROBJECTID FROM SYSIBM.XSROBJECTS
WHERE XSROBJECTNAME = SCHEMA_NAME AND
XSROBJECTSCHEMA = 'SYSXSR';
DECLARE CONTINUE HANDLER FOR INVALID_DOCUMENT
BEGIN
EXECUTE INVALID_STMT USING CUR_SCHEMA_OBJECTID;
END;
SET SELECT_STMT_SQL =
'SELECT XMLSERIALIZE(' || XML_COLUMN ||
' AS CLOB(2G)) AS DOC FROM ' || TABLE_SCHEMA ||
'.' || TABLE_NAME || ' FOR UPDATE OF ' ||
'XML_SCHEMA_INFO';
PREPARE SELECT_STMT FROM SELECT_STMT_SQL;
SET VALID_STMT_SQL = 'UPDATE ' || TABLE_SCHEMA ||
'.' || TABLE_NAME ||
' SET XML_SCHEMA_INFO = ? WHERE CURRENT OF CUR1';
PREPARE VALID_STMT FROM VALID_STMT_SQL;
SET INVALID_STMT_SQL = 'UPDATE ' || TABLE_SCHEMA ||
'.' || TABLE_NAME ||
' SET XML_SCHEMA_INFO = (-1) * ?' ||
' WHERE CURRENT OF CUR1';
PREPARE INVALID_STMT FROM INVALID_STMT_SQL;
SET SCHEMA_FULL_QUALIFIER = 'SYSXSR' || '.' || SCHEMA_NAME;
-- SCHEMA_OBJECTID ERMITTELN
OPEN CUR2;
FETCH CUR2 INTO CUR_SCHEMA_OBJECTID;
CLOSE CUR2;
OPEN CUR1;
FETCH CUR1 INTO CUR_DOC;
WHILE (SQLCODE=0) DO
-- OPTIMISTISCHE ANNAHME: DOKUMENT IST „GÜLTIG“
-- FALLS NICHT,
-- DANN KORRIGIERT CONDITION ZU „FEHLERHAFT“
EXECUTE VALID_STMT USING CUR_SCHEMA_OBJECTID;
SET CUR_DOC = XMLSERIALIZE(
XMLPARSE(DOCUMENT SYSFUN.DSN_XMLVALIDATE(
CUR_DOC, SCHEMA_FULL_QUALIFIER))
AS CLOB(2G));
FETCH CUR1 INTO CUR_DOC;
END WHILE;
CLOSE CUR1;
COMMIT;
END
203
Messergebnisse
Messreihe: Automatische und nachträgliche Schemavalidierung
Merkmalsausprägung
automatische Schemavalidierung
(inklusive Kosten für den INSERT)
Elapsed
CPU
nachträgliche Schemavalidierung
(exklusive Kosten für den INSERT)
Elapsed
CPU
1K x 100.000
205,17
82,55
101,96
36,05
10K x 10.000
81,78
36,38
60,36
17,13
100K x 1.000
56,93
22,47
62,19
14,28
1M x 100
53,71
18,60
55,94
13,16
204
A.7
Komplettzugriff (Abschnitt 8.2.1)
Messprozeduren
Exemplarisch am Beispiel
Messreihe: Größe und Anzahl (XML)
Merkmalsausprägung: „10K x 10.000“
CREATE PROCEDURE T24431A.SP_XML_KOMPLETT_10K()
LANGUAGE SQL
BEGIN
DECLARE SQLCODE INTEGER DEFAULT 0;
DECLARE TMP CLOB(2G) CCSID UNICODE;
DECLARE C1 CURSOR FOR SELECT XML_DOC FROM T24431A.TXML_10K;
OPEN C1;
WHILE (SQLCODE=0) DO
FETCH C1 INTO TMP;
END WHILE;
CLOSE C1;
END
205
Zugriffspläne
Alle Messreihen
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML, XML (mit 3 Indexen))
Merkmalsausprägung
CLOB
Elapsed
200B x 500.000
VARCHAR
CPU
Elapsed
XML
(mit 3 Indexen)
XML
CPU
Elapsed
CPU
Elapsed
CPU
174,07
22,98
4,79
1,66
11,27
5,89
10,99
5,77
1K x 100.000
57,69
4,92
2,44
0,37
10,44
4,11
10,89
3,98
10K x 10.000
6,89
0,52
2,59
0,11
10,25
4,61
10,10
4,57
100K x 1.000
3,03
0,11
-
-
9,36
4,56
10,44
4,52
1M x 100
2,71
0,07
-
-
10,61
4,22
9,59
4,31
10M x 10
2,32
0,08
-
-
11,40
3,03
10,96
3,05
206
Messreihe: Strukturiertheit (CLOB und XML)
Merkmalsausprägung
CLOB
Elapsed
VARCHAR
CPU
Elapsed
CPU
E (tief)
8,76
1,31
8,76
1,31
E (flach)
3,55
1,41
3,55
1,41
E (balanciert)
6,52
1,44
6,52
1,44
T
2,32
0,39
2,32
0,39
A
60,83
25,29
60,83
25,29
A, T
13,30
6,65
13,30
6,65
E, T (tief)
3,33
0,70
3,33
0,70
E, T (flach)
3,89
0,66
3,89
0,66
E, T (balanciert)
7,05
0,75
7,05
0,75
11,24
2,45
11,24
2,45
A, E (flach)
5,93
1,87
5,93
1,87
A, E (balanciert)
9,20
2,14
9,20
2,14
A, E, T (tief)
5,51
1,59
5,51
1,59
A, E, T (flach)
4,37
1,34
4,37
1,34
A, E, T (balanciert)
7,32
1,43
7,32
1,43
A, E (tief)
207
Messreihe: Zusammensetzung (XML)
XML
Merkmalsausprägung
Elapsed
CPU
1K x 100.000
11,52
4,37
10K x 10.000
8,14
3,47
100K x 1.000
8,44
3,11
1M x 100
7,97
2,75
10M x 10
7,17
1,98
208
A.8
Indexunterstützter Zugriff (Abschnitt 8.2.2)
Messprozeduren
Exemplarisch am Beispiel
Messreihe: Größe und Anzahl (XML)
Merkmalsausprägung: „10K x 10.000“
CREATE PROCEDURE T24431A.SP_XML_INDEX_10K()
LANGUAGE SQL
BEGIN
DECLARE TMP INTEGER;
DECLARE C1 CURSOR FOR
SELECT COUNT(*) FROM T24431A.TXML_10K
WHERE XMLEXISTS('$x/seite/textblock
[@id="muster_textblock1"]'
PASSING XML_DOC AS "x");
OPEN C1;
FETCH C1 INTO TMP;
CLOSE C1;
END
209
Zugriffspläne
Messreihe: Größe und Anzahl (XML (mit 3 Indexen))
Alle anderen Messreihen
210
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Merkmalsausprägung
CLOB
Elapsed
VARCHAR
CPU
Elapsed
CPU
XML
(mit 3 Indexen)
XML
Elapsed
CPU
Elapsed
CPU
1K x 100.000
57,69
4,92
2,44
0,37
3,45
0,45
0,20
0,00
10K x 10.000
6,89
0,52
2,59
0,11
3,82
0,29
0,21
0,00
100K x 1.000
3,03
0,11
-
-
3,52
0,19
0,19
0,00
1M x 100
2,71
0,07
-
-
3,42
0,21
0,23
0,00
10M x 10
2,33
0,08
-
-
3,96
0,36
0,21
0,01
Messreihe: Zusammensetzung (XML)
XML
Merkmalsausprägung
Elapsed
CPU
1K x 100.000
3,81
0,45
10K x 10.000
3,68
0,28
100K x 1.000
4,09
0,24
1M x 100
3,59
0,24
10M x 10
3,71
0,21
211
A.9
Selektiver Zugriff (Abschnitt 8.2.3)
Messprozeduren
Exemplarisch am Beispiel
Messreihe: Größe und Anzahl (XML)
Merkmalsausprägung: „10K x 10.000“
CREATE PROCEDURE T24431A.SP_XML_SELEKTIV_10K()
LANGUAGE SQL
BEGIN
DECLARE SQLCODE INTEGER DEFAULT 0;
DECLARE TMP CLOB(2G) CCSID UNICODE;
DECLARE C1 CURSOR FOR
SELECT XMLQUERY('$x/seite/textblock
[@id="muster_textblock1"]'
PASSING XML_DOC AS "x")
FROM T24431A.TXML_10K
WHERE XMLEXISTS('$x/seite/textblock
[@id="muster_textblock1"]'
PASSING XML_DOC AS "x");
OPEN C1;
WHILE (SQLCODE=0) DO
FETCH C1 INTO TMP;
END WHILE;
CLOSE C1;
END
212
Zugriffspläne
Messreihe: Größe und Anzahl (XML (mit 3 Indexen))
Alle anderen Messreihen
213
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Merkmalsausprägung
CLOB
Elapsed
VARCHAR
CPU
Elapsed
CPU
XML
(mit 3 Indexen)
XML
Elapsed
CPU
Elapsed
CPU
1K x 100.000
57,69
4,92
2,44
0,37
2,92
0,34
0,18
0,00
10K x 10.000
6,89
0,52
2,59
0,11
2,73
0,30
0,19
0,00
100K x 1.000
3,03
0,11
-
-
3,08
0,29
0,21
0,01
1M x 100
2,71
0,07
-
-
3,44
0,33
0,25
0,01
10M x 10
2,33
0,08
-
-
4,11
0,46
0,63
0,08
Messreihe: Zusammensetzung (XML)
XML
Merkmalsausprägung
Elapsed
CPU
1K x 100.000
3,09
0,34
10K x 10.000
2,50
0,20
100K x 1.000
2,34
0,15
1M x 100
2,79
0,14
10M x 10
2,47
0,14
214
A.10 Komplexe Prädikate (Abschnitt 8.2.4)
Messprozeduren
Exemplarisch am Beispiel
Messreihe: Größe und Anzahl (XML)
Merkmalsausprägung: „10K x 10.000“
CREATE PROCEDURE T24431A.SP_XML_COMPLEX_10K()
LANGUAGE SQL
BEGIN
DECLARE TMP INTEGER;
DECLARE C1 CURSOR FOR
SELECT COUNT(*) FROM T24431A.TXML_10K
WHERE XMLEXISTS('$x/seite/textblock
[(@pox=20 and @posy=10) or
(@posx=10 and @posy=20)]'
PASSING XML_DOC AS "x");
OPEN C1;
FETCH C1 INTO TMP;
CLOSE C1;
END
215
Zugriffspläne
Messreihe: Größe und Anzahl (XML (mit 3 Indexen)) –
nur Merkmalsausprägung „1K x 100.000“
Alle anderen Messreihen
216
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
Merkmalsausprägung
CLOB
Elapsed
VARCHAR
CPU
Elapsed
CPU
XML
(mit 3 Indexen)
XML
Elapsed
CPU
Elapsed
CPU
1K x 100.000
57,69
4,92
2,44
0,37
11,29
5,90
0,22
0,01
10K x 10.000
6,89
0,52
2,59
0,11
34,75
13,97
39,30
14,12
100K x 1.000
3,03
0,11
-
-
36,46
15,10
40,44
14,88
1M x 100
2,71
0,07
-
-
34,71
14,75
43,57
15,09
10M x 10
2,33
0,08
-
-
37,14
15,93
44,11
16,52
Messreihe: Zusammensetzung (XML)
XML
Merkmalsausprägung
Elapsed
CPU
1K x 100.000
17,58
5,90
10K x 10.000
15,42
5,16
100K x 1.000
15,98
5,47
1M x 100
15,71
5,57
10M x 10
12,70
4,77
217
Selbstständigkeitserklärung
Ich erkläre, dass ich die vorliegende Arbeit selbstständig und nur unter Verwendung der
angegebenen Quellen und Hilfsmittel angefertigt habe.
Jena, 31.01.2012, Christoph Koch