Home 
ORDIX News 4/2007 Datenbanken
ORDIX News 4/2007 Datenbanken
ORDIX News 4/2007 Datenbanken
Funktionen der Datenbank DB2
UDB vertraut machen wollen.
Weiterführende Links
Automatisierung ist im DB2-Umfeld keine vollkommene Neuheit, da die ersten Funktionen aus diesem Bereich bereits mit der Version 8.2 eingeführt wurden. Dazu gehörten zum Beispiel:
Die Aktivierung dieser Funktionen wird über Konfigurationsparameter gesteuert (siehe Abbildung 1). Damit eine Funktion allerdings auch verwendet wird, müssen die jeweils übergeordneten, zentralen Parameter ebenfalls aktiv sein.
Das bedeutet zum Beispiel, dass die automatische Statistikerfassung nur aktiv ist, wenn neben dem Parameter AUTO_RUNSTATS auch die beiden Parameter AUTO_TBL_MAINT und AUTO_MAINT auf den Wert "ON" gesetzt wurden.
Die eigentliche Konfiguration muss dann teilweise noch anhand der Steuer- oder Diagnosezentrale vorgenommen werden.
Basierend auf den oben genannten Funktionen aus der Version 8.2 gibt es mit dem neuen Release nun einige Erweiterungen für die automatische Statistikerfassung von Tabellen und die automatische Reorganisation von Tabellen und Indizes. Daneben sind mit dem anpassungsfähigen Hauptspeicher, der automatischen Speicherung und den neuen möglichen Parameterwerten für Prefetcher und PageCleaner aber auch neue Funktionen hinzugekommen.
Statistiken einer Tabelle werden anhand eines Statistikprofils erfasst, das in älteren Versionen durch den Datenbankadministrator manuell erstellt werden musste. Aufgrund von Datenbankaktivitäten generiert DB2 ab der Version 8.2 dieses Profil automatisch. Dafür müssen die folgenden Parameter auf den Wert "ON" gesetzt werden:
Damit nun Tabellenstatistiken erfasst werden, muss der Befehl RUNSTATS ausgeführt werden. Ab der Version 8.2 kann dies ebenfalls automatisch erfolgen. Dazu dienen die folgenden Parameter:
Ab der Version 9.1 wird der Datenbank Konfigurationsparameter AUTO_RUNSTATS nun standardmäßig aktiviert. Je nach Bedarf des Datenbanksystems erfolgt die Statistikerfassung dann automatisch über einen Hintergrundprozess. Die automatische Aktivierung gilt allerdings nur für Datenbanken, die mit der Version 9.1 erstellt werden. Bei migrierten Datenbanken muss der Parameter zunächst manuell gesetzt werden.
Automatic maintenance (AUTO_MAINT) = ON
Automatic database backup (AUTO_DB_BACKUP) = OFF
Automatic table maintenance (AUTO_TBL_MAINT) = ON
Automatic runstats (AUTO_RUNSTATS) = ON
Automatic statistics profiling (AUTO_STATS_PROF) = OFF
Automatic profile updates (AUTO_PROF_UPD) = OFF
Automatic reorganization (AUTO_REORG) = OFF |
| Abb. 1: Parameter ab Version 8.2 mit neuen Default-Einstellungen ab Version 9.1. |
 |
| Abb. 2: Erweiterung der automatischen Reorganisation. (vergrößern) |
db2inst1@sles10:~> ps -ef | grep db2pclnr db2inst1 3693 3417 0 23:45 pts/0 00:00:00 db2pclnr |
| Abb. 3: Kontrolle der PageCleaner und Prefetcher. |
Im Laufe der Zeit kann eine Tabelle durch Löschen von Daten sehr stark fragmentiert werden. Dies wirkt sich letzten Endes auf die Performance von SQL-Abfragen und den Platzbedarf aus. Eine Reorganisation der betroffenen Tabelle ist dann notwendig.
Ab Version 8.2 kann auch dieses automatisiert werden. Die Parameter für die Aktivierung sind die Folgenden:
Mit der Version 9.1 sind neue Optionen implementiert worden:
Die eigentliche Konfiguration und Verwaltung der Offline-Reorganisationen erfolgt über die Steuer- oder Diagnosezentrale. Hier können dann zum Beispiel Angaben über Tabellen oder Wartungsfenster gemacht werden (siehe Abbildung 2).
Bei den PageCleanern (oftmals auch als I/O-Cleaner bezeichnet) und den Prefetchern handelt es sich unter Unix um Prozesse und unter Windows um Threads. Jede Datenbank besitzt ihre eigenen PageCleaner und Prefetcher, die gestartet werden, sobald die Datenbank aktiviert wird (also beim ersten Connect).
Prefetcher lesen Datenseiten bereits vorab von der Festplatte in den Bufferpool. PageCleaner hingegen sind dafür zuständig, die veränderten Seiten (dirty pages) aus dem Bufferpool zurück auf die Festplatte zu schreiben. Durch Optimierung der beiden Funktionen kann eine Performance-Verbesserung erreicht werden, da ja bekanntlich die beiden Vorgänge - von Festplatte lesen und auf Festplatte schreiben - die meiste Zeit in Anspruch nehmen.
Die Anzahl der zu startenden PageCleaner und Prefetcher werden über Konfigurationsparameter gesteuert:
Seit der Version 9.1 können diese beiden Parameter neben einem numerischen Wert auch den Wert AUTOMATIC annehmen. Bei neu erstellten Datenbanken unter 9.1 ist diese Einstellung der Standard. Ausschlaggebend sind dann andere Umgebungsmerkmale, anhand derer der Datenbankserver die optimale Anzahl von PageCleanern und Prefetchern ermittelt:
Unter Unix kann man die Anzahl gestarteter PageCleaner- oder Prefetcher-Prozesse an der Prozessliste ablesen (siehe Abbildung 3).
Bereits ab der Version 8.2 konnte man den Konfigurationsparameter DFT_PREFETCH_SZ auf den Wert AUTOMATIC setzen. Mit diesem wird die Anzahl der Seiten bestimmt, die während eines Lesevorgangs in den Bufferpool gelesen werden.
Mit der Version 9.1 ist in DB2 ein anpassungsfähiger Hauptspeicher eingeführt worden, der in der Lage ist, sich je nach Leistung und Bedarf selbst zu optimieren. Dies bezieht sich zum einen auf die Größe des Bufferpools und zum anderen auf die Werte von Konfigurationsparametern, die für die Zuordnung und Dimensionierung der Speicherbereiche zuständig sind.
Die Aktivierung der automatischen Anpassung der Bufferpoolgröße erfolgt mittels SQL. Ist dies beim Anlegen eines Bufferpools mit dem CREATE BUFFERPOOL-Statement noch nicht geschehen, so kann es nachträglich mit dem ALTER BUFFERPOOL-Statement erfolgen (siehe Abbildung 4).
Jede Datenbank besitzt ihre eigenen Konfigurationsparameter für die verwendeten Speicherbereiche. Diese können entweder, wie bei älteren Versionen, auf einen numerischen Wert gesetzt werden, oder ab der Version 9.1 den Wert AUTOMATIC annehmen. Es handelt sich um die folgenden Parameter:
create bufferpool mybuf size automatic alter bufferpool mybuf size automatic |
| Abb. 4: Automatische Bufferpoolgröße. |
Ist die Automatisierung aktiviert, erfolgt eine dynamische Verteilung des zur Verfügung stehenden Bereiches im Hauptspeicher auf die oben genannten Bereiche. Der gesamte Speicherbereich selbst wird über den Parameter DATABASE_MEMORY angegeben.
Unter AIX und Windows besitzt dieser Parameter noch eine Besonderheit. Dort kann er auf den Wert AUTOMATIC gesetzt werden. Dadurch wird die Größe des Speicherbereiches, den die Datenbanken benötigen, während der Laufzeit dynamisch berechnet. Zu Zeiten hoher Auslastung wird der Bereich automatisch vergrößert. Ist die hohe Auslastung vorbei, wird auch der Bereich im Hauptspeicher wieder verkleinert und die überflüssigen Ressourcen werden dem Betriebssystem zurückgegeben.
Neben einem numerischen Wert und dem Wert AUTOMATIC (Windows und AIX) kann der Parameter zusätzlich auf COMPUTED gesetzt werden. Dies bedeutet, dass der Datenbankserver beim Aktivieren der Datenbank eine Berechnung des Gesamtspeichers auf Basis der zu diesem Zeitpunkt aktuellen Werte durchführt.
Im Gegensatz zur festen Definition der Container eines Tablespaces über die Syntaxklauseln "MANAGED BY SYSTEM" oder "MANAGED BY DATABASE", werden die Container beim Einsatz von dynamischem Speicher vom Datenbankmanager angelegt und verwaltet. Anstelle der Container bzw. der Pfade der Container werden bei der Verwendung von dynamischem Speicher nur Speicherpfade bzw. Gruppen von Speicherpfaden definiert. Dahinter verbirgt sich nichts anderes als Verzeichnisse im Dateisystem.
Die Speicherpfade, die bei der Verwendung von dynamischem Speicher definiert werden können, sind der Datenbankpfad und der Speicherpfad. Im Datenbankpfad werden vom Datenbankmanager interne Verwaltungsinformationen für die Datenbank gespeichert. Im Speicherpfad werden die eigentlichen Daten (Tabelleninhalte und Indizes) gespeichert.
CREATE DATABASE MYDB Datenbank- und Speicherpfad = Standarddatenbankpfad |
| Abb. 5: Datenbank mit dynamischem Speicher ohne Angabe von Speicherpfaden. |
CREATE DATABASE MYDB4 ON /daten/pfad1 DBPATH ON /daten/pfad2 -> Datenbankpfad = /daten/pfad2 -> Speicherpfad = /daten/pfad1 |
| Abb. 6: Datenbank mit dynamischem Speicher mit Angabe eines Datenbankpfades und eines Speicherpfades. |
CREATE DATABASE MYDB3 ON /daten/pfad1, /daten/pfad2 -> Datenbankpfad = /daten/pfad1 -> Speicherpfad = /daten/pfad1, /daten/pfad2 |
| Abb. 7: Datenbank mit dynamischem Speicher mit Angabe eines Speicherpfades. |
Wird beim Anlegen einer Datenbank kein Pfad definiert, so wird für beide Bereiche der Standarddatenbankpfad (DBM CFG dftdbpath) verwendet (siehe Abbildung 5).
Bei der CREATE DATABASE Anweisung kann durch die Klausel ON ein alternativer Speicherpfad und durch die Klausel DBPATH ON ein alternativer Datenbankpfad definiert werden (siehe Abbildung 6).
Wird beim Anlegen der Datenbank nur der Speicherpfad mit der ON-Klausel definiert, so wird für den Datenbankpfad der erste Pfad des Speicherpfades verwendet (siehe Abbildung 7).
Ob eine Datenbank mit dynamischem Speicher arbeitet oder nicht, wird beim Anlegen der Datenbank festgelegt. Eine nachträgliche Änderung, sowohl das Einschalten als auch das Ausschalten, ist nicht mehr möglich. Ab der Version 9.1 ist die Verwendung von dynamischem Speicher beim Anlegen einer Datenbank Standard. Soll eine Datenbank ohne dynamischen Speicher angelegt werden, so ist beim Kommando CREATE DATABASE die Syntaxerweiterung AUTOMATIC STORAGE NO zu verwenden.
Da die Automatische Speicherung ein Thema ist, mit dem man sicher ganze Seiten füllen könnte, soll dies zunächst nur ein kleiner Vorgeschmack sein. In einer der nächsten ORDIX News Ausgaben wird sich ein Artikel ausschließlich mit der Automatischen Speicherung befassen und alle Funktionen aus diesem Bereich ausführlicher beschreiben.
Good to know
|
Die oben genannten Funktionen haben den Vorteil, dass wesentlich weniger Konfigurationsaufwand für eine Datenbank ensteht. Es muss nicht mehr manuell auf bestimmte Situationen reagiert werden. Der Datenbankserver nimmt dem Datenbankadministrator an dieser Stelle die Arbeit ab.
Allerdings könnte man darin die Gefahr sehen, dass dem Administrator das System sozusagen "aus den Händen gleitet". Er weiß nicht genau, was der DB-Server intern für Berechnungen durchführt, um Konfigurationen durchzuführen. Im schlimmsten Fall könnte es beispielsweise so sein, dass die Konfigurationen zwar für ein Szenario passen, für ein anderes allerdings vollkommen falsch sind.
Das ist aber ein Punkt, bei dem man mit Sicherheit individuell Arbeitsersparnis gegen Risiko abwägen muss.
Thorsten Schuhmacher (info@ordix.de).