Db2

Dieser Artikel beschreibt ein Datenbankmanagementsystem von IBM. Zum Sportwagen siehe Aston Martin DB2.

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

Db2
Basisdaten
Entwickler	IBM
Erscheinungsjahr	1983
Aktuelle Version	12 (z/OS: 25. Oktober 2013 / LUW: 12. April 2016)
Betriebssystem	IBM Mainframe (z/OS), Linux, Unix, Windows
Programmiersprache	C, C++, Assemblersprache
Kategorie	Datenbankmanagementsystem
Lizenz	proprietär
deutschsprachig	ja
Db2-Seite bei ibm.com

Eigenschaften

Das Datenbankmanagementsystem DataBase 2 (Db2) wird von IBM für verschiedene Plattformen vertrieben:

Seit der neuen Organisationsstruktur der rund 17.000 IBM Softwareprodukte, welche nach dem Verkauf der Social Produkte (IBM Notes, IBM Sametime, BigFix etc.) im Jahr 2019 an HCL eingeführt wurde, besteht die DB2 Produktfamilie aus 466 Artikeln. Diese gliedern sich in die Produktgruppen IBM Database 2, IBM Database Management, IBM Information Integration und PureData Sys Op Analytics. Die klassischen IBM-DB2-Produkte gehören zur IBM-Database-2-Familie. IBM Information Integration sind überwiegend Analysesoftware unter dem IBM InfoSphere Warehouse – die IBM Information Integration ist eine Einbindung in IBM InfoSphere. Die letzte Gruppe, IBM PureData, ist ebenfalls eine Datenanalyselösung, allerdings in Real-time für komplexe Abfragen auf große Datenvolumen und mit über 4,3 Mio. EUR auch das teuerste Produkt der IBM-DB2-Produktfamilie. Ein Standard IBM DB2 Enterprise Server wird nach PVU (Processor Value Units = Prozessorkernen) lizenziert und ist ab 872,00 EUR erhältlich.

Produktfamilie	Produktuntergruppe	Produktname
Db2	IBM Database 2	Data Mgt Busn Intelligence Offer
Db2	IBM Database 2	Data Studio
Db2	IBM Database 2	DB2
Db2	IBM Database 2	DB2 Connect
Db2	IBM Database 2	DB2 Enterprise Server Edition
Db2	IBM Database 2	DB2 Tools
Db2	IBM Database 2	DB2 Universal Database
Db2	IBM Database Management Other	InfoSphere Warehouse
Db2	IBM Information Integrator	IBM Information Integrator
Db2	PureData Sys Op Analytics	PureData Sys Op Analytics

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 zu einem Wechsel auf andere Plattformen.

Aktuell sind die Versionen:

• Db2 for z/OS, Version 12 (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 11.1
  • Db2 Data Warehouse Edition für AIX, Linux, Windows
  • Db2 Everyplace IBM hat die IBM DB2 Everyplace-Produkte vom Vertrieb zurückgezogen. Außerdem wurde das Ende der Unterstützung für den 30. April 2013 angekündigt.
• Db2 for i, Version 7 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).

Seit Februar 2006 gibt es eine kostenlose Community Edition 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. 4 GB Hauptspeicher (bzw. 8 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 kostenbasierter Anfrageoptimierer, welches bei der Programmvorbereitung den Zugriff auf die betreffenden Tabellen festlegt. Dies beruht unter anderem auf den sogenannten Tabellenstatistiken, die mit dem 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. 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)).

Die graphische Oberfläche wurde ab der Version 10.1 abgelöst. Stattdessen kann der IBM Data Server Manager benutzt werden.

Das sogenannte Db2-EEE (sprich „triple E“, oder „trippel-Ih“) – ab 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.

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 IBM die wichtigsten Manuals für Db2 V9 LUW in deutscher Sprache 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 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.

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.
• QMF: Programm zur Ausführung von SQL-Statements. QMF ist unter ISPF und Windows verfügbar.

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.

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 bis p9

Es werden die Partitionsgruppen g1 bis 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 ab 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 ab 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. Ab 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 secondary 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 ab 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. Ab 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 stattdessen 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.

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.

OLAP-Extender

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

• RANK
• DENSE_RANK
• ROW_NUMBER

Geschichte

Im Zuge der Entwicklung der relationalen Benutzerschnittstelle „Structured Query Language“ (SQL) wurde IBM-intern der erste Prototyp, das sogenannte System R entwickelt (1975–1979), das 1977 erstmals 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 1979) 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, Windows (XP/2000/2003)) und Db2 Universal Database (UDB) for iSeries (System i, 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 die Db2 auf Basis einer EnterpriseDB-Technologie verfügbar zu machen.

Geschichte (Db2 z/OS)

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

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

• Index Typ 2. Die Partitionierung gibt es zwar schon ab 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.

Version 11 (verfügbar seit Juni 2016)

• AI-Funktionen für verbesserte Leistung
• 4K Sektor-Support: Unterstützung von physikalische Laufwerke mit einer nativen Sektorgröße von 4 KB.
• Erweiterte Sicherheit durch eine hostbasierte Firewall
• Optimierte SQL Befehle (INSERT, UPDATE) für sehr große Datenmengen
• Neue Überwachungsfunktionen für SQL-Abfragefehler
• Automatische Kompression für Spaltentabellen (Optimierung der Kompressionsdaten beim Einfügen von neuen Daten)
• Verbesserter Treiber für das CLI (Call Level Interface)

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
• Distributed Relational Database Architecture (DRDA)

Weblinks

• Offizielle Startseite von IBM zu Db2
  • Db2 Comunity Edition (früher Express-C) – kostenlose Version von Db2 für Linux und Windows (Registrierung erforderlich)
  • DB2 11.5
  • DB2 11.1
  • DB2 for linux UNIX and Windows 10.5.0
  • DB2 for linux UNIX and Windows 10.1.0
  • DB2 for linux UNIX and Windows 9.7.0
  • (Memento vom 26. Mai 2016 im Internet Archive) In: ibm.com, 19. November 2008 (englisch; Dokumentation)
  • (Memento vom 25. August 2013 im Internet Archive)
  • (Memento vom 17. Januar 2008 im Internet Archive) In: ibm.com, (englisch; Einstieg in Db2 Express-C 9.5)
  • Startseite von IBM zu Db2 z/OS
    • DB2 for z/OS 12.0
    • DB2 for z/OS 11.0
• Graeme Birchall: Db2 SQL Cookbook
• Berni Schiefer, Manager bei IBM, im Interview zur Weiterentwicklung von Db2
• Vortrag zu Weiterentwicklung von Db2 Datenbanktage

Einzelnachweise

1. IBM Db2 Systemeigenschaften. Abgerufen am 13. April 2019. 
2. IBM DB2 Produktübersicht. IBM Business Partner, 8. Dezember 2020, abgerufen am 2. Januar 2021. 
3. IBM Db2 12 for z/OS – Overview – United States. 30. September 2019, abgerufen am 30. September 2019 (amerikanisches Englisch). 
4. Express-C (kostenlose Version)
5. Graig S. Mullins: DB2 Developer’s Guide. 2004, S. 722.
6. (Memento vom 14. Oktober 2007 im Internet Archive) In: ibm.com.
7. 6.3.3.2 DB2 UDB for z/OS V8 Application Programming and SQL Guide. IBM Library Server
8. (Memento vom 27. Januar 2007 im Internet Archive) In: ibm.com.
9. ibm.com
10. IBM Redbooks
11. IBM DB2 Administration Guide Planning
12. SQL & XML Working Together
13. (Memento vom 16. Februar 2008 im Internet Archive) In: research.ibm.com.
14. The Big Picture: IBM DB2 Information Management Software and DB2 Universal Database
15. Collaborate to Integrate Technology in New Version of DB2. Abgerufen am 27. September 2011 (englisch). 
16. 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