Upload
nguyenkhanh
View
217
Download
0
Embed Size (px)
Citation preview
Der Datentyp XML in DB2 for z/OS aus Performance-Perspektive
- Diplomarbeit -
zur Erlangung des akademischen Grades Diplom-Informatiker
eingereicht von
Christoph Koch
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 verant-
wortlichen Kollegen konnte mit Hilfe dieser Daten ein breites Spektrum an Performance-
Messreihen 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 pureXML-
Implementierung 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 vor-
liegende 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 XML-
Speicherung 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
8
1 Einleitung
Das aktuelle Kapitel führt in die Thematik der vorliegenden, in der DATEV erstellten Diplom-
arbeit 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 W3C-
Consortium [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 XML-
Extender 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.
1 Einleitung
9
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 Migrations-
mö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-Speicher-
formen 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 aus-
gewä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
1 Einleitung
10
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 XML-
Schema-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 Themenschwer-
punkte aufzuzeigen. Dazu sei eine Anwendung angenommen, die zum aktuellen Zeitpunkt
XML-Daten nicht-nativ in Form von CLOB-Dokumenten speichert und gezielt anwendungs-
seitig auswertet. Mehrere solcher Anwendungen existieren derart in der DATEV.
Aufgrund der durch die Anwendung datenbankseitig verwendeten nicht-nativen XML-Speicher-
form 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 Daten-
zugriff sind nur anwendungsseitig realisierbar und finden dementsprechend auch anwendungs-
seitig 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 pureXML-
Technologie denkbar. Zum einen wäre es mit dieser möglich, einzelne Dokumentteile gezielt
1 Einleitung
11
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 Daten-
manipulationen 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 Nach-
betrachtungen 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 Unter-
suchung 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.
1 Einleitung
12
Die Ausführungen in diesem Teil sind eng an die Darstellungen aus der dieser Arbeit vorange-
henden Studienarbeit [Koc11] angelehnt.
Grundlagen (Kapitel 3)
In Kapitel 3 werden grundlegende Begrifflichkeiten und Sachverhalte wie die Auszeich-
nungssprache 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 Performance-
Analysen, die dem Detailgrad der in dieser Arbeit durchgeführten, an die DATEV-Spezifika
angelehnten Betrachtungen zu den Bereichen Migration und Parsen, XML-Schema-
Management und Query Performance entsprechen. Dennoch gibt es zahlreiche allgemein ausge-
legte 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über-
legungen 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 Messdaten-
erhebung 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 wesent-
lichen, 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.
1 Einleitung
13
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 W3C-
Consortium 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 Vor-
zügen erfolgt hier auch die Thematisierung nachteiliger Aspekte der nativen XML-Speicherung,
sodass infolgedessen konkrete Defizite gemeinsam mit Anregungen zur Optimierung beschrie-
ben 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 umfang-
reich 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 vor-
liegenden Arbeit.
2 Die DATEV eG
14
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 erfolg-
reiche 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
2 Die DATEV eG
15
Mitgliedern noch weitere Leistungen, wie Möglichkeiten des IT-Outsourcing [DAT11f]
(beispielsweise in Form von DATEVasp [DAT11g]) oder die Nutzung des hauseigenen Druck-
und 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 Aus-
richtung 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 Betrach-
tung. 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 XML-
Speicherung 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
2 Die DATEV eG
16
(Performance-)Vorteile der nativen XML-Speicherung in den unterschiedlichen Themen-
schwerpunkten
� 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 Über-
blick 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 nicht-
nativen Strukturen effizienter ist.
3 Grundlagen
17
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 Versio-
nen 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 unter-
scheiden. 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
3 Grundlagen
18
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 unter-
scheiden [Von05]. Während jedes XML-Dokument, das den in der XML-Spezifikation fest-
gelegten 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 Wohl-
geformtheit.
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äts-
steigernd 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 Ein-
schrä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 XML-
Schema-Konzepts. [Mül08]
<seite id="seite1"><textblock id="textblock1">
Ich bin ein Text!</textblock>
</seite>
Element (öffnender Tag)
Element (schließender Tag)
Attribut
Elementinhalt
Abbildung 1: wohlgeformtes XML-Dokument
4 Eine ausführliche Abhandlung der Syntaxregeln findet sich in [W3C06b] beziehungsweise in [W3C08].
3 Grundlagen
19
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 aus-
schließlich der Begriff „nicht-nativ“ Verwendung.
Auf nicht-native Weise gespeicherte XML-Dokumente benötigen für die Zwecke ihrer XML-
spezifischen Verarbeitung ein Mapping von dem vorliegenden (relationalen) Speichermodell
hin zu dem XML-Datenmodell [Päß07]. Dazu existiert zum einen die Möglichkeit der XML-
Dekomposition5 [NK09]. Mit deren Hilfe ist es möglich, XML-Dokumente zur nicht-
nativen XML-Speicherung datenbankseitig in relationale Strukturen zu zerlegen. Da diese
Funktionalität aber in der DATEV derzeit keine Anwendung findet (und zudem Performance-
Nachteile 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.
3 Grundlagen
20
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 not-
wendiges XML-Parsen der nicht-nativ gespeicherten Dokumente. Auf diesen XML-Parse-
Prozess 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 nicht-
nativen Ablage. Detaillierte Betrachtungen zu den Strukturen der dabei miteinander ver-
glichenen nativen und nicht-nativen Formen der XML-Speicherung als XML-, CLOB-
oder 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.
3 Grundlagen
21
XML-Parsen
XML-Serialisieren
<seite id="seite1"><textblock id="textblock1">Ich bin ein Text!</textblock></seite>
<seite id="seite1"><textblock id="textblock1">
Ich bin ein Text!</textblock>
</seite>
nativesXML-Dokument
nicht-nativesXML-Dokument
Abbildung 2: Beispiel für XML-Parsen und XML-Serial isieren
Die Prozesse XML-Parsen und XML-Serialisieren – fortan auch verkürzt als Parsen und Seriali-
sieren 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 XML-
Dokumente 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 Serialisierungspro-
zess erforderlich. Beide Prozesse finden aber auch an anderer Stelle, wie beispielsweise inner-
halb 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 trans-
parent 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 Anwen-
der durch die entsprechenden Funktionsaufrufe veranlasst wird. Durch diese Sachverhalte wird
3 Grundlagen
22
eine umfassende Transparenz der nativen XML-Speicherung erreicht, was vor allem in Migrati-
onsszenarien – 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 An-
wender. 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 ver-
wendet.
<seite id="seite1"><textblock id="textblock1">
Ich bin ein Text!</textblock>
</seite>
<seite id="seite1"><textblock id="textblock1">Ich bin ein Text!</textblock></seite>
XML-Dokument mit Whitespace
XML-Dokument ohne Whitespace
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, seriali-
sierte 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.
3 Grundlagen
23
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.
Selektiert einen Attributknoten@
Selektiert den Elternknoten des aktuellen Knotens..
Selektiert den aktuellen Knoten.
Selektiert alle Knoten des Dokuments, die der weiteren Selektionentsprechen, egal wo sie sich befinden
//
Selektiert von dem Wurzelknoten ausgehend/
BeschreibungAchse
Selektiert einen Attributknoten@
Selektiert den Elternknoten des aktuellen Knotens..
Selektiert den aktuellen Knoten.
Selektiert alle Knoten des Dokuments, die der weiteren Selektionentsprechen, egal wo sie sich befinden
//
Selektiert von dem Wurzelknoten ausgehend/
BeschreibungAchse
Abbildung 4: Beschreibung wesentlicher XPath-Ausdrücke [W3S11b]
3 Grundlagen
24
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.
3 Grundlagen
25
� 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 durch-
gefü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 Datenbank-
managementsystem, das für verschiedene Plattformen verfügbar ist. Die verbreitetsten Produkt-
linien 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/OS-
Betriebssystem [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 Main-
frame 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]
3 Grundlagen
26
und um neue Features, wie beispielsweise die native Speicherung und Verarbeitung von XML-
Daten, 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 DB2-
Produktlinien 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.
3 Grundlagen
27
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 BUFFERPOOL = BP4
LOCKSIZE = ANY LOCKMAX = SYSTEM
CODED CHARACTER SET IDENTIFIER (CCSID) =
EBCDIC beziehungsweise UNICODE (nur Abschnitt 6.1.3)
� LOB-Tablespaces
DATA SET SIZE (DSSIZE) = 4G STORAGEGROUP = STASPD01
BUFFERPOOL = BP16K1 LOCKSIZE = ANY LOCKMAX = SYSTEM
� XML-Tablespaces
STORAGEGROUP = STASPD01 BUFFERPOOL = BP4
LOCKSIZE = ANY 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 ALLOCATED = 6857
BUFFERS ACTIVE = 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 ALLOCATED = 1000
BUFFERS ACTIVE = 1000 PAGE STEALING METHOD = LRU
VP SEQUENTIAL STEAL THRESHOLD (VPSEQT) = 80
DEFERRED WRITE THRESHOLD (DWQT) = 50
VERTICAL DEFERRED WRITE THRESHOLD (VDWQT) = 10, 0
3 Grundlagen
28
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 DB2-
interne 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.
3 Grundlagen
29
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 Performance-
Engpä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 Daten-
erhebung 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.
3 Grundlagen
30
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] empfoh-
len. 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, inner-
halb 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 betrach-
tet, 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.
3 Grundlagen
31
� 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 Zugriffsplan-
informationen 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 einge-
gangen 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
3 Grundlagen
32
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 zusam-
mengefasst 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 Anwen-
dungen/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.
4 Aktueller Kenntnisstand zu Performance-Kennzahlen
33
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]
4 Aktueller Kenntnisstand zu Performance-Kennzahlen
34
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 Mess-
ergebnisse 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 Unter-
suchungen 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 Performance-
Analyse der XML-Verarbeitung in Datenbankmanagementsystemen genutzt werden kann. Dabei
orientiert sich der TPOX-Benchmark an einem einfachen Modell einer typischen Finanzan-
wendung und legt seinen Schwerpunkt auf die Aspekte XQuery, SQL/XML, XML-Speicherung,
4 Aktueller Kenntnisstand zu Performance-Kennzahlen
35
XML-Indexierung, XML-Schema-Unterstützung, XML UPDATEs, Logging und Nebenläufig-
keit. 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.
5 Vorbetrachtungen zur Messdatenerhebung
36
5 Vorbetrachtungen zur Messdatenerhebung
Die vorliegende Diplomarbeit betrachtet drei Themenschwerpunkte aus Performance-
Perspektive:
� 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 Trans-
aktionslä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 Ver-
fahrensweise 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.
5 Vorbetrachtungen zur Messdatenerhebung
37
5.1 Generelle Vergleichskriterien
XML-Dokumente können sich in ihrem Aufbau voneinander in vielfältiger Weise unter-
scheiden. 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 Ver-
gleichskriterien. 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 Kilo-
byte. „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
5 Vorbetrachtungen zur Messdatenerhebung
38
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 Merkmals-
ausprä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.
0
20
40
60
80
100
120
140
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Sekunden
Größe und Anzahl
ELAPSED
CPU
Abbildung 6: Beispieldiagramm – Größe und Anzahl
5 Vorbetrachtungen zur Messdatenerhebung
39
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 Bedeu-
tung 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 zusam-
mensetzen. 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 Nachvollzieh-
barkeit und Verständlichkeit der in dieser Arbeit vorgestellten Messreihen.
11 nach erfolgter Prüfung des Datenschutzes und Bewilligung durch die verantwortlichen Anwendungs-
entwickler
5 Vorbetrachtungen zur Messdatenerhebung
40
<?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 Über-
legungen erfolgt die Generierung der Testdaten für die Messreihen zu dem Kriterium der Struk-
turiertheit der XML-Dokumente. Im Detail ergeben sich dabei 15 verschiedene Testdaten-
bestä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 XML-
Verarbeitung 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
5 Vorbetrachtungen zur Messdatenerhebung
41
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 Dokument-
größe von 100K bietet den Vorteil, dass sie zum einen eine aussagekräftige Basis für die Struk-
turiertheit 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 Diagram-
men 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.
5 Vorbetrachtungen zur Messdatenerhebung
42
Dokumentwurzel Elementknoten (E) Attributknoten (A) Textknoten (T)
-
1 Dokumentwurzel
1 Textknoten
T
balanciertflachtiefStruktur
Grafik
1 Dokumentwurzel
4.096 Elementknoten
E (balanciert)
1 Dokumentwurzel
4.096 Elementknoten
E (tief)
1 Dokumentwurzel
4.096 ElementknotenKnoten
E (flach)Titel
-
1 Dokumentwurzel
1 Textknoten
T
balanciertflachtiefStruktur
Grafik
1 Dokumentwurzel
4.096 Elementknoten
E (balanciert)
1 Dokumentwurzel
4.096 Elementknoten
E (tief)
1 Dokumentwurzel
4.096 ElementknotenKnoten
E (flach)Titel
flach
1 Dokumentwurzel
2.048 Elementknoten
2.048 Textknoten
E, T (flach)
tief--Struktur
Grafik
1 Dokumentwurzel
2.048 Elementknoten
2.048 Textknoten
E, T (tief)
1 Dokumentwurzel
4.096 Attributknoten
A
1 Dokumentwurzel
2.048 Attributknoten
1 Textknoten
Knoten
A, TTitel
flach
1 Dokumentwurzel
2.048 Elementknoten
2.048 Textknoten
E, T (flach)
tief--Struktur
Grafik
1 Dokumentwurzel
2.048 Elementknoten
2.048 Textknoten
E, T (tief)
1 Dokumentwurzel
4.096 Attributknoten
A
1 Dokumentwurzel
2.048 Attributknoten
1 Textknoten
Knoten
A, TTitel
-
1 Dokumentwurzel
2.048 Attributknoten
2.048 Elementknoten
A, E (balanciert)
flachtiefbalanciertStruktur
Grafik
1 Dokumentwurzel
2.048 Attributknoten
2.048 Elementknoten
A, E (flach)
1 Dokumentwurzel
2.048 Elementknoten
2.048 Textknoten
E, T (balanciert)
1 Dokumentwurzel
2.048 Attributknoten
2.048 Elementknoten
Knoten
A, E (tief)Titel
-
1 Dokumentwurzel
2.048 Attributknoten
2.048 Elementknoten
A, E (balanciert)
flachtiefbalanciertStruktur
Grafik
1 Dokumentwurzel
2.048 Attributknoten
2.048 Elementknoten
A, E (flach)
1 Dokumentwurzel
2.048 Elementknoten
2.048 Textknoten
E, T (balanciert)
1 Dokumentwurzel
2.048 Attributknoten
2.048 Elementknoten
Knoten
A, E (tief)Titel
balanciertflachtiefStruktur
Grafik
1 Dokumentwurzel
1.366 Attributknoten
1.366 Elementknoten
1.366 Textknoten
A, E, T (balanciert)
1 Dokumentwurzel
1.366 Attributknoten
1.366 Elementknoten
1.366 Textknoten
A, E, T (tief)
1 Dokumentwurzel
1.366 Attributknoten
1.366 Elementknoten
1.366 Textknoten
Knoten
A, E, T (flach)Titel
balanciertflachtiefStruktur
Grafik
1 Dokumentwurzel
1.366 Attributknoten
1.366 Elementknoten
1.366 Textknoten
A, E, T (balanciert)
1 Dokumentwurzel
1.366 Attributknoten
1.366 Elementknoten
1.366 Textknoten
A, E, T (tief)
1 Dokumentwurzel
1.366 Attributknoten
1.366 Elementknoten
1.366 Textknoten
Knoten
A, E, T (flach)Titel
Abbildung 8: Merkmalsausprägungen des Kriteriums der Strukturiertheit
5 Vorbetrachtungen zur Messdatenerhebung
43
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 Attribut-
knoten. Weiterhin ist zu erwähnen, dass die Daten der als „tief“ bezeichneten Merkmals-
ausprä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 unvoll-
stä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 XML-
Speicherung an realitätsnahen und XML-spezifischen Abfragen aufzuzeigen. Die für das Krite-
rium 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 mithil-
fe der in den Messreihen verwendeten einheitlichen XPath-Pfadausdrücken nicht möglich wäre.
5 Vorbetrachtungen zur Messdatenerhebung
44
Im Rahmen der Messreihe „Komplettzugriff“ aus Kapitel 8 findet das Kriterium der
Strukturiertheit dagegen Anwendung. Dementsprechend werden auch für den XML-
Serialisierungsprozess von der Strukturiertheit abhängige Kennzahlen ermittelt. Nähere Details
dazu finden sich in Abschnitt 8.2.1.
5.1.3 Zusammensetzung
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 Test-
datenbestand 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 eben-
falls 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 Merkmals-
ausprägung von 10M (siehe Abbildung 9).
10M1M100K10K1K 10M1M100K10K1K
1K
10 x 1K 100 x 1K 1.000 x 1K 10.000 x 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
…
Abbildung 9: Merkmalsausprägungen des Kriteriums der Zusammensetzung
5 Vorbetrachtungen zur Messdatenerhebung
45
In weiterer Analogie zum Kriterium der Größe und Anzahl wurde auch das Gesamtdaten-
volumen 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 Gesamt-
datenvolumen 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 ver-
wendeten 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).
5 Vorbetrachtungen zur Messdatenerhebung
46
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 Randbe-
dingungen, 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 Bufferpool-
Management 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
5 Vorbetrachtungen zur Messdatenerhebung
47
veranschaulicht die beschriebenen, zueinander in Beziehung stehenden Datenbankobjekte. Der
Übersichtlichkeit halber ist dabei auf die Illustration der Datasets verzichtet worden. [IBM09a]
Tablespaces Indexspaces
Pagesets
Datenbank
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.
5 Vorbetrachtungen zur Messdatenerhebung
48
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 Ent-
wicklungsumgebung 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 LOB-
Tablespace 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 verwen-
deten 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
5 Vorbetrachtungen zur Messdatenerhebung
49
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 pureScale-
Technologie 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 Daten-
durchsatzraten. 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]
5 Vorbetrachtungen zur Messdatenerhebung
50
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 Cache-
strukturen und ermöglicht auf diese Weise eine effiziente Datenverarbeitung im Rechner-
Cluster. 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 durch-
gefü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 Performance-
Messungen 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
5 Vorbetrachtungen zur Messdatenerhebung
51
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].
5 Vorbetrachtungen zur Messdatenerhebung
52
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üh-
rendes 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 Bind-
Prozess 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 Zusammen-
hang sind die in Abbildung 12 aufgeführten Kosten der einzelnen Prozesse, anhand deren sich
5 Vorbetrachtungen zur Messdatenerhebung
53
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 Prozedur-
ablauf äußerst geringfügig und daher vernachlässigbar.
1
1
1
100.000
100.000
SQL_COUNT
0,0000020,000002CLOSE
0,0000540,000116OPEN
0,0010160,001322PREPARE
4,62918062,131371FETCH
10,70084242,388315EXECUTE
CPU_TIME(in Sekunden)
ELAPSED_TIME(in Sekunden)
SQL_CALL
1
1
1
100.000
100.000
SQL_COUNT
0,0000020,000002CLOSE
0,0000540,000116OPEN
0,0010160,001322PREPARE
4,62918062,131371FETCH
10,70084242,388315EXECUTE
CPU_TIME(in Sekunden)
ELAPSED_TIME(in Sekunden)
SQL_CALL
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 Datenbankmanagement-
systemen, über Transaktionen gesteuert. Dabei handelt es sich um Folgen von zusammen-
gehö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 Autocommit-
Modus 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 be-
troffenen 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
5 Vorbetrachtungen zur Messdatenerhebung
54
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 Trans-
aktion per COMMIT-Befehl abgeschlossen wird.
� Force oder No Force [Stö01]
Mithilfe dieser Strategiealternative lässt sich der Umgang mit im Bufferpool be-
findlichen 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ührungs-
zeitpunkten 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ück-
nehmen 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]
5 Vorbetrachtungen zur Messdatenerhebung
55
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 Transaktions-
struktur 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 ver-
zichtet. 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 Lauf-
zeiten 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.
5 Vorbetrachtungen zur Messdatenerhebung
56
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.
5.3 Verfahrensweise zur Messdatenerhebung
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 Mess-
prozeduren 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.
5 Vorbetrachtungen zur Messdatenerhebung
57
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 Themen-
schwerpunkten 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
5 Vorbetrachtungen zur Messdatenerhebung
58
CREATE PROCEDURE T24431A.SP_XMLPARSE_100K()LANGUAGE SQLBEGIN
FOR V ASC CURSOR FOR
SELECT NNXML_DOC AS CUR_DOC FROM T24431A.TCLOB_100KDO
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 Auto-
matismus 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 Vorver-
arbeitung in einem BEFORE-Trigger automatisieren [NK09]. Für DB2 for z/OS besteht ledig-
lich die Möglichkeit eines „nachträglichen“, per AFTER-Trigger initiierten Validierungsauto-
matismus. 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_1KAFTER INSERT ON T24431A.TXML_1KREFERENCING NEW AS NEW_ROWFOR EACH ROW MODE DB2SQLBEGIN 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
5 Vorbetrachtungen zur Messdatenerhebung
59
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-Defined-
XML-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 SQLBEGIN
DECLARE TMP INTEGER;
DECLARE C1 CURSOR FORSELECT 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.
5 Vorbetrachtungen zur Messdatenerhebung
60
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 SELECT-
Statements Aufschluss.
5 Vorbetrachtungen zur Messdatenerhebung
61
SQL_CALL INDB2_TIME INDB2_CPU -------- ------------ ------------FETCH 00:00.201656 00:00.004255OPEN 00:00.000063 00:00.000062CLOSE 00:00.000008 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 ver-
meiden. 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 ab-
laufende Applikationstests also auch nächtliche Batchabläufe. Auf dem in der Entwicklungs-
umgebung 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.
5 Vorbetrachtungen zur Messdatenerhebung
62
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 Entwicklungs-
system 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 unterschied-
lichen 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)
5 Vorbetrachtungen zur Messdatenerhebung
63
-30
-20
-10
0
10
20
30
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Dif
fere
nz
(in
Pro
zen
t)
Größe und Anzahl
ELAPSED
CPU
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 Lage-
parameter 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 Vergleichs-
kriterium 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.
6 Migration und Parsen
64
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 Funktiona-
litä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 wer-
den 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 ein-
zufü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
Umsetzung einzelner Abläufe sind in [Koc11] zu finden.
Input
XML
(6.1.2)Konkatenation
Unicode-Konvertierung
(6.1.3)
(6.1.4)XML-Parsen
Vorverarbeitung
INSERT
VARCHAR/CLOB
Mig
ratio
n (6
.1)
Neueinfügung (6.2)
Abbildung 18: Überblick der betrachteten INSERT-Szenarien
6 Migration und Parsen
65
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 vernach-
lä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 Utility-
basierten 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 inner-
halb 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 Indexierungs-
mö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 INSERT-
Performance 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 nach-
trä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]
6 Migration und Parsen
66
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 nicht-
nativen XML-Dokumenten in den nativen XML-Datentyp mit fest vorgegebener Unicode-
Codepage (UTF-8) aktuell in der DATEV durch folgende Besonderheiten. Den Ausgangspunkt
bilden Quelldokumente, die als VARCHAR- oder CLOB-Dokument jeweils in der EBCDIC-
Codepage 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 Migrations-
folge 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
6 Migration und Parsen
67
die Messreihe zum Konkatenationsprozess. Da dieser nicht unmittelbar innerhalb des INSERT-
Statements 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 ge-
wü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.
Kostenanteil des XML-Parsens (6.1.4)(4) – (3)(4) XML-Parsen
Kosten für die Konkatenation (6.1.2)(2) Konkatenation (optional)
Kostenanteil der Konvertierung (6.1.3)(3) – (1)(3) Unicode-Konvertierung
Kosten für das einfache Kopieren (6.1.1)(1) Einfaches Kopieren
ErgebnisDifferenzMessreihe
Kostenanteil des XML-Parsens (6.1.4)(4) – (3)(4) XML-Parsen
Kosten für die Konkatenation (6.1.2)(2) Konkatenation (optional)
Kostenanteil der Konvertierung (6.1.3)(3) – (1)(3) Unicode-Konvertierung
Kosten für das einfache Kopieren (6.1.1)(1) Einfaches Kopieren
ErgebnisDifferenzMessreihe
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 aus-
schließ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.
6 Migration und Parsen
68
KonkatenationInput
XML
Unicode-Konvertierung
XML-Parsen
Vorverarbeitung
INSERT
VARCHAR/CLOB
VARCHAR/CLOB
(EBCDIC)
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.
6 Migration und Parsen
69
0
5
10
15
20
25
30
35
40
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Sekunden
Größe und Anzahl
CPU - VARCHAR
CPU - CLOB
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 Beson-
derheiten 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 XML-
Dokumente, 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).
6 Migration und Parsen
70
Der zuletzt betrachtete Sachverhalt bietet jedoch keine Erklärung für den deutlichen Werte-
unterschied 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 XML-
Dokumenten 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 INSERT-
Performance 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
6 Migration und Parsen
71
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
0,05
0,1
0,15
0,2
0,25
Se
ku
nd
en
Strukturiertheit
CPU
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 Strukturiert-
heitsmessung. 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 betrachte-
ten größenmäßigen Charakteristika aufzeigen und keine zusätzlichen Erkenntnisse liefern.
Trotzdem lässt sich daraus folgern, dass das „einfache Kopieren“ für kumulierte XML-
Dokumente wesentlich schneller abläuft, als für über viele Dokumente verteilt gespeicherte
Entitätsausprägungen.
6 Migration und Parsen
72
6.1.2 Konkatenation
In DB2 werden zur nicht-nativen Speicherung von XML-Dokumenten vorwiegend die Daten-
typen 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].
Tupel 3
Tupel 2
Tupel 1
nicht-natives XML
(„zerhackt“)
Tupel 3
Tupel 2
Tupel 1
nicht-natives XML
(„zerhackt“)
e></customerinfo>
<customerinfo id="1001"><name>Mustermann</
name><phone type="work">408-555-1358</phon
<customerinfo id="1001"><name>
Mustermann</name><phone type="work">
408-555-1358</phone>
</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 Konkatenations-
prozesses liegt, soll für die den Varianten zugrunde liegenden Überlegungen auf [Koc11]
verwiesen werden.
6 Migration und Parsen
73
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 durch-
gefü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 CLOB-
Daten als verrechnete Referenzwerte gewählt. Der Ablauf der durchgeführten Testreihe gestaltet
sich wie im Überblick in Abbildung 24 dargestellt.
Input
XML
Unicode-Konvertierung
XML-Parsen
Vorverarbeitung
INSERT
VARCHAR/CLOB
Konkatenation
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 XML-
Dokumentteile. 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.
6 Migration und Parsen
74
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 1000
Zusammensetzung eines
Ergebnisdokuments
Anzahl anAusführungen
Abbildung 25: Beispiel für die Bezeichnung einer Merkmalsausprägung
In dem Ablauf der hier beschriebenen Messreihe zeigen sich viele Parallelen zu den Aus-
fü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 Verfahrens-
weise 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.
6 Migration und Parsen
75
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 Kompaktheits-
grü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 Kon-
katenation 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 XML-
Dokumentteile 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 unein-
geschrä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
6 Migration und Parsen
76
1
10
100
1000
10000
Sekunden
Größe und Anzahl
CPU - CLOB - SP
CPU - VARCHAR - SP
CPU - CLOB - RSQL
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 Konkatenations-
vorgang. 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
6 Migration und Parsen
77
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 XML-
Tablespaces 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 XML-
Dokumenten 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
6 Migration und Parsen
78
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 Aufwands-
abschätzung für den Performance-Anteil des Konvertierungsprozesses berechnen.
KonkatenationInput
XML
XML-Parsen
Vorverarbeitung
INSERT
VARCHAR/CLOB
VARCHAR/CLOB
(Unicode)
Unicode-Konvertierung
Abbildung 27: Überblicksgrafik – Unicode-Konvertierung
Zu dem hier betrachteten Prozess der Unicode-Konvertierung sind folgende, den Vorbetrach-
tungen 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.
6 Migration und Parsen
79
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 Unicode-
Konvertierung der Daten entstehen.
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Sekunden
Größe und Anzahl
CPU - VARCHAR
CPU - CLOB
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 XML-
Dokumenten 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
6 Migration und Parsen
80
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 Merkmals-
ausprä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 Merkmals-
ausprä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 Unicode-
Konvertierung 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ück-
geschrieben. 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 zusammen-
gesetzter Form oder einzeln verarbeitet werden. Eine (erneute) Begründung der Ergebnisse soll
6 Migration und Parsen
81
an dieser Stelle nicht erfolgen. Dazu wird wegen der bestehenden Analogie auf die Ausfüh-
rungen 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.
KonkatenationInput
Vorverarbeitung
VARCHAR/CLOB Unicode-
Konvertierung
INSERT
XML
XML-Parsen
Abbildung 29: Überblicksgrafik – XML-Parsen der Dokumente
Ähnlich zu der Vorgehensweise bei der Ermittlung des Aufwands für die Unicode-
Konvertierung 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 Kompakt-
heitsgrü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.
6 Migration und Parsen
82
� 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 Ver-
arbeitung 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.
0
2
4
6
8
10
12
14
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Sekunden
Größe und Anzahl
CPU - VARCHAR
CPU - CLOB
Abbildung 30: Messergebnis – XML-Parsen – Größe und Anzahl – CPU-Zeit
6 Migration und Parsen
83
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 LOB-
Objekt 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 XML-
Parse-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.
6 Migration und Parsen
84
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.
6 Migration und Parsen
85
0
20
40
60
80
100
120
140
Se
ku
nd
en
Strukturiertheit
CPU
Abbildung 31: Messergebnis – XML-Parsen – Strukturiertheit – CPU-Zeit
Aus den ermittelten Resultaten können hinsichtlich der Parse-Performance folgende Richt-
linien/Empfehlungen zur Modellierung von XML-Dokumenten abgeleitet werden. Element-
knoten 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 XML-
Dokumenten 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 Performance-
Ergebnisse 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 Zusammen-
setzung 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 Verarbei-
tungsform der hier involvierten Datentypen CLOB und XML zurückführbar. Eine ausführliche
6 Migration und Parsen
86
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.
0
0,5
1
1,5
2
2,5
3
3,5
4
1K
(x 100.000)
10K
(x 10.000)
100K
(x 1.000)
1M
(x 100)
10M
(x 10)
Sekunden
Zusammensetzung (und Anzahl)
CPU
Abbildung 32: Messergebnis – XML-Parsen – Zusammensetzung – CPU-Zeit
Obwohl die Betrachtung zur Strukturiertheit gezeigt hat, dass das Parsen von flacheren XML-
Dokumenten 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 XML-
Dokumenten 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.
6 Migration und Parsen
87
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 „Seiten-
fü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.
0
5
10
15
20
25
30
35
40
45
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Sekunden
Größe und Anzahl
CLOB-INSERT
VARCHAR-INSERT
CLOB-INSERT
(inklusive Unicode-Konvertierung)
VARCHAR-INSERT
(inklusive Unicode-Konvertierung)
XML-INSERT
(inklusive Unicode-Konvertierung
und XML-Parsen)
Abbildung 33: Gegenüberstellung der Prozessketten zur Migrationsuntersuchung
6 Migration und Parsen
88
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 XML-
Dokumenten nicht merklich mehr Zeit in Anspruch nimmt als das „einfache Kopieren“ von
CLOB-Daten. Die Verarbeitung von VARCHAR-Dokumenten ist hier allerdings um ein Viel-
faches 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 Dar-
stellung in Relation zu den Gesamtkosten der Migration gering ist. Auf zusätzliche Schluss-
folgerungen, 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 Kosten-
verteilung formulieren, dass es speziell in Anbetracht der Performance der VARCHAR-
Messungen 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.
6 Migration und Parsen
89
jeder Merkmalsausprägung mit je 100 Prozent. Dabei ist der Anteil, den der Prozess des
Zusammenfügens einnimmt, separat (rot) ausgewiesen.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Se
ku
nd
en
(in
Pro
zen
t)
Größe und Anzahl
Zusatzkosten für
Konkatenation
(per Stored Procedure)
XML-INSERT
(inklusive Unicode-
Konvertierung
und XML-Parsen)
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.
6 Migration und Parsen
90
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 XML-
Parse-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.
6 Migration und Parsen
91
Unicode-Konvertierung
KonkatenationInput
Vorverarbeitung
INSERT
XML
VARCHAR/CLOB
XML-Parsen
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 Konver-
tierung 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 XML-
Dokumenten ohne vorangehende Konkatenation angenommen werden. Hierzu wird auf die
Ausführungen in Abschnitt 6.1 verwiesen. Die Betrachtung anderer möglicher Unicode-
Konvertierungen (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 Migra-
tionsablauf aufgeführten Kosten vermindert um den Konvertierungsanteil aus Abschnitt 6.1.3.
6 Migration und Parsen
92
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 XML-
Daten 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 Pflege-
aufwand bei der Erstellung und Wartung von User-Defined-XML-Indexen im Rahmen des
INSERTs von XML-Dokumenten zu quantifizieren. Dazu wird zwischen zwei Vorgehens-
weisen 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 Massendaten-
INSERTs macht aber auch die Betrachtung der nachträglichen Indexerstellung Sinn. Diese
6 Migration und Parsen
93
zweite Variante dient der Ermittlung von Kennzahlen, die Aussage darüber geben, wie auf-
wä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
6 Migration und Parsen
94
941.490
907.900
880.000
860.000
300.000
0
insgesamt
941.490
907.900
880.000
860.000
300.000
0
insgesamt
941.490
907.900
880.000
860.000
300.000
0
insgesamt
Index_posyIndex_posxIndex_idMerkmalsausprägung
9.0799.0799.0791M x 100
94.149
880
86
3
0
pro Dokument
94.14994.14910M x 10
880880100K x 1.000
868610K x 10.000
331K x 100.000
00200B x 500.000
pro Dokument
pro Dokument
941.490
907.900
880.000
860.000
300.000
0
insgesamt
941.490
907.900
880.000
860.000
300.000
0
insgesamt
941.490
907.900
880.000
860.000
300.000
0
insgesamt
Index_posyIndex_posxIndex_idMerkmalsausprägung
9.0799.0799.0791M x 100
94.149
880
86
3
0
pro Dokument
94.14994.14910M x 10
880880100K x 1.000
868610K x 10.000
331K x 100.000
00200B x 500.000
pro Dokument
pro Dokument
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 Messdaten-
erhebung 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.
6 Migration und Parsen
95
Die Betrachtung der nachträglichen Indexerstellung orientiert sich dagegen direkt an der Lauf-
zeit, 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-Defined-
XML-Indexen während des INSERTs. Die letzte Messreihe stellt den Gesamtaufwand einer
nachträglichen Erstellung aller drei Indexe dar.
0%
100%
200%
300%
400%
500%
600%
700%
800%
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Se
ku
nd
en
(in
Pro
zen
t)
Größe und Anzahl
INSERT (bei 0 Indexen)
INSERT (bei 1 Index)
INSERT (bei 2 Indexen)
INSERT (bei 3 Indexen)
nachträgliche Erstellung aller 3 Indexe
+ Kosten für INSERT (bei 0 Indexen)
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 erwartungs-
gemäß hinsichtlich der Anzahl an zu pflegenden User-Defined-XML-Indexen skaliert und pro
6 Migration und Parsen
96
Index ungefähr gleichermaßen zunimmt. Hier ist aber anzufügen, dass die automatische Index-
pflege 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 Performance-
Vorteile 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 Performance-
Perspektive 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, über-
schrieben28. 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.
6 Migration und Parsen
97
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.
XMLXML-
Dokument(fehlerhaft)
XMLXML-
Dokument(korrigiert)
Korrektur(UPDATE)
XML
XMLXML-
Dokument(fehlerhaft)
XMLXML-
Dokument(korrigiert)
Korrektur(„in-document“-
UPDATE)1 Attributwert
UPDATE „in-document“-UPDATE
Abbildung 39: Beispiel zum Vergleich von UPDATE und „in-document“-UPDATE
29 Davon wären eventuell vorhandene User-Defined-XML-Indexe ebenfalls betroffen.
6 Migration und Parsen
98
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ßen-
dem INSERT der gleichen Daten.
7 XML-Schema-Management
99
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 Schema-
sprachen 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. Dem-
entsprechend 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.
7 XML-Schema-Management
100
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 Besonder-
heiten 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ähr-
leisten, 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 XML-
Dokumenten 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]
7 XML-Schema-Management
101
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. Dem-
zufolge 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 Dokument-
struktur bestimmende Bestandteile des Schema-Konzepts aufgezeigt werden. Dazu zeigt
Abbildung 40 ein XML-Schema für das Beispieldokument aus Abbildung 7.
7 XML-Schema-Management
102
<?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 Deklara-
tionen 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 XML-
Schema-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 Daten-
typ deklarieren. Dieser ergibt sich durch die Verknüpfung von weiteren Knoten-
typen – 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
7 XML-Schema-Management
103
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
7 XML-Schema-Management
104
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].
7 XML-Schema-Management
105
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-Schema-
Spezifikation 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
7 XML-Schema-Management
106
eines gemeinsamen Elternknotens sichergestellt. Dabei bezieht sich der dargestellte Schema-
Ausschnitt 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 Eindeutigkeits-
deklaration 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
7 XML-Schema-Management
107
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 Text-
block, wie eventuell eine Kopfzeile, auf allen Seiten identisch ist. So könnte sich auf den Folge-
seiten 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
7 XML-Schema-Management
108
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 „Verlinkungs-
techniken“ entwickelt. Dazu zählen beispielsweise die Konzepte XLink [W3C10], XInclude
[W3C06a] oder XPointer [W3C02], die anhand ihrer Besonderheiten in [Joc06] zusammen-
gefasst 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 Heraus-
forderung 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 An-
forderungen, die an das XML-Schema-Management und speziell an den Aspekt der Schema-
validierung gestellt und in den weiteren Abschnitten näher beschrieben werden.
7 XML-Schema-Management
109
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.
XML-Schemas
XML-Dokumente
Abbildung 45: Verknüpfung von XML-Dokument und XML- Schema
32 In objektrelationalen Systemen wird durch entsprechende Erweiterungen zum Teil davon abgewichen. 33 verschiedene Szenarien denkbar: beispielsweise XML-Dokument genügt mindestens einem XML-
Schema oder gleichzeitig mehreren XML-Schemas
7 XML-Schema-Management
110
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. Dem-
entsprechend 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 Auto-
matismen 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).
Tabelle
XML-Schema
XML-Dokument
Validierung
INSERT
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 ver-
ursachen 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“ Verar-
beitung 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.
7 XML-Schema-Management
111
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 XML-
Dokumenten regeln. Abbildung 47 veranschaulicht die diskutierten Varianten am Beispiel eines
INSERTs.
Tabelle
XML-Schema
XML-Dokument
Validierung(nicht erfolgreich)
INSERT
Dokument zurückweisen
Tabelle
XML-Schema
XML-Dokument
Validierung(nicht erfolgreich)
INSERT
XML
Dokument mitVermerk versehen
SQLCODE
SQLCODE ≙ Fehler ≙ spezieller „Ungültigkeitsvermerk“ Abbildung 47: Alternativer Umgang mit ungültigen XM L-Dokumenten
7 XML-Schema-Management
112
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.
gültig
ungültig
nicht validiert
XMLXMLXMLXML
XMLXML
✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XMLXML
XMLXML
XMLXML
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
Abbildung 48: Auskunft über Gültigkeit von XML-Doku mente
7 XML-Schema-Management
113
7.2.5 Nachträgliche Schemavalidierung
Aus dem betrachteten Zustand „nicht validiert“ lässt sich bereits schließen, dass es datenbank-
seitig 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 Tages-
geschä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 Performance-
Perspektive 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
7 XML-Schema-Management
114
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 XML-
Schemas. Auf diese Weise werden alte, noch verwendete XML-Schemas bei einer Schema-
evolution 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 Schema-
version, 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 XML-
Dokumente abzusehen.
XML-Dokumente
XML-Schema(Original)
XML-Schema(neue Version)
(1) Neue Version des XML-Schemas registriert
XML-Dokumente
XML-Schema(Original)
XML-Schema(neue Version)
(2) Sukzessives „Nachvalidieren“
7 XML-Schema-Management
115
XML-Dokumente
XML-Schema(Original)
XML-Schema(neue Version)
XML-Schema(Original)
(3) „Nachvalidieren“ vollständig abgeschlossen
XML-Dokumente
XML-Schema(Original)
XML-Schema(neue Version)
XML-Schema(Original)
(4) Original des XML-Schemas entfernen X
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-Schema-
Konzept 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 Daten-
bankmanagementsystem 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
7 XML-Schema-Management
116
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 Informa-
tionen.
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 be-
deutet, 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 Schema-
validierung ergibt, auf den in Abschnitt 7.3.1 näher eingegangen wird.
Abbildung 50: Syntaxdiagramm der Funktion DSN_XMLVALI DATE [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.
7 XML-Schema-Management
117
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 be-
schriebenen 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].
7 XML-Schema-Management
118
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 Anforder-
ungen. 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-Dokumen-
ten. Dazu muss für jede zu validierende XML-Spalte ein Trigger auf der ihr zugehörigen Tabel-
le 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)
7 XML-Schema-Management
119
XML-Daten im Trigger-Body zu verarbeiten, kann eine Schemavalidierung von XML-
Dokumenten nicht vorangestellt innerhalb eines BEFORE-Triggers, wie beispielsweise in DB2
for LUW [NK09], durchgeführt werden. Stattdessen ist es lediglich möglich, die Schema-
validierung 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.
Tabelle
XML-Dokument
INSERT
DB2 for LUW
XML
Tabelle
XML-Schema
XML-Dokument
Validierungund Parsen
(After Trigger)
INSERT
DB2 for z/OS
XML-Schema
Validierung und Parsen(Before-Trigger)
XML?
?
? ≙ Schemainformationen
XML-Parsen
Serialisieren
Abbildung 51: Vorgehensweise zur automatisierten Schemavalidierung in DB2
7 XML-Schema-Management
120
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 Haupt-
unterschied 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 Doku-
menten durchgeführt. Auch wenn es gemäß den Betrachtungen aus Abschnitt 7.2 aus Auf-
wandsgründen in produktiven Kontexten unrealistisch ist, wird für die in Abschnitt 7.3.2 durch-
gefü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 gleicher-
maß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.
7 XML-Schema-Management
121
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 hin-
sichtlich 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 XML-
Dokumenten 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.
NULL5
10004
10003
-10002
10001
SCHEMA_INFOXMLID
NULL5
10004
10003
-10002
10001
SCHEMA_INFOXMLID
XMLXML
XMLXML
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
XML✓✓✓✓
Abbildung 52: Beispielinhalt einer Tabelle mit Zusatzspalte zur Gültigkeitsauskunft
7.3.2 Performance der Schemavalidierung
Nachdem im vorangehenden Abschnitt zwei Verfahrensweisen zur Schemavalidierung heraus-
gearbeitet 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
7 XML-Schema-Management
122
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 XML-
Dokumente handelt. Andererseits existiert zu diesen Daten bereits ein vorgefertigtes XML-
Schema, was die Aussagekraft der weiter unten aufgeführten Messergebnisse nochmals be-
krä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 dazu-
gehö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 Ver-
arbeitung 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 gleich-
zeitig 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)
7 XML-Schema-Management
123
Messprozedur ist vereinfacht so implementiert worden, dass sie mit einer einmaligen Aus-
fü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 „nicht-
validierenden“ INSERT. Zusätzliche Informationen zum konkreten Aufbau der jeweils ver-
wendeten 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 „nicht-
validierenden“ 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über-
stellung 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 bes-
seren Vergleichbarkeit der Verfahren die Kosten eines INSERTs auf die Messwerte zur
7 XML-Schema-Management
124
nachträglichen Schemavalidierung hinzuaddiert worden. Abbildung 53 veranschaulicht den auf
diese Weise beschriebenen Vergleich der Verfahren mit einem INSERT ohne eingeschlossene
Schemavalidierung.
0%
100%
200%
300%
400%
500%
600%
700%
800%
900%
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
Se
ku
nd
en
(in
Pro
zen
t)
Größe und Anzahl
INSERT (ohne
Schemavalidierung)
INSERT (mit
Schemavalidierung)
nachträgliche
Schemavalidierung
(+ Kosten für INSERT)
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 Schema-
validierung 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 nut-
zen, 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 XML-
Dokument 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
7 XML-Schema-Management
125
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 Schema-
informationen 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 vor-
gestellten 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
7 XML-Schema-Management
126
Validierung in dem hier betrachteten Kontext nicht nur für den Moment der Datenmanipulation,
sondern auch insgesamt gesehen effizienter als ihr Pendant die automatische Schema-
validierung. 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-Schema-
Konzept wesentlich geringer. Als Beispiel dafür lässt sich die in Abschnitt 7.1.3 beschriebene
7 XML-Schema-Management
127
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 ein-
schrä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 Beispiel-
dokument 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.
7 XML-Schema-Management
128
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 Ent-
wicklung von Schemasprachen. Analog zu dem XML-Schema-Konzept liegt ihr ein grammatik-
orientierter 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 Schemaforma-
lismus, 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 ange-
sprochenen 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öglich-
keit 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 XML-
Schema-Konzept ebenbürtig. Hier zeigen sich im Wesentlichen lediglich syntaktische Unter-
schiede. So wird bei RELAX NG beispielsweise der Ansatz verfolgt, sämtliche Struktur-
beschreibungen 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.
7 XML-Schema-Management
129
7.4.3 Schematron
Anders als alle zuvor betrachteten Schemasprachen verfolgt Schematron [ISO06] keinen gram-
matikorientierten, 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 Kind-
elementen 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 aus-
geschlossen 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.
8 Query Performance
130
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 XML-
Speicherung 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.
8 Query Performance
131
8.1.1 XML-Indexe
Die zu dem nativen XML-Datentyp gehörenden Strukturen umfassen im Kern implizite XML-
Tablespaces, 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 formulie-
ren, 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 bestimm-
ten 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 User-
Defined-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
8 Query Performance
132
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 XML-
Dokumente 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 XPath-
Ausdruck 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]
CREATE INDEX T24431A.IDX_POSX_TXML_100KON T24431A.TXML_100K(XML_DOC)GENERATE KEY USING XMLPATTERN '/seite/textblock/@posx'AS SQL DECFLOAT;
Position für (optionale) Namespace-Deklaration
Zieldatentyp
XPath-Ausdruck
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 Ad-
ministrator spezifiziert werden. DB2 unterscheidet hier zwischen zwei möglichen Zieldaten-
typen – VARCHAR und DECFLOAT. Während der DECFLOAT-Datentyp für Zahlenwerte
vorgesehen ist, lassen sich mithilfe des VARCHAR-Datentyps nahezu beliebige Werte indexie-
ren. [NK09]
8 Query Performance
133
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, be-
stimmte 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 XPath-
Ausdrü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 Infor-
mationen.
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 User-
Defined-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 XPath-
Ausdrücke auch tatsächlich durch Indexe mit entsprechenden Zieldatentypen indexiert sind.
Unabhängig davon haben SELECT-Statements, die beispielsweise mit der XMLQUERY-
Funktion auf gezielte Teile eines XML-Dokuments zugreifen wollen, keinen Mehrwert von
eventuell vorhandenen Indexen. Weitere Einschränkungen zur Verwendung von User-Defined-
XML-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 „index-
fä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.
8 Query Performance
134
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 Er-
stellung 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 re-
gelmäßig zu aktualisieren. Die andere Form der Statistiken sind Space-Statistiken. Diese werden
beispielsweise vom Administrator genutzt, um die Speicherverwaltung innerhalb des Daten-
bankmanagementsystems 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 XML-
spezifische Erweiterungen in DB2. So ist es hier zwar in Relation zu beispielsweise CLOB-
Daten möglich, derartige Statistiken zu den gespeicherten XML-Dokumenten zu sammeln
[IBM08a]. Die Möglichkeiten dieser Datenerhebung sind allerdings verglichen mit traditio-
nellen 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 ange-
nommen wird. Das wiederum kann zur Folge haben, dass bei einer großen Anzahl an unter-
schiedlichen Werten auch für sehr häufige Werte ein Indexzugriff erfolgt und umgekehrt bei
8 Query Performance
135
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 Zeitinter-
vallen – 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 Alter-
native 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 Nach-
folgeversion 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].
8 Query Performance
136
8.1.3 Zugriffspläne
Zugriffspläne beschreiben eine Folge von internen Operationen, die dazu nötig sind, ein speziel-
les 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 Explain-
Funktionalität, die einen Zugriffsplan innerhalb der Tabelle PLAN_TABLE40 datenbankseitig
persistiert [NK09]. Die dort abgespeicherten Informationen können anschließend auf ver-
schiedenen 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 SQL-
Statements 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 konkre-
ter 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 zuge-
hörigen DocID-Index ein Record Identifier (RID) ermittelt und zurückgegeben.
40 und einigen anderen Tabellen
8 Query Performance
137
� 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“ zu-
zugreifen. Dazu wird der gesamte Datenbestand einer XML-Spalte durch ein XMLEXISTS-
Prä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.
8 Query Performance
138
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 rest-
liche 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].
8 Query Performance
139
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 Kom-
plettzugriffs 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 XML-
Funktionalitä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 ausge-
führt. Dazu müssen die nicht-nativ gespeicherten XML-Dokumente komplett aus DB2 aus-
gelesen, 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.
8 Query Performance
140
Für die Gegenüberstellungen in Abschnitt 8.2.2, 8.2.3 und 8.2.4 wird daher für die Vergleichs-
formen 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 gewis-
se Einschränkungen werden alle dort vorgestellten Vergleichskriterien in die weiteren Unter-
suchungen einbezogen. Abstriche sind dabei lediglich für das Kriterium der Strukturiertheit
vorgenommen worden, da sich die dazugehörigen Testdaten aufgrund ihrer starken Struktur-
unterschiede 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ün-
det 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 Kom-
munikation 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
8 Query Performance
141
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 „Serialisie-
rungsproblem“ 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 betrachte-
ten 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 weiter-
verarbeiten.
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 Gemeinsam-
keiten und Unterschiede eingegangen.
43 Der CLOB-Datentyp ist aufgrund seiner größeren maximalen Länge notwendig (siehe Abschnitt 6.1.2).
8 Query Performance
142
Zu dem hier betrachteten Szenario sind folgende, den Vorbetrachtungen aus Kapitel 5 unter-
liegende 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 In-
formationen 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 CLOB-
Messreihe stark an die diesen Datentypen zugehörigen Ergebnisse aus Abschnitt 6.1.1. Dem-
nach lässt sich vereinfacht feststellen: Je länger ein INSERT von VARCHAR- oder CLOB-
Dokumenten 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.
8 Query Performance
143
0
5
10
15
20
25
200B x
500.000
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Se
ku
nd
en
Größe und Anzahl
CPU - CLOB
CPU - VARCHAR
CPU - XML
CPU - XML
(mit 3 Indexen)
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 Seria-
lisierungsprozesses im Vergleich zur Performance des quasi „Umkehrprozesses“ XML-
Parsen 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 XML-
Parsens 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 XML-
Dokumente auf Wohlgeformtheit oder, falls spezifiziert, deren Validierung gegen ein definiertes
XML-Schema.
8 Query Performance
144
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 seria-
lisiert 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 Infor-
mationen veröffentlicht sind.
0
5
10
15
20
25
30
Sekunden
Strukturiertheit
CPU - XML
CPU - CLOB
Abbildung 59: Messergebnis – Komplettzugriff – Strukturiertheit – CPU-Zeit
In Relation zu dem SELECT der gleichen Dokumente, die nicht-nativ in Form des CLOB-
Datentyps 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 geeigne-
ten Stellen durch Element- oder Textknoten zu ersetzen, bestätigt werden.
8 Query Performance
145
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.
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
5
1K
(x 100.000)
10K
(x 10.000)
100K
(x 1.000)
1M
(x 100)
10M
(x 10)
Sekunden
Zusammensetzung (und Anzahl)
CPU
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.
8 Query Performance
146
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 Muster-
dokuments 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 Doku-
ments.
<?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.
8 Query Performance
147
� 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
0,1
0,2
0,3
0,4
0,5
0,6
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Se
ku
nd
en
Größe und Anzahl
CPU - CLOB
CPU - VARCHAR
CPU - XML
CPU - XML
(mit 3 Indexen)
Abbildung 62: Messergebnis – Indexunterstützter Zugriff – Größe und Anzahl – CPU-Zeit
8 Query Performance
148
Bei der Betrachtung von Abbildung 62 fällt auf, dass hier keine Messergebnisse zu der Merk-
malsausprä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 nicht-
nativen 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 Szena-
rio ein ähnlicher Kurvenverlauf wie bereits bei der Betrachtung aus Abschnitt 8.2.1. Mit zuneh-
mender Dokumentgröße fällt bei gleichzeitig konstant bleibendem Gesamtdatenvolumen die
Kurve der CPU-Zeit ab. Aufgrund der angesprochenen Ähnlichkeit wird daher auf ein zusätz-
liches Diagramm verzichtet und auf Abschnitt 8.2.2 verwiesen. Hervorzuheben bleibt an dieser
Stelle lediglich folgender Unterschied: Die aus den hier ermittelten Messergebnissen resul-
tierende 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 Verarbei-
tung 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
8 Query Performance
149
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 XML-
Verarbeitung. Mithilfe der XMLQUERY-Funktion ist es möglich, gezielt per XPath-Ausdruck
auf spezifizierte Teile eines XML-Dokuments zuzugreifen, ohne dazu erst das gesamte XML-
Dokument 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 Sach-
verhalt 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 betrach-
teten 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_10KWHERE 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
8 Query Performance
150
„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 User-
Defined-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 Ergeb-
nismenge 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 Vor-
betrachtungen 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 konkre-
ten 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 gering-
fü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.
8 Query Performance
151
Dies gilt auch für die Begründung zu der in Abbildung 64 nicht dargestellten Merkmals-
ausprägung „1K x 100.000“.
0
0,1
0,2
0,3
0,4
0,5
0,6
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Se
ku
nd
en
Größe und Anzahl
CPU - CLOB
CPU - VARCHAR
CPU - XML
CPU - XML
(mit 3 Indexen)
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 XML-
Verarbeitung 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 anstei-
gende 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 Inde-
xen)“ lässt sich in der Abarbeitung der XMLQUERY-Funktion vermuten. Bis zu deren Ausfüh-
rung 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 ausge-
wertet. 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 Merk-
malsausprägung wächst, steigt ebenso auch der Gesamtaufwand des hier untersuchten SELECT-
Statements. Für die Messreihe „XML (mit 3 Indexen)“ sind die Kosten, die durch die index-
basierte Projektion per XMLEXISTS-Prädikat entstehen, im Übrigen gemäß den Ausführungen
8 Query Performance
152
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ätz-
liches 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 aus-
wirkt, 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äts-
ausprägungen.
8 Query Performance
153
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 unter-
scheidet 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 be-
titelt 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 Anwen-
dung der COUNT-Funktion.
SELECT COUNT(*) FROM T24431A.TXML_100KWHERE 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 be-
schriebenen Musterdokuments vorausgesetzt. Nun sei angenommen, dass anstatt der typischen
44 Prädikate lassen sich allgemein für die WHERE-, HAVING- oder ON-Klausel spezifizieren.
8 Query Performance
154
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 Muster-
dokuments 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 Vor-
betrachtungen 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 kon-
kreten 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.
8 Query Performance
155
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 XML-
Speicherung wiederum die Kosten für den Komplettzugriff als Referenzwerte verwendet
wurden. Dies basiert auf den Vorbemerkungen von Abschnitt 8.2, welche hier aber nicht noch-
mals thematisiert werden sollen.
0
2
4
6
8
10
12
14
16
18
1K x
100.000
10K x
10.000
100K x
1.000
1M x
100
10M x
10
Se
ku
nd
en
Größe und Anzahl
CPU - CLOB
CPU - VARCHAR
CPU - XML
CPU - XML
(mit 3 Indexen)
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 Merkmals-
ausprä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 resul-
tierende 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
8 Query Performance
156
„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 dar-
gestellten Kurvenverlauf noch eine andere Tatsache verantwortlich. Dazu ist an dieser Stelle ein
Blick auf die sich im Anhang dieses Abschnitts befindlichen Zugriffsplandiagramme notwen-
dig. 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 XMLEXISTS-
Prä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 Merkmals-
ausprä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 betrach-
teten Fall erst noch anwendungsseitig inklusive eines zuvor notwendigen Parse-Prozesses
erfolgen muss. Demnach hängt der tatsächliche Effizienzgewinn, den die native XML-
Speicherung in diesem Kontext (vielleicht) hat, stark von der Performance der anwendungs-
seitigen 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.
8 Query Performance
157
Zusammensetzung (XML)
Entgegen den Ergebnissen zum Kriterium der Größe und Anzahl zeigen sich für die Unter-
suchungen 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 XML-
Dokuments zusammenzufassen. Hinsichtlich des Gesamtaufwands sind die Performance-
Gewinne aber trotzdem nur von geringfügiger Bedeutung.
9 Zusammenfassung und Bewertung von DB2
158
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 Nach-
folgeversion 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 Migra-
tionsszenarien 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.
9 Zusammenfassung und Bewertung von DB2
159
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 effizien-ter 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
Unicode- Konvertierung
- 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 Konkatena-tion) von großen XML-Dokumenten (bei konstantem Gesamtdatenvolumen)
- Struktur hat merklichen Einfluss - kumulierte (zusammengesetzte) XML-Dokumente lassen
sich etwas schneller parsen als „Einzeldokumente“
Mig
ratio
n un
d P
arse
n
Pflege von User-Defined-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
9 Zusammenfassung und Bewertung von DB2
160
Details dazu wurden bereits in Abschnitt 7.3 erwähnt. Eine Zusammenfassung der Messergeb-
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 XML-Schemas
XM
L-S
chem
a-M
anag
emen
t
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 XML-
Schemas
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 Daten-
zugriffs auf nativ gespeicherte XML-Dokumente (siehe Abbildung 69). Besonders hervorzu-
heben 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 ledig-
lich 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 grund-
legenden Verbesserungen.
9 Zusammenfassung und Bewertung von DB2
161
Messreihe Ergebnisse/Bemerkungen
Komplettzugriff
- abgesehen vom „Seitenfüllgradproblem“ ist Komplett-zugriff von nativen XML-Daten deutlich teurer als von nicht-nativen
- merklicher Einfluss der Strukturiertheit der XML-Dokumente beim Zugriff auf nativ gespeicherte XML-Daten
- kumulierte XML-Dokumente lassen sich schneller aus-lesen
Indexunterstützter Zugriff
- gezielte Verwendung von User-Defined-XML-Indexen kann erhebliche Performance-Vorteile bewirken
- geringfügig effizienterer Zugriff auf kumulierte XML-Dokumente
Selektiver Zugriff
- effiziente, nur zum Teil indexunterstützte Möglichkeiten zum selektiven Datenzugriff
- geringfügig effizienterer Zugriff auf kumulierte XML-Dokumente
Que
ry P
erfo
rman
ce
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 XML-Dokumente
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 noch-
mals 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.
9 Zusammenfassung und Bewertung von DB2
162
Zum Kriterium der Zusammensetzung gilt es anzumerken, dass zwar durchgehend ein ab-
nehmender 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 detail-
liert nach einzelnen Entitätsausprägungen gesucht, sodass der übrige Teil eines kumulierten
Dokuments mitunter unnötig verarbeitet werden würde.
10 Schlussbetrachtung
163
10 Schlussbetrachtung
In der vorliegenden Arbeit sind diverse Performance-Untersuchungen zu den Themenschwer-
punkten Migration und Parsen, XML-Schema-Management und Query Performance durchge-
fü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 Nach-
folgeversion 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 beispiels-
weise die „konstruierte“ datenbankseitige XML-Schemavalidierung gegenüber der anwen-
dungsseitigen 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 aktuel-
len Zeitpunkt noch ungeklärt. Hier besteht ein geeigneter Ansatzpunkt für weiterführende
Untersuchungen, bei denen beispielsweise an einer speziellen Anwendungs-Workload proto-
typisch 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 ein-
bezogen ist. Zusammenfassend kann festgehalten werden: Die native Speicherung von XML-
Daten 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.
10 Schlussbetrachtung
164
Rückgabestets als XML
Suchenin XML
Ja Ja
Nein Nein
nativeXML-Speicherung
relationaleSpeicherung
(Dekomposition)
nicht-nativeXML-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.
165
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 XML-
Datentyp definiert wurde. Zur Speicherung von LOB- und XML-Daten
werden noch weitere Tabellen benötigt. Diese nennen sich LOB-Auxiliary-
beziehungsweise 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 Bina-
ry-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ög-
licht 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.
166
CLOB Character Large OBject
Ein CLOB ist eine Form des LOBs. Speziell handelt es sich um einen varia-
bel 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 be-
ziehungsweise überprüft. In DB2 existieren zum Beispiel UNIQUE-, Primär-
schlü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 er-
mö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 Steuer-
berater, 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)
167
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 Zusam-
menhang mit den User-Defined-XML-Indexen betrachtet.
Dekomposition Dekomposition bezeichnet das Zerlegen von XML-Dokumenten in relatio-
nale 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 XML-
Dokument. 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 Bestand-
teil 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.
168
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 Elapsed-
Zeit 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 Daten-
banktool. Es bietet seinen Anwendern verschiedene Funktionalitäten in den
Bereichen Design, Entwicklung, Administration und Tuning. In seiner Basis-
version 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 Inline-
Datentyps durch die maximale Record Size beschränkt. In dieser Arbeit wird
die Bezeichnung zumeist im Zusammenhang mit dem VARCHAR-Datentyp
genannt.
169
JDBC Java DataBase Connectivity
JDBC stellt eine einheitliche Datenbankschnittstelle – Call Level Interface
(CLI) – auf der Java-Plattform dar. Sie ist speziell auf relationale Daten-
bankmanagementsysteme 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-
Tabelle
Eine LOB-Auxiliary-Tabelle ist eine Tabelle, die von DB2 genutzt wird, um
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 Auxiliary-
Index. Erst wenn diese Objekte vollständig erstellt sind, können im LOB-
Tablespace 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 Datenbank-
managementsystem den nativen XML-Datentyp zur Verfügung. Demgegen-
über existieren aber auch dedizierte XML-Datenbankmanagementsysteme.
(siehe Abschnitt 3.1.1)
170
nicht-nativ Im Gegensatz zur nativen XML-Speicherung handelt es sich bei der nicht-
nativen 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 XML-
Speicherung 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 gerin-
gerem (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.
171
Stored Procedure Eine Stored Procedure ist ein datenbankseitig definierbares Anwendungs-
programm, das über ein CALL-Statement aufgerufen werden kann. DB2
unterscheidet dabei zwischen folgenden Prozeduren: externen, SQL (exter-
nen) und SQL (nativen) [IBM11a].
TPOX-Benchmark „Transaction Processing over XML“-Benchmark
Der TPOX-Benchmark ist ein spezieller Benchmark zur Performance-
Analyse der XML-Verarbeitung in Datenbankmanagementsystemen. Er
besteht aus einem Testdatengenerator (inklusive XML-Schemas), einer
Sammlung von Transaktionen, einem Workload-Treiber und Dokumentatio-
nen 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 Datenmanipula-
tion 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 Trigger-
Formen 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 XML-
Dokumenten genutzt wird. Aufgrund des verglichen mit dem EBCDIC-
Zeichensatz erweiterten Zeichenumfangs gewinnt der Unicode-Standard in
DB2 zunehmend an Bedeutung.
User-Defined-XML-
Index
Als User-Defined-XML-Indexe sind im Rahmen dieser Arbeit vom Nutzer
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 XML-
Dokuments.
(siehe Abschnitt 8.1.1)
172
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 Kilo-
bytes. Somit hat ein VARCHAR eine Länge von 1 - 32704 Bytes. Im Rah-
men dieser Arbeit wird der VARCHAR-Datentyp besonders im Zusammen-
hang 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-
Tabelle
Die XML-Auxiliary-Tabelle ist ein implizit erstelltes Verwaltungsobjekt des
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 ange-
sehen 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 verwen-
deten XML-Parser beispielsweise auch ein Validierungsvorgang gegen ein
XML-Schema erfolgen.
(siehe Abschnitt 3.1.2)
173
XML-Schema XML-Schemas dienen der Strukturbeschreibung von XML-Dokumenten. Sie
werden in Form eigener XML-Dokumente definiert. In DB2 sind XML-
Schemas 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 Adressie-
rung 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.
174
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
175
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
176
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
177
Literaturverzeichnis
[Aue10] J. Auer. „Design-Entscheidungen zwischen Element und Attribut bei einer eige-
nen 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
178
[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. Blog-
Artikel.
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übin-
gen, 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 Imple-
mentierung“, 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 Perform-
ance Feature Guide“, 08.2000.
http://publib.boulder.ibm.com/tividd/td/perfrpt/SH19-6818-05/en_US/PDF/SH19-6818-
05.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
179
[IBM04b] IBM Corporation. „DB2 for OS/390 and z/OS library – XML Extender Admini-
stration 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
180
[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
181
[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“, Produkt-
Homepage, 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/
182
[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
183
[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üh-
rungskonzepte 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“, Blog-
Artikel, 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
184
[Mül08] T. Müller. „Verfahren zur Verarbeitung von XML-Werten in SQL-Anfrage-
ergebnissen“, Dissertation, Fakultät für Mathematik und Informatik, Friedrich-
Schiller-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-das-
kompendium/themenkomplex-ii-xml/xml-schema-als-dtd-alternative/grenzen-der-dtd-
technologie/
[Pag04b] Pagina. „Uniqueness und Keys“, 02.2004.
http://www.pagina-online.de/xml-hintergruende/pagina-das-
kompendium/themenkomplex-ii-xml/xml-schema-als-dtd-alternative/uniqueness-und-
keys/
[Pag07] Pagina. „Schematron – Der neue Freund des Lektorats“, 05.2007.
http://www.pagina-online.de/xml-hintergruende/pagina-das-
kompendium/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
185
[Pic09] H.-J. Picht. „Wie ein Pinguin und ein Dinosaurier helfen können, Platz, War-
tungskosten 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, Klassifikati-
on, 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/
186
[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 (Sec-
ond 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
187
[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.
188
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)
CLOB VARCHAR Merkmals-ausprägung
Elapsed CPU Elapsed CPU
200B x 500.000 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 - -
189
Messreihe: Strukturiertheit (CLOB)
CLOB Merkmals-ausprägung
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
190
Messreihe: Zusammensetzung (CLOB)
CLOB Merkmals-ausprägung
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
191
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(2 G) 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
192
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)
CLOB (Stored Procedure)
CLOB (Recursive SQL)
VARCHAR (Stored Procedure) Merkmals-
ausprägung
Elapsed Elapsed CPU CPU Elapsed 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
193
Messreihe: Zusammensetzung (CLOB)
CLOB Merkmals-ausprägung
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
194
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)
CLOB VARCHAR Merkmals-ausprägung
Elapsed CPU Elapsed CPU
200B x 500.000 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 - -
195
Messreihe: Strukturiertheit (CLOB)
CLOB Merkmals-ausprägung
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
196
Messreihe: Zusammensetzung (CLOB)
CLOB Merkmals-ausprägung
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
197
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)
CLOB VARCHAR Merkmals-ausprägung
Elapsed CPU Elapsed CPU
200B x 500.000 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 - -
198
Messreihe: Strukturiertheit (CLOB)
CLOB Merkmals-ausprägung
Elapsed CPU
E (tief) 24,27 6,89
E (flach) 174,85 88,72
E (balanciert) 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
199
Messreihe: Zusammensetzung (CLOB)
CLOB Merkmals-ausprägung
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
200
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
INSERT (bei 1 Index)
INSERT (bei 2 Indexen)
INSERT (bei 3 Indexen)
nachträgliche Erstellung aller
3 Indexe (exklusive Kosten für den INSERT)
Merkmals-ausprägung
Elapsed CPU Elapsed CPU Elapsed CPU Elapsed CPU
200B x 500.000 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
201
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(2 G); 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;
202
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(2 G)); 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(2 G); 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;
203
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(2 G)); FETCH CUR1 INTO CUR_DOC; END WHILE; CLOSE CUR1; COMMIT; END
204
Messergebnisse
Messreihe: Automatische und nachträgliche Schemavalidierung
automatische Schemavalidierung (inklusive Kosten für den INSERT)
nachträgliche Schemavalidierung (exklusive Kosten für den INSERT) Merkmals-
ausprägung
Elapsed CPU 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
205
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(2 G) 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
206
Zugriffspläne
Alle Messreihen
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML, XML (mit 3 Indexen))
CLOB VARCHAR XML XML
(mit 3 Indexen) Merkmals-ausprägung
Elapsed CPU Elapsed CPU Elapsed CPU Elapsed CPU
200B x 500.000 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
207
Messreihe: Strukturiertheit (CLOB und XML)
CLOB VARCHAR Merkmals-ausprägung
Elapsed 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
A, E (tief) 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
208
Messreihe: Zusammensetzung (XML)
XML Merkmals-ausprä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
209
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
210
Zugriffspläne
Messreihe: Größe und Anzahl (XML (mit 3 Indexen))
Alle anderen Messreihen
211
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
CLOB VARCHAR XML XML
(mit 3 Indexen) Merkmals-ausprägung
Elapsed CPU Elapsed CPU 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 Merkmals-ausprä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
212
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(2 G) 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
213
Zugriffspläne
Messreihe: Größe und Anzahl (XML (mit 3 Indexen))
Alle anderen Messreihen
214
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
CLOB VARCHAR XML XML
(mit 3 Indexen) Merkmals-ausprägung
Elapsed CPU Elapsed CPU 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 Merkmals-ausprä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
215
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
216
Zugriffspläne
Messreihe: Größe und Anzahl (XML (mit 3 Indexen)) –
nur Merkmalsausprägung „1K x 100.000“
Alle anderen Messreihen
217
Messergebnisse
Messreihe: Größe und Anzahl (CLOB, VARCHAR, XML und XML (mit 3 Indexen))
CLOB VARCHAR XML XML
(mit 3 Indexen) Merkmals-ausprägung
Elapsed CPU Elapsed CPU 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 Merkmals-ausprä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
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