DB2 Universal Database - Systemverwaltung
Bei einer aktualisierenden Wiederherstellung mit Hilfe des Befehls BACKUP
in Verbindung mit den Befehlen RESTORE und ROLLFORWARD kann die Datenbank oder
der Tabellenbereich in einen Zustand versetzt werden, wie er zu einem
bestimmten Zeitpunkt bestanden hatte.
Wenn Sie eine Datenbank erstellen, wird für
diese Datenbank zunächst nur die Umlaufprotokollierung aktiviert. Das
heißt, daß die Protokolle (reihum) wieder verwendet werden und nicht gesichert
oder archiviert werden. Bei Umlaufprotokollierung ist eine
aktualisierende Wiederherstellung nicht möglich: es kann lediglich eine
Wiederherstellung nach einem Systemabsturz bzw. eine
Versionswiederherstellung durchgeführt werden. Wenn die
Protokollarchivierung durchgeführt wird, ist jedoch eine aktualisierende
Wiederherstellung möglich, weil die Protokolle nach dem Zeitpunkt der letzten
Sicherung vorgenommene Änderungen an der Datenbank aufzeichnen. Sie
können Protokolle archivieren, wenn der Datenbankkonfigurationsparameter
logretain auf RECOVERY gesetzt ist, wenn der
Datenbankkonfigurationsparameter userexit aktiviert ist oder wenn
beides gilt. Wenn einer dieser Parameter wie gerade beschrieben
konfiguriert ist, ist die Datenbank für die aktualisierende
Wiederherstellung aktiviert.
Wenn die Datenbank wiederherstellbar ist, können Sie Sicherung,
Wiederherstellung und aktualisierende Wiederherstellung auf Datenbank- und
Tabellenbereichsebene ausführen. Die Sicherungen der Datenbank und
Tabellenbereiche können online ausgeführt werden. Wiederherstellung und
aktualisierende Wiederherstellung sind auch auf Tabellenbereichsebene online
verfügbar.
Bei der aktualisierenden Wiederherstellung (ROLLFORWARD) werden die in den
Protokollen aufgezeichneten abgeschlossenen Arbeitseinheiten erneut auf die
mit RESTORE wiederhergestellte Datenbank, den Tabellenbereich bzw. die
Tabellenbereiche angewandt. Es kann angegeben werden, daß die
aktualisierende Wiederherstellung bis zum Ende der Protokolle oder bis zu
einem bestimmten Zeitpunkt durchgeführt wird.
Eine aktualisierende Wiederherstellung kann nach Beendigung einer
vollständigen Datenbankwiederherstellung, wie sie im Abschnitt Wiederherstellen einer Datenbank beschrieben ist, durchgeführt werden. Sie kann auch
bei Tabellenbereichen angewandt werden, die sich im Status "Aktualisierende
Wiederherstellung anstehend" befinden. Informationen zu
Gesichtspunkten, die bei der aktualisierenden Wiederherstellung eines
Tabellenbereichs zu beachten sind, finden Sie in Aktualisierendes Wiederherstellen von Änderungen in einem Tabellenbereich.
Weitere Informationen zu den Konfigurationsparametern der Datenbank, die
sich auf die Protokollierungsfunktionen beziehen, finden Sie in Konfigurationsparameter für die Datenbankprotokollierung.
Im folgenden werden die Überlegungen zur Sicherung aufgeführt, die zu
beachten sind, wenn Ihre Datenbank für aktualisierende Wiederherstellung
aktiviert ist. Eine Übersicht über das Ausführen von Sicherungen finden
Sie in den folgenden Abschnitten:
- Durch die Standardeinstellung ("No") der Konfigurationsparameter
logretain und userexit wird die aktualisierende
Wiederherstellung nicht aktiviert. Der Standardwert beider Parameter
ist auf "No" gesetzt, da anfangs keine Sicherung vorhanden ist, die Sie
zur Wiederherstellung der Datenbank heranziehen können. Zu Beginn kann
die Datenbank nicht wiederhergestellt werden, so daß Sie auch keine
aktualisierende Wiederherstellung für sie durchführen können.
Zur Aktivierung einer neuen Datenbank für die aktualisierende
Wiederherstellung müssen Sie mindestens einen dieser Konfigurationsparameter
aktivieren, bevor Sie die erste Sicherung der Datenbank anlegen. Wenn
Sie den Wert eines oder beider Parameter ändern, wird die Datenbank in den
Status Sicherung anstehend versetzt, d. h., Sie
müssen eine Offline-Sicherung der Datenbank erstellen. Nach
erfolgreicher Beendigung der Sicherungsoperation kann die Datenbank verwendet
werden.
- Es ist nicht möglich, eine Datenbank zu sichern, die sich in einem
unbrauchbaren Status befindet, es sei denn, für diese Datenbank steht eine
Sicherung an.
- Wenn eine Datenbank oder ein Tabellenbereich nur teilweise
wiederhergestellt wurde, da während der Wiederherstellung der Datenbank ein
Systemabsturz auftrat, müssen Sie die Datenbank bzw. den
Tabellenbereich von einer Sicherung erfolgreich wiederherstellen, bevor Sie
eine Sicherungskopie davon anlegen können.
- Wenn sich einer der Tabellenbereiche in einer Datenbank in einem
"abnormalen" Status befindet, ist es nicht möglich, die Datenbank
bzw. diesen Tabellenbereich zu sichern, außer sie bzw. er
befindet sich im Status Sicherung anstehend.
- Sie können eine Datenbank bzw. einen Tabellenbereich auf einer
Festplatte, einem Band oder in einem Speicherbereich sichern, der vom
Dienstprogramm TSM oder einem Dienstprogramm zur Speicherverwaltung eines
anderen Lieferanten verwaltet wird. Informationen zu TSM finden Sie in Tivoli Storage Manager.
Unter OS/2 haben Sie außerdem die Möglichkeit, Sicherungskopien auf
Diskette oder mit Hilfe eines Benutzer-Exit-Programms zu
speichern.
- Möglicherweise haben Sie die aktualisierende Wiederherstellung für Ihre
Datenbank aktiviert und arbeiten mit einem Bandsystem, das nicht in der Lage
ist, eindeutig auf Sicherungen zu verweisen. In diesem Fall wird davon
abgeraten, mehrere Sicherungskopien derselben Datenbank auf einem Band zu
speichern.
- Es ist möglich, mehrere Dateien für die gesicherten Daten der Datenbank
bzw. des Tabellenbereichs zu erstellen.
Bei der Wiederherstellung über einen Benutzer-Exit und anschließender
aktualisierenden Wiederherstellung unter OS/2 stellt der Pfad zur Datenbank
den einzigen Verweis dar, der zum Lokalisieren der Behälter verwendet
wird. Aus diesem Grund werden alle Behälter der betreffenden Datenbank,
die sich auf dem Sicherungsband befinden, wiederhergestellt.
- Gehen Sie wie folgt vor, um die erforderliche Zeit für eine Sicherung zu
verringern:
- Verwenden Sie Sicherungen von Tabellenbereichen.
Sie können auch lediglich einen Teil einer Datenbank sichern (und
anschließend wiederherstellen), indem Sie die Option TABLESPACE des Befehls
BACKUP verwenden. Dies erleichtert das Verwalten von Daten, Indizes,
Langfeldern und großen Objekten (LOBs) in separaten Tabellenbereichen.
- Erhöhen Sie den Wert des Parameters PARALLELISM, bis er der Anzahl der zu
sichernden Tabellenbereiche entspricht.
- Beachten Sie beim Sichern von Tabellenbereichen folgendes:
- Es ist nicht möglich, gleichzeitig eine Sicherung eines Tabellenbereichs
und eine Wiederherstellung eines Tabellenbereichs auszuführen. Dies
gilt auch dann, wenn Sicherung und Wiederherstellung für unterschiedliche
Tabellenbereiche erfolgen.
- Bei Tabellen, die sich über mehrere Tabellenbereiche erstrecken, ist es
ratsam, die betreffende Gruppe von Tabellenbereichen zusammen zu sichern (und
wiederherzustellen).
- Wenn sich jeder Tabellenbereich auf einer anderen Platte befindet, wirkt
sich ein Datenträgerfehler nur auf einen bestimmten Tabellenbereich und nicht
auf die gesamte Datenbank aus. Der Tabellenbereich, in dem der Fehler
auftrat, wird in den Status "Aktualisierende Wiederherstellung anstehend"
versetzt. Sie können die anderen Tabellenbereiche in der Datenbank
weiterhin verwenden, sofern der Tabellenbereich in diesem Status nicht die
Systemkatalogtabellen enthält. In diesem Fall kann die Verbindung zur
Datenbank nicht hergestellt werden.
- Der Tabellenbereich mit den Systemkatalogtabellen kann unabhängig vom Rest
der Datenbank wiederhergestellt werden, wenn eine Sicherung auf
Tabellenbereichsebene für den Tabellenbereich mit den Systemkatalogtabellen
verfügbar ist.
- Die Sicherung schlägt fehl, wenn die Liste der zu sichernden
Tabellenbereiche einen temporären Tabellenbereich enthält.
- Beachten Sie bei einer partitionierten Datenbankumgebung
folgendes::
Wenn Sie in der Lage sein wollen, eine aktualisierende Wiederherstellung
durchzuführen, müssen Sie die Datenbank auf den Knoten dieser Liste regelmäßig
sichern und über mindestens eine Sicherungskopie der übrigen Knoten im System
(auch von Knoten, die keine Benutzerdaten für diese Datenbank enthalten)
verfügen. In zwei Situationen ist ein Sicherungsabbild einer
Datenbankpartition auf einem Datenbankpartitions-Server, der keine
Benutzerdaten für die Datenbank enthält, erforderlich::
- Sie haben einen Datenbankpartitions-Server dem Datenbanksystem
hinzugefügt, nachdem die letzte Sicherung erstellt wurde und müssen eine
aktualisierende Wiederherstellung auf diesem Datenbankpartitions-Server
durchführen.
- Es wird eine Wiederherstellung bis zu einem bestimmten Zeitpunkt
durchgeführt, für die erforderlich ist, daß sich alle Datenbankpartitionen im
System im Status "Aktualisierende Wiederherstellung anstehend"
befinden.
Die Datei des Wiederherstellungsprotokolls (Recovery History File) wird
jedesmal automatisch mit den Ergebnisinformationen aktualisiert, wenn Sie eine
Sicherung oder Wiederherstellung einer ganzen Datenbank oder eines
Tabellenbereichs ausführen. Diese Datei kann beim Überwachen der
Wiederherstellungsaktivitäten innerhalb einer Datenbank hilfreich sein.
Diese Datei wird im selben Verzeichnis wie die Konfigurationsdatei der
Datenbank erstellt. Weitere Informationen zur Datei des
Wiederherstellungsprotokolls finden Sie in Informationen in der Datei des Wiederherstellungsprotokolls.
In auf UNIX basierenden Umgebungen setzen sich die Dateinamen, die auf der
Platte erstellt werden, aus folgenden Informationen zusammen, die durch Punkte
voneinander getrennt werden. Auf anderen Plattformen wird eine
Unterverzeichnisstruktur aus vier Ebenen verwendet:
- Aliasname
- Der Aliasname der Datenbank, der aus 1-8 Zeichen besteht und beim Aufruf
des Befehls BACKUP angegeben wurde.
- Art
- Art der erstellten Sicherung. Mögliche Werte: "0" steht
für vollständige Datenbank, "3" steht für Tabellenbereich und "4"
steht für Kopie von einer Tabellenladeoperation.
- Exemplarname
- Der Name des aktuellen Exemplars des Datenbankmanagers, der aus 1-8
Zeichen besteht und der Umgebungsvariablen DB2INSTANCE entnommen
wird.
- Knotennummer
- Die Knotennummer.
- Katalogknotennummer
- Die Nummer des Katalogknotens der Datenbank.
- Zeitmarke
- Ein Wert aus 14 Zeichen, der das Datum und die Uhrzeit angibt, zu dem die
Sicherung ausgeführt wurde. Die Zeitmarke hat das Format
jjjjmmtthhnnss, dabei gilt folgendes:
jjjj steht für das Jahr (1995 bis 9999)
mm steht für den Monat (01 bis 12)
tt steht für den Tag des Monats (01 bis 31)
hh steht für die Stunde (00 bis 23)
nn steht für die Minuten (00 bis 59)
ss steht für die Sekunden (00 bis 59)
- Folgenummer
- Eine dreistellige Ziffernfolge, die als Dateierweiterung verwendet
wird.
Im folgenden werden die Überlegungen zur Wiederherstellung aufgeführt, die
zu beachten sind, wenn Ihre Datenbank für aktualisierende Wiederherstellung
aktiviert ist. Einen Überblick über das Ausführen von
Wiederherstellungen finden Sie in den folgenden Abschnitten:
Sie sollten folgendes beachten:
- Sie können die Sicherungskopie einer vollständigen Datenbank bzw.
eines Tabellenbereichs in eine bereits vorhandene Datenbank
wiederherstellen. Für die Ausführung der Wiederherstellung in eine
vorhandene Datenbank benötigen Sie die Berechtigung SYSADM, SYSCTRL oder
SYSMAINT. Das Sicherungsabbild kann sich von der vorhandenen Datenbank
durch den Aliasnamen, Datenbanknamen oder die Datenbanknummer
unterscheiden.
- Wenn Sie die Wiederherstellung in eine vorhandene Datenbank vornehmen und
die Datenbanknummern identisch sind, werden die Protokolle beibehalten.
- Sie können den Befehl RESTORE nur verwenden, wenn die Datenbank
bzw. der Tabellenbereich zuvor mit dem Befehl BACKUP gesichert
wurde.
- Wenn eine für die aktualisierende Wiederherstellung aktivierte Datenbank
wiederhergestellt wurde, befindet sie sich im Status "Aktualisierende
Wiederherstellung anstehend". Die Datenbank ist so lange nicht
verwendbar, bis sie aktualisierend wiedergeherstellt wird. Dies trifft
nicht zu, wenn für die Wiederherstellung WITHOUT ROLLING FORWARD angegeben
wird. Sie können die aktualisierende Wiederherstellung nicht
inaktivieren, sofern eine Online-Datenbanksicherung wiederhergestellt wurde
oder nur ausgewählte Tabellenbereichssicherungen wiederhergestellt
wurden.
- Die Sicherungskopie der Datenbank bzw. des Tabellenbereichs, die
vom Befehl RESTORE verwendet werden soll, kann sich auf einer Festplatte,
einem Band oder in einem Speicherbereich befinden, der vom Dienstprogramm TSM
(Tivoli Storage Manager) oder einem Dienstprogramm zur Speicherverwaltung
eines anderen Lieferanten verwaltet wird. Informationen zu TSM finden
Sie in Tivoli Storage Manager.
Wenn Sie bei Verwendung von TSM den Parameter TAKEN AT nicht angeben, ruft
TSM die letzte Sicherungskopie ab.
Unter OS/2 kann sich die Sicherungskopie der Datenbank oder des
Tabellenbereichs auch auf einer Diskette befinden oder über einen
Benutzer-Exit lokalisiert werden.
Unter Windows 95 und Windows NT kann sich die Sicherungskopie der Datenbank
oder des Tabellenbereichs auch auf Diskette befinden.
- Obwohl die Wiederherstellung mit RESTORE und die aktualisierende
Wiederherstellung (ROLLFORWARD) unabhängige Operationen sind, kann in Ihrer
Wiederherstellungsstrategie die Wiederherstellung mit RESTORE die erste Phase
einer vollständigen aktualisierenden Wiederherstellung (ROLLFORWARD) einer
Datenbank bilden. Nach einer erfolgreichen Wiederherstellung (RESTORE)
befindet sich eine Datenbank, die zum Zeitpunkt der Sicherung für die
aktualisierende Wiederherstellung konfiguriert war, im Status
"Aktualisierende Wiederherstellung anstehend" und ist nicht verwendbar,
bis der Befehl ROLLFORWARD erfolgreich ausgeführt wurde.
Bei der Ausführung des Befehls ROLLFORWARD geschieht folgendes:
- Wenn sich die Datenbank im Status "Aktualisierende Wiederherstellung
anstehend" befindet, wird die Datenbank aktualisierend
wiederhergestellt.
- Wenn nicht die Datenbank, sondern Tabellenbereiche im Status
"Aktualisierende Wiederherstellung anstehend" sind, werden, wenn Sie den
Befehl ROLLFORWARD absetzen und eine Liste von Tabellenbereichen angeben, nur
diese Tabellenbereiche aktualisierend wiederhergestellt. Wenn Sie keine
Liste angeben, werden alle Tabellenbereiche, die den Status "Aktualisierende
Wiederherstellung anstehend" haben, aktualisierend
wiederhergestellt.
Anmerkung: | Wenn Sie nach der letzten Sicherung einen Tabellenbereich umbenannt haben,
müssen Sie bei der aktualisierenden Wiederherstellung sicherstellen, daß der
neue Name verwendet wird. Der vorherige Tabellenbereichsname wird nicht
erkannt.
|
- Wenn sich in einer partitionierten Datenbankumgebung einige
Datenbankpartitionen im Status "Aktualisierende Wiederherstellung
anstehend" befinden und in anderen Datenbankpartitionen einige
Tabellenbereiche im Status "Aktualisierende Wiederherstellung anstehend"
sind (aber die zugehörige Datenbankpartition dies nicht ist), müssen Sie
zunächst die Datenbankpartitionen und anschließend die Tabellenbereiche
aktualisierend wiederherstellen.
Eine weitere, parallele Wiederherstellung einer Datenbank (mit RESTORE) ist
nicht möglich, während der Prozeß der aktualisierenden Wiederherstellung aktiv
ist.
Anmerkungen:
- Bei der Wiederherstellung von einer vollständigen Datenbanksicherung, die
mit der Option offline des Befehls BACKUP erstellt wurde, können
Sie den Status "Aktualisierende Wiederherstellung anstehend" während des
Wiederherstellungsprozesses umgehen. Mit Hilfe der Option WITHOUT
ROLLING FORWARD können Sie die wiederhergestellte Datenbank unverzüglich
wieder verwenden, ohne die aktualisierende Wiederherstellung
durchzuführen.
- Bei der Wiederherstellung von einer Sicherung, die mit der Option
online des Befehls BACKUP erstellt wurde, ist es nicht
möglich, den Status "Aktualisierende Wiederherstellung anstehend" zu
umgehen.
- Beachten Sie beim Wiederherstellen von Tabellenbereichen folgendes:
- Ein Tabellenbereich kann nur dann wiederhergestellt werden, wenn der
betreffende Tabellenbereich existiert und der identische Tabellenbereich
ist. ("Identisch" heißt in diesem Fall, daß der Tabellenbereich im
Zeitraum zwischen dem Erstellen des Sicherungsabbilds und dem Versuch der
Wiederherstellung nicht gelöscht und erneut erstellt wurde.) Wenn Sie
nach der letzten Sicherung einen Tabellenbereich umbenannt haben, müssen Sie
bei der aktualisierenden Wiederherstellung sicherstellen, daß der neue Name
verwendet wird. Der vorherige Tabellenbereichsname wird nicht
erkannt.
- Es ist nicht möglich, die Sicherungskopie eines Tabellenbereichs in eine
neue Datenbank wiederherzustellen.
- Wenn Sie Tabellen gesichert haben, die sich über mehr als einen
Tabellenbereich erstreckten, sollten Sie diese Gruppe von Tabellenbereichen
zusammen wiederherstellen.
- Nachdem der Befehl RESTORE für eine Tabellenbereichssicherung gestartet
wurde, ist der Tabellenbereich nicht verwendbar, bis der Befehl RESTORE
einschließlich einer aktualisierenden Wiederherstellung erfolgreich
abgeschlossen wurde.
- Die Wiederherstellung eines Tabellenbereichs kann online (gemeinsamer
Zugriff) oder offline (Exklusivmodus) erfolgen.
- Tritt während der Wiederherstellung einer Tabellenbereichssicherung ein
Systemfehler auf, ist lediglich der Tabellenbereich unbrauchbar, der gerade
wiederhergestellt wurde. Die anderen Tabellenbereiche in der Datenbank
können weiterhin verwendet werden.
- Für die Systemkatalogtabellen ist eine Online-Wiederherstellung der
Tabellenbereiche nicht möglich.
- Bei der partiellen oder selektiven Wiederherstellung mit RESTORE haben Sie
entweder die Möglichkeit, eine Tabellenbereichssicherung zu verwenden, oder
die Möglichkeit, eine vollständige Datenbanksicherung zu verwenden und einen
oder mehrere Tabellenbereiche aus diesem Sicherungsabbild auszuwählen.
Alle Protokolldateien, die diesem Tabellenbereich (bzw. diesen
Tabellenbereichen) zugeordnet sind, müssen von dem Zeitpunkt, zu dem die
Sicherung erstellt wurde, vorhanden sein. Wenn Sie nach der letzten
Sicherung einen Tabellenbereich umbenannt haben, müssen Sie beim
Zurückschreiben oder bei der aktualisierenden Wiederherstellung sicherstellen,
daß der neue Name verwendet wird. Der vorherige Tabellenbereichsname
wird nicht erkannt.
Wenn Sie in einem partitionierten Datenbanksystem beabsichtigen, einen
Tabellenbereich (oder Tabellenbereiche) bis zum Ende der Protokolle
aktualisierend wiederherzustellen, müssen Sie ihn (bzw. sie) nicht in
jeder Datenbankpartition (Knoten) wiederherstellen. Sie müssen ihn nur
in den Datenbankpartitionen wiederherstellen, für die die Wiederherstellung
erforderlich ist. Beabsichtigen Sie, einen Tabellenbereich bis zu einem
bestimmten Zeitpunkt aktualisierend wiederherzustellen, müssen Sie den
Tabellenbereich vor der aktualisierenden Wiederherstellung in jeder
Datenbankpartition mit dem Befehl RESTORE wiederherstellen.
- Unter OS/2 ist eine partielle oder selektive Wiederherstellung nicht
möglich, wenn zur Wiederherstellung ein Benutzer-Exit verwendet wird.
- Beachten Sie bei umgeleiteter Wiederherstellung folgendes:
- Während der Sicherung (BACKUP) einer Datenbank bzw. eines oder
mehrerer Tabellenbereiche wird ein Datensatz über alle
Tabellenbereichsbehälter protokolliert, die von den Tabellenbereichen, die
gesichert werden, verwendet werden. Während einer RESTORE-Operation
wird überprüft, ob alle bei der Sicherung aufgelisteten Behälter weiterhin
existieren und zugriffsbereit sind. Wenn aufgrund eines
Datenträgerfehlers (oder aus einem anderen Grund) ein oder mehrere Behälter
nicht zugriffsbereit sind, schlägt die RESTORE-Operation fehl. Zum
Zweck der Wiederherstellung in einem solchen Fall wird während der
RESTORE-Operation das Umleiten der Behälter von Tabellenbereichen
unterstützt. Diese Unterstützung umfaßt das Hinzufügen, Ändern
bzw. Entfernen von Tabellenbereichsbehältern.
- Im Anschluß an eine RESTORE-Operation wird oftmals eine
ROLLFORWARD-Operation ausgeführt, um die Änderungen nachzuvollziehen, die nach
der Sicherung in den Datenbankprotokollen protokolliert wurden. Während
einer aktualisierenden Wiederherstellung können Sie eine Transaktion
wiederholen, die eine Anweisung ALTER TABLESPACE mit der Option ADD
(zum Hinzufügen eines Behälters) ausführt. Damit die
ROLLFORWARD-Operation erfolgreich ausgeführt werden kann, muß Zugriff auf den
hinzuzufügenden Behälter bestehen. Ist der Zugriff auf den Behälter
nicht möglich, wird die aktualisierende Wiederherstellung für den
Tabellenbereich ausgesetzt, und der Tabellenbereich verbleibt im Status
"Aktualisierende Wiederherstellung anstehend".
- Bei Bedarf können Sie die in den Datenbankprotokollen aufgezeichneten
Operationen für das Hinzufügen von Behältern wiederholen. Ihnen ist
möglicherweise nicht bekannt, welche Behälter seit der letzten Sicherung
hinzugefügt wurden. Aus diesem Grund können Sie nicht abschätzen,
welche Behälter benötigt werden. Oder Sie möchten, bedingt durch die
Gründe, aus denen Sie eine umgeleitete Wiederherstellung ausführen, lediglich
die Behälterliste verwenden, die Sie bei der Wiederherstellung angegeben
haben, ohne weitere Behälter hinzuzufügen. Um diese Vorgehensweise zu
steuern, können Sie zum Zeitpunkt der Wiederherstellung angeben, ob die
ROLLFORWARD-Operation die Behälter während der aktualisierenden
Wiederherstellung erneut erstellen soll. (Sie können die Liste mit den
Behältern der Tabellenbereiche im Fenster "Behälter - Ändern" des
Notizbuchs Datenbank wiederherstellen bzw.
Tabellenbereich wiederherstellen in der Steuerzentrale
editieren.)
Eine aktualisierende Wiederherstellung baut auf einer wiederhergestellten
Datenbank auf und ermöglicht Ihnen, eine Datenbank bis zu einem bestimmten
Zeitpunkt wiederherzustellen, der hinter dem Zeitpunkt der Erstellung der
Datenbanksicherung liegt. Dieser Zeitpunkt kann entweder das Ende der
Protokolle sein oder ein Zeitpunkt zwischen dem Zeitpunkt der
Datenbanksicherung und dem Ende der Protokolle.
Anmerkung: | Wenn eine Wiederherstellung oder eine aktualisierende Wiederherstellung bis
zum Ende aller Protokolle ausgeführt wird, steht die auf den Befehl LIST
HISTORY angezeigte Sicherungs-ID für das Ende der Verarbeitungszeit.
Das bedeutet, daß der Wert für die Sicherungs-ID 99991231235959 lautet.
Die Sicherungs-ID wird in dieser Weise nur dann umgesetzt, wenn eine
aktualisierende Wiederherstellung ausgeführt wird.
|
Sie können eine Wiederherstellung bis zu einem bestimmten Zeitpunkt
ausführen, wenn eine aktive oder archivierte Protokolldatei nicht verfügbar
ist. In diesem Fall können Sie die aktualisierende Wiederherstellung
bis zu dem Punkt ausführen, an dem das fehlende Protokoll benötigt
würde. Darüber hinaus können Sie eine aktualisierende Wiederherstellung
bis zu einem bestimmten Zeitpunkt ausführen, wenn eine fehlerhafte Transaktion
in der Datenbank aktiv war. In diesem Fall würden Sie die Datenbank
wiederherstellen (mit RESTORE) und anschließend gerade bis zu einem Zeitpunkt
kurz vor der Ausführung der fehlerhaften Transaktion aktualisierend
wiederherstellen.
Abbildung 55. Aktualisierende Wiederherstellung

Sie können außerdem eine aktualisierende Wiederherstellung bis zu einem
bestimmten Zeitpunkt für Tabellenbereiche durchführen. Weitere
Informationen finden Sie in Aktualisierendes Wiederherstellen von Änderungen in einem Tabellenbereich.
Voraussetzung für die Verwendung dieser Methode ist, daß die Datenbank so
konfiguriert wurde, daß sie für die aktualisierende Wiederherstellung
aktiviert ist. Weitere Informationen zur Konfigurationsdatei der
Datenbank und den Datenbankprotokollen finden Sie unter den folgenden
Themen:
Wenn Sie Tabellen haben, die DATALINK-Spalten enthalten, lesen Sie auch die
Abschnitte Wiederherstellen von Datenbanken und Tabellenbereichen und aktualisierendes Wiederherstellen bis zum Ende der Protokolle und Wiederherstellen von Datenbanken und Tabellenbereichen und aktualisierendes Wiederherstellen bis zu einem bestimmten Zeitpunkt.
Die Konfigurationsdatei der Datenbank enthält Parameter für die
aktualisierende Wiederherstellung. Diese Wiederherstellung wird von den
Standardwerten der Parameter nicht unterstützt. Wenn Sie beabsichtigen,
diese Methode zu verwenden, müssen Sie einige der Standardwerte ändern.
Weitere Informationen zum Konfigurieren von DB2 UDB finden Sie in Kapitel 32, Konfigurieren von DB2.
- Anzahl primärer Protokolldateien (logprimary)
- Dieser Parameter gibt die Anzahl der primären Protokolle an, die erstellt
werden.
Ein primäres Protokoll belegt in leerem sowie in vollem Zustand denselben
Plattenspeicherplatz. Wenn Sie also mehr Protokolle als erforderlich
konfigurieren, wird unnötigerweise Plattenspeicherplatz belegt.
Konfigurieren Sie dagegen zuwenig Protokolle, kann der Fall eintreten, daß
Ihre Protokolle vollständig mit Daten gefüllt werden. Beim Auswählen
der Anzahl der zu konfigurierenden Protokolle müssen Sie daher die für jedes
Protokoll vorgesehene Größe einkalkulieren und berücksichtigen, ob Ihre
Anwendung volle Protokolle behandeln kann.
Wenn Sie für eine existierende Datenbank die aktualisierende
Wiederherstellung aktivieren, müssen Sie die Anzahl der primären Protokolle
auf den Wert der Summe der primären und sekundären Protokolle plus 1
ändern. Zusätzliche Informationen werden für Felder der Datentypen LONG
VARCHAR und LOB in Datenbanken aufgezeichnet, die für die aktualisierende
Wiederherstellung aktiviert sind.
Die Protokolldatei kann maximal 32 GB groß sein. Dies bedeutet,
daß die Anzahl der Protokolldateien (LOGPRIMARY + LOGSECOND) multipliziert mit
der Größe der einzelnen Protokolldateien in Byte (LOGFILSIZ * 4096) kleiner
als 32 GB sein muß.
Weitere Informationen zu diesem Konfigurationsparameter finden Sie in Kapitel 32, Konfigurieren von DB2.
- Anzahl sekundärer Protokolldateien (logsecond)
- Dieser Parameter gibt die Anzahl der sekundären Protokolldateien an, die
erstellt und für Wiederherstellungsprotokolle (nur nach Bedarf) verwendet
werden.
Wenn die primären Protokolldateien voll sind, werden die sekundären
Protokolldateien in der durch logfilsiz Größe definierten Größe
einzeln zugeordnet, wenn sie benötigt werden, und zwar im Höchstfall so viele,
wie durch diesen Parameter festgelegt wird. Wenn mehr sekundäre
Protokolldateien erforderlich sind, als von diesem Parameter zugelassen
werden, wird ein Fehlercode an die Anwendung zurückgegeben, und die
Aktivitäten in der Datenbank werden gestoppt.
Weitere Informationen zu diesem Konfigurationsparameter finden Sie in Kapitel 32, Konfigurieren von DB2.
- Protokollgröße (logfilsiz)
- Dieser Parameter bestimmt die Anzahl der Seiten für jedes der
konfigurierten Protokolle. Eine Seite hat eine Größe von 4 KB.
Anmerkung: | Die Gesamtgröße der Protokolldatei ist auf 32 GB begrenzt
(d. h. (logfilsiz + logprimary) x
logfilsiz < 32 GB/4096).
|
Die Größe jedes primären Protokolls hat eine direkte Auswirkung auf die
Leistung. Wenn die Datenbank für das Beibehalten von Protokollen
definiert wurde, wird jedesmal, wenn ein Protokoll voll ist, eine Anforderung
für die Zuordnung und Initialisierung eines neuen Protokolls abgesetzt.
Durch Erhöhen der Protokollgröße kann die Anzahl der Anforderungen, die für
die Zuordnung und Initialisierung neuer Protokolle erforderlich sind,
verringert werden. (Beachten Sie dabei jedoch, daß bei einer Erhöhung
der Protokollgröße mehr Zeit für das Formatieren jedes neuen Protokolls
benötigt wird.) Das Formatieren neuer Protokolle ist für die
Anwendungen mit einer Verbindung zur Datenbank transparent,
d. h., die Datenbankleistung wird durch die Formatierung
nicht beeinträchtigt.
Angenommen, Sie haben eine Anwendung, die die Datenbank geöffnet hält, um
die Verarbeitungszeit zum Öffnen von Datenbanken zu verringern (siehe Überlegungen zur Wiederherstellungsleistung). In diesem Fall sollte der Wert für die
Protokollgröße durch den Zeitraum bestimmt werden, der erforderlich ist, um
Kopien von Offline-Archivprotokolldateien anzulegen.
Die Kommunikationsgeschwindigkeit der Einheit, die Sie zum Speichern von
Offline-Archivprotokolldateien verwenden, und die Software, mit der Sie die
Kopien anlegen, müssen mindestens der Durchschnittsgeschwindigkeit
entsprechen, mit der der Datenbankmanager Daten in die Protokolle
schreibt. Wenn die Übertragungsgeschwindigkeit für die neuen
Protokolldaten, die generiert werden, nicht ausreicht, kann der
Plattenspeicherplatz knapp werden. Dieser Fall kann eintreten, wenn die
Protokollierungsaktivitäten über einen genügend langen Zeitraum hinweg
fortgesetzt werden. Entscheidend ist dabei die Größe des freien
Plattenspeicherplatzes. Reicht der verfügbare Speicherplatz nicht aus,
wird die Datenbankverarbeitung gestoppt.
Die Kommunikationsgeschwindigkeit spielt insbesondere bei der Verwendung
von Bändern oder optischen Datenträgern eine bedeutende Rolle. (Weitere
Informationen zur Verwendung anderer Medien für die Protokollarchivierung
finden Sie in Anhang F, Benutzer-Exit zur Datenbankwiederherstellung.) Einige Bandeinheiten benötigen stets dieselbe Zeit
zum Kopieren einer Datei, unabhängig davon, wie groß die betreffende Datei
ist. Sie müssen die Leistungsfähigkeit Ihrer Archivierungseinheit
bestimmen.
Darüber hinaus gelten für Bandeinheiten einige besondere Faktoren.
Die Häufigkeit der Archivierungsanforderungen ist entscheidend. Wenn
eine Kopieroperation fünf Minuten in Anspruch nimmt, muß der Umfang des
Protokolls groß genug sein, um bei einer hohen Arbeitsauslastung die
Protokolldaten von fünf Minuten aufnehmen zu können. Bedingt durch die
Eigenschaften Ihrer Bandeinheit kann zudem die Anzahl der pro Tag ausführbaren
Operationen begrenzt sein. Sie müssen diese Faktoren berücksichtigen,
wenn Sie die Protokollgröße definieren.
Die Verlustminimierung von Protokolldaten ist ebenfalls ein wichtiger
Aspekt beim Definieren der Protokollgröße. Von der Archivierung ist
stets das gesamte Protokoll betroffen. Wenn Sie ein einzelnes,
umfangreiches Protokoll verwenden, vergrößern Sie den Zeitraum zwischen den
Archivierungen. Bei einem Defekt des Datenträgers, auf dem sich das
Protokoll befindet, gehen wahrscheinlich einige Transaktionsinformationen
verloren. Das Verringern der Protokollgröße erhöht zwar die Häufigkeit
der Archivierungen, kann aber den Informationsverlust bei einem
Datenträgerfehler verringern, da die kleineren Protokolle, die vor dem
verlorengegangenen Protokoll erstellt wurden, weiterhin verwendet werden
können.
- Protokollpuffer (logbufsz)
- Mit diesem Parameter kann die Menge des gemeinsamen Speichers angegeben
werden, die als Puffer für Protokollsätze verwendet werden soll, bevor diese
Protokollsätze auf die Festplatte geschrieben werden. Die
Protokollsätze werden bei Eintreten einer der folgenden Umstände auf die
Platte geschrieben:
- Eine Transaktion wird festgeschrieben.
- Der Protokollpuffer ist voll.
- Ein anderes internes Ereignis im Datenbankmanager macht das Schreiben auf
die Platte erforderlich.
Durch Puffern der Protokollsätze werden E/A-Operationen für die
Protokolldateien effektiver, da weniger häufig Schreiboperationen durchgeführt
und bei jeder Schreiboperation mehr Protokollsätze geschrieben werden.
- Anzahl der Gruppenfestschreibungen (mincommit)
- Mit diesem Parameter können Sie das Schreiben von Protokollsätzen auf die
Platte verzögern, bis eine Mindestanzahl von Festschreibungen
(COMMIT-Operationen) durchgeführt wurde. Diese Verzögerung kann dazu
beitragen, daß der Systemaufwand für den Datenbankmanager im Zusammenhang mit
dem Schreiben von Protokollsätzen verringert wird und infolgedessen der
Durchsatz erhöht wird, wenn mehrere Anwendungen für eine Datenbank ausgeführt
werden und viele Festschreibungen von den Anwendungen innerhalb kurzer Zeit
angefordert werden.
Diese Gruppierung von Festschreibungen wird nur dann ausgeführt, wenn der
Wert dieses Parameters größer als eins und die Anzahl der Anwendungen, die mit
der Datenbank verbunden sind, größer als der Wert dieses Parameters
ist. Wenn die Gruppierung von Festschreibungen durchgeführt wird,
werden Festschreibungsanforderungen von Anwendungen solange zurückgehalten,
bis entweder eine Sekunde vergangen oder die Anzahl der
Festschreibungsanforderungen gleich dem Wert dieses Parameters ist.
- Neuer Protokollpfad (newlogpath)
- Anfangs werden die Datenbankprotokolle im Unterverzeichnis SQLOGDIR des
Datenbankverzeichnisses erstellt. Sie können die Position, an der die
aktiven Protokolle sowie die künftigen Archivprotokolldateien gespeichert
werden, ändern, indem Sie den Wert für diesen Konfigurationsparameter so
ändern, daß er entweder auf ein anderes Verzeichnis oder auf eine andere
Einheit zeigt. Archivprotokolldateien, die momentan im Verzeichnispfad
der Datenbankprotokolle gespeichert werden, werden nicht an die neue Position
versetzt, wenn die Datenbank für die aktualisierende Wiederherstellung
konfiguriert ist.
Da Sie den Protokollpfad ändern können, befinden sich die für die
aktualisierende Wiederherstellung erforderlichen Protokolle möglicherweise in
verschiedenen Verzeichnissen bzw. auf verschiedenen Einheiten.
Sie können diesen Konfigurationsparameter während der aktualisierenden
Wiederherstellung ändern, um Zugriff auf Protokolle an mehreren
Speicherpositionen zu ermöglichen.
Die Änderung am Wert des Parameters newlogpath wird nur
angewendet, sofern sich die Datenbank in einem konsistenten Status
befindet. Der Status der Datenbank wird mit dem zu Informationszwecken
dienenden Datenbankkonfigurationsparameter database_consistent
angezeigt. Weitere Informationen zu diesem Konfigurationsparameter
finden Sie in Kapitel 32, Konfigurieren von DB2. Informationen zu der Rolle, die Datenbankprotokolle
spielen, wenn eine Datenbank nicht konsistent ist, finden Sie in Überlegungen zur Verwaltung von Protokolldateien.
- Beibehalten von Protokollen (logretain)
- Dieser Parameter bewirkt, daß archivierte Protokolle im Verzeichnispfad
der Datenbankprotokolle verbleiben. Wenn dieser Parameter auf
"RECOVERY" gesetzt ist, kann der Datenbankmanager zur Methode der
aktualisierenden Wiederherstellung verwendet werden. Es ist nicht
erforderlich, userexit zu aktivieren, wenn der
Konfigurationsparameter logretain aktiviert ist. Einer
dieser beiden Parameter reicht aus, um die aktualisierende Wiederherstellung
zu ermöglichen.
Bei Verwendung dieses Parameters wird die Umlaufprotokollierung (der
Standardwert) außer Kraft gesetzt.
- Benutzer-Exit (userexit)
- Dieser Parameter bewirkt, daß der Datenbankmanager ein
Benutzer-Exit-Programm zum Archivieren und Abrufen von Protokollen
aufruft. Bei aktiviertem Benutzer-Exit ist die aktualisierende
Wiederherstellung möglich. Es ist nicht erforderlich,
logretain zu aktivieren, wenn der Konfigurationsparameter
userexit aktiviert ist. Einer dieser beiden Parameter reicht
aus, um die aktualisierende Wiederherstellung zu ermöglichen.
Bei Verwendung dieses Parameters wird die Umlaufprotokollierung (der
Standardwert) außer Kraft gesetzt. Userexit impliziert
logretain, umgekehrt ist dies jedoch nicht der Fall.
Weitere Informationen zum Benutzer-Exit-Programm finden Sie in Anhang F, Benutzer-Exit zur Datenbankwiederherstellung.
Bei der Verwendung des Konfigurationsparameters userexit oder
logretain spielt der Pfad der aktiven Protokolldatei eine wichtige
Rolle, um die aktualisierende Wiederherstellung zu ermöglichen. Wenn
der Konfigurationsparameter userexit aktiviert ist, wird ein
Benutzer-Exit-Programm aufgerufen, um die Protokolldateien in einem anderen
als dem aktiven Protokollpfad zu archivieren. Wenn der
Konfigurationsparameter logretain auf "RECOVERY" gesetzt ist,
wird sichergestellt, daß die Protokolldateien im aktiven Protokollpfad
verbleiben. Der aktive Protokollpfad wird entweder durch den
Konfigurationsparameter logpath oder newlogpath
festgelegt.
Wenn die Datenbank für aktualisierende Wiederherstellung aktiviert ist,
können Sie bestimmte Tabellenbereiche sichern, wiederherstellen und
aktualisierend wiederherstellen, anstatt die gesamte Datenbank zu
verwenden. Es kann sinnvoll sein, eine Wiederherstellungsstrategie für
einzelne Tabellenbereiche zu implementieren, da sich dadurch möglicherweise
Zeit einsparen läßt: Eine Wiederherstellung eines Teils der Datenbank
dauert nicht so lange wie eine Wiederherstellung der gesamten
Datenbank. Wenn zum Beispiel eine Festplatte fehlerhaft ist und sie nur
einen Tabellenbereich enthält, kann der Tabellenbereich von einer Sicherung
wiederhergestellt und aktualisierend wiederhergestellt werden, ohne daß die
gesamte Datenbank wiederhergestellt werden muß (und ohne den Benutzerzugriff
auf die übrigen Teile der Datenbank zu beeinträchtigen). Außerdem
bieten Sicherungen auf Tabellenbereichsebene eine Möglichkeit, kritische Teile
der Datenbank häufiger als andere Teile zu sichern. Dies dauert nicht
so lange wie das Sichern der gesamten Datenbank.
Wenn Sie nach der letzten Sicherung einen Tabellenbereich umbenannt haben,
müssen Sie bei der aktualisierenden Wiederherstellung sicherstellen, daß der
neue Name verwendet wird. Der vorherige Tabellenbereichsname wird nicht
erkannt. Sie müssen eine aktualisierende Wiederherstellung vornehmen,
die die Datenbank mindestens auf den Zeitpunkt zurücksetzt, zu der der
Tabellenbereich umbenannt wurde.
Wenn sich in einer partitionierten Datenbankumgebung einige
Datenbankpartitionen im Status "Aktualisierende Wiederherstellung
anstehend" befinden und in anderen Datenbankpartitionen einige
Tabellenbereiche im Status "Aktualisierende Wiederherstellung anstehend"
sind (aber die zugehörige Datenbankpartition dies nicht ist), müssen Sie
zunächst die Datenbankpartitionen und anschließend die Tabellenbereiche
aktualisierend wiederherstellen.
Wenn die Daten und großen Objekte einer Tabelle in getrennten
Tabellenbereichen gespeichert sind und die Tabelle reorganisiert wurde, müssen
die Tabellenbereiche sowohl für die Daten als auch für die großen Objekte
gemeinsam von einer Sicherung wiederhergestellt und aktualisierend
wiederhergestellt werden. Es ist ratsam, nach dem Reorganisieren der
Tabelle eine Sicherung der betroffenen Tabellenbereiche zu erstellen.
Verschiedene Status zeigen den aktuellen Zustand eines Tabellenbereichs
an:
Nach der Wiederherstellung eines Tabellenbereichs von einer Sicherung
befindet sich der Tabellenbereich immer im Status der anstehenden
aktualisierenden Wiederherstellung (d. h., wenn Sie einen
Tabellenbereich wiederherstellen und den Parameter WITHOUT ROLLING FORWARD
angeben, wird der Parameter WITHOUT ROLLING FORWARD ignoriert). Um den
Tabellenbereich verwendbar zu machen, müssen Sie eine aktualisierende
Wiederherstellung für ihn ausführen. Dabei haben Sie die Möglichkeit,
die aktualisierende Wiederherstellung bis zum Ende der Protokolldateien oder
bis zu einem bestimmten Zeitpunkt auszuführen. Bei der aktualisierenden
Wiederherstellung eines Tabellenbereichs bis zu einem bestimmten Zeitpunkt ist
folgendes zu berücksichtigen:
- Systemkatalogtabellen können nicht bis zu einem bestimmten Zeitpunkt
aktualisierend wiederhergestellt werden. Diese Tabellen müssen bis zum
Ende der Protokolle aktualisierend wiederhergestellt werden, um
sicherzustellen, daß alle Tabellenbereiche in der Datenbank konsistent
bleiben.
- Ein Tabellenbereich, der bis zu einem bestimmten Zeitpunkt aktualisierend
wiederhergestellt werden soll, muß von einer Sicherung wiederhergestellt
worden sein, die früher als der für die aktualisierende Wiederherstellung
angegebene Zeitpunkt erstellt wurde.
- Wenn Sie den Tabellenbereich nicht aktualisierend wiederherstellen wollen,
können Sie ROLLFORWARD STOP angeben, was der aktualisierenden
Wiederherstellung des Tabellenbereichs bis zum Zeitpunkt der
wiederhergestellten Sicherung entspricht.
Anmerkung: | Dies ist nicht möglich, wenn das Sicherungsabbild online erstellt
wurde. In dieser Situation müssen Sie bis mindestens zum Ende der
Sicherung aktualisierend wiederherstellen.
|
- Wenn Sie bis zu einem bestimmten Zeitpunkt aktualisierend wiederherstellen
und eine Tabelle in mehreren Tabellenbereichen enthalten ist, müssen alle
Tabellenbereiche, die die Tabelle enthalten, gleichzeitig aktualisierend
wiederhergestellt werden. Wenn zum Beispiel die Tabellendaten in einem
Tabellenbereich und der Index für die Tabelle in einem anderen Tabellenbereich
gespeichert sind, müssen beide Tabellenbereiche gleichzeitig bis zum selben
Zeitpunkt aktualisierend wiederhergestellt werden.
- Führen Sie vor der aktualisierenden Wiederherstellung eines
Tabellenbereichs den Befehl LIST TABLESPACES SHOW DETAIL aus. Dieser
Befehl liefert Informationen zum "Mindestwiederherstellungszeitpunkt"
(Minimum Recover Time), d. h. zum frühesten Zeitpunkt, bis
zu dem der Tabellenbereich aktualisierend wiederhergestellt werden
kann. Der Mindestwiederherstellungszeitpunkt wird aktualisiert, wenn
DDL-Anweisungen (DDL - Datendefinitionssprache) für den Tabellenbereich oder
für Tabellen in diesem Tabellenbereich ausgeführt werden. Der
Tabellenbereich muß mindestens bis zum Mindestwiederherstellungszeitpunkt
aktualisierend wiederhergestellt werden, so daß er mit den Informationen in
den Systemkatalogtabellen synchronisiert wird.
- Wenn Sie den Tabellenbereich umbenannt haben, müssen Sie eine
aktualisierende Wiederherstellung vornehmen, die die Datenbank mindestens auf
den Zeitpunkt zurücksetzt, zu dem der Tabellenbereich umbenannt
wurde.
- Wenn Sie eine Wiederherstellung für einen Tabellenbereich ausführen, der
eine Tabelle mit einer Identitätsspalte für einen Zeitpunkt vor dem Ende der
Protokolle enthält, kann sich eine Lücke in der Folge der generierten Werte
ergeben. Diese Situation kann zur Folge haben, daß DB2 doppelte Werte
für bestimmte Identitätsspalten generiert. Diese Werte sind zwar
gleich, wird jedoch nur der Inhalt der Datenbank untersucht, werden diese
nicht als gleiche Werte erkannt.
- Sie können unter bestimmten Voraussetzungen die Daten aus Tabellen
wiederherstellen, die versehentlich gelöscht wurden. Weitere
Informationen finden Sie in Wiederherstellen einer gelöschten Tabelle.
- Sie können den Befehl QUIESCE TABLESPACES FOR TABLE ausführen, um einen
transaktionskonsistenten Zeitpunkt zu erstellen, den Sie für die
aktualisierende Wiederherstellung von Tabellenbereichen verwenden
können. Wenn Sie Tabellenbereiche für eine Tabelle mit diesem Befehl in
den Wartemodus versetzen (Optionen "in share", "intent to update"
oder "exclusive"), wartet die Anforderung (mit Hilfe von Sperren) auf die
Beendigung aller aktiven Transaktionen, die auf Objekte in den
Tabellenbereichen zugreifen, während sie gleichzeitig neue Anforderungen für
die Tabellenbereiche blockiert. Wenn die QUIESCE-Anforderung bestätigt
wird, sind alle ausstehenden Transaktionen bereits beendet
(d. h. festgeschrieben oder rückgängig gemacht), und die
Tabellenbereiche sind in einem konsistenten Status. Sie können durch
einen Blick in die Datei des Wiederherstellungsprotokolls (Recovery History
File) QUIESCE-Punkte feststellen und prüfen, ob sie nach dem
Mindestwiederherstellungszeitpunkt liegen, um den gewünschten Zeitpunkt für
den Stopp der aktualisierenden Wiederherstellung festzulegen.
- Wenn Sie einen Tabellenbereich bis zu einem bestimmten Zeitpunkt
aktualisierend wiederherstellen wollen und eine Tabelle in dem Tabellenbereich
an einer referentiellen Integritätsbeziehung mit einer anderen Tabelle
beteiligt ist, die in einem anderen Tabellenbereich enthalten ist, sollten Sie
beide Tabellenbereiche gleichzeitig bis zum selben Zeitpunkt aktualisierend
wiederherstellen. Wenn Sie dies nicht tun, befinden sich beide
Tabellenbereiche am Ende der aktualisierenden Wiederherstellung bis zu einem
bestimmten Zeitpunkt im Status "Überprüfung anstehend". Wenn Sie
beide Tabellenbereiche zur gleichen Zeit aktualisierend wiederherstellen,
bleibt die Integritätsbedingung am Ende der aktualisierenden Wiederherstellung
bis zu einem bestimmten Zeitpunkt aktiv.
- Angenommen, Sie wollen einen Tabellenbereich bis zu einem bestimmten
Zeitpunkt aktualisierend wiederherstellen, und eine Tabelle im Tabellenbereich
ist von einem der beiden folgenden Typen:
- Eine zugrundeliegende Tabelle für eine Übersichtstabelle, die sich in
einem anderen Tabellenbereich befindet
- Eine Übersichtstabelle für eine Tabelle in einem anderen Tabellenbereich
In diesem Fall müssen Sie beide Tabellenbereiche zum gleichen Zeitpunkt
aktualisierend wiederherstellen. Wenn Sie dies nicht tun, wird die
Übersichtstabelle am Ende der Operation zur aktualisierenden Wiederherstellung
in den Status Überprüfung anstehend versetzt.
- Sie sollten darauf achten, daß die aktualisierende Wiederherstellung bis
zu einem bestimmten Zeitpunkt von Tabellenbereichen nicht dazu führt, daß eine
Transaktion in einigen Tabellenbereichen mit ROLLBACK rückgängig gemacht und
in anderen festgeschrieben werden. Dies kann in den folgenden Fällen
geschehen:
- Eine aktualisierende Wiederherstellung bis zu einem bestimmten Zeitpunkt
wird für eine Untergruppe der Tabellenbereiche durchgeführt, die durch eine
Transaktion aktualisiert wurden, und der bestimmte Zeitpunkt liegt vor dem
Zeitpunkt, zu dem die Transaktion die Aktualisierungen festgeschrieben
hat.
- Eine Tabelle, die in dem Tabellenbereich enthalten ist, der bis zu einem
bestimmten Zeitpunkt aktualisierend wiederhergestellt wird, hat einen
zugeordneten Auslöser oder wird von einem Auslöser aktualisiert, der auf
andere Tabellenbereiche als den, der aktualisierend wiederhergestellt wird,
zugreift.
Sie sollten einen Stoppzeitpunkt für die aktualisierende Wiederherstellung
suchen, der dies verhindert.
- Nach einer für Tabellenbereiche durchgeführten aktualisierenden
Wiederherstellung bis zu einem bestimmten Zeitpunkt werden diese
Tabellenbereiche in den Status "Sicherung anstehend" versetzt. Sie
müssen eine Sicherung des Tabellenbereichs erstellen, weil alle
Aktualisierungen für den Zeitraum zwischen dem Zeitpunkt, bis zu dem die
aktualisierende Wiederherstellung erfolgte, und dem aktuellen Zeitpunkt
entfernt wurden. Sie können den Tabellenbereich nicht mehr von einer
vorherigen Sicherung der Datenbank bzw. des Tabellenbereichs bis zum
aktuellen Zeitpunkt aktualisierend wiederherstellen. Das folgende
Beispiel zeigt, warum die Sicherung des Tabellenbereichs erforderlich ist und
wie sie verwendet wird. (Um den Tabellenbereich verfügbar zu machen,
können Sie entweder die gesamte Datenbank, den Tabellenbereich im Status
"Sicherung anstehend" oder eine Gruppe von Tabellenbereichen, die den
Tabellenbereich im Status "Sicherung anstehend" enthält, sichern.)
Abbildung 56. Sicherungsanforderung für Tabellenbereiche
BACKUP für Zeit von ROLLFORWARD für RESTORE für
Datenbank Tabellenbereich TABER1 bis Datenbank und
T2. BACKUP für TABER1. ROLLFORWARD
bis Protokollende
T1 T2 T3 T4
| | | |
| | | |
|---------------------------------------------------------------------------
| Protokolle werden nicht
auf TABER1 angewandt
zwischen T2 und T3
während aktualisierender
Wiederherstellung bis T2.
|
Im vorangegangenen Beispiel wird die Datenbank zum Zeitpunkt T1
gesichert. Später, zum Zeitpunkt T3, wird der Tabellenbereich TABER1
bis zum Zeitpunkt T2 aktualisierend wiederhergestellt und eine Sicherung des
Tabellenbereichs nach T3 erstellt. (Da sich der Tabellenbereich im
Status "Sicherung anstehend" befindet, muß eine Sicherung von ihm
erstellt werden. Die Zeitmarke der Tabellenbereichssicherung weist eine
Zeit nach T3 aus, während sich der Tabellenbereich in dem Zustand zum
Zeitpunkt T2 befindet. Die Protokollsätze für den Zeitraum zwischen T2
und T3 werden auf TABER1 nicht angewandt.) Zum Zeitpunkt T4 wird die
Datenbank anhand der Sicherung, die bei T1 erstellt wurde, wiederhergestellt
und bis zum Ende der Protokolle aktualisierend wiederhergestellt. Der
Tabellenbereich TABER1 wird in den Status "Wiederherstellung anstehend"
versetzt, wenn der Zeitpunkt T3 erreicht wird.
Der Tabellenbereich wird bei T3 in den Status "Wiederherstellung
anstehend" versetzt, weil der Datenbankmanager annimmt, daß Operationen an
TABER1 zwischen T3 und T4 durchgeführt wurden, ohne daß die
Protokolländerungen zwischen T2 und T3 auf den Tabellenbereich angewandt
wurden. Wenn die protokollierten Änderungen zwischen T2 und T3 während
der ROLLFORWARD-Operation für die Datenbank wieder angewandt würden, träfe
diese Annahme nicht mehr zu. Die erforderliche Sicherung eines
Tabellenbereichs, die nach der aktualisierenden Wiederherstellung bis zu einem
bestimmten Zeitpunkt erstellt werden muß, ermöglicht es, diesen
Tabellenbereich bis nach dem Zeitpunkt einer vorherigen aktualisierenden
Wiederherstellung (in diesem Beispiel T3) aktualisierend
wiederherzustellen.
Wenn Sie den Tabellenbereich TABER1 beispielsweise bis zum Zeitpunkt T4
wiederherstellen wollen, würden Sie den Tabellenbereich von einer Sicherung
wiederherstellen, die nach T3 (entweder die erforderliche Sicherung oder eine
andere) erstellt wurde, und anschließend den Tabellenbereich TABER1 bis zum
Ende der Protokolle aktualisierend wiederherstellen.
Im vorangegangenen Beispiel wäre die effizienteste Vorgehensweise zur
Wiederherstellung des Tabellenbereichs bis zum Zeitpunkt T4 die Ausführung der
erforderlichen Schritte in folgender Reihenfolge.
- Stellen Sie die Datenbank von einer Sicherung wieder her.
- Stellen Sie den Tabellenbereich von einer Sicherung wieder her.
- Stellen Sie die Datenbank aktualisierend wieder her.
- Stellen Sie den Tabellenbereich aktualisierend wieder her.
Da Sie vor der aktualisierenden Wiederherstellung der Datenbank den
Tabellenbereich von einer Sicherung wiederherstellen, werden keine Ressourcen
zum Anwenden der Protokollsätze auf den Tabellenbereich verwendet, wenn die
Datenbank aktualisierend wiederhergestellt wird. Dies würde geschehen,
wenn Sie die Datenbank schon vor der Wiederherstellung des Tabellenbereichs
von der Sicherung aktualisierend wiederherstellten.
Wenn Sie das Sicherungsabbild von TABER1 für einen Zeitpunkt nach T3 nicht
mehr auffinden können oder den Tabellenbereich TABER1 auf einem Stand vor oder
bis T3 wiederherstellen wollen, haben Sie folgende Möglichkeiten:
- Stellen Sie den Tabellenbereich bis zum Zeitpunkt T3 aktualisierend wieder
her. Sie brauchen den Tabellenbereich nicht erneut wiederherzustellen,
weil er von der Datenbanksicherung wiederhergestellt wurde.
- Stellen Sie den Tabellenbereich erneut von der Sicherung der Datenbank,
die Sie zum Zeitpunkt T1 erstellt haben, wieder her und stellen Sie
anschließend den Tabellenbereich bis zu einem Zeitpunkt vor T3 aktualisierend
wieder her.
- Löschen Sie den Tabellenbereich.
In einer partitionierten Datenbankumgebung müssen Sie alle Teile des
Tabellenbereichs bis zum selben Zeitpunkt gleichzeitig aktualisierend
wiederherstellen. Dadurch wird sichergestellt, daß der Tabellenbereich
in jeder Datenbankpartition konsistent ist.
Vor der Verwendung des Befehls ROLLFORWARD sind folgende Punkte zu
beachten:
- Sie benötigen die Berechtigung SYSADM, SYSCTRL oder SYSMAINT.
- Bei der Datenbank kann es sich um eine lokale oder ferne Datenbank
handeln.
- In einer partitionierten Datenbankumgebung muß der Befehl zur
aktualisierenden Wiederherstellung vom Katalogknoten der Datenbank abgesetzt
werden.
- Die Datenbank muß für die aktualisierende Wiederherstellung konfiguriert
sein (d. h. logretain, userexit oder
beide Parameter müssen aktiviert sein). Wenn die Datenbank zum ersten
Mal für die aktualisierende Wiederherstellung konfiguriert wird, müssen Sie
eine Sicherungskopie von ihr anlegen.
- Eine Datenbank muß erst erfolgreich von einer Sicherung wiederhergestellt
werden (mit dem Befehl RESTORE), bevor sie aktualisierend wiederhergestellt
werden kann. Bei einem Tabellenbereich ist dies jedoch nicht
erforderlich. Ein Tabellenbereich kann zeitweilig in den Status
"Aktualisierende Wiederherstellung anstehend" versetzt werden, erfordert
aber eine RESTORE-Operation, um diesen Status zu beheben
(z. B. im Fall einer Netzstromunterbrechung).
- Eine aktualisierende Wiederherstellung einer Datenbank wird offline
ausgeführt. Die Datenbank steht nicht zur Verfügung, bis die
aktualisierende Wiederherstellung abgeschlossen ist (entweder durch Erreichen
des Endes der Protokolle während der aktualisierenden Wiederherstellung eines
Tabellenbereichs oder durch Angabe des Befehls ROLLFORWARD STOP). Sie
können jedoch eine aktualisierende Wiederherstellung der Tabellenbereiche
online ausführen, solange SYSCATSPACE nicht eingeschlossen ist. Wenn
Sie eine aktualisierende Wiederherstellung für einen Tabellenbereich online
durchführen, steht dieser nicht zur Verwendung zur Verfügung. Die
anderen Tabellenbereiche in der Datenbank bleiben jedoch verfügbar.
- Gehen Sie bei der aktualisierenden Wiederherstellung wie folgt vor:
- Setzen Sie den Befehl ROLLFORWARD (ohne die Option STOP) ab.
- Setzen Sie den Befehl ROLLFORWARD QUERY STATUS ab.
Wenn Sie eine aktualisierende Wiederherstellung bis zum Ende der Protokolle
ausführen, kann der Befehl QUERY STATUS anzeigen, daß eine Protokolldatei
(oder Protokolldateien) fehlt, wenn der von QUERY STATUS zurückgegebene
Zeitpunkt früher liegt, als Sie erwarten.
Wenn Sie eine aktualisierende Wiederherstellung bis zu einem bestimmten
Zeitpunkt durchführen, kann der Befehl QUERY STATUS dabei helfen
sicherzustellen, daß die aktualisierende Wiederherstellung bis zum richtigen
Zeitpunkt erfolgt.
- Setzen Sie den Befehl ROLLFORWARD STOP ab. Nach dem Befehl
ROLLFORWARD STOP können keine weiteren Änderungen mehr aktualisierend
wiederhergestellt werden.
- Sie können eine partielle oder selektive Wiederherstellung einer Sicherung
durchführen, die mit der aktuellen Version von DB2 erstellt wurde. Dies
funktioniert nicht mit einer früheren Version von DB2.
- Für einen Tabellenbereich muß eine aktualisierende Wiederherstellung
ausgeführt werden, wenn er sich im Status "Aktualisierende Wiederherstellung
anstehend" befindet. Ein Tabellenbereich weist diesen Status auf,
nachdem eine Wiederherstellung auf Tabellenbereichsebene ausgeführt wurde oder
nachdem er aufgrund eines Datenträgerfehlers offline geschaltet wurde.
Abbildung 57. Aktualisierende Wiederherstellung von Tabellenbereichen

- Es ist nicht erforderlich, Ihre Datenbank mit der letzten Sicherungskopie
der Datenbank wiederherzustellen. Sie können mit einer beliebigen
Sicherung beginnen, vorausgesetzt, Sie verfügen über die Protokolle, die
dieser Sicherung zugeordnet sind und die auf diese Sicherung folgen.
- Sie sollten weiterhin regelmäßige Sicherungen einer Datenbank ausführen,
um den für die Wiederherstellung erforderlichen Zeitaufwand zu
verringern.
- Wenn Sie eine aktualisierende Wiederherstellung abbrechen müssen
(d. h. ROLLFORWARD STOP wurde nicht angegeben, oder der
Befehl ROLLFORWARD schlug fehl), um erneut zu starten, können Sie dazu den
Befehl ROLLFORWARD CANCEL verwenden.
Wenn Sie den Befehl ROLLFORWARD CANCEL für eine Datenbank ausführen, wird
die Datenbank in den Status "Wiederherstellung anstehend" versetzt,
unabhängig davon, ob eine aktualisierende Wiederherstellung für die Datenbank
aktiv ist oder nicht.
Der Befehl ROLLFORWARD CANCEL wirkt sich für Tabellenbereiche wie folgt
aus:
- Wenn Sie den Befehl ROLLFORWARD CANCEL absetzen und eine Liste der
Tabellenbereiche angeben, die sich im Status "Aktualisierende
Wiederherstellung anstehend" befinden, werden sie in den Status
"Wiederherstellung anstehend" versetzt. In diesem Status ist kein
Befehl zur aktualisierenden Wiederherstellung aktiv.
Anmerkung: | Wenn Sie keine Liste mit Tabellenbereichen angeben, wird SQL4906
zurückgegeben.
|
- Wenn mehrere Tabellenbereiche bis zum Ende der Protokolle aktualisierend
wiederhergestellt werden und Sie den Befehl ROLLFORWARD CANCEL mit einer Liste
angeben, werden nur die Tabellenbereiche, die sich in der Liste befinden, in
den Status "Wiederherstellung anstehend" versetzt. Die
Tabellenbereiche, die nicht in der Liste enthalten sind, verbleiben im Status
"Aktualisierende Wiederherstellung aktiv". Wenn Sie den Befehl
ROLLFORWARD CANCEL ohne Liste angeben, werden alle Tabellenbereiche, die den
Status "Aktualisierende Wiederherstellung aktiv" besitzen, in den Status
"Wiederherstellung anstehend" versetzt. Außerdem ist der Befehl
ROLLFORWARD nicht länger aktiv.
- Wenn Sie den Befehl ROLLFORWARD CANCEL absetzen und mindestens ein
Tabellenbereich bis zu einem bestimmten Zeitpunkt aktualisierend
wiederhergestellt wird, werden alle Tabellenbereiche in den Status
"Wiederherstellung anstehend" versetzt, unabhängig davon ob Sie eine
Liste angeben oder nicht. Auch wenn Sie eine Liste angeben, wird diese
ignoriert und alle Tabellenbereiche, die im Status "Aktualisierende
Wiederherstellung aktiv" sind, werden in den Status "Wiederherstellung
anstehend" versetzt. Außerdem ist der Befehl ROLLFORWARD nicht
länger aktiv.
Anmerkung: | Sie können eine aktive Operation zur aktualisierenden Wiederherstellung nicht
mit dem Befehl ROLLFORWARD CANCEL abbrechen. Mit diesem Befehl können
Sie nur eine Operation zur aktualisierenden Wiederherstellung abbrechen, die
zwar beendet wurde, für die aber kein Befehl ROLLFORWARD STOP abgesetzt wurde,
bzw. eine Operation zur aktualisierenden Wiederherstellung, die vor der
Beendigung fehlschlug.
|
Wenn Sie Tabellen haben, die DATALINK-Spalten enthalten, lesen Sie auch den
Abschnitt Überlegungen zu den Dienstprogrammen RESTORE und ROLLFORWARD.
Sie können eine partitionierte Datenbank von einem Client der Version 2 aus
nicht aktualisierend wiederherstellen.
Vor dem Aufrufen des Befehls ROLLFORWARD sind einige Punkte zu
beachten:
- Sie können beim Aufrufen des Befehls ROLLFORWARD einen Zeitpunkt angeben,
um die Anzahl der Transaktionen zu beschränken, die anhand der
Datenbankprotokolle wiederhergestellt werden. Bei einer
Wiederherstellung mit Hilfe einer Sicherung, die mit der Option
online des Befehls BACKUP erstellt wurde, muß der mit dem Befehl
ROLLFORWARD angegebene Zeitpunkt nach der Endzeit der Online-Sicherung
liegen.
- Ein Protokoll verwendet eine Zeitmarke, die der Beendigung der
Arbeitseinheit zugeordnet ist. Die Zeitmarke in den Protokollen
verwendet die Weltzeit (CUT = Coordinated Universal Time). Dieses
Verfahren hilft dabei, zu verhindern, daß verschiedenen Protokollen dieselbe
Zeitmarke zugewiesen wird (z. B. aufgrund des Wechsels zur
Sommerzeit). Die Zeitmarke, die in der Sicherung verwendet wird,
basiert auf der Ortszeit, zu der der Befehl BACKUP gestartet wurde.
Infolgedessen müssen Sie beim Aufrufen des Befehls ROLLFORWARD die Zeitangabe
in Weltzeit (entspricht der westeuropäischen Zeit) vornehmen.
Anmerkungen:
- Das Sonderregister CURRENT TIMEZONE enthält den Unterschied zwischen der
westeuropäischen Zeit (WEZ) und der Ortszeit der Datenbank auf dem
Anwendungs-Server. Die Ortszeit entspricht der westeuropäischen Zeit
(WEZ) plus dem Inhalt des Sonderregisters CURRENT TIMEZONE.
- Wenn Sie einen Tabellenbereich (oder Tabellenbereiche) bis zu einem
bestimmten Zeitpunkt aktualisierend wiederherstellen, müssen Sie die
aktualisierende Wiederherstellung mindestens bis zum
Mindestwiederherstellungszeitpunkt durchführen, der der Zeitpunkt der letzten
Aktualisierung der Systemkataloge für diesen Tabellenbereich oder die
Tabellenbereiche ist. Sie können den Mindestwiederherstellungszeitpunkt
für den Tabellenbereich mit Hilfe des Befehls LIST TABLESPACES SHOW DETAIL
ermitteln. Ausführliche Angaben zu diesem Befehl finden Sie im Handbuch
Command Reference.
- Wenn Sie die ROLLFORWARD-Operation stoppen, bevor der Zeitpunkt der
Beendigung der Online-Sicherung erreicht ist, verbleibt die Datenbank im
Status "Aktualisierende Wiederherstellung anstehend". Wenn ein
Tabellenbereich aktualisierend wiederhergestellt wird, verbleibt er im Status
"Aktualisierende Wiederherstellung aktiv".
Anhand der Variablen DB2LOADREC der Profilregistrierdatenbank wird die Datei
mit den Angaben zur Speicherposition der Ladekopie identifiziert. Diese
Datei wird während der aktualisierenden Wiederherstellung zum Lokalisieren der
Ladekopie verwendet. Sie enthält Informationen zu den folgenden
Punkten:
- Datenträgertyp
- Anzahl der zu verwendenden Datenträgereinheiten
- Speicherposition der Ladekopie, die beim Laden der Tabelle generiert wurde
- Dateiname der Ladekopie (sofern zutreffend)
Falls diese Datei nicht existiert oder darin kein übereinstimmender Eintrag
gefunden wurde, werden die Informationen aus dem Protokollsatz
verwendet.
Die Informationen in der Datei können überschrieben werden, bevor die
aktualisierende Wiederherstellung stattfindet.
Anmerkungen:
- In einer partitionierten Datenbankumgebung muß sich die Variable
DB2LOADREC der Profilregistrierdatenbank in der Datei db2profile
befinden.
- In einer partitionierten Datenbankumgebung muß die Datei der Ladekopie auf
jedem Datenbankpartitions-Server vorhanden und der Dateiname (einschließlich
des Pfads) derselbe sein.
- Ist ein Eintrag in der Datei, die mit der Variablen DB2LOADREC der
Profilregistrierdatenbank angegeben wurde, ungültig, wird die alte Datei mit
den Angaben zur Speicherposition der Ladekopie verwendet, um Ersatzdaten für
den ungültigen Eintrag bereitzustellen.
Folgende Informationen werden in der Datei mit den Angaben zur
Speicherposition bereitgestellt. Die ersten fünf Parameter müssen
gültige Werte aufweisen und werden zum Identifizieren der Ladekopie
verwendet. Die gesamte Struktur wird für jede aufgezeichnete Ladekopie
wiederholt. Beispiel:
TIMestamp 19950725182542 * Während des Ladens generierte Zeitmarke
SCHema PAYROLL * Schema der geladenen Tabelle
TABlename EMPLOYEES * Tabellenname
DATabasename DBT * Datenbankname
DB2instance TORONTO * DB2INSTANCE
BUFfernumber NULL * Anzahl der Puffer für die Wiederherstellung
SESsionnumber NULL * Anzahl der Sitzungen für die Wiederherstellung
TYPeofmedia L * Datenträgertyp - L für lokale Einheit
A für TSM
O für andere Lieferanten
LOCationnumber 3 * Anzahl der Speicherpositionen
ENTry /u/toronto/dbt.payroll.employes.001
ENT /u/toronto/dbt.payroll.employes.002
ENT /dev/rmt0
TIM 19950725192054
SCH PAYROLL
TAB DEPT
DAT DBT
DB2 TORONTO
SES NULL
BUF NULL
TYP A
TIM 19940325192054
SCH PAYROLL
TAB DEPT
DAT DBT
DB2 TORONTO
SES NULL
BUF NULL
TYP O
SHRlib /@sys/lib/backup_vendor.a
Anmerkungen:
- Für jedes Schlüsselwort sind die ersten drei Zeichen wichtig. Alle
Schlüsselwörter sind in der angegebenen Reihenfolge erforderlich.
Leerzeilen werden nicht akzeptiert.
- Die Zeitmarke hat das Format jjjjmmtthhmmss (Jahr Monat Tag
Stunde Minute Sekunde).
- Alle Felder sind verbindlich, ausgenommen die Werte für BUF und SES, die
den Wert NULL haben können. Ist SES gleich NULL, wird der im
Konfigurationsparameter NUMLOADRECSES angegebene Wert verwendet. Ist
BUF gleich NULL, ist der Standardwert gleich SES+2.
- Auch wenn lediglich ein Eintrag in der Datei mit den Angaben zur
Speicherposition ungültig ist, wird die vorherige Datei mit den Angaben zur
Speicherposition der Ladekopie zur Bereitstellung dieser Einträge
verwendet.
- Es gibt folgende Datenträgertypen: lokale Einheit (L für Band,
Platte oder Diskette), TSM (A) oder Datenträger anderer Lieferanten
(O). Lautet der Typ "L", ist die Anzahl der Speicherpositionen
(LOCationnumber) gefolgt von den Einträgen zur Speicherposition
erforderlich. Lautet der Typ "A", ist keine weitere Eingabe
erforderlich. Lautet der Typ "O", ist der Name der gemeinsamen
Bibliothek (SHRlib) erforderlich. Weitere Informationen zur Verwendung
von TSM oder der Produkte anderer Lieferanten als Sicherungsdatenträger finden
Sie in Tivoli Storage Manager.
- Der Parameter SHRlib zeigt auf eine Bibliothek, die die Funktion zum
Speichern der Daten für LOAD COPY enthält.
Anmerkung: | Wenn Sie LOAD COPY NO ausführen und keine Sicherungskopie der Datenbank oder
der betroffenen Tabellenbereiche nach Ausführung von LOAD erstellen, können
Sie die Datenbank oder Tabellenbereiche nach der Ausführung von LOAD nicht bis
zu einem bestimmten Zeitpunkt wiederherstellen. Das heißt, Sie können
keine aktualisierende Wiederherstellung ausführen, um die Datenbank
bzw. die Tabellenbereiche auf einem Stand nach der Ausführung der
LOAD-Operation wiederherzustellen. Sie können die Datenbank bzw.
die Tabellenbereiche lediglich bis zu einem Zeitpunkt vor der LOAD-Operation
wiederherstellen.
|
Für den Fall, daß Sie eine bestimmte Ladekopie verwenden wollen, werden die
LOAD-Zeitmarken in der Datei des Wiederherstellungsprotokolls (Recovery
History File) für die Datenbank aufgezeichnet. In einer partitionierten
Datenbankumgebung ist die Datei des Wiederherstellungsprotokolls für jede
Datenbankpartition lokal.
Weitere Informationen zum Befehl LOAD finden Sie im Handbuch Versetzen von Daten Dienstprogramme und Referenz.
Es kann vorkommen, daß Sie Tabellen versehentlich löschen, obwohl Sie die
enthaltenen Daten weiterhin benötigen. Sollten Sie Tabellen, deren
Daten nicht verloren gehen dürfen, versehentlich gelöscht haben, ziehen Sie in
Betracht, die betreffende Tabelle oder die betreffenden Tabellen nach dem
Löschen wiederherstellbar zu machen.
Sie können die Tabellendaten mit der Datenbankwiederherstellung (RESTORE)
und einer anschließenden aktualisierenden Wiederherstellung
wiederherstellen. Wenn die Datenbank groß ist, kann dies zeitaufwendig
sein, und die Daten der Datenbank sind während der Wiederherstellung nicht
verfügbar. Indem Sie die Wiederherstellung für gelöschte Tabellen
anwenden, können Sie die Daten in der gelöschten Tabelle auf der
Tabellenbereichsebene wiederherstellen und aktualisierend
wiederherstellen. Dies ist wiederum schneller als eine
Wiederherstellung auf Datenbankebene, und die Datenbank kann zudem für die
Benutzer verfügbar bleiben.
Damit eine gelöschte Tabelle wiederherstellbar ist, muß für den
Tabellenbereich, in dem sich die Tabelle befindet, der Parameter DROPPED TABLE
RECOVERY aktiviert sein. Dies können Sie mit der Anweisung ALTER
TABLESPACE oder der Anweisung CREATE TABLESPACE erreichen. Weitere
Informationen zu diesen Anweisungen finden Sie im Handbuch SQL Reference.
Die Option DROPPED TABLE RECOVERY ist tabellenbereichsspezifisch und kann
nur für einen regulären Tabellenbereich angegeben werden. Wenn Sie
bestimmen möchten, ob ein Tabellenbereich dieses Merkmal aufweist, können Sie
die Spalte DROP_RECOVERY des Tabellenbereichsnamens in der Katalogtabelle
syscat.tablespaces abfragen.
Wenn eine Anweisung DROP TABLE für eine Tabelle ausgeführt wird, die sich
in einem Tabellenbereich mit "aktivierter" Option DROPPED TABLE RECOVERY
befindet, wird in den Protokolldateien ein zusätzlicher Protokolleintrag
erstellt. Der Protokolleintrag enthält Informationen, die die gelöschte
Tabelle angeben. Außerdem wird in der Datei des
Wiederherstellungsprotokolls ein Eintrag erstellt, der Informationen zur
erneuten Erstellung der Tabelle enthält.
Gehen Sie wie folgt vor, um eine gelöschte Tabelle
wiederherzustellen:
- Stellen Sie die Kennung der gelöschten Tabelle fest. Diese Kennung
befindet sich in der Datei des Wiederherstellungsprotokolls. Verwenden
Sie dazu den Befehl LIST HISTORY DROPPED TABLE. Dadurch werden ein
Tabellenverzeichnis mit gelöschten Tabellen und die erforderlichen
Informationen zum erneuten Erstellen der Tabelle angezeigt.
Anmerkung: | Die ID der gelöschten Tabelle wird in der Ausgabe von LIST HISTORY in der
Spalte für die Sicherungs-ID ausgegeben.
|
Weitere Informationen zu diesem Befehl finden Sie im Handbuch Command Reference.
- Führen Sie die Wiederherstellung auf Datenbank- oder Tabellenbereichsebene
mit einer Sicherungskopie aus, die vor dem Löschen erstellt wurde.
- Führen Sie eine aktualisierende Wiederherstellung bis zu einem Zeitpunkt
nach dem Löschen aus. Verwenden Sie für den Befehl ROLLFORWARD die
Option RECOVER DROPPED TABLE. Wenn Sie diese Option verwenden, sind
folgende weiteren Informationen erforderlich: die Kennung der gelöschten
Tabelle und der Pfad, in den die Ausgabedateien gespeichert werden
sollen. Auf den Verzeichnispfad muß entweder von allen
Datenbankpartitionen aus zugegriffen werden können, oder er muß auf allen
Partitionen vorhanden sein. Weitere Informationen zu diesem Befehl
finden Sie im Handbuch Command Reference.
- Erstellen Sie die Tabelle mit der Anweisung CREATE TABLE aus der Datei des
Wiederherstellungsprotokolls erneut.
- Importieren Sie die mit dem Befehl ROLLFORWARD exportierten Daten in die
Tabelle.
Die exportierten Daten werden in Dateien mit den folgenden
Namenskonventionen geschrieben: Unterhalb des für den Befehl ROLLFORWARD
vom Benutzer definierten Verzeichnisses exportverzeichnis wird für
die einzelnen Datenbankpartitionen ein Unterverzeichnis erstellt. Der
Benutzer kann die Unterverzeichnisse anlegen, bevor die Anforderung zum
aktualisierenden Wiederherstellen abgesetzt wird. Damit können Sie die
Daten auch auf ein bestimmtes Laufwerk oder eine bestimmte Maschine
exportieren. Die Unterverzeichnisse sind nach dem Muster
"NODEnnnn" benannt, wobei nnnn für die Nummer der
Datenbankpartition oder des Knotens steht. In die einzelnen
Unterverzeichnisse wird eine Datendatei mit dem Namen "data"
exportiert. Die Datendateien enthalten die Daten der gelöschten Tabelle
in dem Zustand, wie sie sich in der jeweiligen Datenbankpartition befunden
haben.
Für die Art der Daten, die von einer gelöschten Tabelle wiederhergestellt
werden können, gibt es einige Einschränkungen. Es kann nur eine
gelöschte Tabelle zur gleichen Zeit wiederhergestellt werden. Zur
Wiederherstellung mehrerer gelöschter Tabellen muß die oben beschriebene
Wiederherstellungsreihenfolge für jede einzelne Tabelle ausgeführt werden, die
wiederhergestellt werden soll. Folgende Daten können nicht
wiederhergestellt werden:
- LOB- oder LONG-Daten. Der Parameter DROPPED TABLE RECOVERY wird für
Tabellenbereiche für lange Objektdaten (LONG) nicht unterstützt. Wenn
Sie versuchen, ihn für einen Tabellenbereich für lange Objektdaten zu
verwenden, wird der Fehler SQL628N zurückgegeben. Wenn Sie versuchen,
eine gelöschte Tabelle mit Spalten des Typs LOB oder LONG VARCHAR
wiederherzustellen, werden diese Spalten in der generierten Exportdatei auf
NULL gesetzt. Der Parameter DROPPED TABLE RECOVERY sollte nur für
reguläre Tabellenbereiche auf "ON" gesetzt werden, aber nicht für
temporäre Tabellenbereiche oder Tabellenbereiche für lange Objektdaten.
- Die Namen der Dateien mit einer Programmverbindung (Link), die
DATALINK-Spalten zugeordnet sind, können wiederhergestellt werden. Nach
dem Datenimport muß die Tabelle mit dem DB2 Data Links Manager erneut
abgeglichen werden. Die Sicherungskopien der Dateien können
möglicherweise vom DB2 Data Links Manager wiederhergestellt werden, je
nachdem, ob diese von der Speicherbereinigung bereits gelöscht wurden oder
nicht.
- Metadaten, die den Zeilentypen zugeordnet sind. (Die Daten selbst
werden wiederhergestellt, nicht jedoch die Metadaten.) Die Daten in der
Hierarchietabelle der typisierten Tabelle werden wiederhergestellt.
Diese Daten sind möglicherweise größeren Umfangs als die Daten in der
typisierten Tabelle, die gelöscht wurden.
Bei der Verwaltung von Datenbankprotokollen sind folgende
Punkte zu beachten:
- Das Numerierungsschema für Archivprotokolldateien beginnt mit
S0000000.LOG und reicht bis S9999999.LOG
(10 000 000 Protokolle). Der Datenbankmanager
beginnt unter folgenden Bedingungen erneut mit der Verwendung des Protokolls
S0000000.LOG:
- Die Konfigurationsdatei der Datenbank wurde geändert, um die
aktualisierende Wiederherstellung zu aktivieren.
- Die Konfigurationsdatei der Datenbank wurde geändert, um die
aktualisierende Wiederherstellung zu inaktivieren.
- Nach Verwendung des Protokolls S9999999.LOG wird wieder die erste
Nummer für das Protokoll verwendet.
Wenn die aktualisierende Wiederherstellung erfolgreich ausgeführt wurde,
wird das letzte bei der aktualisierenden Wiederherstellung verwendete
Protokoll abgeschnitten und die Protokollierung mit dem nächsten sequentiellen
Protokoll fortgesetzt. Dies hat zur Folge, daß jedes Protokoll im
Protokollpfadverzeichnis mit einer Folgenummer, die größer als die des letzten
für die aktualisierende Wiederherstellung verwendeten Protokolls ist, erneut
verwendet wird. Sie müssen eine Kopie der Protokolle erstellen, bevor
Sie den Befehl ROLLFORWARD absetzen (Mit Hilfe eines Benutzer-Exit-Programm
können Sie die Protokolle an eine andere Speicherposition kopieren.)
Es können aus folgenden Gründen doppelte Namen für verschiedene Protokolle
auftreten:
- Der Datenbankmanager beginnt mit der Numerierung von Protokollen wieder
bei S0000000.LOG (wie oben beschrieben).
- Der Datenbankmanager verwendet die Protokollnamen nach dem
Wiederherstellen einer Datenbank (mit und ohne aktualisierende
Wiederherstellung) erneut.
Der Datenbankmanager stellt sicher, daß bei der aktualisierenden
Wiederherstellung kein falsches Protokoll verwendet wird. Er ist jedoch
nicht in der Lage, die Speicherposition des erforderlichen Protokolls zu
ermitteln. Sie müssen sicherstellen, daß die korrekten Protokolle für
die aktualisierende Wiederherstellung zur Verfügung stehen.
- Wenn Sie Protokolldateien an eine andere Speicherposition als die, die
durch den Konfigurationsparameter logpath der Datenbank angegeben
wird, versetzt haben, verwenden Sie den Parameter OVERFLOW LOG PATH des
Befehls ROLLFORWARD, um den zusätzlichen Pfad zu diesen Dateien
anzugeben.
Wenn Sie Änderungen in einer Datenbank oder einem Tabellenbereich
aktualisierend wiederherstellen und die aktualisierende Wiederherstellung das
nächste Protokoll nicht finden kann, wird der Name des Protokolls mit Hinweis
auf die nächste benötigte Protokolldatei im SQL-Kommunikationsbereich (SQLCA)
zurückgegeben und die aktualisierende Wiederherstellung gestoppt. Wenn
zu diesem Zeitpunkt keine weiteren Protokolle verfügbar sind, können Sie die
Verarbeitung mit Hilfe des Befehls ROLLFORWARD stoppen.
Wenn Sie die aktualisierende Wiederherstellung (durch Angabe der Option
STOP im Befehl ROLLFORWARD) beenden und das Protokoll, das den Abschluß einer
Transaktion enthält, nicht auf die Datenbank oder den Tabellenbereich
angewandt wurde, wird die unvollständige Transaktion rückgängig gemacht, um
sicherzustellen, daß die Datenbank oder der Tabellenbereich in einem
konsistenten Status verbleibt.
-
Archivierte Protokolldateien werden im Protokollpfad abgelegt. Der
Protokollpfad ist standardmäßig auf das Unterverzeichnis SQLOGDIR gesetzt,
kann jedoch mit dem Konfigurationsparameter newlogpath geändert
werden. Wenn Sie die Dateien an einer anderen Position ablegen möchten,
können Sie die Datenbank für den Benutzer-Exit aktivieren oder den
Protokollpfad mit dem Konfigurationsparameter newlogpath
ändern. Möglicherweise müssen Sie hierzu den Parameter OVERFLOW LOG
PATH des Befehls ROLLFORWARD verwenden, um die Dateien für eine
aktualisierende Wiederherstellung anzugeben.
- Wenn Sie einen Benutzer-Exit durch Ändern der Konfigurationsdatei der
Datenbank aktivieren, können die archivierten Protokolle auf eine
benutzerdefinierte Speichereinheit (z. B. ein Bandlaufwerk)
umgeleitet werden. Außerdem können Sie ein Benutzer-Exit-Programm
verwenden, um den Speicher der archivierten Protokolle zu verwalten.
Weitere Informationen zu einem Benutzer-Exit-Programm finden Sie in Anhang F, Benutzer-Exit zur Datenbankwiederherstellung.
- Wenn Sie den Parameter newlogpath ändern, hat dies keine
Auswirkungen auf bereits archivierte Protokolle. Sie müssen die
Speicherposition der Protokolle verfolgen.
- Wenn eine Datenbank, die für die aktualisierende Wiederherstellung
aktiviert ist, entweder nur wiederherstellt wird (ohne aktualisierende
Wiederherstellung) oder bis zu einem bestimmten Zeitpunkt aktualisierend
wiederhergestellt wird, kann ein archiviertes Protokoll zwei oder mehreren
verschiedenen Protokollsequenzen einer Datenbank zugeordnet sein, weil die
Protokollnamen wieder verwendet werden. (Abbildung 58 zeigt die Protokolle, die erstellt werden. Wenn Sie
mit "Sicherung 2" eine Wiederherstellung ausführen wollen, ist besondere
Vorsicht geboten, da es zwei Protokollsequenzen gibt, die verwendet werden
könnten.) Vor dem Löschen eines archivierten Protokolls müssen Sie
unbedingt sicherstellen, daß Sie es tatsächlich nicht mehr benötigen.
Abbildung 58. Erneutes Verwenden der Namen von Protokolldateien

- Wenn Sie während einer vollständigen Wiederherstellung der Datenbank die
aktualisierende Wiederherstellung bis zu einem bestimmten Zeitpunkt ausführen
und dann mitten in den Protokollen stoppen, beginnen Sie eine neue
Protokollsequenz. Es ist nicht möglich, die beiden Protokollsequenzen
miteinander zu kombinieren. Wenn Sie über eine Online-Sicherung
verfügen, die sich über die erste Protokollsequenz erstreckt, müssen Sie die
aktualisierende Wiederherstellung anhand der ersten Protokollsequenz
beenden.
- Wenn Sie nach der Wiederherstellung eine neue Protokollsequenz erstellt
haben, werden Tabellenbereichssicherungen in den alten Protokollsequenzen
ungültig gemacht. In diesem Fall weist die RESTORE-Operation die
Sicherungskopien der Tabellenbereiche zurück. In manchen Situationen
kann RESTORE nicht erkennen, daß die Sicherungen nicht mehr gültig sind
(insbesondere bei Online-Sicherungen), und die Wiederherstellung wird trotzdem
erfolgreich ausgeführt. In diesem Fall schlägt jedoch die
aktualisierende Wiederherstellung für den Tabellenbereich fehl und dieser
verbleibt im Status "Aktualisierende Wiederherstellung anstehend".
In der vorangegangenen Abbildung wird davon ausgegangen, daß eine Sicherung
eines Tabellenbereichs, Sicherung 3, in der oberen Protokollsequenz zwischen
S0000013.LOG und S0000014.LOG beendet
wurde. Angenommen, mit Sicherung 2 der Datenbank würde eine
Wiederherstellung sowie eine aktualisierende Wiederherstellung ausgeführt,
dann müßte die aktualisierende Wiederherstellung bis
S0000012.LOG erfolgen. In Anschluß daran könnte die
aktualisierende Wiederherstellung entweder über die obere Protokollsequenz
oder über die neuere, untere Protokollsequenz fortgeführt werden. Bei
einer aktualisierenden Wiederherstellung mit der unteren Protokollsequenz wäre
es nicht möglich, die Sicherung 3 des Tabellenbereichs zu verwenden, um eine
Wiederherstellung des Tabellenbereichs und eine anschließende aktualisierende
Wiederherstellung auszuführen.
Um mit Sicherung 3 des Tabellenbereichs eine aktualisierende
Wiederherstellung des Tabellenbereichs bis zum Protokollende ausführen zu
können, müßte zunächst eine Wiederherstellung mit Sicherung 2 der Datenbank
erfolgen. Anschließend könnte dann die obere Protokollsequenz verwendet
werden. Nach der Wiederherstellung der Sicherung 3 des Tabellenbereichs
wäre es möglich, eine aktualisierende Wiederherstellung bis zum Ende der
Protokolle anzufordern.
- Ein Protokoll verwendet eine Zeitmarke, die der Beendigung der
Arbeitseinheit zugeordnet ist. Die Zeitmarke in den Protokollen
verwendet die koordinierte Weltzeit (CUT = Coordinated Universal Time).
Dieses Verfahren hilft dabei, zu verhindern, daß verschiedenen Protokollen
dieselbe Zeitmarke zugewiesen wird (z. B. aufgrund des
Wechsels zur Sommerzeit). Die Zeitmarke, die in der Sicherung verwendet
wird, basiert auf der Ortszeit. Infolgedessen müssen Sie beim Aufrufen
des Befehls ROLLFORWARD die Zeitangabe in koordinierter Weltzeit (entspricht
der westeuropäischen Zeit) vornehmen.
Anmerkung: | Das Sonderregister CURRENT TIMEZONE enthält den Unterschied zwischen der
westeuropäischen Zeit (Weltzeit) und der Ortszeit der Datenbank auf dem
Anwendungs-Server. Die Ortszeit entspricht der westeuropäischen Zeit
(bzw. Weltzeit) plus dem Inhalt des Sonderregisters CURRENT
TIMEZONE.
|
Sie können für das Datenbankprotokoll eine unformatierte
Einheit (Raw-Einheit) verwenden. Dies hat Vor- und Nachteile.
- Es gibt die folgenden Vorteile:
- Sie können mehr als 26 physische Laufwerke an das System
anschließen.
- Die Länge des Datei-E/A-Pfads ist kürzer. Dies kann zu einer
verbesserten Systemleistung führen. Sie sollten Vergleichstests
durchführen, um festzustellen, ob es meßbare Vorteile für Ihre
Systemauslastung gibt.
- Es gibt die folgenden Nachteile:
- Die Einheiten können nicht von anderen Anwendungen mitverwendet
werden. Die gesamte Einheit muß DB2 zugeordnet sein.
- Die Einheit kann von keinen Dienstprogramm des Betriebssystems oder einem
Tool anderer Hersteller verwendet werden, die auf die Einheit sichern oder von
der Einheit kopieren würden.
- Sie können leicht das Dateisystem auf einem vorhandenen Laufwerk löschen,
wenn Sie die falsche Nummer für das physische Laufwerk angeben.
Sie können ein Protokoll auf einer unformatierten Einheit mit dem
Datenbankkonfigurationsparameter newlogpath konfigurieren.
Weitere Informationen zur Syntax bei der Angabe einer unformatierten Einheit
finden Sie in Direkter Plattenzugriff (Raw I/O). Vorher sollten Sie die oben aufgeführten Vor- und
Nachteile abwägen. Außerdem sollten Sie die folgenden Aspekte
berücksichtigen:
- Nur eine Einheit ist zulässig. Sie können die Einheit über mehrere
Platten hinweg auf Betriebssystemebene definieren. DB2 führt einen
Betriebssystemaufruf aus, um die Größe der Einheit in 4-KB-Seiten zu
ermitteln.
Wenn Sie mehrere Platten verwenden, wird dadurch eine größere Einheit
bereitgestellt, und das resultierende plattengreifende Lesen und Schreiben von
Daten kann aufgrund des schnelleren E/A-Durchsatzes zu einer
Leistungssteigerung führen.
- DB2 versucht, auf die letzte 4-KB-Seite der Einheit zu schreiben.
Wenn die Einheit größer als 2 GB ist, schlägt der Versuch, auf die letzte
Seite zu schreiben, bei Betriebssystemen fehl, die keine Unterstützung für
Einheiten bereitstellen, die größer als 2 GB sind. In diesem Fall
versucht DB2, alle Seiten bis zur unterstützten Begrenzung zu
verwenden.
Mit Hilfe der Informationen zur Größe der Einheit wird die Einheitengröße
(in 4-KB-Seiten) angegeben, die für DB2 bei Unterstützung durch das
Betriebssystem zur Verfügung steht. Die Menge von Plattenspeicherplatz,
auf die DB2 schreiben kann, wird als verfügbare Einheitengröße
bezeichnet.
Die erste 4-KB-Seite der Einheit wird von DB2 nicht verwendet (dieser
Speicherbereich wird in der Regel vom Betriebssystem für andere Zwecke
verwendet). Dies bedeutet, daß der für DB2 verfügbare
Gesamtspeicherbereich Einheitengröße = verfügbare Einheitengröße -
1 ist.
- Der Parameter logsecond wird nicht verwendet. DB2 ordnet
keine sekundären Protokolle zu. Die Größe des aktiven
Protokollspeicherbereichs ist die Anzahl von 4-KB-Seiten, die sich aus
logprimary x logfilsiz ergibt.
- Protokollsätze werden weiterhin in Protokollspeicherbereichen gruppiert,
wobei jeder eine Protokolldateigröße (logfilsiz) von 4-KB-Seiten
hat. Protokollspeicherbereiche werden nacheinander in die unformatierte
Einheit plaziert. Jeder Speicherbereich besteht zudem aus zwei
zusätzlichen Seiten für den Kennsatz des Speicherbereichs. Dies
bedeutet, daß sich die Anzahl verfügbarer
Protokollspeicherbereiche, die die Einheit unterstützen kann, aus
Einheitengröße / (logfilsiz+ 2) berechnen läßt.
- Die Einheit muß groß genug sein, um den aktiven Protokollspeicherbereich
unterstützen zu können. Das heißt, daß die Anzahl verfügbarer
Protokollspeicherbereiche größer als der (oder gleich dem) Wert sein
muß, der für den Konfigurationsparameter logprimary angegebenen
ist.
- Bei Verwendung eines Umlaufprotokolls legt der Konfigurationsparameter
logprimary die Anzahl von Protokollspeicherbereichen fest, die auf
die Einheit geschrieben werden. Dies kann zu freiem Speicherplatz auf
der Einheit führen.
- Bei Verwendung von Protokollspeicherung (logretain) ohne
Benutzer-Exit empfangen alle Operationen, die zu einer Aktualisierung führen,
nach Ausschöpfung der Anzahl verfügbarer Protokollspeicherbereiche
die Fehlernachricht, daß das Protokoll voll ist. Zu diesem Zeitpunkt
müssen Sie die Datenbank schließen und eine Offline-Sicherung erstellen, um
die Wiederherstellungsfähigkeit sicherzustellen. Nach der
Datenbanksicherung gehen die auf die Einheit geschriebenen Protokollsätze
verloren. Dies bedeutet, daß Sie eine frühere Datenbanksicherung nicht
zur Wiederherstellung der Datenbank und zur anschließenden aktualisierenden
Wiederherstellung verwenden können. Wenn Sie eine Datenbanksicherung
vor der Ausschöpfung der Anzahl verfügbarer
Protokollspeicherbereiche erstellen, können Sie die Datenbank
wiederherstellen und aktualisierend wiederherstellen.
- Bei Verwendung von Protokollspeicherung (logretain) mit
Benutzer-Exit wird das Benutzer-Exit-Programm für jeden
Protokollspeicherbereich aufgerufen, wenn er mit Protokollsätzen gefüllt
ist. Das Benutzer-Exit-Programm muß die Einheit lesen und das
Archivprotokoll als Datei speichern können. DB2 ruft keinen
Benutzer-Exit auf, um Protokolldateien für eine unformatierte Einheit
abzurufen. Statt dessen liest DB2 während der aktualisierenden
Wiederherstellung den Kennsatz des Speicherbereichs, um zu ermitteln, ob die
unformatierte Einheit die zu verwendende Protokolldatei enthält. Wenn
die erforderliche Protokolldatei nicht in der unformatierten Einheit gefunden
wird, sucht DB2 im Überlaufprotokollpfad. Wenn die Protokolldatei auch
dort nicht gefunden wird, ruft DB2 den Benutzer-Exit auf, um die
Protokolldatei in den Überlaufprotokollpfad abzurufen. Wenn Sie für den
Befehl rollforward keinen Überlaufprotokollpfad angeben, ruft DB2
den Benutzer-Exit zum Abrufen des Protokolls während der Operationen zur
aktualisierenden Wiederherstellung nicht auf. Zusätzliche Informationen
zum Aufrufen des Benutzer-Exit-Programms finden Sie in Aufrufformat für auf UNIX basierende Betriebssysteme oder Windows NT.
- Wenn Sie DataPropagator Relational verwenden und Protokolle auf eine
unformatierte Einheit schreiben, ruft die API zum Lesen des Protokolls den
Benutzer-Exit zum Abrufen der Protokolldateien nicht auf. Angeforderte
Protokollsätze werden jedoch weiterhin zurückgegeben, sofern sie auf der
Einheit verfügbar sind. Wenn Sie Protokolle anfordern, die den ältesten
auf der Einheit zeitlich vorangehen, werden sie nicht zurückgegeben (diese
Arbeitsweise ähnelt der von DB2, wenn die Protokolldatei nicht auffindbar ist,
die die angeforderten Protokollsätze enthält).
Anmerkungen:
- Es wird empfohlen, DataPropagator Relational bei Verwendung einer
unformatierten Einheit zum Protokollieren nicht einzusetzen.
- Wenn Sie die API sqlurlog verwenden, sollten Sie keine unformatierte
Einheit zum Protokollieren einsetzen.
- Beim Löschen einer Datenbank werden alle Protokolle im aktuellen
Verzeichnis des Protokollpfads der Datenbank gelöscht. Vor dem Löschen
einer Datenbank sollten Sie eventuell Kopien der Protokolle anlegen.
- Wenn Sie eine Datenbank bis zu einem bestimmten Zeitpunkt aktualisierend
wiederherstellen, werden das letzte Protokoll, das bei der aktualisierenden
Wiederherstellung verwendet wurde, und alle vorhandenen nachfolgenden
Protokolle erneut verwendet. Sie büßen dadurch die Möglichkeit ein,
eine Wiederherstellung auszuführen, die über den angegebenen Zeitpunkt
hinausgeht. Aus diesem Grund sollten Sie alle Protokolle im aktuellen
Verzeichnis des Protokollpfads der Datenbank kopieren, bevor Sie
mit einer Wiederherstellung bis zu einem bestimmten Zeitpunkt beginnen.
Bei Beendigung der aktualisierenden Wiederherstellung wird die
Protokolldatei mit der zuletzt festgeschriebenen Transaktion abgeschnitten,
und die Protokollierung beginnt mit dem nächsten sequentiellen
Protokoll. Wenn Sie weder über eine Kopie des Protokolls, die vor dem
Abschneiden erstellt wurde, noch über Protokolle mit höheren Folgenummern
verfügen, können Sie keine Wiederherstellung der Datenbank über den
angegebenen Zeitpunkt hinaus ausführen. (Sobald nach einer
aktualisierenden Wiederherstellung wieder die normalen Datenbankaktivitäten
stattfinden, werden neue Protokolle erstellt, die dann für nachfolgende
Wiederherstellungen verwendet werden können.)
- Wenn Sie das Protokollpfadverzeichnis ändern und anschließend das
Unterverzeichnis entfernen oder in dem im Protokollpfad angegebenen
Unterverzeichnis befindliche Protokolle löschen, sucht der Datenbankmanager
beim Öffnen der Datenbank im Standardprotokollpfad SQLOGDIR nach den
Protokollen. Falls die Protokolle nicht auffindbar sind, wird die
Datenbank in den Status "Sicherung anstehend" versetzt. In diesem
Fall müssen Sie eine Datenbanksicherung durchführen, damit die Datenbank
wieder verwendbar ist.
Diese Sicherung muß auch dann ausgeführt werden, wenn das Unterverzeichnis
leere Protokolle enthielt.
- Wenn Sie das Protokoll verlieren, das den Endzeitpunkt der
Online-Sicherung enthält, und eine aktualisierende Wiederherstellung des
entsprechenden wiederhergestellten Abbilds ausführen, ist die Datenbank nicht
mehr verwendbar. Um die Datenbank wieder verwendbar zu machen, müssen
Sie sie mit einer anderen Sicherung und allen zugehörigen Protokollen
wiederherstellen.
Stellen Sie sich beispielsweise folgende Situation vor: Sie möchten
eine Wiederherstellung einer vollständigen Datenbank bis zu einem bestimmten
Zeitpunkt ausführen, befürchten jedoch, daß während des
Wiederherstellungsprozesses ein Protokoll verlorengehen könnte. (Eine
solche Situation könnte eintreten, wenn es eine große Anzahl archivierter
Protokolle zwischen dem Zeitpunkt des letzten Sicherungsabbilds der Datenbank
und dem Zeitpunkt gibt, bis zu dem die Wiederherstellung durchgeführt werden
soll.)
Als erstes sollten Sie alle gültigen Protokolle an eine "sichere"
Speicherposition kopieren. Anschließend könnten Sie den Befehl RESTORE
ausführen und die Datenbank bis zum gewünschten Zeitpunkt aktualisierend
wiederherstellen. Falls bei diesem Prozeß Protokolle beschädigt werden
oder verlorengehen, können Sie auf die an anderer Stelle gespeicherten
Sicherungskopien aller Protokolle zurückgreifen.
[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]