Wiederherstellungsmodelle für DB2

In DB2 können für Geodatabases folgende Arten der Wiederherstellung verwendet werden: Versionswiederherstellung (verwendet Umlaufprotokollierung), aktualisierende Wiederherstellung (verwendet Archivprotokollierung) und High Availability Disaster Recovery (HADR).

Hinweis:

Stellen Sie bei der Wiederherstellung einer Geodatabase in ArcSDE for DB2 for z/OS sicher, dass alle Datenbanken wiederhergestellt werden, die Teil der ArcSDE-Geodatabase sind.

• Versionswiederherstellung und Umlaufprotokollierung

  Bei der Umlaufprotokollierung werden Datenbankänderungen in einem "Ring" von Protokolldateien aufgezeichnet. Wenn das letzte Protokoll im Ring voll ist, wird wieder die erste Datei verwendet. Da Transaktionsinformationen überschrieben werden können, ist bei Verwendung der Umlaufprotokollierung keine aktualisierende Wiederherstellung möglich. Beim Laden von Daten ist jedoch normalerweise keine Wiederherstellung erforderlich. Die Umlaufprotokollierung ist das Standardprotokollierungsmodell.

• Aktualisierende Wiederherstellung und Archivprotokollierung

  Die aktualisierende Wiederherstellung ist die empfohlene Wiederherstellungsmethode für ArcSDE-Geodatabases. Wenn Sie diese Methode verwenden möchten, verwenden Sie die Archivprotokollierung. Bei der Archivprotokollierung werden die Protokolldateien nicht überschrieben, sondern es werden zusätzliche Protokolle erstellt, um alle seit der letzten Sicherung erfolgten Transaktionen aufzuzeichnen. Für die Archivprotokollierung ist mehr Festplattenspeicher erforderlich, da die Protokolle nicht wie bei der Umlaufprotokollierung immer wieder verwendet werden.

• HADR

  HADR (High-Availability Disaster Recovery) ist eine in DB2 verfügbare Funktion zur Datenbankreplikation. Zum Schutz der Daten werden Datenänderungen von einer Quelldatenbank (auch als Primärdatenbank bezeichnet) in eine Zieldatenbank (auch als Bereitschaftsdatenbank bezeichnet) repliziert. Wenn die Primärdatenbank ausfällt, können Sie zur Bereitschaftsdatenbank wechseln und mit dieser weiterarbeiten, während Sie die Primärdatenbank wiederherstellen.

  Für HADR können drei Synchronisierungsmodi angegeben werden: synchron, fast synchron und asynchron.

  Im synchronen Modus werden an der Primärdatenbank vorgenommene Änderungen erst dann in die Primärdatenbank übernommen, wenn die zugehörigen Protokolle in die Transaktionsprotokolle in der Bereitschaftsdatenbank geschrieben wurden. Dies sorgt dafür, dass die beiden Datenbanken synchron bleiben, denn es werden nur solche Änderungen in die Primärdatenbank aufgenommen, die in einer Protokolldatei in der Bereitschaftsdatenbank gespeichert sind (und somit wiederhergestellt werden können). In diesem Modus wird die Leistung der Primärdatenbank am stärksten beeinträchtigt.

  Im fast synchronen Modus werden an der Primärdatenbank vorgenommene Änderungen erst dann in die Primärdatenbank übernommen, wenn die zugehörigen Protokolle in den Speicher der Bereitschaftsdatenbank geschrieben wurden. Diese Methode ist fast genauso effektiv wie der synchrone Modus, wirkt sich jedoch weniger nachteilig auf die Leistung der Primärdatenbank aus. Falls jedoch die Bereitschaftsdatenbank ausfällt, nachdem die Daten in die Primärdatenbank übernommen wurden, gehen die übertragenen Daten möglicherweise verloren, und die beiden Datenbanken sind nicht mehr konsistent.

  Übernahmen (COMMIT) von Datenbanktransaktionen in die Primärdatenbank sind von der Übermittlung von Protokolldatensätzen an die Bereitschaftsdatenbank nicht betroffen. In diesem Modus besteht ein höheres Risiko, dass die Daten in den beiden Datenbanken inkonsistent werden. In DB2 können noch weitere Replikationsverfahren genutzt werden, z. B. SQL Replication und Q Replication. Weitere Informationen finden Sie in der DB2-Dokumentation.

Zur Wiederherstellung einer Geodatabase können Sie den Befehl RECOVER DATABASE oder den Assistenten zum Wiederherstellen einer Datenbank in der DB2-Steuerzentrale verwenden. Die Geodatabase kann in eine vorhandene oder eine neue Datenbank wiederhergestellt werden. Die folgenden Hinweise betreffen die Wiederherstellung in eine neue Datenbank:

• Bei der Wiederherstellung in eine neue Datenbank müssen Sie mit der Instanz verbunden sein.
• Wenn Sie die Datenbank in eine neue Datenbank auf einem anderen Server wiederherstellen und der Quell- und der Zielserver nicht die gleiche Standardcodeseite verwenden, müssen Sie zunächst auf dem Zielserver eine Datenbank mit der richtigen Codeseite erstellen, bevor Sie die Wiederherstellung durchführen können. Andernfalls wird im Wiederherstellungsdienstprogramm von der Standardcodeseite ausgegangen, wenn Produktionscodeseite und Quellcodeseite unterschiedlich sind. Dies führt zu einem SQL2548N-Fehler.
• Bei der Wiederherstellung in eine neue Datenbank wird die Wiederherstellungsverlaufsdatei des Sicherungsimages zur Wiederherstellungsverlaufsdatei der neuen Datenbank.

Wenn Sie eine vollständige Datenbankwiederherstellung einer wiederherstellbaren Datenbank durchführen, darf nur eine Verbindung zu der Datenbank bestehen, nämlich die, die beim Wiederherstellen der Datenbank hergestellt wird. Beim Wiederherstellen einer vollständigen Datenbanksicherung wird von DB2 überprüft, ob alle im Sicherungsimage referenzierten Tablespaces in der Datenbank vorhanden sind, in der die Daten wiederhergestellt werden. (Dabei kann es sich um eine vorhandene oder eine neue, leere Datenbank handeln.) Wenn festgestellt wird, dass ein Tablespace fehlt oder nicht verfügbar ist (kein Zugriff), schlägt der Wiederherstellungsvorgang fehl.

Zur Vermeidung dieses Problems können Sie eine umgeleitete Wiederherstellung durchführen. Dabei können Sie neue Tablespaces angeben, in denen Sie Tablespaces des Sicherungsimages wiederherstellen können, die in der Zieldatenbank fehlen. Weitere Informationen zur Durchführung einer umgeleiteten Wiederherstellung finden Sie in der DB2-Dokumentation.

Wenn Sie nur einzelne Tablespaces einer wiederherstellbaren Datenbank wiederherstellen, kann die Datenbank online bleiben, sofern keine Benutzer mit den wiederherzustellenden Tablespaces verbunden sind.

Tipp

• Sie können das Archivieren und Abrufen von Protokolldateien mit einem Benutzerexit-Programm automatisieren. Hierzu müssen Sie den Konfigurationsparameter "logarchmeth1" auf "USEREXIT" setzen.

  Weitere Informationen zum Entwickeln und Verwenden eines Benutzerexit-Programms finden Sie in der DB2-Dokumentation.

• Im Fall einer partitionierten Datenbank müssen Sie den Befehl "RECOVER DATABASE" von der Katalogpartition aus ausführen. Wenn Sie eine partitionierte Datenbank auf den Stand eines bestimmten Zeitpunktes wiederherstellen, sind von diesem Vorgang alle in der Datei "db2nodes.cfg" aufgeführten Partitionen betroffen. Wenn Sie bis zum Ende der Protokolle wiederherstellen, können Sie angeben, welche Partitionen berücksichtigt werden sollen. Wenn Sie keine Partitionen angeben, werden alle in der Datei "db2nodes.cfg" aufgeführten Partitionen berücksichtigt.