IBM DB2
DB2 ist die kommerzielle relationale Datenbank der Firma IBM.
DB2 kann nahezu beliebige Datenmengen und Datentypen (Text, Töne, Bilder, Videos) speichern und verwalten. Zusammen mit Oracle und MS SQL-Server gehört DB2 zu den kommerziellen Systemen mit den größten Marktanteilen.
DB2 existiert in Versionen für Mainframes (zSeries) unter z/OS (vormals MVS) oder VSE, für Midrangesysteme (iSeries) unter OS/400 (hier / Besonderheit: als integraler Bestandteil des Betriebssystemes) sowie für Unix-und Windowsbasierte Systeme.
DB2 für Unix und Windows wird mit SQL-Befehlen in der Kommandozeile administriert oder graphisch über das Kontrollzentrum (db2cc). Die Administration auf Mainframes erfolgt in der Regel mittels Batchjobs, wobei unterschieden wird zwischen DB2 Utilities (RUNSTATS, COPY, REORG usw.) und DBA Jobs (SQL wird mittels DSNTIAD in einem TSO Backgroundjob durchgeführt). Kleinere Arbeiten werden oft auch am TSO Terminal mittels SPUFI unter ISPF durchgeführt. Um bei der Ausführung von integrierten DB-Zugriffen (Statisches SQL) eine optimale Performance zu erzielen, wird ein sog. Optimizer eingesetzt, ein Expertensystem welches bei der Programmvorbereitung den Zugriff auf die betreffenden Tabellen festlegt. Dies beruht auf den sog. Statistiken, die mittels o. a. Tool RUNSTATS periodisch aktualisiert werden.
Das so genannte DB2-EEE (sprich "triple I") ist für größere Unix- oder Windowsumgebungen, wobei die Datenbank-Partitionen über mehrere Rechner (Nodes) verteilt werden können. Größere Mainframeumgebungen verwenden DB2 Data Sharing, wobei die Funktionalität des Parallel Sysplex der zSeries-Rechner voll genutzt wird.
Der Datenzugriff der Anwendungsschicht erfolgt mit ANSI-SQL und kann daher aus vielen Programmiersprachen heraus erfolgen.
Link zu unseren DB2 Kursen: Content Management Kurse
- DB2 UDB for z/OS, Version 8
- DB2 UDB for Linux, UNIX and Windows, V8.2.2
- DB2 UDB for iSeries, Version 5 Release 3
- DB2 Server for VSE & VM, V7.4
RUNSTATS
RUNSTATS ist ein Utility zur Erzeugung von statistischen Daten über die Inhalte von DB2-Tabellen. 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 relationalen Tabellen, in denen DB2 Informationen über alle Objekte wie Tabellen, Indizes, Spalten usw. ablegt (self descriptive, also „selbstbeschreibend“).
Das DBMS benötigt 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 Zugriffwege abgelegt sind.
Das Tool kann für Tabellenbereiche (Tablespace) oder Indizes ausgeführt werden und kann auch im Rahmen anderer administrativer Utilities eingebettet laufen (REORG, LOAD).
REORG
REORG ist ein Utility zur Reorganisation von DB2-Tabellen (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-or-Page, Near-Of-Page) werden wieder an die bestmögliche Position verschoben.
Das Utility kann offline oder online arbeiten. Bei der Offline-Variante werden die Daten dem Clustering-Index entsprechend sortiert und in temporäre Dateien gespeichert. Der Tablespace wird dann neu angelegt und die Daten werden – nun sortiert – wieder in den Tabellenbereich eingetragen. Anschließend werden alle Indizes neu aufgebaut.
Bei der Online-Variante wird ein neuer Tablespace („Schattenkopie“) angelegt und die Daten werden sukzessive in den neuen Bereich sortiert übertragen. Zwischenzeitliche Änderungen werden anschließend aus dem Recovery-Log eingearbeitet, wobei eine Arbeitstabelle (Mappingtable) der Zuordnung von alten zu neuen internen Satzschlüsseln (Record Identifiers) dient. Sind alle Änderungen berücksichtigt, findet ein „Switch“ statt, nach dem die DB2 fortan auf den neuen Tabellenbereich zugreift. Der alte Bereich wird verworfen.
Zusätzlich zum Reorganisieren können Sicherungskopien (COPY) und statistische Daten (RUNSTATS) ermittelt werden.
