Der Datentyp XML in DB2 for z/OS aus Performance...

Der Datentyp XML in DB2 for z/OS aus Performance-Perspektive

- Diplomarbeit -

zur Erlangung des akademischen Grades Diplom-Informatiker

eingereicht von

Christoph Koch

[email protected]

Betreuer

Prof. Klaus Küspert, Friedrich-Schiller-Universität Jena

Norbert Wolf, DATEV eG

Friedrich-Schiller-Universität Jena

Fakultät für Mathematik und Informatik Institut für Informatik

Lehrstuhl für Datenbanken und Informationssysteme

Januar 2012

Danksagung Die vorliegende Diplomarbeit wurde nur durch die breite Unterstützung zahlreicher Akteure

ermöglicht. Ihnen möchte ich an dieser Stelle meinen ausdrücklichen Dank aussprechen.

Prof. Klaus Küspert

Prof. Küspert trug maßgeblich dazu bei, dass ich über ein durch ihn vermitteltes

Praktikum im Jahr 2010 mit der DATEV eG in Kontakt getreten bin. Daran schloss sich eine

Studienarbeit und nun in thematisch ähnlichem Umfeld auch die vorliegende Diplomarbeit an,

deren universitäre Betreuung in beiden Fällen Prof. Küspert selbst übernahm. Dabei scheute er

keine Mühen und reiste neben diversen Besprechungsterminen in Jena auch mehrfach zur

DATEV eG nach Nürnberg.

Norbert Wolf

Herr Wolf übernahm als Fachberater Datenbanken (DB2 for z/OS) die Betreuung der

Diplomarbeit in der DATEV eG. In engem Kontakt stand er mir stets für Fragen zur Verfügung

und investierte viel Zeit darin, mich mit seinem Wissen fachlich zu unterstützen. Darüber hinaus

gab er mir auch zahlreiche persönliche Ratschläge, so dass er für mich eine Funktion als Mentor

einnahm.

„Belegwesen“-Projekt

Das „Belegwesen“-Projekt in der DATEV eG verwaltet in DB2 for z/OS eine sehr

umfangreiche Menge an XML-Dokumenten. Nach Absprache und Prüfung durch die 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>

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>

<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.


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.


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


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]


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,


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


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.


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


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


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


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


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.


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


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


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


A

1 Dokumentwurzel


1 Textknoten

Knoten

A, TTitel

-

1 Dokumentwurzel


2.048 Elementknoten

A, E (balanciert)

flachtiefbalanciertStruktur

Grafik

1 Dokumentwurzel


2.048 Elementknoten

A, E (flach)

1 Dokumentwurzel

2.048 Elementknoten

2.048 Textknoten

E, T (balanciert)

1 Dokumentwurzel


2.048 Elementknoten

Knoten

A, E (tief)Titel

-

1 Dokumentwurzel


2.048 Elementknoten

A, E (balanciert)

flachtiefbalanciertStruktur

Grafik

1 Dokumentwurzel


2.048 Elementknoten

A, E (flach)

1 Dokumentwurzel

2.048 Elementknoten

2.048 Textknoten

E, T (balanciert)

1 Dokumentwurzel


2.048 Elementknoten

Knoten

A, E (tief)Titel


Grafik

1 Dokumentwurzel


1.366 Elementknoten

1.366 Textknoten

A, E, T (balanciert)

1 Dokumentwurzel


1.366 Elementknoten

1.366 Textknoten

A, E, T (tief)

1 Dokumentwurzel


1.366 Elementknoten

1.366 Textknoten

Knoten

A, E, T (flach)Titel


Grafik

1 Dokumentwurzel


1.366 Elementknoten

1.366 Textknoten

A, E, T (balanciert)

1 Dokumentwurzel


1.366 Elementknoten

1.366 Textknoten

A, E, T (tief)

1 Dokumentwurzel


1.366 Elementknoten

1.366 Textknoten

Knoten

A, E, T (flach)Titel

Abbildung 8: Merkmalsausprägungen des Kriteriums der Strukturiertheit


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.


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


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).


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


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.


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


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]


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


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].


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


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


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]


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.


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.


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


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


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.


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.


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.


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)


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


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


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]


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


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.


68

KonkatenationInput

XML


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.


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).


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


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.


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.


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


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.


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.








75


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


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


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


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)


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.









79


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


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


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.


82









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


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.


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.


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


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.


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


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.


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.


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.


91


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.


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


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


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.


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)



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


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.


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.


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


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.


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]


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.


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


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


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].


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


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


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


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.


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


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.


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


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


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


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



(2) Sukzessives „Nachvalidieren“


115

XML-Dokumente




(3) „Nachvalidieren“ vollständig abgeschlossen

XML-Dokumente




(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


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.


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].


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)


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


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.


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


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)


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


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


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


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


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.


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.


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



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.


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.


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.



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




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.


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.



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



8 Query Performance

155


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


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


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.


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


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.


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.


161


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


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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].


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.


[DAT11b] DATEV. „… was Sie über DATEV wissen sollten“, 2011.


[DAT11c] DATEV. „Neu bei DATEV?“, 2011.


[DAT11d] DATEV. „Vorstandsvorsitzender – Professor Dieter Kempf “, 2011.


[DAT11e] DATEV. „DATEV“, Online-Präsenz, 2011.

http://www.datev.de

[DAT11f] DATEV. „Outsourcing an DATEV“, 2011.


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.


[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.


[IBM06b] IBM Corporation. „IBM Redbook – LOBs with DB2 for z/OS: Stronger and

Faster“, 11.2006.


[IBM07] IBM Corporation. „IBM Redbook – DB2 9 for z/OS Performance Topics“,

09.2007.


[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.


[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.


180

[IBM09d] IBM Corporation. „IBM Redbook – DB2 9 for z/OS: Packages Revisited“,

03.2009.


[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.


[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.


kompendium/themenkomplex-ii-xml/xml-schema-als-dtd-alternative/uniqueness-und-

keys/

[Pag07] Pagina. „Schematron – Der neue Freund des Lektorats“, 05.2007.


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



[W3C04c] World Wide Web Consortium (W3C). „XML Schema Part 2: Datatypes Second



[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


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


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)


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


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


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


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



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




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




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



Elapsed CPU

E (tief) 6,69 0,42

E (flach) 5,14 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


A, E (tief) 6,26 0,41

A, E (flach) 6,46 0,39


A, E, T (tief) 6,37 0,41

A, E, T (flach) 5,06 0,42


196



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




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




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



Elapsed CPU

E (tief) 24,27 6,89

E (flach) 174,85 88,72


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


A, E (tief) 16,64 4,48

A, E (flach) 63,33 23,94


A, E, T (tief) 17,34 3,52

A, E, T (flach) 33,99 11,53


199



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)



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


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


Messreihe: Größe und Anzahl (XML)


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


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)



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




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))




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



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




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))


214

Messergebnisse





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



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




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“


217

Messergebnisse





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



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

Der Datentyp XML in DB2 for z/OS aus Performance...

Documents

Transcript of Der Datentyp XML in DB2 for z/OS aus Performance...