DB2 Universal Database - Systemverwaltung


Wiederherstellungsmethode: aktualisierende Wiederherstellung

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.

Überlegungen zur Sicherung

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:

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.

Überlegungen zur Wiederherstellung

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:

Aktualisierendes Wiederherstellen von Änderungen in einer Datenbank

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

SQLD0RFL

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.

Konfigurationsparameter für die Datenbankprotokollierung

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:

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.

Aktualisierendes Wiederherstellen von Änderungen in einem Tabellenbereich

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:

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:

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.

Planen der Verwendung des Befehls ROLLFORWARD

Vor der Verwendung des Befehls ROLLFORWARD sind folgende Punkte zu beachten:

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.

Aufrufen des Befehls ROLLFORWARD

Vor dem Aufrufen des Befehls ROLLFORWARD sind einige Punkte zu beachten:

Verwenden der Datei mit den Angaben zur Speicherposition der Ladekopie

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:

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:

  1. In einer partitionierten Datenbankumgebung muß sich die Variable DB2LOADREC der Profilregistrierdatenbank in der Datei db2profile befinden.

  2. In einer partitionierten Datenbankumgebung muß die Datei der Ladekopie auf jedem Datenbankpartitions-Server vorhanden und der Dateiname (einschließlich des Pfads) derselbe sein.

  3. 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:

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.

Wiederherstellen einer gelöschten Tabelle

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:

  1. 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.
  2. Führen Sie die Wiederherstellung auf Datenbank- oder Tabellenbereichsebene mit einer Sicherungskopie aus, die vor dem Löschen erstellt wurde.
  3. 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.
  4. Erstellen Sie die Tabelle mit der Anweisung CREATE TABLE aus der Datei des Wiederherstellungsprotokolls erneut.
  5. 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:

Überlegungen zur Verwaltung von Protokolldateien

Bei der Verwaltung von Datenbankprotokollen sind folgende Punkte zu beachten:

Verwenden von Protokollen auf unformatierten Einheiten

Sie können für das Datenbankprotokoll eine unformatierte Einheit (Raw-Einheit) verwenden. Dies hat Vor- und Nachteile.

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:

Verlust von Protokollen

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 ]