Release-Informationen

|13.3 Verwendung der zurückgestellten Ein-/Ausgabe für Datenbankwiederherstellung

| | | | |

|Die unten aufgeführten Informationen zum Dienstprogramm db2inidb |haben Vorrang vor den Informationen im Handbuch Neue Funktionen von |Version 7.2.

|db2inidb ist ein Tool, das mit DB2 geliefert wird und das |Wiederherstellungen nach Systemabstürzen durchführen oder eine Datenbank in |den Status "Aktualisierende Wiederherstellung anstehend" setzen |kann.

|Die zurückgestellte Ein-/Ausgabe unterstützt fortlaufende |Systemverfügbarkeit, indem sie eine vollständige Implementierung für die |Handhabung der Onlineteilung einer Spiegeldatenbank, d. h. |Teilung einer Spiegeldatenbank ohne Herunterfahren der Datenbank, |bietet. Wenn Sie sich keine Offline- oder Onlinesicherungen einer |großen Datenbank leisten können, können Sie Sicherungen oder Systemkopien von |einem Spiegelimage mit Hilfe zurückgestellter Ein-/Ausgabe und eines Image |einer geteilten Spiegeldatenbank erstellen.

|Zurückgestellte E/A verhindert das Schreiben auf Platte, während das Image |der geteilten Spiegeldatenbank einer Datenbank erstellt wird. Neben der |Onlinesicherung und -wiederherstellung sollten alle Datenbankoperationen |normal funktionieren, während eine Datenbank zurückgestellt ist. Einige |Operationen warten jedoch eventuell darauf, dass E/A-Schreibvorgänge |fortgesetzt werden, wenn benutzte Seiten aus dem Pufferpool auf Platte |geschrieben oder Puffer protokolliert werden müssen. Diese Operationen |sollten normal fortgesetzt werden, sobald die Datenbank-E/A wieder aufgenommen |wird. Es ist wichtig, dass die Datenbank-E/A von derselben Verbindung |wieder aufgenommen wird, von der sie ursprünglich zurückgestellt wurde. |Andernfalls können nachfolgende Verbindungsversuche blockieren, wenn sie das |Schreiben benutzter Seiten aus dem Pufferpool auf Platte erfordern. |Diese Verbindungen werden beendet, sobald die Ein-/Ausgabe der Datenbank |fortgesetzt wird. Wenn Ihre Verbindungsversuche blockieren und es |unmöglich ist, die Ein-/Ausgabe von der Verbindung fortzusetzen, die Sie zum |Zurückstellen verwendet haben, müssen Sie eine Wiederherstellung nach |Systemabsturz mit der Option WRITE RESUME des Befehls RESTART |durchführen.

|In einer Umgebung mit partitionierten Datenbanken müssen Sie |E/A-Schreibvorgänge nicht auf allen Partitionen gleichzeitig |zurückstellen. Sie können eine Untermenge mit einer oder mehreren |Partitionen zurückstellen, um geteilte Spiegeldatenbanken für |Offlinesicherungen zu erstellen. Wenn der Katalogknoten in der |Untermenge enthalten ist, muss er als letzte Partition zurückgestellt |werden.

|Beim Spiegeln einer Datenbank wird vor allem der gesamte Inhalt des |Datenbankverzeichnisses und des lokalen Datenbankverzeichnisses |kopiert. Das lokale Datenbankverzeichnis, sqldbdir, befindet |sich auf derselben Ebene der Dateistruktur wie das |Hauptdatenbankverzeichnis. Wenn das Protokollverzeichnis und die |Tabellenbereichsbehälter sich nicht im Datenbankverzeichnis befinden, müssen |sie ebenfalls kopiert werden. Da die geteilte Spiegeldatenbank von |diesen Verzeichnispfaden abhängt, müssen die Pfade, in die diese Verzeichnisse |kopiert werden, identisch mit denen auf dem primären System sein. Dies |bedeutet, dass das Exemplar ebenfalls das gleiche sein muss. Als |Ergebnis dieser Abhängigkeit ist es nicht möglich, eine Spiegeldatenbank auf |demselben System wie die primäre Datenbank zu erstellen, sofern nicht die neue |Option "relocate" des Tools db2inidb verwendet wird.

|Die Option "relocate" ermöglicht es, eine Datenbank auf einem |bestimmten System mit einer angegebenen Konfigurationsdatei zu |verlagern. Dies kann das Ändern des internen Datenbankverzeichnisses, |des Behälterverzeichnisses, des Protokollverzeichnisses, des Exemplarnamens |und der Datenbanknamen umfassen. Wenn das Datenbankverzeichnis, die |Behälterverzeichnisse und das Protokollverzeichnis erfolgreich auf andere |Verzeichnispfade auf demselben System wie die primäre Datenbank gespiegelt |wurden, kann das Tool db2inidb zusammen mit der Option |"relocate" verwendet werden, um die internen Pfade der gespiegelten |Datenbnak zu aktualisieren. Ein Nutzungsszenario mit dieser Option |finden Sie weiter unten.

|Je nachdem, wie die Speichereinheiten gespiegelt werden, ist die Verwendung |von db2inidb unterschiedlich. Im Folgenden wird davon |ausgegangen, dass die gesamte Datenbank konsistent im Speichersystem |gespiegelt wird.

|In einer Umgebung mit mehreren Knoten muss das Tool |db2inidb auf jeder Partition ausgeführt werden, bevor die geteilte |Spiegeldatenbank von einer der Partitionen verwendet werden kann. Das |Tool db2inidb kann mit dem Befehl db2_all auf allen |Partitionen gleichzeitig ausgeführt werden. |

|
|Erstellen einer Klondatenbank
|Das Ziel ist, einen Klon der primären Datenbank zu erhalten, der auf einem |anderen System verwendet werden kann. Die folgende Prozedur beschreibt, |wie eine Klondatenbank erstellt werden kann: |
1. |Stellen Sie E/A-Schreibvorgänge in der primären Datenbank mit folgendem |Befehl zurück:
```
|     db2 set write suspend for database
```
2. |Verwenden Sie Betriebssystem- und Plattensubsystembefehle zum |Heraustrennen der Spiegeldatenbank aus der primären Datenbank. Stellen |Sie sicher, dass Sie die Daten und die Protokolle teilen.
3. |Nehmen Sie E/A-Schreibvorgänge in der primären Datenbank mit folgendem |Befehl wieder auf:
```
|     db2 set write resume for database
```
  |Nach dem Ausführen des Befehls sollte die primäre Datenbank wieder im |normalen Zustand sein.
4. |Hängen Sie die geteilte Spiegeldatenbank der primären Datenbank auf einem |anderen System an.
5. |Starten Sie das Datenbankexemplar auf dem anderen System mit folgendem |Befehl:
```
|     db2start
```
6. |Starten Sie die DB2-Wiederherstellung nach Systemabsturz mit folgendem |Befehl:
```
|db2inidb datenbankname AS SNAPSHOT
```
  |Anmerkung:
  Dieser Befehl entfernt den Status des zurückgestellten Schreibens und macht |die Änderungen von Transaktionen rückgängig, die zum Zeitpunkt der Teilung |abliefen. |
  |
|Sie können diesen Prozess auch für eine Offlinesicherung verwenden. |Wenn sie jedoch in der primären Datenbank wiederhergestellt wird, kann diese |Sicherung nicht mehr zur aktualisierenden Wiederherstellung verwendet werden, |da die Protokollkette nicht übereinstimmt.

|
|Verwenden der geteilten Spiegeldatenbank als |Bereitschaftsdatenbank
|Während die gespiegelte (Bereitschafts-)Datenbank ständig über die |Protokolle aktualisierend wiederhergestellt wird, werden neue Protokolle, die |von der primären Datenbank erstellt werden, ständig vom primären System |abgerufen. Die folgende Prozedur beschreibt, wie die geteilte |Spiegeldatenbank als Bereitschaftsdatenbank verwendet werden kann: |
1. |Stellen Sie E/A-Schreibvorgänge in der primären Datenbank zurück:
```
|	db2 set write suspend for database
```
2. |Verwenden Sie Betriebssystem- und Plattensubsystembefehle zum |Heraustrennen der Spiegeldatenbank aus der primären Datenbank. Stellen |Sie sicher, dass Sie nur die Daten und nicht die Protokolle teilen.
3. |Setzen Sie die E/A-Schreibvorgänge in der primären Datenbank fort, so dass |sie zurück in die normale Verarbeitung wechselt.
```
|	db2 set write resume for database
```
4. |Hängen Sie die geteilte Spiegeldatenbank der Datenbank auf einem anderen |System an.
5. |Starten Sie das primäre Datenbankexemplar mit dem Befehl |db2start.
6. |Setzen Sie die Spiegeldatenbank in den Status "Aktualisierende |Wiederherstellung anstehend", und stellen Sie die Spiegeldatenbank |aktualisierend wieder her:
```
|	db2inidb datenbankname AS STANDBY
```
  |
  |Anmerkung:
  Dieser Befehl entfernt den Status des zurückgestellten Schreibens und setzt |die gespiegelte Datenbank in den Status "Aktualisierende Wiederherstellung |anstehend". |
7. |Kopieren Sie Protokolle, indem Sie ein Benutzer-Exit-Programm einrichten, |um Protokolldateien vom primären System abzurufen, damit sichergestellt ist, |dass die neuesten Protokolle für diese gespiegelte Datenbank verfügbar |sind.
8. |Stellen Sie die Datenbank bis zum Ende der Protokolle aktualisierend |wieder her.
9. |Kehren Sie zurück zu Schritt f, und wiederholen Sie diesen Prozess, bis |die primäre Datenbank inaktiv ist.
10. |Stellen Sie die Datenbank bis zum Ende der Protokolle aktualisierend |wieder her. Verwenden Sie dabei die Option AND STOP, um die Datenbank |wieder in den Onlinestatus zu setzen. Die Datenbank kann jetzt |verwendet werden. |

|
|Verwenden der geteilten Spiegeldatenbank als Sicherungsimage
|Die folgende Prozedur beschreibt, wie die gespiegelte Datenbank als |Sicherungsimage zur Wiederherstellung über die primäre Datenbank verwendet |werden kann: |
1. |Stoppen Sie das primäre Datenbankexemplar mit dem Befehl |db2stop.
2. |Verwenden Sie Betriebssystem- und Plattensubsystembefehle, um die |gespiegelten Daten zurück über die primäre Datenbank zu kopieren. |Kopieren Sie die Protokolldatei nicht zurück. Die Protokolle auf der |primären Datenbank müssen für aktualisierende Wiederherstellungen verwendet |werden.
3. |Starten Sie das primäre Datenbankexemplar mit dem Befehl |db2start.
4. |Führen Sie den folgenden Befehl aus, um die gespiegelte Datenbank in den |Status "Aktualisierende Wiederherstellung anstehend" zu setzen und das |zurückgestellte Schreiben zu beenden:
```
|db2inidb datenbankname AS MIRROR
```
5. |Stellen Sie die Datenbank bis zum Ende der Protokolle aktualisierend |wieder her. Verwenden Sie dabei die Option AND STOP, um die Datenbank |wieder in den Onlinestatus zu setzen. Die Datenbank kann jetzt |verwendet werden. |

|
|Teilen einer Spiegeldatenbank auf demselben System wie die primäre |Datenbank
|Die folgende Prozedur beschreibt, wie Sie die Option "relocate" des |Tools db2inidb zum Spiegeln einer Datenbank auf demselben System |wie die primäre Datenbank verwenden können. Bei dem Beispiel wird davon |ausgegangen, dass die Datenbank unter einem neuen Exemplar verwendet |wird. |
1. |Erstellen Sie ein neues Exemplar auf dem aktuellen System.
2. |Stellen Sie E/A-Schreibvorgänge in der primären Datenbank zurück:
```
|	db2 set write suspend for database
```
3. |Verwenden Sie Betriebssystem- und Plattensubsystembefehle zum |Heraustrennen der Spiegeldatenbank aus der primären Datenbank.
  |Anmerkung:
  Das Datenbankverzeichnis, das lokale Datenbankverzeichnis, die |Behälterverzeichnisse und das Protokollverzeichnis müssen in das neue Exemplar |kopiert werden. Wenn die Behälterverzeichnisse oder das |Protokollverzeichnis unter dem Datenbankverzeichnis vorhanden sind, müssen nur |das Datenbankverzeichnis und das lokale Datenbankverzeichnis kopiert |werden. |
4. |Setzen Sie die E/A-Schreibvorgänge in der primären Datenbank fort, so dass |sie zurück in die normale Verarbeitung wechselt:
```
|	db2 set write resume for database
```
5. |Erstellen Sie eine Konfigurationsdatei mit den folgenden |Informationen:
  | DB_NAME=name,optionaler-neuer-name
  | DB_PATH=primärer-db-verzeichnispfad,gespiegelter-db-verzeichnispfad
  | INSTANCE=primäres-exemplar,gespiegeltes-exemplar
  | LOG_DIR=primäres-db-protokollverzeichnis,gespiegeltes-db-protokollverzeichnis
  | CONT_PATH=pfad-für-primären-db-behälter-#1,
  | pfad-für-gespiegelten-db-behälter-#1 ...
  | CONT_PATH=pfad-für-primären-db-behälter-#n,
  | pfad-für-gespiegelten-db-behälter-#n
  | NODENUM=knoten-#
  
  |
  |Anmerkung:
  Die Felder LOG_DIR und CONT_PATH sind nur erforderlich, wenn das |Protokollverzeichnis und die Behälterverzeichnisse sich nicht im |Datenbankverzeichnis befinden. Alle anderen Felder sind erforderlich, |mit Ausnahme von NODENUM, das standardmäßig den Wert null verwendet, wenn |nichts anderes angegeben ist. |
6. |Starten Sie die Datenbank vom neu erstellten Exemplar:
```
|	db2start
```
7. |Verlagern Sie die gespiegelte Datenbank, heben Sie den |Zurücksetzungsstatus auf, und setzen Sie die Spiegeldatenbank in den Status |"Aktualisierende Wiederherstellung anstehend":
```
|	db2inidb datenbankname as STANDBY relocate using konfigurationsdatei
```
8. |Kopieren Sie Protokolle, indem Sie ein Benutzer-Exit-Programm einrichten, |das Protokolldateien von der primären Datenbank abruft, damit sichergestellt |ist, dass die neuesten Protokolle für diese gespiegelte Datenbank verfügbar |sind.
9. |Stellen Sie die Datenbank bis zum Ende der Protokolle aktualisierend |wieder her.
10. |Kehren Sie zurück zu Schritt h, und wiederholen Sie diesen Prozess, bis |die primäre Datenbank inaktiv ist.
11. |Stellen Sie die Datenbank bis zum Ende der Protokolle aktualisierend |wieder her. Verwenden Sie dabei die Option AND STOP, um die Datenbank |wieder in den Onlinestatus zu setzen. Die Datenbank kann jetzt |verwendet werden. |
|

[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]