Eine Datenbank kann aufgrund von Hardware- oder Softwarefehlern (oder beiden) unbrauchbar werden. Die verschiedenen Fehlerszenarios können verschiedene Maßnahmen zur Wiederherstellung erforderlich machen. Sie sollten eine erprobte Strategie zur Hand haben, um Ihre Datenbank gegen die Möglichkeit fehlerbedingter Ausfälle zu schützen.
In diesem Abschnitt werden die verschiedenen Wiederherstellungsmethoden behandelt und erläutert, wie sich die für eine gegebene Geschäftsumgebung am besten geeignete Wiederherstellungsmethode bestimmen läßt. Die folgenden Themen werden behandelt:
Sie sollten mit den Strategien vertraut sein, die Ihnen bei Problemen mit Ihrer Datenbank zur Verfügung stehen. Zu diesem Problemen gehören Datenträger- und Speicherausfälle, Unterbrechungen der Stromversorgung und Anwendungsfehler. Sie haben die Möglichkeit, Ihre Datenbank bzw. einzelne Tabellenbereiche zu sichern und ggf. erneut zu erstellen, falls sie auf irgendeine Weise beschädigt oder unbrauchbar gemacht wurden. Das Konzept einer Datenbanksicherung ist mit jeder anderen Datensicherung vergleichbar: Erstellen einer Kopie der Daten und Speichern der Kopie auf einem anderen Datenträger für den Fall eines Ausfalls oder einer Beschädigung der Originaldaten. Den einfachsten Fall einer Sicherung bildet das Verfahren, bei dem zunächst die Datenbank gestoppt wird, um sicherzustellen, daß keine weiteren Transaktionen auftreten, und anschließend die Daten gesichert (Backup) werden.
Das erneute Erstellen der Datenbank wird als Wiederherstellung bezeichnet. Eine Wiederherstellung nach einem Systemabsturz versucht automatisch, die Datenbank nach einem Fehler wiederherzustellen. Es gibt zwei Methoden, eine beschädigte Datenbank wiederherzustellen: Versionswiederherstellung und aktualisierende Wiederherstellung (Roll Forward).
Bei nicht wiederherstellbaren Datenbanken sind die beiden Konfigurationsparameter logretain und userexit der Datenbank inaktiviert. Dies bedeutet, daß lediglich die für Wiederherstellung nach einem Systemabsturz erforderlichen Protokolle beibehalten werden. Diese Protokolle werden als aktive Protokolldateien bezeichnet und enthalten aktuelle Transaktionsdaten. Die Versionswiederherstellung mit Hilfe von Offline-Sicherungen ist das primäre Mittel zur Wiederherstellung für eine nicht wiederherstellbare Datenbank. (Eine Offline-Sicherung bedeutet, daß während der Sicherungsoperation keine andere Anwendung die Datenbank verwenden kann.) Eine solche Datenbank kann nur offline wiederhergestellt werden. Sie wird in dem Status wiederhergestellt, den sie hatte, als das Sicherungsabbild erstellt wurde.
Bei wiederherstellbaren Datenbanken ist entweder der Konfigurationsparameter logretain der Datenbank auf den Wert "RECOVERY" gesetzt, oder der Konfigurationsparameter userexit der Datenbank aktiviert, oder beides. Aktive Protokolldateien sind weiterhin für Wiederherstellung nach einem Systemabsturz verfügbar, Ihnen stehen jedoch auch die Archivprotokolldateien zur Verfügung, die festgeschriebene Transaktionsdaten enthalten. Eine solche Datenbank kann nur offline wiederhergestellt werden. Sie wird in dem Status wiederhergestellt, den sie hatte, als das Sicherungsabbild erstellt wurde. Mit Hilfe der aktualisierenden Wiederherstellung (Roll Forward Recovery) können Sie jedoch die Datenbank aktualisierend wiederherstellen (d. h. über den Zeitpunkt hinaus, zu dem das Sicherungsabbild erstellt wurde), indem Sie die aktiven und archivierten Protokolle entweder bis zu einem bestimmten Zeitpunkt oder bis zum Ende der aktiven Protokolldateien anwenden.
Sicherungsoperationen für wiederherstellbare Datenbanken können entweder offline oder online (online heißt, daß andere Anwendungen während der Sicherungsoperation eine Verbindung zur Datenbank herstellen können) durchgeführt werden. Die Operationen zur Wiederherstellung und aktualisierenden Wiederherstellung der Datenbank müssen immer offline ausgeführt werden. Während einer Online-Sicherung stellt die aktualisierende Wiederherstellung sicher, daß alle Tabellenänderungen erfaßt und erneut angewendet werden, wenn diese Sicherungskopie wiederhergestellt wird.
Bei einer wiederherstellbaren Datenbank können Sie auch einzelne Tabellenbereiche sichern, wiederherstellen und aktualisierend wiederherstellen. Wenn Sie einen Tabellenbereich online sichern, kann er weiterhin verwendet werden, und gleichzeitig durchgeführte Änderungen werden in den Protokollen aufgezeichnet. Wenn Sie eine Online-Operation zur Wiederherstellung oder aktualisierenden Wiederherstellung für einen Tabellenbereich ausführen, kann der Tabellenbereich selbst nicht mehr verwendet werden, bis die Operation beendet ist, Benutzer können jedoch weiterhin auf Tabellen in anderen Tabellenbereichen zugreifen.
Durch die Wiederherstellung nach einem Systemabsturz wird verhindert, daß eine Datenbank in einem inkonsistenten, d. h. unbrauchbaren, Status verbleibt. Bei einem Systemabsturz können Transaktionen (bzw. Arbeitseinheiten), die für die Datenbank ausgeführt werden, auf unerwartete Weise unterbrochen werden. Wenn eine Störung auftritt, bevor alle Änderungen, die Bestandteil der Arbeitseinheit sind, beendet und festgeschrieben wurden, verbleibt die Datenbank in einem inkonsistenten und unbrauchbaren Status.
Daraufhin muß die Datenbank wieder in einen konsistenten und brauchbaren Status versetzt werden. Dies geschieht durch Rückgängigmachen der unvollständigen Transaktionen und Beenden der festgeschriebenen Aktionen, die sich noch im Hauptspeicher befanden, als der Systemabsturz auftrat (Abbildung 13).
Abbildung 13. Rückgängigmachen von Arbeitseinheiten
Wenn eine Datenbank in einem konsistenten und verwendbaren Zustand ist, hat sie einen Punkt erreicht, der als wird dies als "Konsistenzzustand" bezeichnet wird. Eine Offline-Datenbanksicherung stellt einen solchen Konsistenzzustand dar. Wenn ein Konsistenzzustand erreicht ist, sind alle Transaktionen aufgelöst und alle Daten stehen anderen Benutzern oder oder Anwendungen zur Verfügung.
Nach einem Absturz können Sie einen Konsistenzzustand erreichen, indem Sie den Befehl RESTART DATABASE ausführen (siehe Handbuch Command Reference). Wenn dies bei jedem Fehler geschehen soll, sollten Sie eine Verwendung des Konfigurationsparameters zur Aktivierung des automatischen Neustarts (autorestart) in Betracht ziehen. Die Standardfuntionsweise dieses Konfigurationsparameters der Datenbank ist jeweils das Aufrufen des Befehls RESTART DATABASE, wenn dies erforderlich ist. Wenn der Parameterautorestart aktiviert ist, wird durch die nächste Verbindungsanforderung an die Datenbank nach einem Fehler der Befehl RESTART DATABASE aufgerufen.
Durch die Wiederherstellung nach einem Systemabsturz wird die Datenbank in einen konsistenten und brauchbaren Status versetzt. Wenn eine Wiederherstellung nach einem Systemabsturz für eine Datenbank durchgeführt wird, für die die aktualisierende Wiederherstellung aktiviert ist (d. h. der Konfigurationsparameter logretain ist auf RECOVERY gesetzt, oder der Konfigurationsparameter userexit ist aktiviert) und während dieser Wiederherstellung ein Fehler auftritt, der auf einen einzelnen Tabellenbereich zurückzuführen ist, muß dieser Tabellenbereich offline genommen werden. Auf ihn kann erst dann wieder zugegriffen werden, nachdem er repariert wurde. Anschließend wird die Wiederherstellung nach dem Systemabsturz fortgesetzt. Nach der Beendigung der Wiederherstellung nach Systemabsturz sind die anderen Tabellenbereiche in der Datenbank weiterhin verwendbar, und es können Verbindungen zur Datenbank hergestellt werden. (Es gibt Ausnahmen bei Tabellenbereichen, die temporäre Tabellen oder Systemkatalogtabellen enthalten. Diese Ausnahmen werden in der Beschreibung der aktualisierenden Wiederherstellung behandelt.)
Wie bereits zuvor erwähnt, bietet DB2 zwei Methoden zur Wiederherstellung einer beschädigten Datenbank:
Durch die Operation einer Datenbankwiederherstellung wird die gesamte Datenbank mit Hilfe einer zu einem früheren Zeitpunkt erstellten Sicherungskopie rekonstruiert. Eine Sicherungskopie der Datenbank ermöglicht Ihnen, eine Datenbank in dem Status wiederherzustellen, in dem sie sich zum Zeitpunkt der Sicherung befand. Alle Arbeitseinheiten, die vom Zeitpunkt der Sicherung ausgehend bis zum Eintreten des Fehlers ausgeführt wurden, sind verloren (siehe Abbildung 14).
Bei Einsatz der Methode der Versionswiederherstellung müssen Sie regelmäßige Gesamtsicherungen der Datenbank einplanen und ausführen.
In einer Umgebung mit partitionierten Datenbanken ist eine Datenbank auf viele Datenbankpartitions-Server (oder Knoten) verteilt. Sie müssen alle Partitionen wiederherstellen, und die Sicherungsabbilder, die Sie zur Wiederherstellung der Datenbank verwenden, müssen alle zum gleichen Zeitpunkt erstellt worden sein. (Jede Datenbankpartition wird getrennt gesichert und wiederhergestellt.) Eine Sicherung, bei der alle Sicherungskopien der Datenbankpartitionen zur gleichen Zeit erstellt werden, wird als Versionssicherung bezeichnet.
Abbildung 14. Wiederherstellen einer Datenbank mit Hilfe der Sicherungskopie
Es können zwei Typen der aktualisierenden Wiederherstellung in Erwägung gezogen werden:
In einer Umgebung mit partitionierten Datenbanken ist eine Datenbank über viele Datenbankpartitionen verteilt. Wenn Sie eine aktualisierende Wiederherstellung bis zu einem bestimmten Zeitpunkt ausführen, müssen alle Datenbankpartitionen aktualisierend wiederhergestellt werden, um sicherzustellen, daß alle Partitionen den gleichen Stand haben. Wenn Sie eine einzelne Datenbankpartition wiederherstellen müssen, können Sie eine aktualisierende Wiederherstellung bis zum Ende der Protokolle durchführen, um sie auf den gleichen Stand wie die anderen Partitionen in der Datenbank zu bringen.
Abbildung 15. Aktualisierende Wiederherstellung einer Datenbank
Anmerkungen:
Eine aktualisierende Wiederherstellung von Tabellenbereichen kann in den beiden folgenden Situationen ausgeführt werden:
Anmerkung: | Wenn der fehlerhafte Tabellenbereich die Systemkatalogtabellen enthält, können Sie die Datenbank nicht starten. Sie müssen den Tabellenbereich SYSCATSPACE wiederherstellen und anschließend die aktualisierende Wiederherstellung bis zum Ende der Protokolle ausführen. |
Wenn Sie in einer Umgebung mit partitionierten Datenbanken einen Tabellenbereich bis zu einem bestimmten Zeitpunkt aktualisierend wiederherstellen, müssen Sie die Liste der Knoten (Datenbankpartitionen) nicht angeben, auf die sich der Tabellenbereich verteilt. DB2 übergibt die Anforderung zur aktualisierenden Wiederherstellung an alle Partitionen. Dies bedeutet, daß der Tabellenbereich auf allen Datenbankpartitionen, auf denen der Tabellenbereich sich befindet, wiederhergestellt werden muß.
Wenn Sie in einer Umgebung mit partitionierten Datenbanken einen Tabellenbereich bis zum Ende der Protokolle aktualisierend wiederherstellen, müssen Sie die Liste der Datenbankpartitionen angeben, wenn Sie den Tabellenbereich nicht in allen Partitionen aktualisierend wiederherstellen wollen. Wenn Sie alle Tabellenbereiche in allen Partitionen, die sich im Status Aktualisierende Wiederherstellung anstehend befinden, bis zum Ende der Protokolle aktualisierend wiederherstellen wollen, müssen Sie die Liste der Datenbankpartitionen nicht angeben. Standardmäßig wird die Anforderung ROLLFORWARD DATABASE an alle Partitionen gesendet.
Berücksichtigen Sie folgende Faktoren bei der Entscheidung über die zu verwendende Wiederstellungsmethode:
Allgemein sollte die Strategie zur Wartung und Wiederherstellung der Datenbank sicherstellen, daß alle Informationen verfügbar sind, wenn sie für eine Wiederherstellung der Datenbank benötigt werden. Die Strategie sollte einen regelmäßigen Plan zur Erstellung von Datenbanksicherungen vorsehen und Sicherungen einplanen, wenn eine Datenbank erstellt wird oder, wie im Fall eines Systems mit partitionierten Datenbanken, wenn das System durch Hinzufügen oder Löschen von Datenbankpartitions-Servern (Knoten) skaliert wird. Über diese Grundanforderungen hinaus sollte eine gute Strategie Elemente enthalten, die die Wahrscheinlichkeit und die Auswirkungen eines Datenbankfehlers verringern.
Unter den folgenden Themen finden Sie weitere Informationen:
Obwohl das Hauptgewicht dieses Abschnitts auf der Datenbank liegt, sollte Ihre Gesamtplanung zur Wiederherstellung auch die Wiederherstellung folgender Komponenten berücksichtigen:
Lassen sich Ihre Daten problemlos erneut erstellen, kann die Datenbank, die diese Daten enthält, als nicht wiederherstellbare Datenbank betrieben werden. Zum Beispiel:
Können Ihre Daten nicht problemlos erneut erstellt werden, sollte die Datenbank, die diese Daten enthält, als wiederherstellbare Datenbank betrieben werden. Nachfolgend sind Beispiele für Daten aufgeführt, die in einer wiederherstellbaren Datenbank gespeichert werden sollten:
Jeder Datenbank sind Protokolldateien zugeordnet. In diesen Protokolldateien werden die Datenbankänderungen aufgezeichnet. Wenn eine Datenbank über den Stand der letzten vollständigen Offline-Sicherung hinaus wiederhergestellt werden muß, sind Protokolle erforderlich, um die Datenbank bis zu dem Zeitpunkt des Fehlers aktualisierend wiederherstellen zu können.
DB2 stellt zwei Arten von Protokollierung zur Verfügung: Umlaufprotokolle und Archivprotokolle. Jede Art stellt eine andere Stufe der Wiederherstellbarkeit bereit.
Umlaufprotokolle bilden die Standardprotokollierung, wenn eine neue Datenbank erstellt wird. Bei dieser Art der Protokollierung sind nur vollständige Offline-Sicherungen der Datenbank gültig. Wie der Name bereits andeutet, bilden Umlaufprotokolle einen "Ring" von Online-Protokollen, die eine Wiederherstellung nach Transaktionsfehlern oder Systemabstürzen ermöglichen. Die Protokolle werden nur so lange verwendet und behalten, wie es erforderlich ist, um die Integrität der aktuellen Transaktionen zu gewährleisten. Bei der Verwendung von Umlaufprotokollen ist es nicht möglich, eine Datenbank durch frühere Transaktionen, die seit der letzten Gesamtsicherung durchgeführt wurden, aktualisierend wiederherzustellen. Die Wiederherstellung nach Datenträgerausfällen und Systembeschädigungen erfolgt mit Hilfe einer vollständigen Offline-Sicherung. Alle Änderungen, die seit der letzten Sicherung vorgenommen wurden, gehen verloren. Die Datenbank muß offline sein (d. h. für Benutzer nicht zugänglich), wenn eine Gesamtsicherung erstellt wird. Da diese Art der Wiederherstellung die Daten auf dem Stand des bestimmten Zeitpunkts der Gesamtsicherung wiederherstellt, wird sie als Versionswiederherstellung bezeichnet.
Abbildung 16 zeigt, daß die aktive Protokolldatei mit einem Ring aus Protokolldateien arbeitet, wenn die Umlaufprotokollierung aktiv ist.
Abbildung 16. Umlaufprotokollierung
Aktive Protokolldateien werden von der Wiederherstellung nach einem Systemabsturz verwendet, um zu verhindern, daß eine Datenbank nach einer Störung (Stromausfall oder Anwendungsfehler) in einem inkonsistenten Status zurückbleibt. Der Befehl RESTART DATABASE verwendet die aktiven Protokolle bei Bedarf, um die Datenbank in einen konsistenten und brauchbaren Status zu versetzen. Während einer Wiederherstellung nach einem Systemabsturz werden in diesen Protokollen aufgezeichnete Änderungen, die aufgrund der Störung nicht festgeschrieben wurden, rückgängig gemacht. Festgeschriebene, aber nicht physisch aus dem Hauptspeicher (Pufferpool) auf Platte (Datenbankbehälter) geschriebene Änderungen werden wiederholt. Durch diese Maßnahmen wird die Integrität der Datenbank gewährleistet. Der Befehl ROLLFORWARD DATABASE kann bei einer Wiederherstellung bis zu einem bestimmten Zeitpunkt oder bis zum Ende der Protokolle ebenfalls die aktiven Protokolle (sofern erforderlich) verwenden. Aktive Protokolldateien befinden sich im Verzeichnispfad der Datenbankprotokolle.
Archivierte Protokolldateien werden besonders für die aktualisierende Wiederherstellung verwendet. Dazu gehören folgende Arten von Dateien:
Abbildung 17. Online archivierte Protokolle
Abbildung 18. Offline archivierte Protokolle
Von der aktualisierenden Wiederherstellung können sowohl archivierte als auch aktive Protokolldateien verwendet werden, um eine Datenbank entweder bis zum Ende der Protokolle oder bis zu einem bestimmten Zeitpunkt wiederherzustellen. Die Funktion zur aktualisierenden Wiederherstellung erreicht dies, indem sie die in den archivierten und aktiven Protokolldateien gefundenen festgeschriebenen Änderungen erneut auf die wiederhergestellte Datenbank anwendet.
Die aktualisierende Wiederherstellung kann mit Hilfe von Protokollen auch einen Tabellenbereich wiederherstellen, indem festgeschriebene Aktualisierungen in den archivierten und aktiven Protokolldateien erneut angewendet werden. Sie können einen Tabellenbereich bis zum Ende der Protokolle oder bis zu einem bestimmten Zeitpunkt wiederherstellen.
Während einer Online-Sicherung werden alle Aktivitäten an der Datenbank protokolliert. Wenn eine Online-Sicherung wiederhergestellt wird, muß mit Hilf der Protokolle die Datenbank mindestens bis zu dem Zeitpunkt aktualisierend wiederhergestellt werden, zu dem die Sicherung abgeschlossen wurde. Damit dies geschehen kann, müssen Sie die Protokolle archivieren und bereitstellen, wenn die Datenbank wiederhergestellt werden soll. Die Protokolldatei, die zum Zeitpunkt der Sicherung verwendet wurde, bleibt möglicherweise auch nach Abschluß der Sicherungsoperation noch geöffnet. Mit Hilfe der Option FLUSH LOG für die Online-Sicherung im Befehl BACKUP DATABASE wird die aktive Protokolldatei geschlossen, wenn die Online-Sicherung beendet ist. Dadurch kann die aktive Protokolldatei archiviert werden, sodaß Sie über eine vollständige Sicherung und sämtliche, für eine Wiederherstellung dieser Sicherung erforderlichen Protokolle verfügen.
Abbildung 19. Aktive und archivierte Datenbankprotokolle bei aktualisierender Wiederherstellung
Mit Hilfe zweier Konfigurationsparameter der Datenbank können Sie die Position ändern, an der die archivierten Protokolldateien gespeichert werden sollen: newlogpath und userexit. Änderungen am Parameter newlogpath wirken sich außerdem auf die Speicherposition aus, an der die aktiven Protokolle gespeichert werden. Weitere Informationen zu diesen Konfigurationsparametern finden Sie im Handbuch Systemverwaltung: Optimierung.
Welche Protokollspeicherbereiche (siehe Behälter) im Verzeichnispfad der Datenbankprotokolle archivierte Protokolldateien sind, können Sie am Wert des Konfigurationsparameters loghead der Datenbank ablesen. Dieser Parameter gibt das Protokoll mit der niedrigsten Nummer an, das aktiv ist. Bei Protokollen mit Folgenummern, die niedriger als loghead sind, handelt es sich um archivierte Protokolldateien, die versetzt werden können. Die Werte dieser Parameter können Sie überprüfen, indem Sie die Steuerzentrale verwenden oder mit Hilfe des Befehlszeilenprozessors den Befehl GET DATABASE CONFIGURATION ausführen, um die "erste aktive Protokolldatei" anzuzeigen. Weitere Informationen zu diesem Konfigurationsparameter finden Sie im Handbuch Systemverwaltung: Optimierung.
Anmerkungen:
Wenn Ihre Anwendung Arbeitstabellen aus Originaltabellen erstellt und mit Werten füllt und Sie sich um die Wiederherstellbarkeit dieser Arbeitstabellen keine Gedanken machen müssen, weil sie leicht mit Hilfe der Originaltabellen wieder erstellt werden können, können Sie die Arbeitstabellen unter Angabe der Klausel NOT LOGGED INITIALLY in der Anweisung CREATE TABLE erstellen. Die Verwendung des Parameters NOT LOGGED INITIALLY hat den Vorteil, daß alle Änderungen an der Tabelle (einschließlich Operationen zum Einfügen, Löschen, Aktualisieren sowie Erstellen von Indizes) innerhalb derselben Arbeitseinheit, in der die Tabelle erstellt wird, nicht protokolliert werden. Dadurch werden nicht nur die Protokollieraktivitäten verringert, sondern auch eine bessere Leistung für Ihre Anwendung erzielt. Sie können das gleiche Ergebnis für vorhandene Tabellen erreichen, indem Sie die Anweisung ALTER TABLE mit dem Parameter NOT LOGGED INITIALLY verwenden.
Anmerkungen:
Da die Änderungen der Tabelle nicht protokolliert werden, sollten Sie bei der Entscheidung, die Klausel NOT LOGGED INITIALLY zu verwenden, folgendes beachten:
Anmerkung: | Bei der Erstellung einer Tabelle werden Zeilensperren für die Katalogtabellen aktiviert, bis eine COMMIT-Operation ausgeführt wird. Die Inaktivierung der Protokollfunktion ist nur dann von Vorteil, wenn Sie die Tabelle innerhalb derselben Arbeitseinheit mit Werten füllen, in der sie erstellt wird. Daraus ergeben sich Konsequenzen für den gemeinsamen Zugriff. Weitere Informationen finden Sie im Abschnitt über gemeinsamen Zugriff im Handbuch Systemverwaltung: Optimierung. |
Weitere Informationen zum Erstellen von Tabellen finden Sie im Handbuch SQL Reference.
Wenn Sie planen, mit deklarierten temporären Tabellen zu arbeiten, ist folgendes zu beachten:
Weitere Informationen zu deklarierten temporären Tabellen und ihren Einschränkungen finden Sie im Abschnitt zur Anweisung DECLARE GLOBAL TEMPORARY TABLE des Handbuchs SQL Reference.
Die Methoden der Versionswiederherstellung und der aktualisierenden Wiederherstellung stellen unterschiedliche Wiederherstellungspunkte zur Verfügung. Bei der Versionsmethode ist eine Offline-Sicherung der gesamten Datenbank zu festgesetzten Zeiten erforderlich. Bei dieser Methode ist die wiederhergestellte Datenbank nur so aktuell, wie die Sicherungskopie, die wiederhergestellt wird. Wenn Sie beispielsweise am Ende jedes Tages eine Sicherungskopie anlegen und die Datenbank in der Mitte des folgenden Tages beschädigt wird, verlieren Sie die Änderungen eines halben Tages.
Bei der aktualisierenden Wiederherstellung werden die Änderungen, die an der Datenbank vorgenommen werden, in Protokolldateien aufgezeichnet. Bei dieser Methode stellen Sie zunächst die Datenbank bzw. die Tabellenbereiche mit Hilfe einer Sicherungskopie wieder her. Anschließend verwenden Sie die Protokolldateien, um die Änderungen erneut anzuwenden, die seit dem Erstellen der letzten Sicherungskopie an der Datenbank vorgenommen wurden.
Wenn die aktualisierende Wiederherstellung aktiviert ist, können Sie die Vorzüge der Online-Sicherung und der Sicherung auf Tabellenbereichsebene nutzen. Bei einer aktualisierenden Wiederherstellung der gesamten Datenbank und aller Tabellenbereiche haben Sie die Wahl, ob die Wiederherstellung bis zum Ende der Protokolle oder bis zu einem bestimmten Zeitpunkt erfolgen soll. Wenn z. B. eine Anwendung die Datenbank beschädigt, könnten Sie von einer wiederhergestellten Kopie der Datenbank ausgehend die Änderungen bis kurz vor den Zeitpunkt, an dem die Anwendung gestartet wurde, aktualisierend wiederherstellen. Keine Arbeitseinheiten, die nach dem angegebenen Zeitpunkt in die Protokolle geschrieben wurden, werden erneut angewendet.
Sie können auch Tabellenbereiche bis zum Ende der Protokolle oder bis zu einem bestimmten Zeitpunkt aktualisierend wiederherstellen.
In Ihrem Wiederherstellungsplan sollten regelmäßige Sicherungen vorgesehen sein, da das Sichern einer Datenbank Zeit und Systemressourcen in Anspruch nimmt.
Sie sollten in regelmäßigen Abständen Gesamtsicherungen der Datenbanken erstellen, selbst wenn Sie die Protokolle archivieren (die eine aktualisierende Wiederherstellung ermöglichen). Wenn in Ihrer Wiederherstellungsstrategie die aktualisierende Wiederherstellung vorgesehen ist, bedeutet eine erst kürzlich erstellte Gesamtsicherung der Datenbank, daß es weniger archivierte Protokolle gibt, die auf die Datenbank anzuwenden sind, und daß infolgedessen das Dienstprogramm ROLLFORWARD zur Wiederherstellung der Datenbank weniger Zeit benötigt.
Außerdem sollten Sie in Betracht ziehen, die Sicherungen und Protokolldateien nicht zu überschreiben, sondern eher mehrere Gesamtsicherungen der Datenbank mit zugehörigen Protokollen als weitere Vorsichtsmaßnahme zu erstellen.
Wenn die erforderliche Zeit für die Anwendung der Archivprotokolldateien bei der Wiederherstellung und der aktualisierenden Wiederherstellung einer sehr aktiven Datenbank wichtig ist, sollten Sie den Aufwand häufigerer Datenbanksicherungen berücksichtigen. Dadurch verringert sich die Anzahl der Archivprotokolldateien, die Sie bei einer aktualisierenden Wiederherstellung anwenden müssen.
Sie können eine Sicherung durchführen, während die Datenbank online oder offline ist. Wenn die Datenbank online ist, können andere Anwendungen oder Prozesse weiterhin Verbindungen zur Datenbank herstellen sowie Daten lesen und ändern, während die Sicherungsoperation ausgeführt wird. Bei einer offline durchgeführten Sicherung kann nur die Sicherungsoperation mit der Datenbank verbunden sein. Die übrige Organisation kann keine Verbindung zur Datenbank herstellen, solange die Sicherungsoperation ausgeführt wird.
Um den Zeitraum, in dem die Datenbank nicht verfügbar ist, möglichst kurz zu halten, sollten Sie Online-Sicherungen in Betracht ziehen. Online-Sicherungen werden nur unterstützt, wenn die aktualisierende Wiederherstellung aktiviert ist. Wenn die aktualisierende Wiederherstellung aktiviert ist und Sie über einen kompletten Satz von Protokollen verfügen, können Sie die Datenbank im Bedarfsfall rekonstruieren.
Anmerkungen:
Wenn eine Datenbank große Mengen von Daten der Typen LONG und LOB enthält, kann das Sichern der Datenbank sehr viel Zeit in Anspruch nehmen. Der Befehl BACKUP bietet die Möglichkeit, ausgewählte Tabellenbereiche zu sichern. Wenn Sie DMS-Tabellenbereiche verwenden, können Sie verschiedene Arten von Daten in speziellen Tabellenbereichen speichern, um die für Sicherungsoperationen benötigte Zeit zu verringern. Sie können die Tabellendaten in einem Tabellenbereich, die Langfeld- und LOB-Daten in einem anderen Tabellenbereich und die Indizes in einem dritten Tabellenbereich unterbringen. Wenn sich die Landfeld- und LOB-Daten in separaten Tabellenbereichen befinden, läßt sich der für das Sichern von Daten erforderliche Zeitaufwand dadurch verringern, daß die Tabellenbereiche mit den Langfeld- und LOB-Daten von der Sicherung ausgeschlossen werden. Handelt es sich bei Ihren LONG- und LOB-Daten um wichtige Unternehmensdaten, sollten Sie das Sichern dieser Tabellenbereiche gegen den für die Wiederherstellungsoperation erforderlichen Zeitaufwand abwägen. Wenn die LOB-Daten von einer getrennten Quelle reproduziert werden können, sollten Sie beim Erstellen oder Ändern einer Tabelle zum Hinzufügen von LOB-Spalten die Option NOT LOGGED verwenden.
Wenn Sie eine Tabelle reorganisieren, sollten Sie die betroffenen Tabellenbereiche nach Beendigung der Operation sichern. Wenn dann der Fall eintritt, daß die Tabellenbereiche wiederhergestellt werden müssen, muß die Datenreorganisation nicht mehr aktualisierend wiederhergestellt werden.
Anmerkung: | Wenn Sie einen Tabellenbereich sichern, der nicht alle Tabellendaten enthält, können Sie keine aktualisierende Wiederherstellung bis zu einem bestimmten Zeitpunkt für diesen Tabellenbereich ausführen. Alle Tabellenbereiche, die irgendeine Art von Daten für eine Tabelle enthalten, müssen gleichzeitig bis zum selben Zeitpunkt aktualisierend wiederhergestellt werden. |
Die Zeit, die zur Wiederherstellung einer Datenbank benötigt wird, setzt sich aus zwei Perioden zusammen: die Zeit, die zur Wiederherstellung der Sicherungskopie benötigt wird, sowie, wenn für die Datenbank die aktualisierende Wiederherstellung aktiviert ist, die Zeit, die zur Anwendung der Protokolle während der aktualisierenden Wiederherstellung benötigt wird. Bei der Formulierung eines Wiederherstellungsplans sollten Sie diesen Wiederherstellungsaufwand und die dadurch verursachte Auswirkung auf den Geschäftsbetrieb berücksichtigen. Durch Testen des Gesamtwiederherstellungsplans können Sie ermitteln, ob die Zeit, die zur Wiederherstellung der Datenbank benötigt wird, in Anbetracht Ihrer Geschäftserfordernisse angemessen ist. Nach einem Test können Sie zu dem Schluß kommen, daß es vorteilhaft ist, die Häufigkeit der Sicherungen zu erhöhen. Wenn Ihre Strategie eine aktualisierende Wiederherstellung vorsieht, wird dieses Vorgehen die Anzahl der zwischen Sicherungen archivierten Protokolle reduzieren und auf diese Weise die für eine aktualisierende Wiederherstellung der Datenbank benötigte Zeit nach einer Wiederherstellung von der Sicherungskopie verringern.
Anmerkung: | Die Einstellung des Konfigurationsparameters des Datenbankmanagers zur Aktivierung der partitionsinternen Parallelität (intra_parallel) wirkt sich auf die Leistung der Sicherungsoperationen und der Wiederherstellungsoperationen nicht aus. Es werden für beide Operationen unabhängig von der Einstellung des Parameters intra_parallel mehrere Prozesse verwendet. |
Bei der Entscheidung der zu verwendenden Wiederherstellungsmethode sollten Sie auch den erforderlichen Speicherplatz in Betracht ziehen.
Bei der Versionswiederherstellung wird Speicherplatz für die Sicherungskopie der Datenbank und für die wiederhergestellte Datenbank benötigt. Bei einer aktualisierenden Wiederherstellung wird Speicherplatz für die Sicherungskopie der Datenbank bzw. Tabellenbereiche, für die wiederhergestellte Datenbank sowie für die archivierten Datenbankprotokolle benötigt.
Enthält eine Tabelle LONG- oder LOB-Spalten, ist es u. U. ratsam, die betreffenden Daten in einen separaten Tabellenbereich zu stellen. Dies hat Auswirkungen auf Ihre Überlegungen zum Speicherbedarf sowie auf Ihren Wiederherstellungsplan. Wenn Sie einen separaten Tabellenbereich für LONG- und LOB-Daten verwenden und Ihnen der Zeitaufwand für das Sichern der LONG- und LOB-Daten bekannt ist, können Sie einen Wiederherstellungsplan verwenden, bei dem dieser Tabellenbereich nur gelegentlich gesichert wird. Beim Erstellen oder Ändern einer Tabelle, die LOB-Daten umfaßt, können Sie zudem angeben, daß Änderungen an den betreffenden Spalten nicht protokolliert werden sollen. Dadurch verringert sich die Größe der Protokolldateien und somit der erforderliche Protokollarchivierungsspeicher.
Die Sicherungskopie eines SMS-Tabellenbereichs mit LOB-Daten kann größer werden als der ursprüngliche Tabellenbereich. Die Sicherungskopie kann je nach Größe der LOB-Daten im Tabellenbereich bis zu 40% größer werden. Wenn Sie beispielsweise eine Sicherung eines 1 GB großen Tabellenbereichs (mit LOB-Daten) erstellen, benötigen Sie zur Wiederherstellung des Tabellenbereichs mehr als 1 GB Plattenspeicherplatz. Dies tritt nur bei Dateisystemen auf, die die Zuordnung von Dateien mit freien Bereichen (Sparse Allocation) unterstützen (z. B. auf UNIX basierende Betriebssysteme).
Um zu verhindern, daß ein Datenträgerfehler die Datenbank beschädigt und Ihnen die Wiederherstellung unmöglich macht, sollten Sie die Sicherungskopie der Datenbank, die Datenbankprotokolle sowie die Datenbank selbst auf unterschiedlichen Einheiten speichern. Aus diesem Grund wird ausdrücklich empfohlen, nach dem Erstellen der Datenbank die Datenbankprotokolle mit Hilfe des Konfigurationsparameters newlogpath auf eine separate Einheit umzuleiten. (Eine Beschreibung dieses sowie weiterer Konfigurationsparameter, die für das Protokollieren relevant sind, finden Sie in Aktualisierendes Wiederherstellen von Änderungen in einer Datenbank .)
Die Datenbankprotokolle können viel Speicherplatz in Anspruch nehmen. Wenn Sie beabsichtigen, eine aktualisierende Wiederherstellung auszuführen, müssen Sie sich daher für eine Verwaltung der archivierten Protokolle entscheiden. Ihnen stehen folgende Möglichkeiten zur Auswahl:
Anmerkung: | Unter OS/2 unterstützt DB2 ein Benutzer-Exit-Programm, das die Speicherung der Sicherungsabbilder und Protokolle von Datenbanken auf Standard- und Nicht-Standardeinheiten verwaltet. Weitere Informationen finden Sie in Anhang F, Benutzer-Exit zur Datenbankwiederherstellung . |
Aufgrund Ihres Datenbankentwurfs sind Sie mit den Abhängigkeiten vertraut, die zwischen Tabellen bestehen. Diese Abhängigkeiten können auf Anwendungsebene ausgedrückt werden, wenn Transaktionen mehr als eine Tabelle aktualisieren, oder auf Datenbankebene, wenn es referentielle Integritätsbedingungen zwischen Tabellen gibt oder wenn sich Auslöser für eine Tabelle auf eine andere Tabelle auswirken. Diese Abhängigkeiten sollten bei der Entwicklung eines Wiederherstellungsplans berücksichtigt werden. Wahrscheinlich ist es sinnvoll, voneinander abhängige Mengen von Daten gemeinsam zu sichern. Solche zusammengehörigen Datenmengen können entweder auf Tabellenbereichsebene oder auf Datenbankebene eingerichtet werden. Wenn die zusammengehörigen Datenmengen zusammen gesichert werden, können sie bis zu einem Punkt wiederhergestellt werden, an dem alle Daten konsistent sind. Dies ist besonders wichtig, wenn Sie in der Lage sein wollen, eine aktualisierende Wiederherstellung bis zu einem bestimmten Zeitpunkt für Tabellenbereiche durchzuführen.
Wenn Sie in einer Umgebung mit mehreren Betriebssystemen arbeiten, müssen Sie berücksichtigen, daß die Sicherungs- und Wiederherstellungspläne nicht integriert werden können. Dies bedeutet, daß Sie den Befehl BACKUP DATABASE nicht unter dem einen Betriebssystem und den Befehl RESTORE DATABASE unter einem anderen Betriebssystem ausführen können. Sie sollten die Wiederherstellungspläne für die einzelnen Betriebssysteme getrennt halten und unabhängig voneinander ausführen.
Wenn Sie Tabellen von einem Betriebssystem auf ein anderes verschieben müssen, verwenden Sie den Befehl db2move, oder verwenden Sie den Befehl EXPORT und dann den Befehl IMPORT oder LOAD. Weitere Informationen finden Sie im Handbuch Versetzen von Daten Dienstprogramme und Referenz.
Ein beschädigter Tabellenbereich enthält einen oder mehrere Behälter, auf den/die nicht zugegriffen werden kann. Die wird häufig durch Datenträgerprobleme verursacht, die entweder permanent (z. B. eine defekte Platte) oder temporär sind (z. B. eine Platte, die offline ist, oder ein abgehängtes Dateisystem).
Wenn der beschädigte Tabellenbereich der Bereich für die Systemkatalogtabellen ist, kann die Datenbank nicht neu gestartet werden. Wenn die Behälterprobleme nicht behoben werden können, ohne daß die ursprünglichen Daten erhalten bleiben, sind nur die folgenden Optionen verfügbar:
Anmerkung: | Die Wiederherstellung des Tabellenbereichs ist nur für wiederherstellbare Datenbanken zulässig, da die Datenbank aktualisierend wiedergeherstellt werden muß. |
Wenn der beschädigte Tabellenbereich kein Bereich für eine Systemkatalogtabelle ist, versucht DB2 so viel von der Datenbank wie möglich verfügbar zu machen. Der Erfolg hängt in diesem Fall von der Protokollierstrategie ab.
Wenn der beschädigte Tabellenbereich der einzige Tabellenbereich für temporäre Tabellen ist, müssen Sie einen neuen Tabellenbereich für temporäre Tabellen erstellen, sobald eine Verbindung zur Datenbank hergestellt ist. Nach der Erstellung kann der neue Tabellenbereich für temporäre Tabellen verwendet werden, und der normale Datenbankbetrieb, der einen Tabellenbereich für temporäre Tabellen erfordert, kann fortgesetzt werden. Den offline befindlichen Tabellenbereich für temporäre Tabellen können Sie löschen, wenn Sie es wünschen. Für die Reorganisation von Tabellen, die mit einem Tabellenbereich für temporäre Systemtabellen arbeitet, sind die folgenden speziellen Überlegungen zu berücksichtigen:
Der beschädigte Tabellenbereich wird in den Status offline und nicht verfügbar und Aktualisierende Wiederherstellung anstehend versetzt, da eine Wiederherstellung nach Systemabsturz erforderlich ist. Die Neustartoperation ist erfolgreich, falls kein weiterer Fehler vorliegt. Der beschädigte Tabellenbereich kann wieder verwendet werden, wenn folgendes geschehen ist:
Da eine Wiederherstellung nach einem Systemabsturz notwendig ist und die Protokolle nicht unendlich lange gespeichert werden, kann die Neustartoperation nur erfolgreich sein, wenn der Benutzer bereit ist, die beschädigten Tabellenbereiche zu löschen. (Erfolgreiche Wiederherstellung bedeutet, daß die Protokollsätze, die zum Wiederherstellen eines konsistenten Zustands der beschädigten Tabellenbereiche erforderlich sind, verloren sind, und damit die einzige gültige Aktion für solche Tabellenbereiche das Löschen dieser Tabellenbereiche ist.)
Dies können Sie erreichen, indem Sie eine Operation RESTART DATABASE ohne Qualifikationsmerkmale durchführen. Wenn keine beschädigten Tabellenbereiche vorhanden sind, ist diese Operation erfolgreich. Wenn sie fehlschlägt (SQL0290N), können Sie die vollständige Liste der Tabellenbereiche, die momentan beschädigt sind, in der Datei db2diag.log überprüfen.
Anmerkung: | Wenn der Name eines Tabellenbereichs in der Liste DROP PENDING TABLESPACES aufgeführt wird, bedeutet dies nicht, daß der Tabellenbereich in den Status Löschen anstehend versetzt wird. Dies wäre nur der Fall, wenn der Tabellenbereich während des Neustarts beschädigt ist. Nach der erfolgreichen Ausführung der Neustartoperation müssen Sie jeden der Tabellenbereiche, die sich im Status Löschen anstehend befinden (mit Hilfe des Befehls LIST TABLESPACES können Sie die Tabellenbereiche in diesem Status feststellen), durch Ausführen von Anweisungen DROP TABLESPACE löschen. Dadurch kann der Speicherbereich wieder verfügbar gemacht oder die Tabellenbereiche erneut erstellt werden. |
Folgendes ist im Hinblick auf die Wiederherstellungsleistung zu beachten:
Berücksichtigen Sie dabei außerdem, welche anderen Dateien sich auf der Platte befinden. Wenn die Protokolldateien z. B. auf eine Platte gestellt werden, die auch für den Systemseitenwechsel in einem System verwendet wird, das nicht über genügend Realspeicher verfügt, werden dadurch Ihre Optimierungsversuche zunichte gemacht.
Wenn Sie mehrere Puffer und E/A-Kanäle verwenden, sollten Sie zumindest doppelt so viele Puffer als Kanäle verwenden, um sicherzustellen, daß die Kanäle nicht auf Daten warten müssen. Die Größe der Puffer wirkt sich ebenfalls auf die Leistung der Wiederherstellungsoperation aus. Die ideale Größe der Wiederherstellungspuffer ist ein Vielfaches der Größe des durch EXTENTSIZE definierten Bereichs für die Tabellenbereiche.
Wenn Sie mehrere Tabellenbereiche mit verschiedenen EXTENTSIZE-Bereichen haben, geben Sie einen Wert an, der ein Vielfaches des größten Werts für EXTENTSIZE darstellt.
Die empfohlene Mindestanzahl von Puffern ist die Summe der Anzahl der externen Einheiten bzw. Behälter und der für die Option PARALLELISM angegebenen Zahl.
Anmerkung: | Wenn Sie einen Tabellenbereich sichern, der Tabellendaten ohne die zugehörigen LONG- oder LOB-Felder enthält, können Sie keine aktualisierende Wiederherstellung bis zu einem bestimmten Zeitpunkt für diesen Tabellenbereich ausführen. Alle Tabellenbereiche für eine Tabelle müssen gleichzeitig bis zum selben Zeitpunkt aktualisierend wiederhergestellt werden. |
Unter dem Begriff Wiederherstellung nach Schäden werden die Aktivitäten zusammengefaßt, die zur Wiederherstellung der Datenbank nach einem Brand, einem Erdbeben, nach Vandalismus oder anderen zerstörerischen Ereignissen erforderlich sind. Ein Plan zur Wiederherstellung nach Schäden kann folgendes vorsehen:
Wenn Ihr Plan zur Wiederherstellung nach Schäden vorsieht, die gesamte Datenbank auf einer anderen Maschine wiederherzustellen, benötigen Sie zumindest eine vollständige Datenbanksicherung und alle archivierten Protokolldateien für die Datenbank. Es kann sinnvoll sein, eine Bereitschaftsdatenbank ebenfalls auf dem aktuellen Stand zu halten, indem die Protokolle, die archiviert werden, auf sie angewendet werden. Oder Sie könnten die Datenbanksicherung und Protokollarchive auf dem Bereitschaftssystem speichern und eine Wiederherstellung bzw. eine aktualisierende Wiederherstellung nur ausführen, wenn ein Schaden aufgetreten ist. (In diesem Fall ist eine möglichst aktuelle Sicherung von Vorteil.) Bei Eintritt eines unvorhergesehenen Schadens ist es gewöhnlich jedoch nicht möglich, alle Transaktionen bis zum Zeitpunkt des Unglücksfalls wiederherzustellen.
Der Nutzen einer Tabellenbereichssicherung zur Wiederherstellung nach einer Beschädigung hängt vom Ausmaß der Beschädigung ab. In der Regel ist für die Fehlerbehebung die Wiederherstellung der gesamten Datenbank erforderlich, das heißt, daß eine Gesamtsicherung der Datenbank am Bereitschaftsstandort zur Hand sein sollte. Selbst wenn Sie ein getrenntes Sicherungsabbild jedes Tabellenbereichs haben, können Sie sie nicht zur Wiederherstellung der Datenbank verwenden. Wenn die Beschädigung eine Platte betrifft, kann mit Hilfe einer Tabellenbereichssicherung jedes Tabellenbereichs auf dieser Platte die Wiederherstellung durchgeführt werden. Wenn Sie aufgrund eines Plattenfehlers (oder aus einem anderen Grund) keinen Zugriff auf einen Behälter mehr haben, können Sie den Behälter an einer anderen Position wiederherstellen. Weitere Informationen finden Sie in Erneutes Definieren von Tabellenbereichsbehältern während der Wiederherstellung mit RESTORE .
Sowohl Tabellenbereichssicherungen als auch vollständige Datenbanksicherungen können in Ihrer Planung zur Schadensbehebung eingesetzt werden. Die zur Sicherung, Wiederherstellung und aktualisierenden Wiederherstellung von Daten verfügbaren DB2-Einrichtungen bieten die Grundlage für einen Plan zur Schadensbehebung. Sie sollten die eingerichteten Wiederherstellungsprozeduren getestet haben, um Ihr Unternehmen zu schützen.
Zur Verringerung der Wahrscheinlichkeit eines Datenträgerfehlers und zur Vereinfachung der Wiederherstellung der Daten nach einem solchen Fehler, sollten Sie folgende Maßnahmen in Betracht ziehen:
Wenn Sie sich Gedanken über die Möglichkeit einer Beschädigung von Daten oder aktiven Protokollen aufgrund eines Plattenabsturzes machen, sollten Sie über den Einsatz von Systemen nachdenken, die eine gewisse Toleranz gegenüber Plattenfehlern gewährleisten. Im allgemeinen bietet sich hier die Verwendung einer Platteneinheit (Disk Array) an. Eine Platteneinheit besteht aus einem Verbund von Plattenlaufwerken, die einer Anwendung gegenüber wie ein einziges großes Plattenlaufwerk erscheinen.
Solche Platteneinheiten bieten Striping-Funktionen, d. h. Funktionen zur Verteilung einer Datei über mehrere Platten, Funktionen zur Spiegelung von Platten und zur Paritätsprüfung.
Platteneinheiten werden manchmal einfach als RAID (Redundant Array of Independent Disks) bezeichnet. Der spezielle Begriff RAID bezieht sich im allgemeinen nur auf Hardwareplatteneinheiten. Platteneinheiten können darüber hinaus durch Software auf Betriebssystem- oder Anwendungsebene implementiert werden. Das Unterscheidungsmerkmal zwischen Hardware- und Softwareplatteneinheiten ist die Art der CPU-Verarbeitung von E/A-Anforderungen. Bei Hardwareplatteneinheiten werden die E/A-Aktivitäten von Einheiten-Controllern verwaltet, während bei Softwareplatteneinheiten dies vom Betriebssystem bzw. von einer Anwendung übernommen wird.
Bei einer RAID-Platteneinheit werden mehrere Datenträger von einem Einheiten-Controller mit eigener CPU verwendet und verwaltet. Da sämtliche Logik, die zur Verwaltung der zu dieser Einheit gehörenden Platten erforderlich ist, im Einheiten-Controller enthalten ist, ist diese Implementierung vom Betriebssystem unabhängig.
Es gibt fünf Typen der RAID-Architektur, die mit RAID-1 bis RAID-5 bezeichnet werden und alle eine Toleranz gegenüber Plattenfehlern bieten. Jede variiert in Funktion und Leistung. Im allgemeinen bezeichnet RAID eine redundante Gruppe von Einheiten (Redundant Array). Die Spezifikation RAID-0, die nur Funktionen zum Daten-Striping (und keine fehlertolerante Redundanz) vorsieht, wird aus dieser Diskussion ausgeklammert. Obgleich die RAID-Spezifikation fünf Architekturen definiert, werden heutzutage gewöhnlich nur RAID-1 und RAID-5 verwendet.
RAID-1 ist auch als zeitgleiches Spiegeln (Mirroring) oder Duplizierung (Duplexing) von Platten bekannt. Beim zeitgleichen Spiegeln werden Daten (eine vollständige Datei) von einer Platte auf einer zweiten Platte mit Hilfe eines einzigen Einheiten-Controllers dupliziert. Bei der Plattenduplizierung (Disk Duplexing) geschieht dasselbe wie beim Spiegeln, jedoch sind die Platten an einen zweiten Einheiten-Controller (wie zwei SCSI-Adapter) angeschlossen. Der hierdurch implementierte Datenschutz ist gut. Es kann jede der beiden Platten ausfallen, und die Daten bleiben über die jeweils andere Platte verfügbar. Bei der Plattenduplizierung ist auch bei Ausfall eines Einheiten-Controllers der vollständige Schutz der Daten gewährleistet. Die Leistung bei einer RAID-1-Implementierung ist ebenfalls gut, allerdings muß mit ihr in Kauf genommen werden, daß die erforderliche Plattenkapazität doppelt so groß sein muß wie die tatsächliche Datenmenge, da die Daten auf Laufwerkspaaren dupliziert werden.
Durch RAID-5 wird das plattenübergreifende Lesen und Schreiben (Striping) von Daten und Parität nach Sektoren über alle Platten hinweg implementiert. Die Paritätsinformationen werden zusammen mit Daten, und nicht auf einem dedizierten Laufwerk gespeichert. Der hierdurch implementierte Datenschutz ist gut. Wenn eine Platte ausfällt, stehen die Daten über die Informationen von den anderen Platten zusammen mit den verteilten Paritätsinformationen immer noch zur Verfügung. Die Leseleistung ist gut, während die Schreibleistung beträchtlich schlechter als bei RAID-1 oder einer normalen Platte ist. Für eine RAID-5-Konfiguration sind mindestens drei identische Platten erforderlich. Die Menge des zusätzlich erforderlichen Speicherplatzes für den Systemaufwand variiert mit der Anzahl der Platten in der Platteneinheit. In Fall einer RAID-5-Konfiguration von fünf Platten, beträgt der Speichermehraufwand 20%.
Bei Verwendung einer RAID-Platteneinheit hindert eine ausgefallene Platte (außer bei RAID-0) Sie nicht daran, auf die Daten der Platteneinheit zuzugreifen. Wenn direkt im Betrieb anschließbare oder austauschbare Platten in der Platteneinheit verwendet werden, kann die ausgefallene Platte während des Betriebs der Platteneinheit gegen eine Ersatzplatte ausgetauscht werden. Wenn bei einer RAID-5-Konfiguration zwei Platten gleichzeitig ausfallen, gehen alle Daten verloren (jedoch ist die Wahrscheinlichkeit eines gleichzeitigen Ausfalls zweier Platten sehr gering).
Für Ihre Protokolle können Sie eine RAID-1-Konfiguration oder durch Software gespiegelte Platten (siehe Softwareplatteneinheiten) in Betracht ziehen, da diese Möglichkeiten eine Wiederherstellbarkeit bis zu dem Punkt des Ausfalls bieten und eine gute Schreibleistung zeigen, die für Protokolle wichtig ist. In Fällen, in denen Zuverlässigkeit von essentieller Bedeutung ist (d. h., daß keine Zeit für eine Wiederherstellung der Daten nach einem Plattenfehler verloren gehen darf) und die Schreibleistung nicht ebenso wichtig ist, kann eine RAID-5-Konfiguration für die Platten in Betracht kommen. Wenn hingegen die Schreibleistung eine erhebliche Rolle spielt und Sie diese auch mit dem Aufwand zusätzlichen Speicherplatzes sicherstellen wollen, ziehen Sie eine RAID-1-Konfiguration für Ihre Daten und Ihre Protokolle in Betracht.
Eine Softwareplatteneinheit leistet im wesentlichen dasselbe wie eine Hardwareplatteneinheit (siehe Hardwareplatteneinheiten (RAID)), jedoch wird die Verwaltung des Plattenverkehrs entweder durch eine Betriebssystemtask oder durch ein auf dem Server aktives Anwendungsprogramm erledigt. Wie alle anderen Programme auch steht die Softwareplatteneinheit bei der Nutzung der CPU- und Systemressourcen in einer Konkurrenzsituation. Dies ist keine gute Lösung für ein System mit knappen CPU-Ressourcen, und es ist zu bedenken, daß die Gesamtleistung der Platteneinheit von der Auslastung und Kapazität der CPU des Servers abhängig ist.
Eine typische Softwareplatteneinheit bietet Funktionen zur Spiegelung von Platten (siehe Hardwareplatteneinheiten (RAID)). Obwohl redundante Platten erforderlich sind, ist eine Softwareplatteneinheit relativ preiswert zu implementieren, da kostenintensive RAID-Einheiten-Controller nicht benötigt werden.
Anmerkung: | Wenn sich das Boot-Laufwerk des Betriebssystems in der Platteneinheit befindet, kann Ihr System nicht starten, wenn dieses Laufwerk ausfällt. Wenn das Laufwerk ausfällt, bevor die Platteneinheit aktiv ist, kann die Platteneinheit keinen Zugriff auf das Laufwerk ermöglichen. Ein Boot-Laufwerk sollte von der Platteneinheit getrennt betrieben werden. |
Zur Verringerung der Auswirkungen von Transaktionsfehlern versuchen Sie, folgendes sicherzustellen:
Unter den Datenbankpartitions-Servern sollte für eine relative hohe Synchronisation der Systemuhren gesorgt werden, um einen reibungslosen Datenbankbetrieb und eine uneingeschränkte Möglichkeit zur aktualisierenden Wiederherstellung zu gewährleisten. Zeitunterschiede unter den Datenbankpartitions-Servern, einschließlich aller potentiellen betriebs- und übertragungsbedingten Verzögerungen, für eine Transaktion sollten kleiner sein als der für den Konfigurationsparameter max_time_diff des Datenbankmanagers angegebene Wert, mit dem die maximale Zeitdifferenz zwischen Knoten definiert wird.
Zur Sicherstellung, daß die Zeitmarken der Protokollsätze die Reihenfolge von Transaktionen in einem partitionierten Datenbanksystem richtig wiedergeben, verwendet DB2 die Systemuhr der jeweiligen Maschine als Basis für die Zeitmarken in den Protokollsätzen. Wenn die Systemuhr jedoch vorgestellt wird, wird die Protokolluhr automatisch mit vorgestellt. Obwohl die Systemuhr wieder zurückgestellt werden kann, kann die Uhr für die Protokolle dies nicht und bleibt auf dieser vorgestellten Zeit, bis die Systemuhr mit dieser Zeit übereinstimmt. Dann sind die Systemuhren synchron. Dies hat zur Konsequenz, daß ein kurzfristiger Systemuhrfehler auf einem Datenbankknoten einen langfristigen Effekt auf die Zeitmarken von Datenbankprotokollen haben kann.
Nehmen Sie zum Beispiel an, daß die Systemuhr auf Datenbankpartitions-Server A fälschlicherweise auf den 7. November 1999 gesetzt wird, obwohl das Jahr 1997 ist, und nehmen Sie weiter an, daß der Fehler korrigiert wurde, nachdem eine Transaktion zur Aktualisierung in der Partition auf diesem Datenbankpartitions-Server festgeschrieben wurde. Wenn die Datenbank ständig in Gebrauch ist und regelmäßig aktualisiert wird, bleibt jeder Zeitpunkt zwischen dem 7. November 1997 und dem 7. November 1999 durch die aktualisierende Wiederherstellung praktisch unerreichbar. Wenn die Festschreibung auf Datenbankpartitions-Server A erfolgt, wird die Zeitmarke im Datenbankprotokoll auf 1999 gesetzt und die Uhr des Protokolls bleibt auf dem 7. November 1999 stehen, bis die Systemuhr diesen Zeitpunkt erreicht. Wenn Sie versuchen, eine aktualisierende Wiederherstellung bis zu einem Zeitpunkt innerhalb dieses Zeitrahmens durchzuführen, stoppt die Operation an der ersten Zeitmarke, die über den angegebenen Stoppzeitpunkt hinausgeht (d. h. 7. November 1997).
Obwohl DB2 die Aktualisierung der Systemuhr nicht beschränken kann, verringert der Konfigurationsparameter max_time_diff des Datenbankmanagers die Möglichkeit, daß diese Art von Problem auftritt:
Gehen Sie wie folgt vor, um eine falsche Zeitmarke in einem Datenbankprotokoll zu korrigieren und eine weitere Verbreitung der falschen Zeitmarke zu verhindern:
Nach diesen Maßnahmen ist die Protokollzeit richtig eingestellt, und die falsche Zeitmarke wird nicht weitergegeben. Sie sind in der Lage, eine Wiederherstellung bis zu einem bestimmten Zeitpunkt mit Hilfe der letzten Sicherung durchzuführen, die von der Datenbankpartition erstellt wurde.