DB2

aus Wikipedia, der freien Enzyklopädie

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

[Bearbeiten] Eigenschaften

Das Datenbankmanagementsystem DB2 wird von IBM für verschiedene Betriebssystem-Plattformen vertrieben.

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

Eine andere Produktlinie wurde ursprünglich für das Betriebssystem OS/2 entwickelt. Diese Software ist in der Programmiersprache C geschrieben und wurde weiterentwickelt für die Betriebssysteme Linux, Unix und Windows (LUW).

Eine weitere Produktlinie ist eine in das Betriebssystem IBM i integrierte Version für IBM-Midrangesysteme (heutige Maschinenbezeichnung System i).

Die vierte Produktlinie betrifft die Betriebssysteme VSE und VM. Für diese Produktlinie gibt es zwar noch Support, aber keine Weiterentwicklung mehr. IBM möchte die Kunden dieser Produktlinie dazu bewegen, auf dem Rechner Linux zu installieren, damit das DB2 für Linux, Unix, Windows verwendet werden kann.

Aktuell sind die Versionen:

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

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

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

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

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

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

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

[Bearbeiten] Eigenschaften (DB2 LUW)

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

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

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

[Bearbeiten] Komponenten

[Bearbeiten] Komponenten (DB2 z/OS)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Bearbeiten] Komponenten (DB2 LUW)

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

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

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

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

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

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

• DB2 Connect siehe DB2 CAE.

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

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

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

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

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

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

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

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

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

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

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

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

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

[Bearbeiten] Tools

[Bearbeiten] Tools (DB2 z/OS)

• Visual Explain: Tool zur Anzeige des Zugriffspfades einzelner SQL-Statements. Visual Explain läuft unter Windows und wird von der IBM als kostenlosesr Download angeboten. Voraussetzung für die Nutzung ist allerdings die Installation des DB2-Connect.
• Workload Manager: Komponente, die für die Arbeit auf einem z/OS den Zugang zu den Betriebsmitteln steuert.
• SPUFI: Programm zur Ausführung von SQL-Statements
• QMF: Programm zur Ausführung von SQL-Statements. QMF besitzt zusätzlich einige Formatierungs-Befehle. Es ist ein komplettes Re-Design für die QMF-Software angekündigt. Die Software soll zukünftig ein Client-Tool mit einer graphischen Benutzeroberfläche sein.
• DB2 Connect: Datenbank-Programmierschnittstelle, die einem Client den Zugriff auf einen Datenbank-Server ermöglicht
• Performance Estimator: Werkzeug zur Abschätzung der Leistung von SQL-Statements.
• File-AID for DB2: Frontend unter ISPF für den konfortablen Zugriff auf die Datenbank. Mit Tools zum Anlegen, Löschen, Sichern, Laden von Tabellen, Tablespaces und Daten.

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

[Bearbeiten] Skalierbarkeit (DB2 LUW)

Das DBMS kann auf unterschiedlichen Hardware-Konfigurationen installiert werden.

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

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

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

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

[Bearbeiten] Partitionierung

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

[Bearbeiten] Datenbankpartitionierung

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

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

Beispiel:

Es gibt die Datenbankpartitionen p1, p2, … p9

Es werden die folgenden Partitionsgruppen eingerichtet:

g1 = ( p1 )

g2 = ( p2 )

g3 = ( p3, p4, p5 )

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

g5 = ( p6, p7, p8, p9 )

g6 = ( p9 )

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

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

[Bearbeiten] Tabellenpartitionierung

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

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

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

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

Beispiel 1:

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

ts1 bis ts5 sind die bereits vorhandenen Tabellenbereiche.

Beispiel 2:

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

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

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

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

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

[Bearbeiten] Indexpartitionierung

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

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

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

Beispiel:

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

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

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

[Bearbeiten] Index-Typen

Durch die Einführung der Tabellenpartitionierung der DB2 z/OS V8 sind vielfältige Gestaltungsmöglichkeiten für das Index-Design entstanden. In der DB2 LUW V9 können Indices noch nicht partitioniert werden. 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

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

Weitere secondary Indices konnten in früheren Versionen nur als *2 oder *3 erstellt werden. Sie konnten aber nicht partitioniert sein. Die Verwendung eines DPSI ist erst in der DB2 z/OS V8 möglich.

• Partitioned / Nonpartitioned. Auf deutsch: partitioniert / nicht partitioniert. Die Abkürzung NPI steht für nonpartitioned Index. Damit wird unterschieden, ob der Index selber in mehreren Partitionen gespeichert wird oder ob er als eine einzige zusammenhängende Struktur gespeichert wird. Ein nicht partitionierter Index kann in einem einzigen Dataset gespeichert werden. Wenn ein Index partitioniert ist, dann existiert für jede Partition eine eigene Index-Struktur.

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

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

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

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

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

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

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

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

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

[Bearbeiten] SQL PL

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

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

[Bearbeiten] Utilities

[Bearbeiten] RUNSTATS

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

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

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

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

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

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

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

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

Unter Unix könnte ein Kommando so aussehen:

RUNSTATS ON TABLE beispielschema.beispieltabelle 
WITH DISTRIBUTION AND DETAILED INDEX

[Bearbeiten] REORGCHK

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

[Bearbeiten] REORG

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

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

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

Zusätzlich zum Reorganisieren können Sicherungskopien