DB2

DB2
Datenbank
Basisdaten
Entwickler	IBM
Aktuelle Version	10 (zOS) / 9.7 (LUW) (22. Oktober 2010)
Betriebssystem	IBM Mainframe, Linux, Unix, Microsoft Windows
Kategorie	Datenbankmanagementsystem
Lizenz	proprietär
Deutschsprachig	ja
DB2 Seite bei ibm.com

DB2 ist ein kommerzielles relationales Datenbankmanagementsystem (RDBMS) des Unternehmens IBM, dessen Ursprünge auf das System R und die Grundlagen von E. F. Codd vom IBM Research aus dem Jahr 1970 zurückgehen.

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 10 – verfügbar seit 22. Oktober 2010 (frühere Bezeichnungen: DB2 UDB for z/OS für Version 8 bzw. DB2 UDB for z/OS and OS/390 für Version 7)
• DB2 UDB for Linux, UNIX and Windows, Version 9.7
  • 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 der Größe der Datenbank und der Anzahl der Benutzer, ohne zusätzlichen Wartungsvertrag gibt es jedoch 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 Open-Source-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 Datenbankpartitionen ü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 und Kommunikationsinformationen für DDF bzw. Sysplex 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 Architecture). Die einzelnen DB2-Subsysteme können auf denselben oder auf unterschiedlichen Rechnerknoten 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 Rechnerknoten liegen, zusammengeschlossen werden, als auch Data-Sharing-Member eingebunden werden, die auf einem bis zu 40 km entfernten Rechnerknoten liegen.

Data Sharing Member 

Ein in einer Data-Sharing-Gruppe enthaltenes DB2-Subsystem.

Datenbank 

Ein logisches Ordnungskriterium von DB2-Objekten. Wenn Data-Sharing verwendet wird, dann ist jede Datenbank genau einer Data-Sharing-Gruppe zugeordnet. Zu jeder Datenbank 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, das vom Betriebssystem gestartet wurde und im Arbeitsspeicher aktiv ist. Auf einem Rechnerknoten können mehrere DB2-Subsysteme installiert werden. Wenn die Data-Sharing-Funktion genutzt wird, dann hat ein DB2-Subsystem auf alle Datenbanken Zugriff, die der gesamten Data-Sharing-Gruppe zugeordnet sind (Shared Everything Architecture). 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 Architecture). 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 

Systemparameter. Hier werden Konfigurationsparameter 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 Rechnerknoten. Der GLM kommuniziert mit den LLM der Rechnerknoten.

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 Rechnerknotens

LLM 

Local Lock Manager. Das ist der Lock-Manager, der das Locking innerhalb eines Rechnerknotens steuert. Wenn Ressourcen vom Festplattenspeicher angefordert werden, die sich bereits vom LLM anderer Rechnerknoten 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, das 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^[2]vom Application Programming and SQL Guide^[4]) 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. Wurde in früheren Versionen verwendet, um einen Adressraum für Stored Procedures zu definieren. In neueren Versionen werden Stored Procedures in WLM-managed Adressräumen ausgeführt.

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^[5] 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^[6] 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 Standardinstallation so konfiguriert, dass er startet, wenn das Betriebssystem gestartet wird. Der DAS speichert ab der Version 8 seine Parameter nicht mehr in Konfigurationsdateien, 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 Datenbankverzeichnis 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 Datenbankverzeichnis. Jede Instanz hat ihr eigenes Datenbankverzeichnis, 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 Datenbankverzeichnis ein. Es können auch entfernte Datenbanken eingetragen werden, wenn sie auf einem Knoten liegen, der im Knotenverzeichnis katalogisiert ist. Das Datenbankverzeichnis und das Knotenverzeichnis 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 Rechnerknoten. 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 müssen, sondern auf einem zentralen LDAP-Server abgelegt sein können. 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 Tablespaces, der angibt, dass die Verwaltung des Tablespaces vom Betriebssystem durchgefü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 Formatierungsbefehle. 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 kostenloser Download angeboten. Voraussetzung für die Nutzung ist allerdings die Installation von 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 PL/SQL- 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ächstgröß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 Rechnerknoten installiert wird, dann muss eine Datenbankpartitionierung eingesetzt werden. Das bedeutet, dass auf jedem Rechnerknoten eine (oder auch mehrere) Datenbankpartition eingerichtet wird. Ein einzelnes DBMS kann auf maximal 512 Rechnerknoten installiert werden.

Um die maximale Hardware-Leistung für ein DBMS zur Verfügung zu stellen, können für die einzelnen Rechnerknoten 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 die Zugriffsperformance durch Parallelverarbeitung zu erhöhen. Eines dieser Konzepte ist die Partitionierung.^[7]

Datenbankpartitionierung

Datenbankpartitionierung gibt es nur für DB2 LUW. Es muss eingesetzt werden, wenn eine DB2-Instanz auf mehreren Rechnerknoten installiert wird. Auf jedem Rechnerknoten muss mindestens eine Datenbankpartition eingerichtet werden. Es kann auch eingesetzt werden, wenn die DB2-Instanz auf nur einem Rechnerknoten installiert ist. Bei einer Installation auf einem Rechnerknoten lohnt sich die Datenbankpartitionierung vor allem dann, wenn auf diesem mehrere Festplatten installiert sind. Auf jeder Festplatte kann eine eigene Datenbankpartition eingerichtet werden. Auf diese Weise kann eine gleichmäßige Verteilung der Daten auf mehrere Festplatten erreicht 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 Partitionsgruppen g1, g2, - g6 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 Rechnerknoten verteilt werden.

Die Verteilung erfolgt implizit durch Generierung eines Partitionsschlüssels mittels eines Hash-Algorithmus. Das System wählt selbst 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 steht sie ebenfalls ab der Version 8 zur Verfügung.

In der englischen Literatur werden dafür die Begriffe ‚table-controlled partitioned', ‚table partitioned‘ oder auch ‚data partitioned‘ 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))
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 Indices, 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 Indices einer partitionierten Tabelle ebenfalls partitioniert sind, dann wird dadurch eine völlige Unabhängigkeit der einzelnen Tabellenpartitionen hergestellt. Eindeutige (UNIQUE) Indices können allerdings nur dann partitioniert werden, wenn sie alle partitionierenden Spalten enthalten; dies muss bei der Wahl des primary key berücksichtigt werden. Es kann dann 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 ‚index partitioned‘ 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. Bei der Indexdefinition wird der Verteilschlüssel festgelegt, nach dem die Daten auf die einzelnen Partitionen aufgeteilt werden. Dieser Index bestimmt gleichzeitig die Sortierreihenfolge (Cluster-Order) der Daten und er wird selbst nach dem gleichen Verteilschlüssel partitioniert gespeichert.

Beispiel:

CREATE tablespace ts1
numparts 5
IN db01;
 
CREATE TABLE t1
( ID INTEGER NOT NULL,
  verkaufsdatum DATE NOT NULL,
  umsatz DECIMAL(11,2),
  PRIMARY KEY(ID) )
   IN db01.ts1;
 
CREATE 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 Partitionierungsschlüssel und die Cluster-Reihenfolge untrennbar miteinander verbunden. Bei der Tabellenpartitionierung können diese Elemente unabhängig voneinander bestimmt werden.

Index-Typen

Indices können in DB2 z/OS sowie in DB2 LUW ab Version 9.7 partitioniert werden. In DB2 LUW bis und mit V9.5 ist die Partitionierung von Indices nicht möglich. Die nachfolgenden Ausführungen über Indexpartitionierung beziehen sich also auf DB2 z/OS und DB2 LUW ab 9.7.

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 Indexpartitionierung einer Tabelle konnte nur der Cluster-Index partitioniert werden. Das ist der Typ *1. Indices vom Typ *1 können natürlich in der aktuellen Version auch erstellt werden.

Wenn zu einer partitionierten Tabelle weitere Secondary Indices erstellt werden sollten, dann konnten diese 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 non-partitioned index. Damit wird unterschieden, ob der Index selbst 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 Indexstruktur. 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 Indexspalten 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 Indexspalten nicht mit den Spalten übereinstimmen, die die Partitionierung der Tabelle ausmachen. Ein DPSI kann nicht UNIQUE definiert werden. Das liegt daran, dass ein bestimmter Indexschlüssel in jeder Partition vorkommen kann, also in jeder Indexstruktur vorkommen kann. Die Eindeutigkeit eines Schlüssels könnte nur durch einen Zugriff auf die Indexstrukturen 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 selbst partitioniert ist, dann handelt es sich um physische Indexpartitionen, da jede Indexpartition auch tatsächlich in einer (oder mehreren) separaten Datei(en) gespeichert wird. 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 Indexstruktur.

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 Partitionierungskriterien ü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 VARCHAR-Daten nur in der Länge, in der sie auch tatsächlich vorliegen. Hier wird die Längeninformation mitgespeichert. Bis zur DB2 z/OS V7 konnten VARCHAR-Datenfelder im Index nur padded gespeichert werden. Seit der Version 8 gibt es diese Wahlmöglichkeit.
• 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 sequentiell durchgelesen werden konnten. Seit der DB2 z/OS V8 können die Leaf-Pages eines Index in beiden Richtungen sequenziell 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 PostgreSQL PL/pgSQL, allerdings werden beispielsweise ROWTYPES, einfach strukturierte Tabellen nicht unterstützt.

Wie Oracle und PostgreSQL bietet auch DB2 die Möglichkeit weitere Sprachen datenbankseitig in gespeicherten Prozeduren (stored procedures) zu nutzen, DB2 bietet hier C++ und Java an.

Utilities

Statistiken

RUNSTATS ist ein Utility zur Erzeugung von statistischen Daten über die Inhalte von DB2-Tabellen und deren Indices. 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, Indices, 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 Indexzugriffe 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 Indices 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 Indices 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'
//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 Indices 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

Reorganisation

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 ist ein Utility zur Reorganisation von DB2-Tabellen bzw. Indices (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 Indices 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 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'
//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.

Indexüberprüfung

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. Das Utility protokolliert allerdings nur inkonsistente Zustände, beseitigt sie aber nicht und setzt auch keinen pending-status.

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) 
//SYSIN DD * 
  CHECK INDEX (ALL) TABLESPACE DSN8D81A.DSN8S81E 
//*

Indexneubau

REBUILD INDEX muss nach einem Point-in-time Recovery für alle Tablespaces ausgeführt werden, sofern der Index nicht ebenfalls mit Imagecopy gesichert wird. In diesem Fall könnte statt dessen auch ein RECOVER INDEX auf den gleichen Zeitpunkt stattfinden.

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

//STEP1 EXEC DSNUPROC,UID=’IUIQU1UQ.RBLD’, 
// UTPROC=’’,
// SYSTEM=’DSN’ 
//SYSUT1 DD DSN=&SYSUT1,DISP=(,DELETE), 
// UNIT=SYSDA,SPACE=(8000,(200,20),,,ROUND) 
//SYSIN DD * 
  REBUILD INDEX (ALL) TABLESPACE DSN8D81A.DSN8S81E 
//*

Hier werden vom Tablespace DSN8S81E der Database DSN8D81A alle Indices neu aufgebaut.

Integritätstest

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. Optional können fehlerhafte Daten aus den Tablespaces gelöscht und in Fehlertabellen (exception tables) übertragen werden. 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. Verschlüsselte Tabellen können mit diesem Utility nicht geprüft werden, 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 Tablespaces ausgeführt werden, bei denen 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 eines gestarteten DB2-Utilitys 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 Utilitys. 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.^[8]

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 Elementen eines XML-Dokuments liegt Ende 2008 weiterhin keine Standarddefinition vor, weshalb auch DB2 nur das Update von ganzen XML-Dokumenten erlaubt.^[9]

OLAP-Extender

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

• RANK
• DENSE_RANK
• ROW_NUMBER

Geschichte

^[10] 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 wurde 1983 als Datenbanksystem für MVS herausgebracht und war damit (nach Oracle-Markteinführung bereits im Jahr 1977) das zweite verfügbare relationale DBMS am Markt.

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

Zwischenzeitlich existieren DB2-Produkte auf unterschiedlichen Systemplattformen 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.

Im April 2009 schlossen EnterpriseDB und IBM einen Vertrag um Oracle Kompatibilität für das DB2 auf Basis einer EnterpriseDB Technologie verfügbar zu machen.^[11]

Geschichte (DB2 z/OS)

1983 wurde DB2 als Datenbanksystem für das Mainframe Betriebssystem MVS herausgebracht.

^[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, wurden Programme, die auf andere Partitionen zugriffen, in Mitleidenschaft gezogen. Erst in der Version 4 wurde dieses Problem behoben durch die Einführung des Indextyps 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 embedded 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 Isolationslevel kann bei einem einzelnen SQL-Statement festgelegt werden abweichend von dem Isolationslevel, den das ganze Programm (Package) hat.
• der Isolationslevel Dirty Read wird unterstützt
• Sperren einzelner Datenzeilen möglich. Bisher war nur ein Sperren von Datenpages (mindestens 4 kB) möglich.
• Sperren von Indexeinträ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 einander 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 Textdokumente 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 Scroll-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 Arbeitsspeicherbereiche 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 Tabellenspalten ä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 Scroll Cursor. Erweiterung des Static Scroll 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 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 Indexstrukturen und der Trigger
• Versteckter Last-Change-Timestamp erleichtert die Realisierung des Optimistic Locking
• INSTEAD OF Trigger
• Maximale Größe einer Tabelle: 128 TB. Maximale Anzahl von Partitionen für einen Tabellenraum: 4096

Version 10 (verfügbar seit Oktober 2010)

• XML-Funktionen, mit denen einzelne Knoten innerhalb eines XML-Datenfeldes geändert werden können (INSERT, REPLACE, DELETE)
• verbesserte Zugriffsperformance unter anderem durch verbesserte Parallel-Verarbeitung
• verschiedene administrative Arbeiten können nun während des laufenden Betriebes ausgeführt werden, die bisher eine Downtime erforderten.

Sonstiges

Neben DB2 bietet IBM mit Informix eine weitere kommerzielle Datenbank an. Nach dem Erwerb von Informix im Jahr 2001 gab es kurzzeitig den Plan, Informix mit DB2 zusammenzuführen, was eine gewisse Verunsicherung der Informix-Kunden auslöste. Dieser Plan wurde jedoch bald verworfen. Seitdem werden Informix und DB2 parallel weiterentwickelt und für unterschiedliche Einsatzbereiche positioniert. Allerdings wurden neue Technologien häufig in das jeweils andere System übernommen.

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

Einzelnachweise

1. ↑ Kooperation mit MySQL AB
2. ↑ ^{a b} 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. ↑ DB2 for z/OS – DB2 for z/OS Version 8 books
5. ↑ http://www-306.ibm.com/software/data/db2/udb/support/manualsNLVv9.html#de_main
6. ↑ IBM Redbooks
7. ↑ IBM DB2 Administration Guide Planning
8. ↑ SQL & XML Working Together
9. ↑ http://www.research.ibm.com/journal/sj/452/beyer.html
10. ↑ The Big Picture: IBM DB2 Information Management Software and DB2 Universal Database
11. ↑ Collaborate to Integrate Technology in New Version of DB2. Abgerufen am 27. September 2011 (englisch). 
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