IBM Knowledge Center

Das Knowledge Center ist die erste Anlaufstelle bei allen sich stellenden Fragen rund um die DB2 LUW. Hier sind alle Befehle, Konzepte und APIs detailliert beschrieben. Die jeweils aktuelle Version der vom IBM Knowledge Center ist über das Internet unter folgendem Link erreichbar: http://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.kc.doc/welcome.html
Dieses Dokument kann nur Hinweise auf die wichtigsten Funktionen von DB2 liefern. Für detaillierte Informationen muss in jedem Fall das IBM Knowledge Center herangezogen werden.

DB2 Sicherheit

Die höchste Berechtigung die ein Benutzer erhalten kann ist SYSADM. In einer Windows Umgebung sind standardmäßig alle Benutzer der lokalen Administratorengruppe mit der Berechtigung SYSADM ausgestattet. Die Gruppen DB2ADMNS und DB2USERS dienen der erweiterten Sicherheit auf Betriebssystemebene und werden in keiner Weise den DB2 Berechtigungsstufen zugeordnet. Über den DBM Parameter SYSADM_GROUP kann aber eine lokale Gruppe ausgewählt werden, die über SYSADM Rechte verfügen soll. Wenn der Parameter gesetzt wird sollte die DB2ADMNS Gruppe ausgewählt werden. Der Standardwert ist NULL und besagt, dass die Administratorengruppe SYSADM Rechte besitzt.
In der DB2 10.5 hat ein SYSADM nicht automatisch die DBADM Berechtigung für vorhandene Datenbanken. Nur der SYSADM Benutzer der die Datenbank erstellt hat bekommt automatisch DBADM Rechte auf der Datenbank.
Die Rechtevergabe für die DB2 User ist Sache eines DB2 Administrators. Um mit oxaion Open arbeiten zu können müssen Berechtigungen auf Schema- , Tabellen-, View- und Paketebene gesetzt werden. Dies erfolgt automatisch über den DB Wizard während der Ausführung des Punktes „Berechtigungen erteilen" auf der Seite „DB Objekte erstellen".
Der User, der im oxaion open Applikationsserver als DB Benutzer fungiert, muss mit folgenden Berechtigungen ausgestattet werden:
Der hier verwendete Schemaname „OOPEN" muss durch den beim Kunden verwendeten ersetzt werden z. B. GMT430. Zwingend sind 3 große Buchstaben und 3 Ziffern für die GMT Versionsnummer.
Datenbank:Verbinden
Tabellen erstellen
Schema: OOPEN – alle
Tabelle: Alle Rechte für alle Tabellen im Schema OOPEN
Select für alle im Schema SYSIBM
Index: -
Sicht: SELECT und DELETE für alle im Schema OOPEN
SELECT für alle in SYSCAT
SELECT für alle in SYSIBM
TBSP:USEJOURNALSPACE
OOPEN_TBSP4-32
OPENTEMPSPACE
Funktion: EXECUTE OOPEN.GET_USER
EXECUTE OOPEN.GET_JOBINBR
EXECUTE OOPEN. RPAD
Prozedur:-
Methode:-
Paket: EXECUTE für alle in NULLID
Wenn ein User über Fremdanwendungen auf die Sichten im Schema SYSIBMADM zugreifen möchte ist SYSMON Berechtigung erforderlich.
DB2 Sicherheit ist ein äußerst umfangreiches Thema. Es empfiehlt sich die Lektüre des Kapitels „Sicherheit" unter „Grundlegende Informationen zu Datenbanken" im DB2 10.5 IBM Knowledge Center.

Die Kommandozeile (CLP)

Starten des CLP

Nach der Installation der DB2 LUW stehen 2 Befehlszeilentools über das Startmenu zur Verfügung. Sie lauten Befehlsfenster und Befehlszeilenprozessor.

Im Befehlsfenster muss jedem Befehl der Ausdruck db2 vorangestellt werden. Beispielsweise: db2 connect to oxopen
Das Befehlsfenster startet man unter Windows mit dem db2cmd Kommando. Unter Linux reicht die Anmeldung als Instanzeigner und kann dann mit jeder Konsole bzw. Terminal den db2 Befehl verwenden.
Gibt man im Befehlsfenster nur db2 ein steht man im Befehlszeilenprozessor. Das heißt man braucht für die Ausführung von CLP Befehlen, „db2 " nicht mehr voranstellen. Je nach Aufgabenstellung kann die eine oder die andere Variante günstiger sein. Beispielsweise sollten CLP Befehle eher im Befehlszeilenprozessor und Systembefehle bevorzugt im Befehlsfenster ausgeführt werden.
Unter Linux muss Im Falle einer CLP Befehlszeile (db2 …) mit Verwendung von einfachen Anführungszeichen zumindest dieser Parameter zusätzlich, über doppelte Anführungszeichen, vor der Interpretation durch die Shell geschützt werden.
Systembefehle wie z.B. db2advis können im Befehlszeilenprozessor nicht ausgeführt werden.

Wichtige CLP Befehle

Dies sind nur die wichtigsten CLP Befehle. Eine Auflistung aller Befehle mit detaillierter Beschreibung findet sich in der 2.1 IBM Knowledge Center im Kapitel:
Datenbankreferenz-> Commands -> Command line processor (CLP) -> CLP commands.
Url: https://www.ibm.com/support/knowledgecenter/de/SSEPGG_10.5.0/com.ibm.db2.luw.admin.cmd.doc/com.ibm.db2.luw.admin.cmd.doc-gentopic3.html?pos=2

Wichtige Systembefehle

Arbeiten mit Befehlsskripten

Ein Befehlsskript enthält eine Aneinanderreihung von CLP Befehlen. Das Skript kann über den Befehlszeilenprozessor mit Hilfe des folgenden Kommandos ausgeführt werden:
db2 –tvf <Pfad zum Skript.ddl>
Bei diesem Kommando müssen die CLP Befehle innerhalb des Skripts mit Semikolons getrennt sein.
Unter Windows muss noch die DB2 spezifische Eingabeauforderung gestartet werden. Um den kompletten Aufruf zu automatisieren lautet die Kommandozeile:
"%DB2_INSTALL_PATH%\BIN\db2cmd.exe" -c -w -i db2 -tvf "%DDL_SCRIPT%"
Wobei %DB2_INSTALL_PATH% mit dem Installationsverzeichnis z.B.: "C:\Program Files\ibm\SQLLIB" ersetzt werden muss. Das Installationsverzeichnis wurde bei der Installation in der Maske „Zu installierende Sprachen" angegeben (siehe Kapitel 1.2.1.6). Die Zeichenkette %DDL_SCRIPT% muss durch den Pfad zur Skriptdatei ersetzt werden.
Eine solche Aufrufmöglichkeit ist z.B. wichtig, wenn ein Skript über die Aufgabenplanung aufgerufen werden soll.
Das Kommando db2cmd ist für die als letztes installierte DB2 Version mit dem aktiviertem Kennzeichen „Als standardmäßige DB2-Kopie auf diesem Computer festlegen" (siehe Kapitel 1.2.1.8 „Namen der DB2 Kopie") auch direkt, ohne Angabe eines Pfades, aufrufbar.

DBM Parameter

Die Parameter des Datenbank Managers (=der DB2 Instanz) werden mit dem CLP Befehl GET DBM CFG abgerufen. Änderungen erfolgen mit dem Befehl UPDATE DBM CFG USING parameterName neuerWert.

Registrierdatenbank- und Umgebungsvariablen von DB2

Die DB2-Produkte stellen eine Reihe von Registrierdatenbankvariablen und Umgebungsvariablen bereit, die Sie kennen sollten, um DB2 betriebsbereit zu machen.
Zum Anzeigen einer Liste aller unterstützten Registrierdatenbankvariablen führen Sie den folgenden Befehl aus:
db2set –lr
Zum Anzeigen der der explizit gesetzten Registrierdatenbankvariablen verwenden sie den Befehl ohne Parameter:
db2set
Sie müssen Werte für Registrierdatenbankvariablen definieren, die Sie aktualisieren wollen, bevor Sie den Befehl db2start ausführen.
Für eine oxaion open Datenbank werden standardmäßig die folgenden Umgebungsvariablen explizit gesetzt, wenn diese, wie im „Installationshandbuch oxaion open" beschrieben, mit dem DBWizard erstellt wurde.
Die Darstellung erfolgt zusammen mit dem Befehl mit dem diese gesetzt werden:
db2set DB2_EVALUNCOMMITTED=ON
db2set DB2_SKIPINSERTED=OFF
db2set DB2_SKIPDELETED=ON
db2set DB2LOCK_TO_RB=STATEMENT
db2set DB2_CAPTURE_LOCKTIMEOUT=ON
db2set DB2_PARALLEL_IO=*
Die Parameter DB2COMM, DB2INSTPROF werden schon bei der DB2 Installation gesetzt.
Insbesondere die Parameter DB2_EVALUNCOMMITTED=ON, DB2_SKIPINSERTED=OFF, DB2_SKIPDELETED=ON und DB2LOCK_TO_RB=STATEMENT sind sehr wichtig für den korrekten Betrieb von oxaion open. Der Parameter DB2_SKIPINSERTED=OFF greift in DB2 10.5 nur wenn der DB Parameter (siehe Kapitel 2.6) CUR_COMMIT nicht auf ON steht.

DB Parameter

Die Parameter der Datenbank werden mit dem CLP Befehl GET DB CFG abgerufen wenn bereits eine Verbindung zur Zieldatenbank besteht. Ansonsten muss die Klausel FOR [DBNAME] nachgestellt werden. Dies kann wichtig sein falls durch einen falsch gesetzten Parameter keine Verbindung zur Datenbank mehr möglich ist!!
Änderungen erfolgen mit dem Befehl UPDATE DB CFG USING parameterName neuer_Wert. Auch hier kann die FOR [DBNAME] Klausel verwendet werden.
Beispiel 1 (keine Verbindung)
db2 update db cfg for oxopen using auto_reorg on
Beispiel 2 (Verbindung kann erfolgreich aufgebaut werden)
db2 connect to oxopen
db2 update db cfg using auto_reorg off
Bei der Datenbank Erstellung über den DB Wizard werden über das CreateDatabase.ddl Skript auch folgende Parameter gesetzt. Die Darstellung erfolgt zusammen mit dem Befehl, mit dem diese gesetzt werden. Die Zeile endet jeweils erst mit dem Semikolon. Ein vorhandener Zeilenwechsel ist nur Anzeige bedingt.
db2 UPDATE DB CFG FOR OXOPEN USING logarchmeth1 OFF logarchmeth2 OFF logprimary 50 logsecond 200 logfilsiz 20000;
db2 UPDATE DB CFG FOR OXOPEN USING UTIL_HEAP_SZ 50000 IMMEDIATE;
db2 UPDATE DB CFG FOR OXOPEN USING SELF_TUNING_MEM ON IMMEDIATE;
db2 UPDATE DB CFG FOR OXOPEN USING LOCKTIMEOUT 30;
db2 UPDATE DB CFG FOR OXOPEN USING CUR_COMMIT AVAILABLE;
db2 UPDATE DB CFG FOR OXOPEN USING STMT_CONC LITERALS;
db2 UPDATE DB CFG FOR OXOPEN USING DFT_DEGREE ANY IMMEDIATE;
db2 UPDATE DB CFG FOR OXOPEN USING SORTHEAP 50000 automatic IMMEDIATE;
db2 UPDATE DB CFG FOR OXOPEN USING LOCKLIST 15000 automatic IMMEDIATE;
db2 UPDATE DB CFG FOR OXOPEN USING PCKCACHESZ 140000 automatic IMMEDIATE;
db2 UPDATE DB CFG FOR OXOPEN USING SHEAPTHRES_SHR 120000 automatic IMMEDIATE;
UPDATE DBM CFG USING SYSMON_GROUP DB2USERS;

Pufferpools

Die Pufferpools haben den wahrscheinlich größten Einfluss auf die Leistung der Datenbank. Ein Pufferpool ist ein Bereich im Hauptspeicher, der dem Datenbankmanager zum Zwischenspeichern von Tabellen- und Indexdaten beim Lesen von Daten vom Datenträger zugeordnet wurde. Jedem Tabellenbereich einer DB2-Datenbank muss ein Pufferpool mit der gleichen Seitengröße zugeordnet sein. In oxaion open werden pro GMT Tabellenbereiche mit den Seitengrößen 8 und 32 Kibibytes angelegt. Nach der Installation durch den DB Wizard existiert jeweils ein Pufferpool OPENSPACE'X' wobei 'X' für die jeweilige Seitengröße steht. Zu der Frage welchen Tabellenbereichen überhaupt DB-Tabellen zugeordnet sind siehe Kapitel 2.8 „Tabellenbereiche". Nur für die Pufferpools, bei denen die zugehörigen Tabellenbereiche Daten enthalten, macht es Sinn zusätzlich verfügbaren Arbeitsspeicher zuzuordnen.
Die Pufferpools haben initial ein automatisches Feintuning aktiviert. In einer Produktivumgebung sollten aber sinnvolle Ausgangswerte ermittelt und eingestellt werden. Auch der Konfigurationsadvisor (siehe Kapitel 2.10) kann hier nicht automatisch optimale Werte ermitteln. Im Idealfall sollte der maximal für die Datenbank verfügbare Hauptspeicher ausgenutzt werden.
Über das folgende SQL kann die aktuelle Anzahl der Seiten und die zugehörige Gesamtgröße ermittelt werden:

Den ausgegebenen Größenwert in Gibibytes können Sie zu der Zahl dazuzählen, die Sie aktuell im Betriebssystem als noch frei und für die Datenbank auch in Zukunft verfügbar identifiziert haben.
Achten dabei darauf, dass unter Linux der von der Datenbank benutzte pufferbezogene gemeinsame Arbeitsspeicher nicht wirklich als verwendeter Arbeitsspeicher angezeigt wird. Das folgende bash Skript wird in diesem Fall korrektere Werte ausgeben.

Um genauer festzustellen wie viel das Datenbanksystem für die Datenbank inkl. der Pufferpools aktuell an Arbeitsspeicher belegt, gibt es den Systembefehl (siehe Kapitel 2.3) „db2mtrk -d -v". Dieser gibt am Ende auch den gesamten verwendeten Arbeitsspeicher in Bytes aus. Mit der Option „-i" kann auch der vergleichsweise geringere von der Datenbankinstanz belegte Arbeitsspeicher angezeigt werden.
Falls die Anwendung auf dem gleichen Server läuft, berücksichtigen Sie auch eventuell parallel gestartete Entwicklungsumgebungen (IDE).
Falls unter Linux der übrige freie Speicher zu knapp bemessen war, und auch nicht ausreichend Swap Speicher zur Verfügung steht wird das Betriebssystem eventuell einen sogenannten „oom-killer" aktivieren, der den größten Memory Nutzer einfach beendet. Leider wird das Opfer dann wahrscheinlich die Datenbank sein. Es gibt allerdings auch die Möglichkeit den Linux Kernel so zu konfigurieren, dass nur ein bestimmter maximaler virtuelle Speicher zur Verfügung steht, so das eher keine neue Prozesse mehr gestartet werden können bzw. diese keinen Arbeitsspeicher reservieren können, als das während dem Betrieb irgend ein Prozess, mit viel reserviertem Arbeitsspeicher, beendet wird.
Ausgehend von der ermittelten Zielgröße in Gibibytes können Sie nun eine neue Seitenanzahl festlegen:
Beispiel Zielgröße=20 Gibibyte (hier mit GiB abgekürzt):
20GiB * 1024MiB/GiB * 1024KiB/MiB / 8KiB/Pages = 2621440
Der CLP Befehl zum Setzen der Größe des Pufferpools mit der Seitengröße von 8 Kibibytes lautet damit:

alter bufferpool openpool8 immediate size 2621440 automatic

Die Einstellungsänderung wird sofort aktiv. Und sollte über das obige SQL nachvollziehbar sein.

Tabellenbereiche

Ein Tabellenbereich ist eine Speicherstruktur, die Tabellen, Indizes, LOB-Daten und LONG-Daten enthält. Tabellenbereiche befinden sich in Datenbankpartitionsgruppen. Mit ihrer Hilfe können Sie die Speicherposition der Datenbank- und Tabellendaten direkt bestimmten Containern zuweisen. (Ein Container kann ein Verzeichnisname, Einheitenname oder Dateiname sein.) Die möglichen Vorzüge sind eine bessere Leistung und eine flexiblere Konfiguration.
Es gibt zwei Typen von Tabellenbereichen, die beide in einer einzelnen Datenbank verwendet werden können:

• Vom System verwaltete Bereiche (SMS - System Managed Space), bei denen der Dateimanager des Betriebssystems den Speicherbereich steuert
• Von der Datenbank verwaltete Bereiche (DMS - Database Managed Space), bei denen der Datenbankmanager den Speicherbereich steuert

Vorteile eines DMS-Tabellenbereichs:

• Die Größe eines Tabellenbereichs kann durch Hinzufügen oder Erweitern von Containern erhöht werden (mit der Anweisung ALTER TABLESPACE). Vorhandene Daten können auf die neue Gruppe von Containern verteilt werden, um die optimale E/A-Effizienz zu erhalten.
• Eine Tabelle kann nach dem Typ der zu speichernden Daten auf mehrere Tabellenbereiche verteilt werden:
• LF-Daten (LF = Long Field, Langfeld) und LOB-Daten (LOB = Large Object, großes Objekt)
• Indizes
• Reguläre Tabellendaten

Die Benennung der Tabellenbereiche erfolgt in der oxaion Open Datenbank nach folgender Konvention:
[SCHEMANAME]_TBSP[Seitengröße]
Beispiel: Für die Tabelle VKOPFP ist eine Seitengröße von 8k erforderlich. Befindet man sich im Schema GMT421 wird die Tabelle im Schema GMT421_TBSP8 gespeichert. Existiert ein Tabellenbereich noch nicht, wird er mit der Eigenschaft „automatische Verwaltung" von der Datenbankzugriffsschicht in oxaion open erzeugt. Anderenfalls wird er einfach verwendet.
So hat man die Möglichkeit zu steuern, ob automatisch verwaltete Tabellenbereiche (DMS) oder selbst definierte Tabellenbereiche(SMS) verwendet werden sollen. Der Vorteil automatisch verwalteter Tabellenbereiche besteht darin, dass der Verwaltungsaufwand gering ist. Der Administrator braucht sich nicht um die Vergrößerung von Containern kümmern, so lange Festplattenplatz zur Verfügung steht.
Die Größenbeschränkung der Tabellenbereiche ist in der folgende Tabelle zusammengefasst:(siehe auch SQL und XML Limits im IBM Knowledge Center: http://www.ibm.com/support/knowledgecenter/de/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001029.html)

Die Tabellenbereiche werden schon vom DB Wizard (siehe "Installationshandbuch oxaion open") während der erstmaligen Datenbanktabellenerzeugung angelegt, wobei jeweils ein Tabellenbereich mit der Seitengröße 8 und 32 Kibibytes angelegt wird. Aktuell (Zeitpunkt der Handbucherstellung) schafft es die DB2 10.5 Datenbank, dass alle „oxaion open" DB-Tabellen innerhalb des 8K Tabellenbereichs angelegt werden können. Trotzdem wird der 32K Tabellenbereich vorsorglich angelegt. Während des normalen Betriebes des Applikationsservers, welcher den Zugriff auf die Datenbank durchführt, ist es berechtigungstechnisch nicht vorgesehen, dass neue Tabellenbereiche automatisch angelegt werden.

Datenbank Erstellung

Um die oxaion open Datenbank inkl. der Auslieferungs-Daten zu erstellen, folgen Sie bitte den Anweisungen aus dem Installationshandbuch oxaion open.

Konfigurationsadvisor

Der Konfigurationsadvisor ist ein hilfreiches Werkzeug der DB2 Software um wichtige Parameter der Datenbank zu konfigurieren. Dieser kann mit dem DB Wizard auf der Seite „DB2 Konfiguration" über die Schaltfläche „DB2 Konfiguration" ausgeführt werden. Dabei kann gleichzeitig das Verzeichnis für die Diagnosedaten geändert werden.

Abbildung 1: DB Wizard/DB2 Konfiguration (Betriebssystem: Linux)

Verzeichnispfad für Diagnosedaten (diagpath)

Es handelt sich hierbei um einen Konfigurationsparameter des Datenbankmanagers. Gesetzt werden kann dieser Parameter, außer über den DB Wizard (siehe Kapitel: 2.10 „Konfigurationsadvisor"), mit dem folgenden CLP Befehl (über das Kommando db2 ausführen, siehe Kapitel 2.3 „Die Kommandozeile (CLP)"):
update dbm cfg using diagpath 'C:\diagpath'
Damit eine Änderung vollständig wirksam wird, muss die Instanz neugestartet werden.

Wartungsarbeiten

Tabellen- und Indexdaten defragmentieren (REORG)

Wir empfehlen nicht anlasslos Index oder Tabellen regelmäßig zu defragmentieren.
Bei der Defragmentierung können Datenbanksperren entstehen die den Betrieb signifikant stören. Demgegenüber bringt eine Defragmentierung nur in seltenen Fällen (Zugriffsarten) eine deutliche Performance Verbesserung. Mit einem folgendem CLP Kommando kann eine Defragmentierung aller Indexe einer DB-Tabelle durchgeführt werden (über das db2 Kommando ausführen, siehe Kapitel 2.3.1 „Starten des CLP"):
REORG INDEXES ALL FOR TABLE schemaname.tabellenname
Die Defragmentierung der DB-Tabelle ist mit dem folgenden CLP Kommando möglich:
REORG TABLE schemaname.tabellenname
Weiter Informationen über diese Befehle finden Sie in im IBM Knowledge Center (Kapitel 2.1) über den Suchbegriff „REORG INDEXES/TABLE".

Datenzugriff optimieren (RUNSTATS)

Über die hier abgebildete Maske des DB Wizards, kann die Statistikerstellung für alle DB-Tabellen eines Schemas, in einem Schritt ausgeführt werden. Achten Sie darauf, dass insbesondere die Schaltflächen „Tabellen erzeugen" oder „Daten importieren" das Potenzial haben vorhandene Daten komplett zu Löschen oder zu Verändern. Für die Statistikerstellung wird nur die Schaltfläche „Statistikerstellung" benötigt.

Bei dieser Statistikerstellung wird ein SQL Befehle für jede DB-Tabelle des angegebenen Schemas ausgeführt, der vergleichbar ist mit dem folgendem CLP Befehl (ausführbar über das db2 Kommando):
RUNSTATS ON TABLE schemaname.tabellenname ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL ALLOW WRITE ACCESS SET PROFILE
Ersetzen Sie dabei die Zeichenkette „schemaname.tabellenname" mit einem gültigen Tabellen namen inklusive Schema.

Datenbank sichern (BACKUP)

Grundsätzlich erfolgt die Erstellung von Backups durch ein CLP Skript. Das Backupziel kann auf dem DB Server selbst liegen. Allerdings sollte die erstellte Sicherungsdatei dann z.B. über die normale Dateisicherung des Servers, auf ein getrenntes Medium oder einen anderen Server gesichert werden.
Für weiterführende Informationen zu dem Thema siehe Kapitel 3.2 „Backups".

Protokollierung

Die Transaktionsprotokolle der DB2 Datenbank werden unter anderem, im Falle eines Crashs, für das konsistente Wiederanlaufen benötigt.
Nachdem über den DB Wizard die „oxopen" Datenbank erstellt worden ist, muss unbedingt die Protokollierungsart von Umlaufprotokollierung auf Archivprotokollierung umgestellt werden (siehe Kapitel 3.1 „Datenbankprotokollierung").
Ohne diesen Schritt können nach einem DB Absturz mehr Daten verloren gehen, da mit Umlaufprotokollierung keine aktualisierende Wiederherstellung möglich ist, also nur die letzte Offline Sicherung wiederhergestellt werden kann!
Außerdem können bis zum Aktivieren der Archivprotokollierung nur Offline Sicherungen gemacht werden. Das heißt die Datenbank kann während eines solchen Backups nicht verwendet werden.