Unfortunately this document is only available in GERMAN but will be translated to ENGLISH in the foreseeable future.
Aufgrund der unterschiedlichen Architektur (jede Datenbank besitzt ihre eigenen Logs, Bufferpools...) ermoeglicht DB2 im Gegensatz zu INFORMIX Backup und Recovery auf Datenbank-Ebene.
Es koennen auch einzelne Tablespaces gesichert und restauriert werden (Tablespace- Backup = INFORMIX: Dbspace-Backup). Fuer Tabellen trifft dies nur zu, wenn sie die einzigen Objekte in dem jeweiligen Tablespace sind, d.h. ein Backup/Recovery auf Tabellen-Ebene wird standardmaessig nicht von DB2 unterstuetzt. Der DBA ist also verpflichtet entsprechende Vorkehrungen zu treffen (Mapping Tablespace/Tabelle) um ein Recovery auf Tabellen-Ebene zu ermoeglichen (analog zu INFORMIX).
Beim Recovery von Daten unterscheidet man grundsaetzlich zwischen 3 Recovery-Methoden:
Das Crash-Recovery (INFORMIX: Fast-Recovery) sorgt fuer einen konsistenten Zustand der Datenbank nach einem Crash. Offene Transaktionen werden dabei zurueckgerollt.
Um ein autom. Crash Recovery zu ermoeglichen muss der DB-Config-Paramter AUTORESTART auf ON gesetzt sein. Der erste Connect einer Applikation an die DB (oder das activate database-Kommando) loesen dann implizit das Crash Recovery aus.
Ist AUTORESTART auf OFF gesetzt, muss der DBA manuell das Crash Recovery ausloesen:
- db2 "restart database <dbname>"
Mit Version Recovery ist das Zurueckspielen eines Backup-Images gemeint, um die DB in den Zustand zum Zeitpunkt dieses Backups zu setzen.
Es entspricht in etwas einem INFORMIX Whole-System-Restore), d.h. es werden keine Logs benoetigt um den Restore durchzufuehren. Als grosse Einschraenkung ist jedoch zu nennen, dass im Gegensatz zu INFORMIX ein Restore von Backup-Images ohne Logs nur moeglich ist, wenn das Backup offline stattgefunden hat .
Ermoeglicht das Zurueckspielen eines Backup-Images plus Logs. Die Datenbank oder auch ein einzelner Tablespace auf den Zeitpunkt unmittelbar vor dem Crash oder zu einem spezifischen Zeitpunkt (Point-In-Time) restauriert werden.
Rollforward Recovery ist nur in Verbindung mit Archival Logging erlaubt. Backups koennen bei dieser Methode auch online erstellt werden.
Wichtig ist, dass das letzte physikalische Backup nicht zu weit zurueckliegt, da sonst zu viele Logs zurueckgespielt werden muessen, was eine lange Recovery- Zeit zur Folge hat.
DB2 ermoeglicht 2 unterschiedliche Arten des Logging, das sog. Circular Logging und das Archival Logging (Log Retention Logging).
Diese Methoden diktieren auch die Backup- und Restore-Moeglichkeiten.
DB2 verwendent einen sog. Write-Ahead-Logging-Mechanismus. D.h., es wird sichergestellt, dass bevor eine modifizierte Page vom Bufferpool auf Platte geschrieben wird, der entsprechende Logbuffer-Eintrag bereits auf den Log auf Platte geflusht wurde.
Beim Insert/Delete wird der komplette Datensatz beim Update nur die veraenderten Spalten (Delta) geloggt. Erfolgt ein Commit durch die Applikation, werden die Log-Eintraege vom Buffer auf die Platte geflusht. Die Applikation erhaelt erst nach dem erfolgreichen Flush die Bestaetigung.
Log-Eintraege koennen auch ohne erfolgtes Commit bereits auf Platte geflusht (``externalized'') worden sein, z.B. wenn der Log-Buffer voll ist. Dies beeintraechtigt jedoch nicht die Integritaet der DB, da eine Transaktion erst als vollstaendig betrachtet wird, wenn der zuegehoerige Commit-Log-Record ebenfalls in den Log auf Platte geflusht wurde.
Geaenderte Pages im Bufferpool muessen aufgrund des angewandten Log-Ahead-Mechanismus nicht beim Commit auf Platte geflusht werden, d.h. sie verbleibem im Cache.
Die Logs werden beim Circular Logging wie ein Ringpuffer gehandhabt und regelmaessig ueberschrieben.
Die beiden DB-Config-File-Parameter LOGRETAIN und USEREXIT muessen beim Circular Logging auf NO stehen.
Bei dieser Methode kann kein Rollforward der DB erfolgen, d.h. es koennen keine Logical-Logs nachgefahren werden. Daraus ergibt sich wiederum, dass Backups nur im Offline-Zustand moeglich sind, da fuer Online-Backups zwingend ein Rollforward der Logs beim spaeteren Restore erfolgen muesste.
Circular Logging entspricht in etwa dem Verhalten von INFORMIX wenn LTAPEDEV auf /dev/null gesetzt wurde, jedoch mit dem Unterschied, dass unter INFORMIX durchaus auch Online-Backups bei dieser Konfiguration moeglich sind (Stichwort: Whole-System-Backup).
Es gibt die beiden Konfigurations-Paramter LOGPRIMARY und LOGSECONDARY. LOGPRIMARY ist die Anzahl der Logfiles, die direkt beim Anlegen einer Datenbank generiert werden.
Sollten die LOGPRIMARY-Logs bei einer Transaktion alle gefuellt werden, so werden - jedoch nur wenn die Logs in SMS-Tablespaces liegen - die konfigurierte Anzahl Logs (LOGSECONDARY) automatisch hinzugefuegt. Sollten sich die Transaktion auch ueber diese Logfiles erstrecken, so gibt es eine LOGFULL-CONDITION.
Sollten die LOGPRIMARY-Logs bei einer Transaktion alle gefuellt werden, so wird autom. ein neues Log allokiert. Dieser Vorgang wiederholt sich bei nachfolgenden Log-Switches bis die konfigurierte Anzahl sekundaerer Logs (DB-Config-File LOGSECONDARY erreicht wurde. Sollten die Transaktion dann immer noch nicht beendet sein, so wird eine eine LOGFULL-CONDITION ausgeloest.
Im Gegensatz zu INFORMIX (9.3) funktioniert das dynamische Allokieren von Logs jedoch nur, wenn sowohl die primaeren als auch die sekundaeren Logs in SMS-Tablespaces liegen. Fuer DMS-Tablespaces (raw devices) ist dieser Mechanismus nicht moeglich.
Das Auftreten einer LOGFULL-CONDITION wird im sog. db2diag.log vermerkt (Parameter DIAGPATH im DBM-Config-File):
db2diag.log: ------------
2001-08-28-20.21.23.633465 Instance:db2inst1 Node:000 PID:1066(db2agent (SAMPLE)) Appid:*LOCAL.db2inst1.010828181941 data_protection sqlpgrsp Probe:50 Database:SAMPLE
Log Full -- active log held by appl. handle 12 End this application by COMMIT, ROLLBACK or FORCE APPLICATION.
2001-08-28-20.21.23.692083 Instance:db2inst1 Node:000 PID:1066(db2agent (SAMPLE)) Appid:*LOCAL.db2inst1.010828181941 data_protection sqlpWriteLR Probe:80 Database:SAMPLE DIA3609C Log file was full.
ZRC=FFFFD509
Die Applikation erhaelt die folgende Fehlermeldung:
Perl/DBI-Beispiel: ------------------ DBD::DB2::st execute failed: [IBM][CLI Driver][DB2/LINUX] SQL0964C SQLSTATE=57011 The transaction log for the database is full.
Lesende Zugriffe durch weitere Prozesse sind noch moeglich. Alle schreibenden Zugriffe paralleler Transaktionen werden ebenfalls mit SQL-Fehler (SQL0964C) abgewiesen. Die Transaktion muss jetzt entweder durch ein rollback innerhalb der Applikation oder durch den Administrator mit Hilfe des folgenden Kommandos beendet werden:
Transaktions-Rollback ausloesen: -------------------------------- db2 "list applications show detail" db2 "force application (#app-id)"
Im Vergleich zu Informix ist anzumerken, dass durch das fehlende Konzept der LongTransaction-HighWater-Marks nicht nur eine Transaktion, sondern alle parallel laufenden Transaktionen von dem Problem betroffen sind. Sie alle erhalten den SQL-Fehlercode SQL0964C durch die LOGFULL-CONDITION. Dies laesst sich in etwa bei Informix mit dem Erreichen der LTXEHWM (LongTransaction Exclusive HighWater Mark) vergleichen, wobei jedoch bei INFORMIX die parallel schreibenden Transaktionen autom. blockiert werden.
Solange noch offene Transaktionen in einem Logfile sind, wird es auch nicht wiederverwendet. Erst wenn keine offene Transaktion mehr existiert, wird der Log zum Wiederbeschreiben freigegeben (analog zum Verhalten von INFORMIX).
Das Problem, dass ein Benutzer eine Transaktion beginnt (z.B. in Log 1) und sich anschl. in die Mittagspause verabschiedet (was zu einer LOGFULL- CONDITION fuehrt, da Log 1 aufgrund der offenen Transaktion nicht freigegeben werden kann), scheint bei DB2 durch Fehlen der LTXHWMs unzureichend geloest. Hier muss der DBA eingreifen und die Transaktion mit dem Befehl db2 ``force application (#app-id)'' manuell beenden.
Bei dieser Methode werden immer neue Logfiles erzeugt (mit eindeutigen Log-IDs). Ein Rollforward der Datenbank ist moeglich.
Archival Logging kann durch Setzen der folgenden Parameter im DB-Config-File aktiviert werden:
- db2 "update db cfg for <dbname> using logretain recovery" (Default: No) - db2 "update db cfg for <dbname> using userexit yes" (Default: No)
Nur einer der Parameter muss gesetzt sein, um Archival Logging einzuschalten. Das autom. Sichern der Logfiles erfolgt jedoch nur wenn USEREXIT auf YES gesetzt ist (L``<Userexit>''). Archival Logging wird erst beim Re-Start der DB aktiv. Die DB befindet sich im Backup Pending-Mode nach erfolgtem Re-Start und muss zuerst im offline- Mode gesichert werden, bevor ein Connect durch eine Applikation moeglich ist. Ob sich die DB im Backup Pending befindet kann wie folgt festgestellt werden:
- db2 "get db cfg for <dbname>" | grep -i "backup pending"
Archival Logging verhaelt sich analog zur Circular Logging. Solange noch offene Transaktionen in einem Logfile sind, kann dieses zwar ueber ein UserExit-Programm gesichert werden, wird aber vom DB2-Datenbankserver nicht freigegeben. Erst wenn die letzte offene Transaktion (die in diesem Log begonnen hat) abgeschlossen ist, wird der Log zum Wieder-Beschreiben freigegeben (entspricht dem Verhalten von INFORMIX).
Die DB-Config-Parameter LOGPRIMARY/LOGSECONDARY funktionieren beim Archival Logging genauso wie beim Circular Logging. Die automatische Nach-Allokation von Logs (LOGSECONDARY) kann - wie bereits oben erwaehnt - nur bei der Verwendung von SMS-Tablespaces fuer die Logs erfolgen. Werden die Logs in einem DMS-Tablespace abgelegt, ist der Parameter LOGSECONDARY obsolet.
Beim Deaktivieren der DB (wenn die letzte Applikation einen disconnect durchfuehrt oder ein deactivate database ausgefuehrt wird), wird autom. der offene Log geschlossen, d.h. es erfolgt ein Log-Switch. Dies kann bei grossen Logs und haeufigen DB-Deaktivierungen dazu fuehren, dass die Kapazitaet eines Logs nur unzureichend ausgenutzt wird (z.B. sind erst einige MB eines 100 MB-Logs benutzt und dann erfolgt der Log-Switch).
Ein manueller Log-Switch kann bei DB2 (ab V7.2) wie folgt durchgefuehrt werden:
db2 "archive log for db <dbname>"
Der DBA kann mittels des activate database-Kommandos dieses Verhalten massgeblich beeinflussen. Er sollte jedoch auch darauf achten, dass das Sichern der Logs nicht zu lange hinausgezoegert wird, da sonst bei einem Plattencrash die Transaktionen verloren sind, da die Logs noch nicht auf ein externes Medium kopiert wurden.
Man unterscheidet hier 3 Arten bzw. Zustaende von Logfiles:
Sie werden beim Crash Recovery benoetigt.
Sie werden als online bezeichnet, da sie noch nicht ausgelagert (gesichert) wurden.
Die Sicherung kann manuell oder ueber ein Userexit-Programm erfolgen.
Die Pagesize fuer Logical-Logs ist immer 4 KB. Ein Logical-Log kann max. ca. 65535 Pages gross sein, d.h ca. 256 MB. LOGPRIMARY+LOGSECONDARY duerfen zusammen nicht die Zahl 128 ueberschreiten, d.h. man koennte bei max. Log-Groesse (256 MB) ca. 32 GB an Logspace allokieren (128 Logs * 256 MB Logsize).
Legt man die Logs in ein DMS-Tablespace darf dieses Tablespace nur aus einem Container (RawDevice) bestehen. Aus dieser Limitierung ist andererseits ersichtlich, dass ein RawDevice groesser als 2 GB sein darf, sonst koennte man ja nur max. 2 GB an Logical-Log-Space allokieren.
Bei Informix kann man die Logical-Logs in unterschiedliche Dbspace legen (logdbs1, logdbs2....). Legt man die Logs dann abwechselnd im Round-Robin-Verfahren an (Log1 in logdbs1, Log2 in logdbs2, Log3 in logdbs1 usw.), hat man den Vorteil, dass das aktuelle Log wo gerade reingeschreiben wird und das zuvor abgeschlossene Log, welches jetzt gesichert wird, auf unterschiedlichen Platten liegen. Der I/O ist somit gleichmaessiger verteilt.
Bei DB2 ist dies aufgrund der obigen Einschraenkung (Log-Tablespace darf nur aus einem Container bestehen) nicht moeglich. Es empfiehlt sich diesen Container auf ein gestriptes Volume zu legen, um einen entsprechenden Durchsatz beim Schreiben der Logs zu erreichen.
Beim Anlegen einer neuen Datenbank werden automatisch 3 Logs (LOGPRIMARY) im Filesystem unter folgendem Verzeichnis-Pfad angelegt.
Annahme: DB2-Instance-Owner = B<db2inst1>: -------- - /home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/
Der obige Pfad kann ueber den informellen Parameter LOGPATH im DB-Config-File ermittelt werden.
Mit Hilfe der DB-Config-File-Parameter LOGPRIMARY, LOGFILSIZ und NEWLOGPATH koennen Anzahl, Groesse und Lokation der Logs geaendert werden:
Anzahl/Groesse aendern: ----------------------- db2 "update db cfg for dbname using logprimary 10" db2 "update db cfg for dbname using logfilsiz 10000"
Lokation aendern (Filesystem): ------------------------------ db2 "update db cfg for dbname using newlogpath '/home/db2inst1/mylogdir/'"
Lokation aendern (RawDevice): ----------------------------- db2 "update db cfg for dbname using newlogpath '/dev/rdevname'"
Die Aenderungen werden beim dem Neu-Start der DB wirksam. Die Aufloesung der alten und das Anlegen der neuen Logs erfolgt dabei automatisch durch DB2. Im Gegensatz zu INFORMIX ist kein manuelles Verschieben der Logs notwendig.
Nach erfolgter Aktivierung des neuen Logpfades durch den DB2 Datanbankserver sollte ein Backup der kompletten DB erfolgen, um die Komplexitaet eines Restores zu verringern.
Interessant sind noch 2 weitere DB-Config-Parameter:
Sollte jedoch mehr als eine Sekunde vergehen oder der Logbuffer voll sein, wird er autom. geflusht, ohne, dass MINCOMMIT erreicht wurde.
Das entspricht nicht 100% ganz dem INFORMIX-Buffered-Logging. Der Unterschied besteht darin, dass bei DB2 die Applikation nach Aufruf des Commits solange warten muss, bis der Commit auch tatsaechlich vom Logbuffer auf Platte geschrieben wurde. D.h. bei konfiguriertem MINCOMMIT, wartet eine Applikation im Extremfall eine Sekunde, bis der Logbuffer geflusht wird.
Man gibt hier die Anzahl von Logs als Prozentwert an, die max. in einem CrashRecovery-Fall nachzufahren sind. Durch die Angabe von SOFTMAX=200 wuerde man z.B. festlegen, dass beim CrashRecovery ca. 2 Logs nachgefahren werden muessen.
Um dies zu gewaehrleisten, fuehrt der DB2-Server sog. SoftCheckpoints durch. Die PageCleaner-Prozesse schreiben dazu in regelmaessigen Abstaenden die Pages aus dem Bufferpool auf Platte, die aus Transaktionen resultieren, die laenger als 2 Logs zurueckliegen (obiges Beispiel).
Wie bereits erwaehnt kann ein Backup auf DB- oder Tablespace-Ebene erfolgen. Um ein Backup durchzufuehren muss man SYSADM-, SYSCTRL- oder zumindest SYSMAINT- Authoritaet besitzen und der DB2 Datenbankserer muss gestartet sein (db2start).
Die zu sichernde DB kann sowohl lokal als auch remote sein. Das Target-Device ist jedoch immer lokal, solange man keinen Storage-Manger verwendet. (INFORMIX kann bei ontape auch Remote-Tape-Devices verwenden).
Die Groesse des zu allokierenden Buffers kann beim Backup-Kommando angegeben werden. Fehlt sie, so wird der DBM-Config-Paramter BACKBUFSZ verwandt. Idealerweise sollte die Backup-Buffer-Size so gewaehlt sein, dass sie ein Vielfaches der groessten verwendeten Extent-Size ist (Extent-Sizes werden auf Tablespace-Ebene eingestellt).
Offline-Backup (kein paralleler Zugriff auf die DB moeglich) --------------- db2 "backup database <dbname> to <directory-path>" db2 "backup database <dbname> tablespace syscatspace to <directory-path>"
Online-Backup: (Nur erlaubt bei eingeschaltetem Archival-Logging) -------------- db2 "backup database <dbname> online to <directory-path>" db2 "backup database <dbname> tablespace syscatspace online to <directory-path>"
Tablespace-Backups und -Restores koennen nicht parallel laufen, auch wenn es sich um unterschiedliche Tablespaces handelt. Mehrere Tablespaces koennen in einem Backup-Kommando zusammengefasst werden. Dies ist vor allem sinnvoll, wenn Tabellen in unterschiedlichen Tablespaces referentielle Abhaengigkeiten zueinander besitzen.
Ein gesondertes Tablespace-Backup des Dictionary-Tablespaces (SYSCATSPACE) ist empfehlenswert, da bei einem beschaedigten SYSCATSPACE kein Connect auf die DB mehr moeglich ist. Dieser Tablespace-Backup wuerde einen schnellen Restore ermoeglichen.
Das Recovery History File speichert historische Informationen ueber eine Datenbank. Folgende Events werden im Recovery History File vermerkt:
- Backup/Restore/Rollforward der DB oder von Tablespaces - Load einer Tabelle - Alter-/Quiesce-Tablespace Kommando - Drop Table - Reorg - Runstats
- db2 "list backup for <dbname>" - db2 "list backup for <dbname> since 20011116" - db2 "list history create tablespace all for <dbname>" - db2 "list history load all for <dbname>"
Nicht mehr benoetigte Eintraege koennen mit folgendem Befehl aus dem History File entfernt werden:
- db2 "prune history 20011231 [with force option]"
Eine spezielle Option beim Restore erlaubt das Wiederherstellen dieses History Files aus einem vorhanden Backup Image.
Wie beim Backup ist auch zum Restore SYSADM-, SYSCTRL- oder SYSMAINT-Authoritaet notwendig (SYSMAINT: Kein Restore in eine neue DB moeglich).
Der Restore einer kompletten DB erfolgt immer exklusiv, d.h. es sind keine parallelen Zugriffe auf diese DB erlaubt. Einzelne Tablespaces koennen sowohl online (share moded) oder offline (exclusive mode) restored werden. Online bedeutet, dass auf andere Tablespaces waehrend des Restores zugegegriffen werden kann.
Mit Hilfe eines sog. Userexit koennen unter UNIX die DB2-Logs gesichert und auch wieder restauriert werden. Unter OS/2 werden z.B. auch die DB-Backups mit Hilfe von Userexits realisiert.
Das definierte Userexit-Programm wird dabei vom DB2-Datenbankserver aufgerufen und muss bestimmte Konventionen (z.B. Returncodes) erfuellen. Es kann jeweils nur ein Userexit pro DB2-Instanz festgelegt werden.
Folgende Beispiele werden unter UNIX standardmaessing mitgeliefert:
- $DB2HOME/samples/c/db2uext2.cadsm
-> Interface zu TSM (Tivoli-Storage-Manager)
- $DB2HOME/samples/c/db2uext2.cdisk
-> Benutzt OS-copy-Kommandos
- $DB2HOME/samples/c/db2uext2.ctape -> Interface to Tapedevice
- $DB2HOME/samples/c/db2uext2.cxbsa -> Interface zu Legato-Networker
Aehnlich dem Informix-ALARMPROGRAM-Mechanismus kann das Userexit-Programm auch in anderen Sprachen (z.B. Perl) implementiert werden.
Name und Lokation des UserExit-Programms sind nicht konfigurierbar. Die festgelegte Konvention ist:
- $INSTANCEHOME/sqllib/adm/db2uext2
Snaphot-Datenbank
-----------------
1) db2 "set write suspend for database"
2) split mirror
3) db2 "set write resume for database"
4) attach mirror-devices to second host
5) db2start
6) db2inidb <dbname> as snapshot
-> CrashRecovery wird durchgefuehrt und anschl. ist die
DB verfuegbar
Standby-Datenbank
-----------------
1) db2 "set write suspend for database"
2) split mirror
3) db2 "set write resume for database"
4) attach mirror-devices to second host
5) db2start
6) db2inidb <dbname> as standby
-> Versetzt die DB in den Rollforward-Pending Status
7) Mit Hilfe eines UserExit muessen die Logfiles vom primaeren System
auf dieses uebertragen werden
8) Rollforward der DB bis zum Ende der Logs und Wiederaufsetzen
auf Punkt 7)
- nicht fuer LOB-Daten
Der DB-Config-Parameter trackmod muss auf yes gesetzt sein um Incremental-/Delta-Backups fahren zu koennen. Das Tracking von geaenderten Pages kann einen leichten Performance-Verlust bedeuten.
Incremental-/Delta-Backup enablen: ----------------------------------- - db2 "update db cfg for <dbname> using trackmod yes" -> Default: NO fuer bestehende Datenbanken ( < V7.2) -> Default: YES fuer unter V7.2 erstellte Datenbanken
Hierbei werden alle Daten gesichert, die sich seit dem letzten Full-Backup veraendert werden.
Wird z.B. Sonntags ein Full-Backup gefahren, so wuerde ein Incremental Backup am Montag nur die seit dem Full-Backup geaenderten Daten enthalten. Folgt Dienstags ein weiteres Incremental Backup, so enthaelt dieses wiederum alle Daten, die sich seit dem Full-Backup von Sonntag geaendert haben. D.h., das Incremental Backup von Dienstag baut auf dem Full-Backup von Sontag und nicht auf dem Incremental Backup von Montag auf, deshalb auch der Ausdruck kumulativ.
Enthaelt alle Daten, die seit dem letzten Full-/Incremental- bzw. Delta- Backup geaendert wurden. Wird z.B. Sonntags ein Full-Backup gefahren, so wuerde ein Delta-Backup am Montag die seit dem Full-Backup geaenderten Daten enthalten. Folgt Dienstags ein weiteres Delta-Backup, so enthaelt dieses nur die seit dem Delta-Backup von Montag geaenderten Daten. Die Backups bauen also aufeinander auf.
db2 "set write resume for database" db2 "set write resume for database"