IBM DB/2

DB2 ist ein kommerzielles relationales Datenbank Management System (RDBMS) der Firma IBM, dessen Ursprünge auf das System R und die Grundlagen von E. F. Codd vom IBM Research aus dem Jahr 1970 zurückgeht.

Eigenschaften

Das Datenbankmanagementsystem DB2 wird von IBM für verschiedene Plattformen vertrieben:

Es gibt die Produktlinie für IBM Mainframes, auf denen sich aus dem Betriebssystem VSE über MVS und OS/390 das System für z/OS entwickelt hat.

Eine andere Linie entstand ursprünglich für das Betriebssystem OS/2. Diese Software ist in der Programmiersprache C geschrieben und bildete die Basis für die Varianten in den Betriebssystemen Linux, Unix und Windows (LUW).

Eine Variation ist eine in das Betriebssystem IBM i integrierte Lösung für IBM-Midrangesysteme (heutige Maschinenbezeichnung System i).

Die vierte Produktlinie betrifft die Betriebssysteme VSE und VM. Für diese gibt es zwar noch Support, aber keine neuen Versionen mehr. IBM rät den Kunden den Wechsel auf andere Plattformen.

Aktuell sind die Versionen:

• DB2 for z/OS, Version 9 – verfügbar seit 16. März 2007 (die Version 8 trägt die Bezeichnung: DB2 UDB for z/OS. Die offizielle Bezeichnung für die Version 7 ist: DB2 UDB for z/OS and OS/390)
• DB2 UDB for Linux, UNIX and Windows, Version 9.5
  • DB2 Data Warehouse Edition für AIX, Linux, Windows
  • DB2 Everyplace
• DB2 UDB for System i, Version 6 Release 1 (frühere Bezeichnung: DB2/400)
• DB2 Server for VSE & VM, Version 7.4

DB2 verwaltet Daten in Tables und speichert sie in Tablespaces. DB2 unterstützt neben den Standard-SQL-Datentypen auch binäre Datentypen (Text, Töne, Bilder, Videos, XML-Daten). Zusammen mit Oracle Database und MS SQL-Server gehört DB2 zu den Datenbanksystemen mit den größten Marktanteilen.

Seit Februar 2006 gibt es eine kostenlose Version (Express-C) für Windows und Linux mit den folgenden Einschränkungen gegenüber den kommerziellen Versionen:

• Benutzung von max. 2 Kernen einer CPU (bzw. 4 Kerne mit zusätzlichem Wartungsvertrag)
• Benutzung von max. 2 GB Hauptspeicher (bzw. 4 GB mit zusätzlichem Wartungsvertrag)

Diese Version hat keine Einschränkungen hinsichtlich Größe der Datenbank und Anzahl der Benutzer, jedoch ohne zusätzlichem Wartungsvertrag gibt es keine Replikation, 24/7-Support und komfortable Updates.

Um bei der Ausführung von DB-Zugriffen optimale Performance zu erzielen, wird ein sog. Optimizer eingesetzt, ein regelbasiertes Expertensystem, welches bei der Programmvorbereitung den Zugriff auf die betreffenden Tabellen festlegt. Dies beruht unter anderem auf den sogenannten Tabellenstatistiken, die mittels o. a. Tool RUNSTATS periodisch aktualisiert werden können, berücksichtigt aber auch andere Kennwerte wie z. B. die Anzahl der CPUs und Hilfs-CPUs, den Systemzustand, die verfügbare Speichermenge und die physische Verteilung der Daten.

Der Datenzugriff der Anwendungsschicht erfolgt mit SQL, das weitgehend dem ANSI-SQL entspricht. Zugriffe auf gespeicherte Daten können daher aus vielen Programmiersprachen heraus mit eingebettetem SQL erfolgen.

DB2 kann auch als eingebettetes Datenbanksystem eingesetzt werden.

Im April 2007 hat IBM eine Kooperation mit MySQL AB angekündigt, um das DB2 UDB for iSeries als Database-Engine für MySQL verfügbar zu machen.^[1] Dadurch kann die OpenSource-Datenbank MySQL auch auf dem System i5 eingesetzt werden. IBM erhofft sich davon, neue Einsatzbereiche des Systems i5 für MySQL- und PHP-Anwendungen zu eröffnen.

Eigenschaften (DB2 z/OS)

Das System erlaubt derzeit Tablespaces mit einer maximalen Größe von 128 Terabyte.

Die Administration auf Mainframes erfolgt in der Regel mittels Batchjobs, wobei zwischen DB2 Utilities (RUNSTATS, COPY, REORG usw.) und DBA-Jobs unterschieden wird (SQL wird mittels DSNTIAD in einem TSO-Backgroundjob durchgeführt). Kleinere Arbeiten werden oft auch am TSO-Terminal mittels SPUFI oder QMF (Query Management Facility) unter ISPF durchgeführt.

Größere Mainframeumgebungen verwenden DB2 Data Sharing, wobei die Funktionalität des Parallel Sysplex der zSeries-Rechner voll genutzt wird.

Eigenschaften (DB2 LUW)

Das DB2 UDB für Linux, Unix und Windows wird oft als DB2 LUW abgekürzt.

Es wird mit CLI-Befehlen in der Kommandozeile administriert oder graphisch über die Steuerzentrale (Control Center (db2cc)).

Das so genannte DB2-EEE (sprich „triple E“, oder „trippel-Ih“) – seit der Version 8 „DPF“ (distributed partitioning feature) genannt – ist für größere Umgebungen, wobei die Datenbank-Partitionen über mehrere Rechner (Nodes) verteilt werden können.

Komponenten

Komponenten (DB2 z/OS)

Liste der Systemkomponenten eines DB2-Systems für z/OS und OS/390. Die Unterschiede zwischen OS/390 und z/OS sind relativ gering, daher muss – bezüglich der DB2-Komponenten und Funktionen – nicht näher unterschieden werden, auf welchem dieser beiden Betriebssysteme DB2 installiert ist. Im Folgenden soll z/OS als Synonym für „z/OS oder OS/390“ verwendet werden. Das DB2 für z/OS ist für eine optimale Nutzung der Betriebssystem- und Hardware-Komponenten ausgerichtet. Um die Zusammenhänge zu verdeutlichen, wurden in dieser Liste auch einige Begriffsdefinitionen von Hardware-Komponenten aufgeführt, die nicht Bestandteil des DB2-Systems im engeren Sinne sind.

• BM = Buffer Manager. Er ist ein Teil des DB2-Subsystems und hat die Aufgabe, den BP zu verwalten und die Kommunikation mit dem GBP auszuführen.

• BP = Buffer Pool. Bezeichnet einen Bereich im Arbeitsspeicher, der von einem DB2-Subsystem verwaltet wird. In einem DB2-Subsystem werden meistens mehrere BP eingerichtet, die den einzelnen Databases oder genauer den Tablespaces zugeordnet werden, wobei ein Bufferpool mehreren Tablespaces zugeordnet sein kann.

• BSDS = Bootstrap Data Set. Dateien, die Recovery-Informationen speichern.

• Data Sharing Function: Eine Data-Sharing-Gruppe schließt mehrere DB2-Subsysteme und mehrere Datenbanken zusammen. Jedes DB2-Subsystem kann auf jede in der Data Sharing-Gruppe enthaltene Datenbank zugreifen (Shared everything Architektur). Die einzelnen DB2-Subsysteme können auf denselben oder auf unterschiedlichen Rechner-Knoten laufen. Eine Anwendung hat keinen unmittelbaren Einfluss darauf, von welchem der DB2-Subsysteme sie bedient wird. Einer Data Sharing Gruppe können während des laufenden Betriebs weitere DB2-Subsysteme hinzugefügt oder entzogen werden. Dadurch wird eine leicht zu administrierende Skalierbarkeit erreicht.

• Data Sharing Gruppe: Eine Data Sharing Gruppe fasst mehrere Data-Sharing-Member zusammen. Eine Data-Sharing Gruppe hat einen GBP und einen DB2-Katalog. Dabei können sowohl mehrere Data Sharing Member, die auf demselben Rechner Knoten liegen, zusammengeschlossen werden, als auch Data Sharing Member eingebungen werden, die auf einem bis zu 40 km entfernten Rechner Knoten liegen.

• Data Sharing Member: Ein in einer Data Sharing Gruppe enthaltenes DB2 Subsystem.

• Datenbank (engl. Database) ist ein logisches Ordnungskriterium von DB2-Objekten, die einer Data Sharing Gruppe zugeordnet sind. Zu jeder Database wird meistens eine RACF-Gruppe und ein gleichnamiges Schema eingerichtet. Ein Tablespace ist genau einer Datenbank zugeordnet.

• DB2 Subsystem: Synonym für DB2 Instanz und für DB2 Exemplar. Bezeichnet wird damit ein Programm, dass vom Betriebssystem gestartet wurde und im Arbeitsspeicher aktiv ist. Auf einem Rechner-Knoten können mehrere DB2-Subsysteme installiert werden. Wenn die Data Sharing Funktion genutzt wird, dann hat ein DB2 Subsytem auf alle Datenbanken Zugriff, die der gesamten Data Sharing Gruppe zugeordnet sind. (Shared everything Architektur) Ein DB2 Subsystem kann auch so installiert werden, dass es in keiner Data-Sharing Gruppe eingebunden ist. Dann kann jedes DB2 Subsystem nur auf seine eigenen Datenbanken zugreifen. (Shared nothing Architektur) Ein DB2-Subsystem besteht aus dem RDS, dem DM mit dem IRLM und dem BM. Es verwaltet mehrere BP und einen SQL-Statement-Cache. Jedes DB2 Subsystem hat seine eigenen Log-Dateien. Daher ist auch jedes DB2 Subsystem für sein eigenes Recovery verantwortlich.

• DB2-Katalog: Verzeichnis aller DB-Objekte. In einer Data-Sharing-Umgebung gibt es einen einzigen DB2-Katalog, in dem alle Objekte, auf die die DB2-Subsysteme zugreifen können, verzeichnet sind. Objekte, die in dem DB2-Katalog verzeichnet sind, sind unter anderem die Databases, Bufferpools, Tablespaces, Tables, Views, Indizes und die Zugriffsberechtigungen.

• DDF = Distributed Data Facility. Komponente für den Zugriff auf ein RDBMS auf einem entfernten System. Dadurch sind sowohl Zugriffe auf andere DB2-Systeme, als auch auf RDBMS anderer Datenbank-Hersteller wie z. B. Oracle und MS SQL-Server möglich.

• DM = Data-Manager. Komponente eines DB2 Subsystems, die den Zugriff auf den Bufferpool ausführt und die Stage-1-Prädikate der SQL-Queries ausführt. (Die Liste der Stage-1- und der Stage-2-Prädikate findet man im Kapitel 6.3.3.2 Summary of predicate processing^[2] vom Application Programming and SQL Guide^[3]) Der DM wird vom RDS aufgerufen, um eine SQL-Query zu evaluieren. Der DM fordert vom BM die erforderlichen Daten an.

• DSNZPARM: System Parameter. Hier werden Konfig-Parameter des DB2-Subsystems gespeichert.

• GBP = Group Buffer Pool. Der GBP steht allen DB2-Subsystemen einer Data Sharing Gruppe zur Verfügung. Der GBP ist die logische Bezeichnung des vom Coupling Facility verwalteten Speicherbereichs.

• GLM = Global Lock Manager. Bei einem Parallel Sysplex nimmt die Coupling Facility die Aufgabe des GLM wahr. Er übernimmt die Kohärenzkontrolle für die gemeinsame Nutzung von Daten durch die einzelnen Rechner-Knoten. Der GLM kommuniziert mit den LLM der Rechner-Knoten.

• Hiper Pool: Stellt eine optionale Erweiterung des Virtual Pools dar und kann bei der DB2 z/OS Version 7 bis zu 8 GB groß definiert werden. Der Hiper Pool befindet sich im Expanded Storage. Seit der DB2 z/OS Version 8 sind Hiper Pools nicht mehr erforderlich, da durch die 64 Bit-Adressierung der gesamte Arbeitsspeicher direkt adressiert werden kann. (Eine 64-Bit Adresse kann 16 Exabyte direkt adressieren).

• Instanz: Synonym für DB2 Subsystem und für DB2-Exemplar.

• IRLM = Internal Resource Lock Manager. Das ist der Lock-Manager eines DB2-Subsystems. Er kommuniziert mit dem LLM des Rechner-Knotens

• LLM = Local Lock Manager. Das ist der Lock-Manager, der das Locking innerhalb eines Rechner-Knotens steuert. Wenn Ressourcen vom Plattenspeicher angefordert werden, die sich bereits vom LLM anderer Rechner-Knoten im Zugriff befinden, dann koordiniert der GLM die Locks zwischen den einzelnen LLM.

• Partitionierung ist bei DB2 z/OS eine Eigenschaft von Tablespaces, Tabellen und Indizes. Alle Partitionen werden im selben Katalog verzeichnet und können von denselben DB2-Subsystemen zugegriffen werden. Partitionierung wird für die Speicherung und Verwaltung von großen Datenbeständen eingesetzt. Eine partitionierte Tabelle bietet die Möglichkeit, dass einzelne Partitionen administriert werden (REORG, RECOVER, COPY), während die Anwendungsprogramme auf den anderen Partitionen aktiv sind. Die Partitionierung ist ein wesentlicher Beitrag zur Gewährleistung einer hohen Verfügbarkeit von großen Datenbeständen.

• RDS = Relational Data System. Komponente eines DB2-Subsystems, dass unter anderem die Stage-2-Prädikate ausführt. (Die Liste der Stage-1- und der Stage-2-Prädikate findet man im Kapitel 6.3.3.2 Summary of predicate processing^[4] vom Application Programming and SQL Guide^[5]) Während der DM alle „einfachen“ Prädikate evaluiert, führt das RDS die „komplexen“ Verknüpfungen zur Ermittlung der Ergebnisse einer SQL-Query aus.

• SPAS = Stored Procedure Address Spaces. Adressraum, in dem eine Stored Procedure ausgeführt wird.

Komponenten (DB2 LUW)

Das DB2 UDB für Linux, Unix und Windows wird oft als DB2 LUW abgekürzt. Im Gegensatz zum DB2 z/OS bietet die IBM die wichtigsten Manuals für DB2 V9 LUW in deutscher Sprache^[6] an. Auch die Fehler- und Hilfetexte werden – eine Installation mit Sprachauswahl deutsch vorausgesetzt – in deutsch ausgegeben. Dabei werden auch die Namen der DB2-Systemkomponenten in deutschen Begriffen angegeben. Das mag den ersten Einstieg erleichtern, da man sich nur die deutschen Begriffe merken muss. Wenn man jedoch die weiteren Details des Systems verstehen will, dann ist man auf die übrigen nicht ins Deutsche übersetzen Manuals und die sonstige englischsprachige Literatur z. B. die Redbooks^[7] angewiesen. Zum anderen werden verständlicherweise im DB2-Katalog nur die originalsprachlichen Begriffe verwendet. Folglich führt kein Weg daran vorbei, sich auch die englischen Begriffe zu merken. In der nachfolgenden Begriffsdefinition werden zuerst die englischen Begriffe, danach die von der IBM verwendeten deutschen Übersetzung angegeben gefolgt von ihrer Erläuterung.

• Connect = Verbindung einer Instanz zu einer Datenbank. Ein Connect ist die Voraussetzung, um SQL-Befehle auszuführen. Es gibt den Connect-Typ-1, bei dem ein Client immer nur zu einer Datenbank eine Verbindung haben kann. Bei dem Connect-Typ-2 kann ein Client innerhalb einer Transaktion zu mehreren Datenbanken eine Verbindung aufbauen. Im 2. Fall wird der Two-Phase-Commit verwendet.

• DAS = Database Administration Server. Auf deutsch: DB2-Verwaltungsserver. DAS ist ein Verwaltungsservice, der die DB2-Verwaltungstools bei der Lokal- und Fernverwaltung, bei der Jobverwaltung und bei Benachrichtigungen unterstützt. Auf einem Computer darf nur ein DAS vorhanden sein. Der DAS wird bei einer Standard-Installation so konfiguriert, dass er startet, wenn das Betriebssystem gestartet wird. Der DAS speichert ab der Version 8 seine Parameter nicht mehr in Konfigurations-Dateien, sondern in der Tools-DB.

• Database. Auf deutsch: Datenbank. Eine Datenbank kann man sich als einen Daten-Container vorstellen. Er wird auf einer (oder mehreren) bestimmten Festplatten gespeichert. Eine Datenbank hat einen eigenen DB2-Katalog und wird von einer lokalen Instanz verwaltet. Auf eine Datenbank können nur die Instanzen zugreifen, die diese Datenbank in ihrem Datenbank-Verzeichnis katalogisiert haben. Wenn auf einem Rechner eine Datenbank installiert ist, dann muss dort auch eine Instanz vorhanden sein, die diese Datenbank verwaltet.

• Database Directory. Auf deutsch Datenbank-Verzeichnis. Jede Instanz hat ihr eigenes Datenbank-Verzeichnis, in der alle Datenbanken verzeichnet sind, zu denen die Instanz einen Connect aufbauen kann. In dem Verzeichnis sind alle lokalen Datenbanken katalogisiert. Wenn eine Instanz eine neue Datenbank erstellt, dann trägt sie diese auch gleich in ihr Datenbank-Verzeichnis ein. Es können auch entfernte Datenbanken eingetragen werden, wenn sie auf einem Knoten liegen, der im Knoten-Verzeichnis katalogisiert ist. Das Datenbank-Verzeichnis und das Knoten-Verzeichnis sind das Äquivalent zu der Datei tnsnames.ora bei Oracle.

• DB2 CAE = DB2 Client Application Enabler. Wird auch DB2 Connect genannt. DB2 CAE kann auf einem Client-Computer installiert werden, um einen Zugriff über das Netzwerk zu einem DB2-Server zu ermöglichen. Im CAE sind ein CLP und die DCS enthalten.

• DB2 Connect siehe DB2 CAE.

• DB2-Registry = DB2-Profil-Registrierdatenbank zum Speichern von Umgebungsvariablen. Alle Systemparameter, die zum Hochfahren der Instanz erforderlich sind, werden vom Betriebssystem verwaltet. Die anderen Systemparameter werden von der Datenbank selber verwaltet. In der DB2-Registry werden vier Ebenen unterschieden:
  • DB2-Profilregistrier-Datenbank auf Exemplarebene. Hier werden Parameter gespeichert, die nur für die Instanz gelten
  • Globale DB2-Profil-Registrierdatenbank. Parameter betreffen alle Instanzen
  • DB2-Profil-Registrierdatenbank auf Exemplarknotenebene. Parameter, die nur für einen Knoten Gültigkeit haben
  • DB2-Exemplarliste. Liste aller auf dem System verfügbaren Exemplar-Namen.

• DCS = Database Connection Service. Das DCS-Verzeichnis wird vom DB2-Connect verwendet wird. Einträge im DCS kann man mit dem Befehl: „CATALOG DCS DATABASE“ vornehmen.

• DDCS = Distributed Database Connection Service. Gateway-Komponente für den Zugriff auf andere DRDA-Systeme. Erforderlich ist dafür die Installation von DB2 Connect Enterprise. Zur DDCS-Komponente gehören verschiedene BND- und LST-Dateien, die das Binden der vom CLP benötigten Packages gegen das entfernte RDBMS erlauben.

• DPF = Data Partitioning Feature. Systemfunktion für die Administration von partitionierten DB2-Objekten.

• DMS = Database Managed Space. Parameter eines Tablespace. Dadurch wird festgelegt, dass die Verwaltung des Tablespace von der DB2-Instanz ausgeführt wird.

• Exemplar: Synonym für Instanz. Siehe Begriffsdefinition dort.

• Federated Server. Eine Instanz kann als Federated Server eingerichtet werden. Dadurch kann zusammen mit der Installation eines Wrappers auf DBMS anderer Hersteller wie z. B. Oracle, MS SQL-Server sowie auf ODBC-Datenquellen zugegriffen werden. Siehe auch Föderiertes Informationssystem.

• Instance. Auf deutsch Instanz. Synonym für Exemplar und dem Begriff eines DB2-Subsystems in der Mainframe-Welt. Aus Sicht des Betriebssystems ist eine Instanz ein Programm mit einer Konfigurationsumgebung (Environment), das vom Betriebssystem gestartet werden kann. Auf einem Rechner können mehrere Instanzen installiert werden. Die Instanz wird vom Betriebssystem unter einem bestimmten User gestartet. Dieser User muss im Betriebssystem registriert sein. Er ist der Eigentümer der Instanz. Eine Instanz kann mehrere lokale Datenbanken verwalten. Sie kann über das Database Directory auch auf Datenbanken anderer Instanzen zugreifen.

• Node. Auf deutsch Knoten oder Rechner-Knoten. Bezeichnet wird damit ein Computer, auf dem eine DB2-Installation vorhanden ist.

• Node Directory. Auf deutsch: Knotenverzeichnis. Liste von Knoten, auf denen weitere DB2-Systeme vorhanden sind, die vom lokalen DB2-System zugegriffen werden sollen. Wenn keine Verbindungen zu fernen Datenbanken eingerichtet sind, dann gibt es auch kein Knotenverzeichnis bzw. das Knotenverzeichnis ist leer.

• LDAP = Lightweight Directory Access Protokoll. Es ist eine Standard-Zugriffsmethode für einen Verzeichnisdienst. Für DB2 bedeutet das, dass das Datenbankverzeichnis und das Knotenverzeichnis nicht mehr lokal auf jeder Maschine gespeichert werden muss, sondern auf einem zentralen LDAP-Server abgelegt ist. Um einen LDAP-Server zu verwenden, müssen alle beteiligten Server beim LDAP-Server registriert sein. Zum Einrichten gibt es im DB2 die „CATALOG LDAP“-Befehle.

• SMS = System Managed Space. Parameter eines Tablespace, der angibt, dass die Verwaltung des Tablespace von Betriebssystem ausgeführt ausgeführt wird.

• Wrapper. Ein Wrapper ermöglicht eine Verbindung zu einer entfernten Datenquelle. Voraussetzung ist, dass der Server als „Federated Server“ parametrisiert ist. In der Version 8 können Wrapper für die folgenden Datenquellen eingerichtet werden: BioRS, BLAST, CTLIB (SYBASE), DRDA (DB2), Entrez, Excel, HMMER, Informix, NET8 (ORACLE), ODBC, OLE DB, Table-structured files, Teradata, Web services, WebSphere Business Integration, XML.

Tools

Tools (DB2 z/OS)

Tools, die unter der ISPF-Benutzeroberfläche laufen:

• Workload Manager: Komponente, die für die Arbeit auf einem z/OS den Zugang zu den Betriebsmitteln steuert.
• SPUFI: Programm zur Ausführung von SQL-Statements
• QMF: Programm zur Ausführung von SQL-Statements. QMF besitzt zusätzlich einige Formatierungs-Befehle. Es ist ein komplettes Re-Design für die QMF-Software angekündigt. Die Software soll zukünftig ein Client-Tool mit einer graphischen Benutzeroberfläche sein.
• InSync for DB2: Werkzeug der Macro 4, womit DB2 Daten interaktiv verarbeitet und verändert werden können.
• File-AID for DB2: Tool zum Anlegen, Löschen, Sichern, Laden von Tabellen, Tablespaces und Daten.

Tools, die auf einem Client z.B. unter Windows laufen und über DB2 Connect auf den DB2-Datenbankserver zugreifen:

• Visual Explain: Tool zur Anzeige des Zugriffspfades einzelner SQL-Statements. Visual Explain läuft unter Windows und wird von der IBM als kostenlosesr Download angeboten. Voraussetzung für die Nutzung ist allerdings die Installation des DB2-Connect.
• Performance Estimator: Werkzeug zur Abschätzung der Leistung von SQL-Statements.
• Control Center: Tool zur Administration der Datenbank über eine grafische Oberfläche
• Development Center: Entwicklungsumgebung zur Erstellung von SQL/PL- und Java-Prozeduren
• Warehouse Manager: Tool zur Konfiguration von ETL-Komponenten wie z.B. Materialized Views
• Replication Center: Tool zur Konfiguration und Administration von Datenreplikationen zu anderen relationalen oder auch nicht relationalen Datenbanken.

Tools (DB2 LUW)

• CLP = Command-Line-Prozessor. Auf deutsch: Befehlszeilenprozessor. Umgebung zur Ausführung von SQL-Statements und DB2-Commands zur Administration der Datenbank. Der CLP wird aufgerufen mit dem Befehl: „db2“. Man kann jederzeit ohne den Connect zur Datenbank zu verlieren, wieder auf die Kommando-Ebene des Betriebssystems wechseln mit dem Befehl: „quit“.
• DB2 Connect: Datenbank-Programmierschnittstelle, die einem Client den Zugriff auf einen Datenbank-Server ermöglicht. Jede Installation braucht ein eigenes Knotenverzeichnis und ein eigenes Datenbank-Verzeichnis. Darüber wird festgelegt, zu welchen DB-Servern und den dort verwalteten Datenbanken ein Connect ausgeführt werden kann.
• Steuerzentrale: Werkzeug zur Administration der Datenbank
• Visual Explain kann auch bei DB2 LUW eingesetzt werden.

Skalierbarkeit (DB2 LUW)

Das DBMS kann auf unterschiedlichen Hardware-Konfigurationen installiert werden.

Wenn ein kleines Datenvolumen verwaltet werden soll und nur wenige Transaktionen ihre Anforderungen an das DBMS stellen, dann ist eine Installation auf einer Einzelprozessormaschine eine kostengünstige Lösung.

Bei einer größeren Anzahl von zu bearbeitenden Transaktionen wäre eine Mehrprozessormaschine die nächst größere Einheit zur Leistungssteigerung. Das System kann die Evaluierung einer einzigen Abfrage auf mehreren Prozessoren parallel bearbeiten. Dadurch wird sowohl die Bewältigung des gesamten Transaktionsvolumens als auch die Ausführung einzelner verarbeitungsintensiver Abfragen beschleunigt. Es sind jedoch nicht alle Abfragen für eine Parallelisierung geeignet. Das DBMS verwaltet die Verteilung der Arbeitsschritte auf die einzelnen Prozessoren (Symmetrisches Multiprozessorsystem). Diese Hardware-Konfiguration wird auch als Shared-everything Architecture bezeichnet, denn die einzelnen Prozessoren müssen sich alle anderen Hardware-Komponenten miteinander teilen.

Wenn sich die Nutzung der anderen Hardware-Komponenten (Plattenspeicher, Controller, Arbeitsspeicher) als Engpass herausstellt, dann kann die Leistung weiter gesteigert werden durch eine Verteilung des DBMS auf mehrere Einzelprozessormaschinen. Diese Hardware-Konfiguration wird auch als Shared Nothing Architecture bezeichnet, da jeder Prozessor seinen eigenen Hauptspeicher, Controller und Plattenspeicher besitzt. Wenn das DBMS auf mehreren Rechner-Knoten installiert wird, dann muss Datenbankpartitionierung eingesetzt werden. Das bedeutet, dass auf jedem Rechner-Knoten eine (oder auch mehrere) Datenbankpartition eingerichtet wird. Ein einzelnes DBMS kann auf maximal 512 Rechner-Knoten installiert werden.

Um die maximale Hardware-Leistung für ein DBMS zur Verfügung zu stellen, können für die einzelnen Rechner-Knoten Mehrprozessormaschinen gewählt werden. Eine solche Hardware-Architektur wird auch als SMP-Cluster bezeichnet.

Partitionierung

DB2 bietet verschiedene Konzepte, um die Administration großer Datenmengen zu erleichtern und um die Zugriffsperformance durch Parallelverarbeitung zu erhöhen. Eines dieser Konzepte ist die Partitionierung.^[8]

Datenbankpartitionierung

Datenbankpartitionierung gibt es nur für DB2 LUW. Es muss eingesetzt werden, wenn eine DB2-Instanz auf mehreren Rechner-Knoten installiert wird. Auf jedem Rechner-Knoten muss mindestens eine Datenbankpartition eingerichtet werden. Es kann auch eingesetzt werden, wenn die DB2-Instanz auf nur einem Rechner-Knoten installiert ist. Bei einer Installation auf einem Rechner-Knoten lohnt sich die Datenbankpartitionierung vor allem dann, wenn unterschiedliche Speicherplatten installiert sind. Auf jeder Speicherplatte kann eine eigene Datenbankpartition eingerichtet werden. Auf diese Weise kann eine gleichmäßige Verteilung der Daten auf mehrere Speicherplatten bewirkt werden. Durch die Parallelisierung der Plattenzugriffe kann schneller auf die Daten zugegriffen werden.

Nachdem die Datenbankpartitionen definiert sind, müssen diese zu Partitionsgruppen zusammengefasst werden. Eine Partitionsgruppe kann aus einer oder aus mehreren Datenbankpartitionen bestehen. Eine Datenbankpartition kann mehreren Partitionsgruppen angehören. Die Partitionsgruppen dürfen sich überschneiden.

Beispiel:

Es gibt die Datenbankpartitionen p1, p2, … p9

Es werden die folgenden Partitionsgruppen eingerichtet:

g1 = ( p1 )

g2 = ( p2 )

g3 = ( p3, p4, p5 )

g4 = ( p3, p4, p5, p6, p7 )

g5 = ( p6, p7, p8, p9 )

g6 = ( p9 )

Beim Erstellen eines Tabellenbereichs (Tablespace) muss in dieser Umgebung immer mit angegeben werden, in welcher Partitionsgruppe der Tabellenbereich erstellt werden soll. Im Beispiel können Tabellenbereiche für kleinere Tabellen in den Partitionsgruppen g1 und g2 angelegt werden. Tabellenbereiche für größere Tabellen können z. B. in der Partitionsgruppe g4 erstellt werden. Alle Tabellen, die in diesem Tabellenbereich erstellt werden, werden automatisch in allen Datenbankpartitionen der benannten Gruppe erstellt. So können die Daten einer Tabelle auf mehrere Rechner-Knoten verteilt werden.

Die Verteilung erfolgt implizit durch Generierung eines Partitionsschlüssels mittels eines Hash-Algorithmus. Das System wählt selber die Spalten aus, die zur Generierung des Hash-Schlüssels herangezogen werden. In den meisten Fällen wird der Primärschlüssel oder ein Teil davon genommen. Wenn die Tabelle ohne Primärschlüssel definiert wird, dann wird die erste Tabellenspalte genommen. Mit dem Administrationswerkzeuge SQLUGTPI kann die Verteilungszuordnung überprüft und ggf. geändert werden.

Tabellenpartitionierung

Tabellenpartitionierung ist eine Funktion, die im DB2 z/OS seit der Version 8 genutzt werden kann. Beim DB2 LUW kann sie in den Versionen 8 und 9 ebenfalls genutzt werden.

In der englischen Literatur werden dafür die Begriffe ‚Tablepartitioned‘ oder auch ‚Datapartitioned‘ verwendet.

Bei der Tabellenpartitionierung wird beim Erstellen einer Tabelle festgelegt, wie viele Partitionen diese Tabelle haben soll und nach welchem Verteilungskriterium die Daten auf die einzelnen Partitionen aufgeteilt werden. Dabei kann für jede Tabellenpartition ein anderer Tabellenbereich (Tablespaces) angegeben werden. Wenn die Tabellenbereiche auf unterschiedlichen Speicherplatten angelegt wurden, dann kann damit eine Parallelisierung (und damit Beschleunigung) der Plattenzugriffe erreicht werden.

Die Zuordnung der Daten zu den einzelnen Partitionen muss bei der Tabellendefinition explizit angegeben werden.

Beispiel 1:

CREATE TABLE t1 (verkaufsdatum date, umsatz decimal(10,2))
IN ts1, ts2, ts3, ts4, ts5
partition BY range(verkaufsdatum)
(starting FROM ('01.01.2007') ending at ('31.12.2007') every (3 month));

ts1 bis ts5 sind die bereits vorhandenen Tabellenbereiche.

Beispiel 2:

CREATE TABLE t1 (verkaufsdatum date, umsatz decimal(10,2))
IN ts1, ts2, ts3, ts4, t5
partition BY range(verkaufsdatum)
( starting FROM ('01.01.2007') ending at ('31.01.2007') IN ts1,
  ending at ('31.05.2007') IN ts2,
  ending at ('01.06.2007') IN ts3,
  ending at ('10.07.2007') IN ts4,
  ending at ('31.12.2007') IN ts5);

Bei der zweiten Variante kann eine Ungleichverteilung der Daten explizit berücksichtigt werden.

Die Partitionierungsgrenzen können nachträglich geändert werden. Es können weitere Partitionen hinzugefügt werden und einzelne Partitionen gelöscht werden.

Bei DB2 z/OS können seit der Version 8 alle Indizes, die zu dieser Tabelle definiert werden, ebenfalls partitioniert werden. Wenn ein Index auch partitioniert wird, dann wird er nach denselben Kriterien partitioniert, wie die Tabelle. Es kann der Primärschlüssel, die Partitionierung und die Sortierreihenfolge der Sätze im Tabellenbereich (CLUSTER-Order) unabhängig voneinander gewählt werden. Wenn alle Indizes einer partitionierten Tabelle ebenfalls partitioniert sind, dann wird dadurch eine völlige Unabhängigkeit der einzelnen Tabellenpartitionen hergestellt. Es kann eine Partition administriert werden (z. B. LOAD REPLACE, RECOVER, REORG, COPY) während auf den anderen Partitionen gleichzeitig Programme aktiv sind. Voraussetzung ist allerdings, dass die Programme so parametrisiert werden können, dass die nur auf die Daten bestimmter Partitionen zugreifen. Im Beispiel oben kann die Partition in ts1 mit LOAD REPLACE geladen werden, während ein Programm die Daten vom Dezember in ts5 verarbeitet.

Bei DB2 LUW Version 9 kann ein Index nicht partitioniert werden. Er kann lediglich in einem eigenen Tabellenbereich angelegt werden. Eine völlige Isolierung der einzelnen Tabellenpartitionen (aus Sicht der Administration) wie bei DB2 z/OS ist daher in der DB2 LUW Version 9 nicht möglich.

Indexpartitionierung

Dieses Konzept war bei DB2 z/OS bis zur Version 7 die einzige Möglichkeit der Partitionierung von Daten. Dieses Konzept ist aus Kompatibilitätsgründen noch in der aktuellen Version enthalten, doch wird vom Hersteller empfohlen, auf die Tabellenpartitionierung zu wechseln.

In der englischen Literatur werden dafür die Begriffe ‚Indexpartitioned‘ oder – um es noch deutlicher auszudrücken – ‚index-controlled partitioned‘ verwendet.

Bei der Indexpartitionierung wird bei der Definition eines Tabellenbereiches die Anzahl der Partitionen festgelegt. In diesem Tabellenbereich kann nur eine einzige Tabelle angelegt werden, die einen Primärschlüssel haben muss. Es muss ein eindeutiger (unique) Index angelegt werden, der zum Primärschlüssel passt. Bei der Indexdefinition wird der Verteilschlüssel festelegt, nach dem die Daten auf die einzelnen Partitionen aufgeteilt werden. Dieser Index bestimmt gleichzeitig die Sortierreihenfolge (Cluster-Order) der Daten und wird selber in den einzelnen Partitionen gespeichert.

Beispiel:

CREATE tablespace ts1
numpart 5
IN db01;
 
CREATE TABLE t1 
( verkaufsdatum date,
  umsatz decimal(10,2),
  PRIMARY KEY(verkaufsdatum))
  IN db01.ts1;
 
CREATE UNIQUE INDEX i1
ON t1 (verkaufsdatum)
cluster
( part 1 VALUES ('31.01.2007'),
  part 2 VALUES ('31.05.2007'),
  part 3 VALUES ('01.06.2007'),
  part 4 VALUES ('10.07.2007'),
  part 5 VALUES ('31.12.2007'));

In dem Beispiel ist db01 der Name der Datenbank, ts1 der Name des Tabellenbereichs, t1 der Name der Tabelle und i1 der Name des Index. Der Tabellenbereich wird für 5 Partitionen definiert. Die Partitionsobergrenzen werden bei der Indexdefinition festgelegt.

Der Nachteil bei der Indexpartitionierung ist, dass alle weiteren Indizes nicht partitioniert werden können. Dadurch ist eine separate Administration einzelner Partitionen stark eingeschränkt. Außerdem sind der Partitionierungs-Schlüssel, der Primärschlüssel und die Cluster-Reihenfolge untrennbar miteinander verbunden. Bei der Tabellenpartitionierung können diese drei Elemente unabhängig voneinander bestimmt werden.

Index-Typen

Indices können nur im DB2 z/OS partitioniert werden. In der DB2 LUW V9 können Indices noch nicht partitioniert werden. Die nachfolgenden Ausführungen über Indexpartitionierung beziehen sich also nur auf das DB2 z/OS.

Durch die Einführung der Tabellenpartitionierung der DB2 z/OS V8 sind vielfältige Gestaltungsmöglichkeiten für das Index-Design entstanden. Die in der Literatur verwendeten englischen Begriffe sollen den deutschen Begriffen – falls vorhanden – zugeordnet werden und kurz beschrieben werden.

Eigenschaften von Indices, die zu partitionierten Tabellen erstellt werden

	partitioned (partitioniert)	nonpartitioned (nicht partitioniert)
partitioning (partitionierend)	*1	*2
nonpartitioning (nicht partitionierend)	DPSI	*3

Bei der in früheren DB2 Versionen verwendeten Index-partitionierung einer Tabelle konnte nur der Primärschlüssel-Index partitioniert werden. Das ist der Typ *1. Indices vom Typ *1 können natürlich in der aktuellen Version auch erstellt werden.

Weitere secondary Indices konnten bis zur Version 7 nur ohne Partitionierung, also als *2 oder *3 erstellt werden. Seit der Version 8 können alle Indices zu einer partitionierten Tabelle ebenfalls partitioniert werden. Zu einer partitionierten Tabelle können nach wie vor auch unpartitionierte Indices angelegt werden. Die Partitionsunabhängigkeit ist dann allerdings eingeschränkt.

• Partitioned / Nonpartitioned. Auf deutsch: partitioniert / nicht partitioniert. Die Abkürzung NPI steht für nonpartitioned Index. Damit wird unterschieden, ob der Index selber in mehreren Partitionen gespeichert wird oder ob er als eine einzige zusammenhängende Struktur gespeichert wird. Ein nicht partitionierter Index kann in einem einzigen Dataset gespeichert werden. Wenn ein Index partitioniert ist, dann existiert für jede Partition eine eigene Index-Struktur. Ein Index kann nur nach denselben Kriterien partitioniert werden wie die Tabelle, auf die er sich bezieht. Das bedeutet, wenn eine Tabelle nicht partitioniert ist, dann können zu dieser Tabelle auch keine partitionierten Indices angelegt werden.

• Partitioning/Nonpartitioning. Auf deutsch: Partitionierend / nicht partitionierend. Ein Index ist partitionierend, wenn er die Spalten der Tabelle, die zur Partitionierung der Tabelle verwendet werden, als vorderste Index-Spalten enthält. Beispiel: eine Tabelle ist partitioniert anhand der Spalten S1, S2. Ein Index I1 über die Spalten S1, S2, S5 ist partitionierend, ein Index I2 über die Spalten S1, S3, S2 ist nicht partitionierend und I3 über die Spalten S7, S8, S9 ist auch nicht partitionierend. Diese Bezeichnung sagt nichts darüber aus, ob der Index partitioniert gespeichert wird oder nicht.

• Secondary Index. Auf deutsch: Sekundärindex. Ist eine andere Bezeichnung für Nonpartitioning also nicht partitionierend. (Index-Typen DPSI und *3 )

• DPSI=Data-partitioned secundary index. Der Index ist partitioniert, aber nicht partitionierend. Er wird also in n Partitionen gespeichert, obwohl seine vordersten Index-Spalten nicht mit den Spalten übereinstimmen, die die Partitionierung der Tabelle ausmachen. Ein DPSI kann nicht UNIQUE definiert werden. Das liegt daran, dass ein bestimmter Index-Schlüssel in jeder Partition vorkommen kann, also in jeder Index-Struktur vorkommen kann. Die Eindeutigkeit eines Schlüssels könnte nur durch einen Zugriff auf die Index-Strukturen aller anderen Partitionen überprüft werden. Wenn Eindeutigkeit erforderlich ist, dann sollte ein nonpartitioning Index als nonpartitioned definiert werden. (Index Typ *3 )

• logische / physische Indexpartition. Beide Begriffe bezeichnen die Menge aller Schlüssel, die der Index speichert, die auf dieselbe Tabellenpartition verweisen. Wenn der Index selber partitioniert ist, dann handelt es sich um physische Indexpartitionen, da jede Indexpartition auch tatsächlich in einer (oder mehreren) separaten Datei(en) gespeichert werden. Es handelt sich um logische Indexpartitionen, wenn der Index nicht partitioniert ist. Die Schlüssel aus den einzelnen logischen Indexpartitionen werden gemischt gespeichert in einer einzigen Index-Struktur.

Weitere Eigenschaften von Indices (betrifft Indices zu partitionierten Tabellen und auch Indices zu nicht partitionierten Tabellen)

• clustering. Wenn mehrere Indices zu einer Tabelle erstellt werden, dann kann einer davon als Cluster-Index definiert werden. Das bedeutet, dass bei einer Reorganisierung der Tabelle die Datensätze in der Reihenfolge abgelegt werden, wie es dieser Index vorgibt. Da seit der Version 8 die Cluster-Reihenfolge nicht mehr zwangsläufig mit dem Primärschlüssel und den Partitionierungs-Kriterien übereinstimmen muss, kann auch ein nicht partitionierender Index als Cluster-Index gewählt werden. Die Sortierreihenfolge bezieht sich immer auf die Sätze innerhalb einer Partition. Ein Clusterindex kann unique oder auch nonunique sein.

• unique / nonunique. Auf deutsch: Eindeutiger / nicht eindeutiger Index. In einem eindeutigen Index kann ein Schlüssel nur einmal vorkommen. Bei einem nicht eindeutigen Index kann ein Schlüssel mehrfach vorkommen.

• padded / non padded. Gibt an, wie VARCHAR-Datenfelder in Index gespeichert werden. Bei einem Padded Index werden VARCHAR-Daten auf ihre volle Länge expandiert, indem sie mit Leerzeichen aufgefüllt werden. Dafür muss die Längeninformation nicht mitgespeichert werden. Ein Non Padded Index speichert VARCHAL-Daten nur in der Länge, in der sie auch tatsächlich vorliegen. Hier wird die Längeninformation mitgespeichert.

• ascending / descending. Auf deutsch: aufsteigende / absteigende Sortierreihenfolge. Die Sortierreihenfolge war in früheren DB2 Versionen ein wichtiger Parameter, da die Leaf-Pages nur in der definierten Sortierreihenfolge durchgelesen werden konnten. Seit der DB2 z/OS V8 können die Leaf-Pages in beiden Richtungen sequentiell gelesen werden.

SQL PL

Die Stored Procedure Engine in DB2 implementiert eine Teilmenge von ISO-standardisiertem SQLPM (SQL Persistent Modules). Sie ist ähnlich zu Oracle PL/SQL und unterstützt ROWTYPES, einfach strukturierte Tabellen und globale Variablen nicht.

Ebenfalls wie schon bei Oracle zu finden ist eine sehr weite DBMS-seitige C++- und Java-Unterstützung. Es ist möglich, Java-Funktionalität in DB2 abzulegen (die Klasse muss vom IBM-Treiber eine bestimmte Klasse ableiten, je nach dem ob eine Funktion oder eine Prozedur erstellt werden soll) und von einer Stored Procedure aufzurufen.

Utilities

RUNSTATS

RUNSTATS ist ein Utility zur Erzeugung von statistischen Daten über die Inhalte von DB2-Tabellen und deren Indizes. Zum Beispiel werden die minimalen und maximalen Werte einer Spalte und die Kardinalität der Spalten und der Tabelle ermittelt.

Abgelegt werden diese Daten im DB2-Systemkatalog, einer Sammlung von Tabellen, in denen DB2 Informationen über alle Objekte, wie Tabellen, Indizes, Spalten usw., ablegt (self descriptive, also „selbstbeschreibend“).

Das Datenbankverwaltungssystem nutzt diese statistischen Daten, um für die vom Anwender realisierten Zugriffe auf die DB2-Tabellen einen möglichst optimalen Zugriffspfad zu verwenden. Z. B. sind Index-Zugriffe in der Regel sinnlos, wenn die gesamte Tabelle nur wenige Zeilen enthält; ein einfaches Lesen aller Daten ist dann schneller. Neben den Daten für den Zugriffspfad (Optimizer) werden aber auch Daten für die Administration ermittelt, z. B. der Quotient der genutzten Speicherseiten oder der Komprimierungsgrad.

RUNSTATS sollte immer dann ausgeführt werden, wenn sich die Inhalte von Tabellen wesentlich geändert haben, oder wenn neue Indizes angelegt wurden. Danach müssen bei statischem SQL auch die verweisenden DB2-Packages neu gebunden werden, da darin die Zugriffswege abgelegt sind.

Das Werkzeug kann für Tabellenbereiche (Tablespace) oder Indizes ausgeführt werden und kann auch im Rahmen anderer administrativer Utilities eingebettet laufen (REORG, LOAD).

JCL-Beispiel für DB2 (z/OS):

//RSTAT    EXEC DSNUPROC,UID='JCA.RUNSTA',TIME=1440,
//         UTPROC=,
//         SYSTEM='V71A',DB2LEV=DB2A
//UTPRINT  DD  SYSOUT=*
//SYSIN    DD *
RUNSTATS TABLESPACE DSNXXX.DSNABCDE
   TABLE(ALL) SAMPLE 25
    INDEX(ALL)
  SHRLEVEL CHANGE

Hier werden im Tablespace DSNXXX.DSNABCDE in allen Tabellen und Indizes 25 % der Zeilen untersucht (SAMPLE 25). Ein paralleler Update durch andere Prozesse ist erlaubt (SHRLEVEL CHANGE).

Unter Unix könnte ein Kommando so aussehen:

RUNSTATS ON TABLE beispielschema.beispieltabelle 
WITH DISTRIBUTION AND DETAILED INDEX

REORGCHK

Mit dem Utility REORGCHK kann ermittelt werden, ob eine Reorganisation von Tabellen oder Indizes möglich ist. Zudem können in vereinfachter Form auch die Statistikdaten einer Tabelle in Analogie zum Utility RUNSTATS aktualisiert werden.

REORG

REORG ist ein Utility zur Reorganisation von DB2-Tabellen bzw. Indizes (Unix- und Windows-Version) oder Tablespaces (Mainframe). Dabei werden die Daten in einer optimalen Art und Weise auf dem permanenten Speicher abgelegt. Die optimale Weise wird über den Cluster-Index bestimmt. Die Speicherseiten werden optimal aufgefüllt und Zeilen, die nicht auf ihrer ursprünglichen Seite stehen (Far-Of-Page, Near-Of-Page), werden wieder an die bestmögliche Position verschoben.

Das Utility kann offline oder online arbeiten. Bei der Offline-Variante werden die Daten dem Clustering-Index entsprechend sortiert und in temporäre Dateien gespeichert. Der Tablespace wird dann neu angelegt und die Daten werden – nun sortiert – wieder in den Tabellenbereich eingetragen. Anschließend werden alle Indizes neu aufgebaut.

Bei der Online-Variante wird ein neuer Tablespace („Schattenkopie“) angelegt und die Daten werden sukzessive in den neuen Bereich sortiert übertragen. Zwischenzeitliche Änderungen werden anschließend aus dem Recovery-Log eingearbeitet, wobei eine Arbeitstabelle (Mappingtable) der Zuordnung von alten zu neuen internen Satzschlüsseln (Record Identifiers) dient. Sind alle Änderungen berücksichtigt, findet ein „Switch“ statt, nach dem die DB2 fortan auf den neuen Tabellenbereich zugreift. Der alte Bereich wird verworfen.

Zusätzlich zum Reorganisieren können Sicherungskopien (COPY) und statistische Daten (RUNSTATS) ermittelt werden.

JCL-Beispiel für DB2 (z/OS):

//REORG    EXEC DSNUPROC,UID='JCA.REORG',TIME=1440,
//         UTPROC=,
//         SYSTEM='V71A',DB2LEV=DB2A
//UTPRINT  DD  SYSOUT=*
//SYSIN    DD *
REORG TABLESPACE DSNXXX.DSNABCDE

Hier wird der Tablespace DSNXXX.DSNABCDE reorganisiert.

Zur Feststellung der Notwendigkeit kann ein weiteres Utility herangezogen werden: REORGCHK.

CHECK INDEX

Das DB2-Utility überprüft ob der Datenbankindex auf dem zu prüfenden Tablespace konsistent zu den Daten ist, auf die der Index angewendet wird. CHECK INDEX sollte nach einem conditional Restart oder einem Point-in-time Recovery für alle Tablespace ausgeführt werden, wo der Index eventuell inkonsistent ist.

JCL-Beispiel für DB2 (z/OS)

//STEP1 EXEC DSNUPROC,UID=’IUIQU1UQ.CHK1’, 
// UTPROC=’’,
// SYSTEM=’DSN’ 
//SYSUT1 DD DSN=IUIQU1UQ.CHK3.STEP1.SYSUT1,DISP=(MOD,DELETE,CATLG), 
// UNIT=SYSDA,SPACE=(8000,(200,20),,,ROUND) 
//SYSERR DD DSN=IUIQU1UQ.CHK3.SYSERR,DISP=(MOD,DELETE,CATLG), 
// UNIT=SYSDA,SPACE=(6000,(20,20),,,ROUND) 
//SORTOUT DD DSN=IUIQU1UQ.CHK3.STEP1.SORTOUT,DISP=(MOD,DELETE,CATLG), 
// UNIT=SYSDA,SPACE=(6000,(20,20),,,ROUND) 
//SYSIN DD * 
  CHECK INDEX (ALL) TABLESPACE DSN8D81A.DSN8S81E 
//*

Hier werden vom Tablespace DSN8S81E der Database DSN8D81A alle Indizes überprüft.

CHECK DATA

Das Utility CHECK DATA überprüft die Verletzung von referentiellen Integritäten und Constraints. Wird eine solche Verletzung ermittelt, wird der entsprechende Tablespace in den „CHECK-pending“ Status versetzt. Bevor ein CHECK DATA ausgeführt wird, sollte vorher ein CHECK INDEX auf diesen Tablespace laufen, damit sichergestellt ist, dass der Index korrekt ist auf den sich das Utility bezieht. Auf verschlüsselten Tabellen wird das Utility Fehler produzieren, weil die Daten vor dem CHECK nicht entschlüsselt werden. CHECK DATA sollte nach einem conditional Restart oder einem Point-in-time Recovery für alle Tablespace ausgeführt werden, wo sich voneinander abhängige Tabellen eventuell nicht synchronisiert haben.

JCL-Beispiel für DB2 (z/OS)

//STEP11 EXEC DSNUPROC,UID=’IUIQU1UQ.CHK2’, 
// UTPROC=’’, 
// SYSTEM=’SSTR’ 
//SYSUT1 DD DSN=IUIQU1UQ.CHK2.STEP5.SYSUT1,DISP=(MOD,DELETE,CATLG), 
// UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND) 
//SORTOUT DD DSN=IUIQU1UQ.CHK2.STEP5.SORTOUT,DISP=(MOD,DELETE,CATLG), 
// UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND) 
//SYSERR DD DSN=IUIQU1UQ.CHK2.SYSERR,DISP=(MOD,DELETE,CATLG), 
// UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND) 
//SYSIN DD * 
   CHECK DATA TABLESPACE DBIQUQ01.TPIQUQ01 SCOPE ALL 
   AUXERROR INVALIDATE 
/*

Monitoring von Utilities (DB2 z/OS)

Um den derzeitigen Status einer gestarteten DB2-Utility zu überwachen, gibt es das Kommando „DB2 DISPLAY UTILITY(*|$UTILID$)“ . Ein Ergebnis ist dann folgendermaßen aufgebaut: JCL-Beispiel für DB2 (z/OS):

DSNU100I – DSNUGDIS – USERID = SAMPID 
   MEMBER = DB1G 
   UTILID = RUNTS PROCESSING UTILITY STATEMENT 1 
   UTILITY = RUNSTATS 
   PHASE = RUNSTATS 
   COUNT = 0 
   NUMBER OF OBJECTS IN LIST = n 
   LAST OBJECT STARTED = m 
   STATUS = STOPPED 
   DSN9022I – DSNUGCC ’-DISPLAY UTILITY’ NORMAL COMPLETION
  

Erklärung des Feldes STATUS:

• STOPPED = Das Utility ist nicht normal beendet worden und die Objekte, die im Zugriff waren (Tablespace und Index) sind noch im Zugriff des abgebrochenen Utility. Um diese Objekte wieder zugänglich zu machen muss entweder das Utility neu gestartet werden oder das Utility über das DB2-Kommando „-TERM UTILITY($UTILID$)“ terminiert werden.
• TERMINATED = Ein Terminierungsrequest wird abgearbeitet.
• ACTIVE = Das Utility befindet sich im aktiven Status und wird derzeit ausgeführt.

Extensions

Die Funktionalität von DB2 kann mit sog. Extendern erweitert werden, die erweiterte Funktionalität für spezialisierte Datentypen anbieten.

Net Search Extender

Für effiziente Volltextsuche auf Spalten mit Textinhalten.

Spatial Extender

Für geografische Probleme (Flutzonenanalyse etc.)

Object Relational Extender

Erweiterung zum Arbeiten mit Objekten auf RDBMS-Basis

XML Extender

Mit der DB2 LUW V9 wurde die Verarbeitung von XML-strukturierten Daten grundlegend geändert. Auch die DB2 z/OS V8 wurde um etliche Funktionen für die Verarbeitung von XML-Daten erweitert.

Der XML-Support in der SQL-Sprache wird inzwischen auch von der ISO beschrieben. ^[9]

Funktionen zur Abfrage von XML-Dokumenten und zur Extraktion der Information für die Speicherung in relationalen Tabellen:

• XMLPARSE
• XMLQUERY
• XPath
• XQuery

Funktionen zur Generierung von XML-Dokumenten aus Datensätzen, die in relationalen Tabellen gespeichert sind: (Beispiele)

• XMLELEMENT
• XMLFOREST
• XMLAGG

Für das Update von einzelnen Nodes eines XML-Dokuments liegt Ende 2008 weiterhin keine Standard-Definition vor, weshalb auch DB2 nur das Update von ganzen XML-Dokumenten erlaubt ^[10].

OLAP-Extender

Unterstützung der SQL-Erweiterungen für OLAP-Anwendungen. Beispiele:

• RANK
• DENSE_RANK
• ROW_NUMBER

Geschichte

^[11] Im Zuge der Entwicklung der relationalen Benutzerschnittstelle „Structured Query Language“ (SQL) wurde IBM-intern der erste Prototyp, das so genannte System R entwickelt (1975-1979), das 1977 erstmalig bei einem IBM-Kunden installiert wurde. Aus diesen Erfahrungen wurde SQL/DS für DOS/VSE (heute z/VSE) und VM (heute z/VM) entwickelt.

Parallel hierzu wurde die eigenständige Produktlinie des Mainframe MVS (heute z/OS) vorangetrieben. DB2 war die zweite verfügbare relationale Datenbank am Markt.

1987 kündigte die IBM eine Datenbank für das Betriebssystem OS/2 an. 1991 wurde die Datenbank ‚OS/2 Database‘ für OS/2 in die Produktpalette aufgenommen. Diese Datenbank ist der Vorläufer für die heutige DB2 UDB. 1993 wurde die Datenbank unter dem Namen DB2 V1 für die Betriebssysteme OS/2 und AIX angeboten. Seit 1995 kann die Datenbank auch unter Windows installiert werden.

Zwischenzeitlich existieren DB2-Produkte auf unterschiedlichen System-Plattformen wie DB2 Universal Database (UDB) for z/OS, DB2/VM/VSE, DB2 Universal Database (UDB) für LUW (AIX, HP-UX, Linux, Sun Solaris, Microsoft Windows (XP/2000/2003)) und DB2 Universal Database (UDB) for iSeries (System i5, ehemals AS/400).

Im Großrechnerbereich hat DB2 zu einem großen Teil das hierarchische Datenbanksystem IMS/DB von IBM abgelöst.

Geschichte (DB2 z/OS)

^[12]

Version 3 (verfügbar seit Dezember 1993, Support bis März 2001)

• Index Typ 2. Die Partitionierung gibt es zwar schon seit der Version 1, doch die Bearbeitung der Partitionen war nicht unabhängig voneinander. Das lag an den Index-Locks, die bei INSERT, UPDATE und DELETE verursacht wurden. Dadurch wurden auch die Daten aus anderen Partitionen mitgesperrt. Wenn ein Programm viele Schreiboperationen in einer Partition vornahm, dann wurden Programme, die auf andere Partitionen zugriffen, in Mitleidenschaft gezogen. Erst in der Version 4 wurde dieses Problem behoben durch die Einführung des Index Typ 2.

Version 4 (verfügbar seit November 1995, Support bis Dezember 2001)

• Stored Procedures und User Defined Functions können verwendet werden. Die Programme müssen in einer Programmiersprache z. B. Cobol oder C geschrieben werden mit embeddet sql. In diesen Programmen kann auch auf DBMS-fremde Ressourcen (z. B. VSAM-Dateien) zugegriffen werden.
• Parallelverarbeitung bei der Evaluierung einer einzelnen Abfrage möglich.
• der Isolationlevel kann bei einem einzelnen SQL-Statement festgelegt werden abweichend von dem Isolationlevel, den das ganze Programm (Package) hat.
• der Isolationlevel Dirty Read wird unterstützt
• Sperren einzelner Datenzeilen möglich. Bisher war nur ein Sperren von Datenpages (mindestens 4 kB) möglich.
• Sperren von Index-Einträgen nicht mehr erforderlich bei INSERT, UPDATE, DELETE. Dadurch wird die Zeit, die auf gesperrte Daten gewartet werden muss, verringert. Programme, die auf unterschiedlichen Partitionen aktiv sind, behindern sich nicht mehr.
• Maximale Größe einer Tabelle: 64 GB. Maximale Anzahl von Partitionen für einen Tabellenraum: 64

Version 5 (verfügbar seit Juni 1997, Support bis Dezember 2002)

• Speicherung von Daten im ASCII-Format möglich. Bisher konnten Daten nur im EBCDIC-Format gespeichert werden. Das bringt eine Performance-Verbesserung für alle Client-Programme, die die Daten im ASCII-Format verarbeiten.
• der SQL-Sprachumfang wird erweitert um das CASE-Statement
• der Online-Reorg ermöglicht ein Reorganisieren der Tabellendaten während Programme auf diese Daten zugreifen (lesend und schreibend). Dadurch wird die Downtime für die Anwendungen deutlich reduziert.
• Maximale Größe einer Tabelle: 1 TB. Maximale Anzahl von Partitionen für einen Tabellenraum: 254

Version 6 (verfügbar seit Juni 1999, Support bis Juni 2005)

• Trigger können verwendet werden
• LOB-Datentypen (=Large Objects) können gespeichert werden. Damit können Pixel-, Audio-, Video-Daten und Text-Dokumente in Tabellen gespeichert werden.
• Maximale Größe einer Tabelle: 16 TB. Maximale Anzahl von Partitionen für einen Tabellenraum: 254

Version 7 (verfügbar seit März 2001, Support bis Juni 2008)

• Speicherung von Daten im Unicode-Format möglich
• SQL/PL, die SQL3-Erweiterungen der SQL-Sprache um prozedurale Elemente. Stored Procedures können dadurch in der Programmiersprache SQL geschrieben werden.
• Temporäre Tabellen können deklariert werden. Jede Connection erhält eine eigene Instanz, sobald sie Zugriffe auf die Tabelle ausführt. Am Ende der Transaktion wird die Instanz automatisch wieder entfernt.
• Static Scrol-Cursor. Vorwärts und rückwärts lesen möglich. Änderungen anderer Transaktionen aktualisieren die Datenmenge, die durch den Cursor gelesen wird. (Ausnahme: neu eingefügte Sätze anderer Transaktionen sind nicht sichtbar)
• Maximale Größe einer Tabelle: 16 TB. Maximale Anzahl von Partitionen für einen Tabellenraum: 254

Version 8 (verfügbar seit März 2004)

• Tabellenpartitionierung. Details siehe Abschnitt Partitionierung. Die Administration großer Datenbestände wird dadurch erleichtert und die Downtime der Anwendungen weiter reduziert.
• interne 64 Bit-Adressierung. Dadurch ist ein Swappen der Arbeitsspeicher-Bereiche nicht mehr erforderlich. Die frühere direkte Adressierbarkeit von maximal 2 GB ist aufgehoben.
• Viele Strukturänderungen sind im laufenden Betrieb möglich, die bisher ein Löschen und Neuerstellen erforderten. Beispiele: Tabelle oder Index um zusätzliche Spalten erweitern, Datentyp von Tabellen-Spalten ändern auch wenn Indices dafür existieren, Hinzufügen, Löschen oder Ändern von Partitionen.
• Die maximale Größe eines einzelnen SQL-Statements wurde von bisher 32 kB auf 2 MB heraufgesetzt.
• Nutzung des neuen Assist Processors (=Co-Prozessor) zIIP
• Dynamic Scrol Cursor. Erweiterung des Static Scrol Cursors aus V7, mit dem nun auch neu eingefügte Sätze anderer Transaktionen gelesen werden können.
• Visual Explain wird als kostenloser Download angeboten. Es kann unter Windows installiert werden und kann die Zugriffspfade der Packages anzeigen.
• Maximale Größe einer Tabelle: 128 TB. Maximale Anzahl von Partitionen für einen Tabellenraum: 4096

Version 9 (verfügbar seit März 2007)

• Erweiterte XML-Funktionen
• Erweiterte Datentypen (64 Bit) BIGINT, DECFLOAT, VARBINARY
• Neue SQL-Funktionen
  • OLAP-Unterstützung: RANK, DENSE_RANK, ROW_NUMBER
  • Mengenoperationen INTERSECT (Schnittmenge) und EXCEPT (Differenzmenge)
  • MERGE-Statement als eine Kombination aus INSERT oder UPDATE
• TRUNCATE Table für schnelles Löschen aller Datensätze einer Tabelle ohne Zerstören der Datenstrukturen, der Index-Strukturen und der Trigger
• Versteckter Last-Change-Timestamp erleichtert die Realisierung des optimistic Locking
• neue SQL/PL Funktionen
• INSTEAD OF Trigger
• Maximale Größe einer Tabelle: 128 TB. Maximale Anzahl von Partitionen für einen Tabellenraum: 4096

Sonstiges

Neben DB2 bietet IBM mit Informix eine weitere, kommerzielle Datenbank an. Die Funktionen von Informix werden seit dem Kauf der Informix-Datenbank in den Funktionsumfang von DB2 hinzugefügt, um den Informix-Anwendern einen Wechsel zu DB2 zu erleichtern. ^[13]

Siehe auch

• relationale Datenbank
• Datenbanksystem
• Datenbankmodell
• Liste der Datenbankmanagementsysteme
• DRDA

Weblinks

• Offizielle Startseite von IBM zu DB2
  • DB2 Express-C - Eine kostenlose Version von DB2 für Linux und Windows
  • Einstieg in DB2 Express-C 9.5
  • Dokumentation zu DB2 V8 LUW
  • Dokumentation zu DB2 V9 LUW
  • Dokumentation zu DB2 V9 LUW in deutscher Sprache
  • Dokumentation zu DB2 UDB for z/OS V8
  • Startseite von IBM zu DB2 z/OS
• Das DB2 SQL Cookbook von Graeme Birchall

Quellen

1. ↑ Kooperation mit MySQL AB
2. ↑ 6.3.3.2 "DB2 UDB for z/OS V8 Application Programming and SQL Guide" IBM Library Server
3. ↑ DB2 for z/OS - DB2 for z/OS Version 8 books
4. ↑ 6.3.3.2 "DB2 UDB for z/OS V8 Application Programming and SQL Guide" IBM Library Server
5. ↑ DB2 for z/OS - DB2 for z/OS Version 8 books
6. ↑ http://www-306.ibm.com/software/data/db2/udb/support/manualsNLVv9.html#de_main
7. ↑ IBM Redbooks
8. ↑ IBM DB2 Administration Guide Planning
9. ↑ SQL & XML Working Together
10. ↑ http://www.research.ibm.com/journal/sj/452/beyer.html
11. ↑ The Big Picture: IBM DB2 Information Management Software and DB2 Universal Database
12. ↑ Quellen: 1. Reference-Manuals für DB2 z/OS von IBM zu den jeweiligen Versionen. 2. What’s new-Dokumente von der IBM zu den einzelnen Versionen. 3. Redbooks What’s new in DB2 z/OS V8
13. ↑ Quelle: Administration Guide Plannung für DB2 LUW V9