Die Wiederherstellung der Umgebung kann eine wichtige Maßnahme sein, um den Verlust kritischer Daten zu verhindern. Es steht eine Reihe von Parametern zur Verfügung, die Ihnen bei der Verwaltung der Umgebung helfen, um sicherstellen zu können, daß eine geeignete Wiederherstellung der Daten bzw. Transaktionen durchgeführt werden kann. Diese Parameter werden in folgende Kategorien unterteilt:
Die folgenden Parameter enthalten Informationen zu Anzahl, Größe und Status der Dateien, die zur Datenbankprotokollierung verwendet werden:
Mit diesem Parameter wird die Größe jeder primären und sekundären Protokolldatei definiert. Die Größe dieser Protokolldateien beschränkt die Anzahl der Protokollsätze, die in die Dateien geschrieben werden können, bevor sie voll sind und eine neue Protokolldatei erforderlich wird.
Die Verwendung primärer und sekundärer Protokolldateien sowie die Maßnahmen, die ausgeführt werden, wenn eine Protokolldatei voll ist, sind von der Art der ausgeführten Protokollierung abhängig:
Eine primäre Protokolldatei kann wieder verwendet werden, wenn die in ihr aufgezeichneten Änderungen festgeschrieben wurden. Wenn die Größe der Protokolldatei beschränkt ist und Anwendungen eine große Anzahl von Änderungen an der Datenbank vorgenommen haben, ohne die Änderungen festzuschreiben, kann eine primäre Protokolldatei schnell voll werden. Wenn alle primären Protokolldateien voll sind, ordnet der Datenbankmanager sekundäre Protokolldateien für die neuen Protokollsätze zu.
Wenn eine primäre Protokolldatei voll ist, wird das Protokoll archiviert und eine neue primäre Protokolldatei zugeordnet.
Empfehlung: Die Größe der Protokolldateien muß mit der Anzahl der primären Protokolldateien abgestimmt werden:
Anmerkung: | Die Protokolldateien dürfen insgesamt maximal 32 GB groß sein. Das heißt, 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ß. |
Eine zu kleine Protokolldatei kann sich auf die Systemleistung auswirken, da das Archivieren alter Protokolldateien, das Zuordnen neuer Protokolldateien sowie das Warten auf verwendbare Protokolldateien einen erhöhten Systemaufwand mit sich bringen.
Eine zu große Protokolldatei kann Ihre Flexibilität bei der Verwaltung archivierter Protokolldateien bzw. beim Kopieren der Protokolldateien einschränken, da möglicherweise auf einigen Platten keine vollständige Protokolldatei gespeichert werden kann.
Wenn Sie die Protokollspeicherung verwenden, wird die aktuelle aktive Protokolldatei geschlossen und abgeschnitten, wenn die letzte Anwendung die Verbindung zu einer Datenbank trennt. Für die nächste zur Datenbank hergestellte Verbindung wird die nächste Protokolldatei verwendet. Wenn Sie also die Protokollanforderungen Ihrer gleichzeitig ausgeführten Anwendungen kennen, können Sie möglicherweise eine Protokolldateigröße festlegen, durch die nicht zu viel Speicher umsonst zugeordnet wird.
Weitere Informationen zu diesem Parameter finden Sie im Abschnitt zu den Konfigurationsparametern für Datenbankprotokollierung im Handbuch Systemverwaltung: Implementierung.
Die primären Protokolldateien reservieren eine feste Menge Speicher, der den Wiederherstellungsprotokollen zugeordnet wird. Mit diesem Parameter kann die Anzahl der im voraus zugeordneten primären Protokolldateien festgelegt werden.
Bei der Umlaufprotokollierung werden die primären Protokolldateien nacheinander wiederholt verwendet. Das heißt, wenn ein Protokoll voll ist, wird die nächste primäre Protokolldatei in der Reihenfolge verwendet, wenn sie verfügbar ist. Ein Protokoll wird als verfügbar angesehen, wenn alle Arbeitseinheiten mit Protokollsätzen in diesem Protokoll festgeschrieben oder rückgängig gemacht wurden. Wenn die nächste Protokolldatei in der Reihenfolge nicht verfügbar ist, wird eine sekundäre Protokolldatei zugeordnet und verwendet. Es werden solange weitere sekundäre Protokolldateien zugeordnet und verwendet, bis die nächste primäre Protokolldatei in der Reihenfolge verfügbar wird oder der durch den Parameter logsecond festgelegte Grenzwert erreicht wird. Sobald diese sekundären Protokolldateien vom Datenbankmanager nicht mehr benötigt werden, wird der für sie verwendete Speicher wieder freigegeben.
Für die Anzahl der primären und sekundären Protokolldateien muß folgende Gleichung gelten:
Empfehlung: Der Wert, der für diesen Parameter gewählt wird, ist von einer Reihe von Faktoren abhängig, zu denen auch die Art der Protokollierung, die Größe der Protokolldateien und die Art der Verarbeitungsumgebung (z.B. die Länge der Transaktionen und die Häufigkeit des Festschreibens) gehören.
Durch die Erhöhung dieses Werts wird mehr Plattenspeicher für die Protokolle erforderlich, weil die primären Protokolldateien bereits bei der ersten Verbindung zur Datenbank im voraus zugeordnet werden.
Wenn sich herausstellt, daß häufig sekundäre Protokolldateien zugeordnet werden, kann die Systemleistung möglicherweise durch eine Vergrößerung der Protokolldateien (logfilsiz) oder durch eine Erhöhung der Anzahl primärer Protokolldateien verbessert werden.
Bei Datenbanken, auf die nicht oft zugegriffen wird, sollte zur Einsparung von Plattenspeicherplatz dieser Parameter auf den Wert 2 gesetzt werden. Bei Datenbanken, für die die aktualisierende Wiederherstellung aktiviert ist, sollte dieser Parameter auf einen größeren Wert gesetzt werden, um den erhöhten Systemaufwand aufgrund der beinahe sofort erforderlichen Zuordnung neuer Protokolle zu vermeiden.
Sie können den Datenbanksystemmonitor zur Ermittlung der geeigneten Größe für die primären Protokolldateien verwenden.
Weitere Informationen finden Sie in den Beschreibungen zu folgenden Monitorelementen im Handbuch System Monitor Guide and Reference:
Die Beobachtung dieser Monitorwerte über einen gewissen Zeitraum hinweg kann sich für die geeignete Einstellung der Parameter als nützlich erweisen, da Durchschnittswerte Ihre tatsächlichen Anforderungen wahrscheinlich besser widerspiegeln.
Dieser Parameter gibt die Anzahl der sekundären Protokolldateien an, die (nach Bedarf) erstellt und für Wiederherstellungsprotokolle verwendet werden. Wenn die primären Protokolldateien voll sind, werden die sekundären Protokolldateien (in der Größe logfilsiz) nacheinander so zugeordnet, wie sie benötigt werden, und zwar höchstens 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 Datenbank wird beendet.
Unter Anzahl primärer Protokolldateien (logprimary) finden Sie weitere Informationen zur Verwendung sekundärer Protokolldateien.
Empfehlung: Verwenden Sie sekundäre Protokolldateien für Datenbanken, die in periodischen Zeitabständen immer wieder große Mengen an Protokollspeicher benötigen. Sekundäre Protokolldateien sollten beispielsweise eingesetzt werden, wenn eine Anwendung, die einmal im Monat ausgeführt wird, mehr Protokollspeicher benötigt, als durch die primären Protokolldateien zur Verfügung gestellt wird. Da sekundäre Protokolldateien keinen permanenten Dateispeicherplatz erforderlich machen, sind sie für solche Zwecke gut geeignet.
Mit diesem Parameter können Sie eine Zeichenfolge mit bis zu 242 Byte angeben, um die Speicherposition der Protokolldateien zu ändern. Die Zeichenfolge kann auf einen Pfadnamen oder auf eine unformatierte Einheit verweisen. Verweist die Zeichenfolge auf einen Pfadnamen, muß es sich um einen vollständig qualifizierten Pfad handeln und nicht um einen relativen Pfad.
Anmerkung: | In einer partitionierten Datenbankumgebung wird die Knotennummer automatisch an den Pfad angefügt. Dadurch wird die Eindeutigkeit des Pfads in Konfigurationen mit mehreren logischen Knoten sichergestellt. |
Geben Sie zum Angeben einer Einheit eine Zeichenfolge an, die vom Betriebssystem als eine Einheit erkannt wird. Beispiel:
Anmerkung: | Damit Protokolle in eine Einheit geschrieben werden können, muß Windows NT Version 4.0 mit Service Pack 3 installiert sein. |
Anmerkung: | Eine Einheit können Sie nur auf AIX-, Windows NT- und Solaris-Plattformen angeben. |
Diese Einstellung wird nur dann zum Wert des Parameters logpath, wenn die beiden folgenden Bedingungen zutreffen:
Wenn die erste neue Verbindung zur Datenbank hergestellt wird, versetzt der Datenbankmanager die Protokolle an die neue, von logpath angegebene Speicherposition.
Im alten Protokollpfad befinden sich eventuell noch Protokolldateien. Diese Protokolldateien wurden eventuell nicht archiviert. Sie müssen sie möglicherweise manuell archivieren. Wenn Sie zudem für diese Datenbank Replikation ausführen, benötigt Replikation eventuell weiterhin die vor der Protokollpfadänderung vorhandenen Protokolldateien. Wenn der Datenbankkonfigurationsparameter für Benutzer-Exit (userexit) für die Datenbank auf "Yes" gesetzt ist und wenn alle Protokolldateien entweder automatisch durch DB2 oder von Ihnen selbst manuell archiviert wurden, dann kann DB2 die Protokolldateien zum Beenden des Replikationsprozesses abrufen. Andernfalls können Sie die Dateien aus dem alten Protokollpfad in den neuen Protokollpfad kopieren.
Empfehlung: Es empfiehlt sich, die Protokolldateien auf einer physischen Platte zu speichern, auf der nicht häufig E/A-Operationen auftreten. Sie sollten beispielsweise die Protokolldateien nicht auf derselben Platte wie das Betriebssystem oder umfangreiche Datenbanken speichern. Dadurch werden die Protokolliervorgänge effizient und verursachen nur ein Minimum an Systemaufwand, wie z. B. Warten auf E/A-Operationen.
Mit dem Datenbanksystemmonitor können Sie die Anzahl der E/A-Operationen für die Datenbankprotokollierung verfolgen.
Weitere Informationen finden Sie in den Beschreibungen der folgenden Monitorelemente im Handbuch System Monitor Guide and Reference:
Die oben genannten Datenelemente geben das Volumen der E/A-Aktivitäten für die Datenbankprotokollierung zurück. Sie können ein Tool zur Betriebssystemüberwachung verwenden, um Daten zu anderen Platten-E/A-Aktivitäten zu sammeln. Anschließend können Sie beide Arten von E/A-Aktivitäten vergleichen.
Dieser Parameter gibt den aktuellen Pfad an, der für die Protokolldateien verwendet wird. Dieser Parameter kann nicht direkt geändert werden, da der Wert vom Datenbankmanager festgelegt wird, wenn eine Änderung am Parameter newlogpath wirksam wird.
Bei der Erstellung einer Datenbank wird die zugehörige Datei des Wiederherstellungsprotokolls in einem Unterverzeichnis des Verzeichnisses erstellt, in dem sich die Datenbank befindet. Standardmäßig wird dieses Unterverzeichnis mit dem Namen SQLOGDIR in dem Verzeichnis angelegt, das für die Datenbank erstellt wurde.
Dieser Parameter gibt den Namen der zur Zeit aktiven Protokolldatei an.
Die folgenden Parameter können den Typ und die Leistung der Datenbankprotokollierung beeinflussen:
Mit diesem Parameter können Sie das Schreiben von Protokollsätzen auf die Festplatte verzögern, bis eine Mindestanzahl von Festschreibungen (COMMIT-Operationen) ausgeführt wurde. Diese Verzögerung kann dazu beitragen, daß der Systemaufwand des Datenbankmanagers für das Schreiben von Protokollsätzen verringert und infolgedessen die Leistung erhöht wird, wenn mehrere Anwendungen für eine Datenbank ausgeführt und von den Anwendungen viele Festschreibungen 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 oder gleich dem Wert dieses Parameters ist. Wenn die Gruppierung von Festschreibungen ausgefü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.
Am Wert dieses Parameters vorgenommene Änderungen werden sofort wirksam. Sie brauchen nicht abzuwarten, bis alle Anwendungen von der Datenbank getrennt wurden.
Empfehlung: Erhöhen Sie den Wert dieses Parameters über seinen Standardwert hinaus, wenn mehrere Schreib-/Leseanwendungen regelmäßig gleichzeitig Datenbankfestschreibungen anfordern. Dadurch wird eine höhere Effizienz bei E/A-Operationen für Protokolldateien erzielt, da diese Operationen weniger häufig auftreten und bei jeder Operation mehr Protokollsätze geschrieben werden.
Sie könnten auch die Anzahl der Transaktionen pro Sekunde ermitteln und diesen Parameter so anpassen, daß die Höchstanzahl von Transaktionen pro Sekunde (oder ein großer Prozentsatz davon) von diesem Parameter berücksichtigt wird. Durch die Berücksichtigung der Spitzenaktivitäten würde der Systemaufwand für das Schreiben von Protokollsätzen in Phasen hoher Systembelastung minimiert.
Wenn der Wert des Parameters mincommit erhöht wird, kann es auch notwendig werden, den Wert des Parameters logbufsz zu erhöhen, um zu vermeiden, daß ein voller Protokollpuffer eine Schreiboperation während dieser Phasen hoher Systembelastung erzwingt. In diesem Fall sollte der Wert für den Parameter logbufsz nach folgender Formel festgelegt werden:
mincommit * (durchschnittlicher Protokollbereich für eine Transaktion)
Sie können den Datenbanksystemmonitor folgendermaßen zur Optimierung des Werts dieses Parameters verwenden:
Durch das Ziehen von Stichproben über einen typischen Arbeitstag hinweg können Sie die Phasen hoher Systembelastung feststellen. Sie können die Gesamtanzahl der Transaktionen durch Addieren der Werte für folgende Monitorelemente berechnen:
Anhand dieser Stichproben und der verfügbaren Zeitmarken können Sie die Anzahl der Transaktionen pro Sekunde berechnen.
Durch das Ziehen von Stichproben über einen gewissen Zeitraum hinweg und für eine Anzahl von Transaktionen können Sie den durchschnittlich verwendeten Protokollspeicherbereich mit dem folgenden Monitorelement berechnen:
Weitere Informationen zum Datenbanksystemmonitor finden Sie in System Monitor Guide and Reference.
Dieser Parameter hat folgende Funktionen:
Beim Steuern der Anzahl der Protokolldateien, die für die Wiederherstellung nach einem Systemabsturz erforderlich sind, verwendet der Datenbankmanager diesen Parameter zum Starten der Seitenlöschfunktionen. Dadurch wird sichergestellt, daß Seiten, die älter sind als das angegebene Wiederherstellungsfenster, bereits auf Platte geschrieben sind. ("Wiederherstellungfenster" bezeichnet hierbei den Zeitraum, der für die Verarbeitung der Protokolldateien bei der Wiederherstellung nach einem Systemabsturz erforderlich ist.)
Zum Zeitpunkt einer Datenbankstörung, die zum Beispiel durch einen Stromausfall verursacht wird, kann für in der Datenbank ausgeführte Änderungen folgendes gelten:
Wenn eine Datenbank erneut gestartet wird, werden die Protokolldateien verwendet, um eine Wiederherstellung der Datenbank nach dem Systemabsturz auszuführen, die sicherstellt, daß die Datenbank in einem konsistenten Zustand verbleibt (d. h., alle festgeschriebenen Transaktionen werden in der Datenbank nachvollzogen, und keine der nicht festgeschriebenen Transaktionen werden in der Datenbank nachvollzogen).
Der Datenbankmanager verwendet eine Protokollsteuerdatei, um festzustellen, welche Datensätze aus der Protokolldatei in der Datenbank nachvollzogen werden müssen. Diese Protokollsteuerdatei wird in regelmäßigen Abständen auf die Festplatte geschrieben, und der Datenbankmanager kann abhängig von der Frequenz dieses Ereignisses Protokollsätze festgeschriebener Transaktionen oder Protokollsätze zu Änderungen, die bereits aus dem Pufferpool auf Platte geschrieben wurden, nachvollziehen. Diese Protokollsätze haben keine Auswirkung auf die Datenbank, das Nachvollziehen dieser Protokollsätze führt jedoch zu einem gewissen erhöhten Systemaufwand während des Neustarts der Datenbank.
Die Protokollsteuerdatei wird immer dann auf die Festplatte geschrieben, wenn eine Protokolldatei voll ist, und außerdem bei bedingten Prüfpunkten. Sie können diesen Konfigurationsparameter dazu verwenden, zusätzliche bedingte Prüfpunkte auszulösen.
Die Ablaufsteuerung für bedingte Prüfpunkte wird mit Hilfe der Differenz zwischen dem "aktuellen Stand" und dem "aufgezeichneten Stand" festgelegt. Diese Differenz wird als Prozentsatz vom Wert des Parameters logfilsiz angegeben. Der "aufgezeichnete Stand" wird anhand des ältesten gültigen Protokollsatzes ermittelt, der von der Protokollsteuerdatei auf der Festplatte angegeben wird, während der "aktuelle Stand" anhand der Protokollsteuerinformationen im Hauptspeicher ermittelt wird. (Der älteste gültige Protokollsatz ist der erste Protokollsatz, der bei einem Wiederherstellungsprozeß gelesen würde.) Der bedingte Prüfpunkt wird ausgelöst, wenn der nach der folgenden Formel berechnete Wert größer oder gleich dem Wert dieses Parameters ist:
( (Bereich zw. aufgezeichnetem u. aktuellem Stand) / logfilsiz ) * 100 * logprimary
Empfehlung: Sie können den Wert dieses Parameters erhöhen oder verringern, je nachdem, ob Ihr Wiederherstellungsfenster größer oder kleiner als eine Protokolldatei sein soll. Wenn Sie den Wert dieses Parameters herabsetzen, wird der Datenbankmanager veranlaßt, die Seitenlöschfunktionen häufiger auszulösen und häufiger bedingte Prüfpunkte anzusetzen. Diese Maßnahmen können die Anzahl der Protokollsätze, die verarbeitet werden müssen, und die Anzahl der überschüssigen Protokollsätze, die während der Wiederherstellung verarbeitet werden, verringern.
Beachten Sie jedoch, daß mehr Auslöser von Seitenlöschfunktionen und häufigere bedingte Prüfpunkte den Systemaufwand erhöhen, der mit der Protokollierung der Datenbank verbunden ist, was sich negativ auf die Leistung des Datenbankmanagers auswirken kann. Daneben können auch folgende Umstände dazu führen, daß häufigere bedingte Prüfpunkte die für den Neustart einer Datenbank benötigte Zeit nicht verkürzen:
In beiden Fällen ändern sich die Protokollsteuerdaten im Hauptspeicher nur selten, und es ist nur dann sinnvoll, die Protokollsteuerdaten auf die Festplatte zu schreiben, wenn sie sich geändert haben.
Es gibt folgende Werte:
Ist logretain auf "Recovery" oder userexit auf "Ja" gesetzt, werden die aktiven Protokolldateien gespeichert und als Online-Archivprotokolldateien in einer aktualisierenden Wiederherstellung eingesetzt. Dies wird Protokollierung mit Protokollspeicherung genannt.
Nach dem Setzen von logretain auf "Recovery" und/oder von userexit auf "Ja" müssen Sie eine Gesamtsicherung der Datenbank vornehmen. Dieser Status wird durch den Markierungsparameter backup_pending angezeigt.
Ist logretain auf "Nein" und userexit auf "Nein" gesetzt, ist die aktualisierende Wiederherstellung für die Datenbank nicht verfügbar.
Wenn logretain auf "Capture" gesetzt ist, ruft das Capture-Programm den Befehl PRUNE LOGFILE zum Löschen der Protokolldateien am Ende des Capture-Programms auf. Setzen Sie logretain nicht auf "Capture", wenn Sie die Datenbank aktualisierend wiederherstellen wollen.
Ist logretain auf "Nein" und userexit auf "Nein" gesetzt, werden die Protokolle nicht gespeichert. In diesem Fall löscht der Datenbankmanager alle Protokolldateien im Verzeichnis logpath (einschließlich der Online-Archivprotokolldateien), ordnet er neue aktive Protokolldateien zu und aktiviert er erneut Umlaufprotokollierung.
Wenn dieser Parameter aktiviert ist, wird unabhängig von der Einstellung des Parameters logretain eine Protokollierung mit Protokollspeicherung ausgeführt. Mit diesem Parameter wird außerdem angegeben, daß ein Benutzerausgangsprogramm verwendet werden soll, um Protokolldateien zu archivieren und wieder abzurufen. Protokolldateien werden archiviert, wenn sie vom Datenbankmanager geschlossen werden. Die Protokolldateien werden wieder abgerufen, wenn das Dienstprogramm ROLLFORWARD sie zur Wiederherstellung einer Datenbank benötigt.
Nach der Aktivierung des Parameters logretain und/oder userexit muß eine Gesamtsicherung der Datenbank ausgeführt werden. Dieser Status wird durch den Markierungsparameter backup_pending angezeigt.
Wenn beide Parameter inaktiviert werden, ist die aktualisierende Wiederherstellung der Datenbank nicht mehr möglich, da keine Protokolldateien mehr gespeichert werden. In diesem Fall löscht der Datenbankmanager alle Protokolldateien im Verzeichnis des Parameters logpath (einschließlich der Online-Archivprotokolldateien), ordnet neue aktive Protokolldateien zu und reaktiviert die Umlaufprotokollierung.
Weitere Informationen zum Benutzer-Exit-Programm finden Sie im Abschnitt zum Benutzer-Exit für Datenbankwiederherstellung im Handbuch Systemverwaltung: Implementierung.
Die folgenden Parameter wirken sich auf die verschiedenen Aspekte der Datenbankwiederherstellung aus:
Siehe auch Wiederherstellung der verteilten Arbeitseinheit.
Die folgenden Parameter werden bei Verwendung von Tivoli Storage Manager (TSM) verwendet:
Wenn dieser Parameter auf ON gesetzt wird, ruft der Datenbankmanager bei Bedarf automatisch das Dienstprogramm zum Neustarten der Datenbank auf, wenn eine Anwendung die Verbindung zur Datenbank herstellt. Das Programm zum Neustarten der Datenbank wird verwendet, um eine Wiederherstellung nach Systemabsturz auszuführen. Es wird ausgeführt, wenn die Datenbank abnormal beendet wurde, während Anwendungen mit ihr verbunden waren. Eine abnormale Beendigung der Datenbank könnte z. B. durch einen Stromausfall oder einen Fehler der Systemsoftware verursacht werden. Bei der Wiederherstellung werden festgeschriebene Transaktionen, die sich im Pufferpool befanden, jedoch zum Zeitpunkt des Fehlers nicht auf die Festplatte geschrieben waren, in der Datenbank nachvollzogen. Außerdem werden alle nicht festgeschriebenen Transaktionen, die auf Platte geschrieben wurden, wieder zurückgesetzt.
Wenn der Parameter autorestart nicht aktiviert ist, empfängt eine Anwendung den Fehler SQL1015N, wenn sie versucht, die Verbindung zu einer Datenbank herzustellen, für die eine Wiederherstellung nach einem Systemabsturz ausgeführt werden muß (für die die Datenbank neu gestartet werden muß). In diesem Fall kann die Anwendung das Dienstprogramm zum Neustarten der Datenbank aufrufen, oder Sie können die Datenbank neu starten, indem Sie die Funktion zum Neustarten im Wiederherstellungsprogramm auswählen.
Dieser Parameter gibt an, wann der Datenbankmanager versucht, ungültige Indizes neu zu erstellen. Für diesen Parameter sind drei Einstellungen möglich:
Informationen zu numerischen Äquivalenten und API-Konstanten für diese Werte finden Sie im Handbuch Administrative API Reference.
Indizes können ungültig werden, wenn nicht behebbare Plattenfehler auftreten. Wenn dabei die Daten selbst beschädigt werden, können die Daten verloren gehen. Wird jedoch ein Index beschädigt, kann der Index durch Neuerstellung wiederhergestellt werden. Wird ein Index neu erstellt, während Benutzer mit der Datenbank verbunden sind, können zwei Probleme auftreten:
Empfehlung: Die beste Option für diesen Parameter auf einem Server mit vielen Benutzern, wenn die Zeit für den Neustart keine kritische Rolle spielt, ist die Indexneuerstellung beim Neustart der Datenbank (DATABASE RESTART) als Teil des Vorgangs, mit dem die Datenbank nach einem Systemabsturz wiederhergestellt und online verfügbar gemacht wird.
Bei der Einstellung "ACCESS" für diesen Parameter verschlechtert sich während der Indexneuerstellung die Leistung des Datenbankmanagers. Jeder Benutzer, der auf den Index oder die Tabelle zugreift, der bzw. die gerade neu erstellt wird, muß zunächst auf die Beendigung der Indexneuerstellung warten.
Wenn dieser Parameter auf "RESTART" gesetzt wird, dauert der Neustart der Datenbank wegen der Indexneuerstellung länger, jedoch wird die normale Verarbeitung nicht mehr beeinträchtigt, sobald die Datenbank wieder online verfügbar ist.
Mit diesem Parameter wird die Standardanzahl von Sitzungen angegeben, die während des Wiederabrufens einer Tabellenladekopie verwendet werden. Der Wert sollte auf eine optimale Anzahl von E/A-Sitzungen gesetzt werden, die zum Wiederabrufen einer Ladekopie verwendet werden sollen. Das Wiederabrufen einer Ladekopie ist eine ähnliche Operation wie die Wiederherstellung. Sie können diesen Parameter durch Einträge überschreiben, die sich in der Datei mit den Angaben zur Speicherposition der exportierten Daten befinden. Diese Datei wird von der Umgebungsvariablen DB2LOADREC angegeben.
Die Standardanzahl der Puffer, die für den Abruf der Ladekopien verwendet werden, ist um zwei größer als der Wert dieses Parameters. Die Anzahl der Puffer kann ebenfalls in der Datei mit den Angaben zur Speicherposition der exportierten Daten überschrieben werden.
Dieser Parameter ist nur gültig, wenn die aktualisierende Wiederherstellung aktiviert ist.
Weitere Informationen zur Wiederherstellung finden Sie im Handbuch Versetzen von Daten Dienstprogramme und Referenz.
Dieser Parameter gibt die Anzahl der Datenbanksicherungen an, die für eine Datenbank beibehalten werden sollen. Wird die angegebene Anzahl Sicherungen erreicht, werden alte Sicherungen in der Datei des Wiederherstellungsprotokolls als abgelaufen markiert. Die Einträge in der Datei des Wiederherstellungsprotokolls für Tabellenbereichssicherungen und Ladekopiesicherungen, die mit der abgelaufenen Datenbanksicherung verbunden sind, werden ebenfalls als abgelaufen markiert. Wird eine Sicherung als abgelaufen markiert, können die physischen Sicherungen von ihrem Speicherort (z. B. Platte, Band, ADSTAR Distributed Storage Manager) gelöscht werden. Die nächste Datenbanksicherung entfernt die abgelaufenen Einträge aus der Datei des Wiederherstellungsprotokolls.
Wird eine Datenbanksicherung in der Protokolldatei als abgelaufen markiert, werden entsprechende über einen DB2 Data Links Manager verbundene Dateisicherungen aus dem Archivierungs-Server gelöscht.
Der Konfigurationsparameter rec_his_retentn muß auf einen Wert gesetzt werden, der mit dem Wert von num_db_backups kompatibel ist. Wenn num_db_backup z. B. auf einen hohen Wert gesetzt ist, muß der Wert für rec_his_retentn hoch genug sein, um diese Anzahl der Sicherungen unterstützen zu können.
Mit diesem Parameter wird angegeben, wie viele Tage die Protokolldaten zu Sicherungen aufbewahrt werden sollen. Wenn die Datei des Wiederherstellungsprotokolls nicht benötigt wird, um Sicherungen, Wiederherstellungen und Ladevorgänge festzuhalten, kann dieser Parameter auf einen kleineren Wert gesetzt werden.
Wenn für diesen Parameter der Wert -1 angegeben wird, kann die Datei des Wiederherstellungsprotokolls nur explizit mit Hilfe der verfügbaren Befehle oder APIs entfernt werden. Wenn der Wert nicht -1 ist, wird die Datei des Wiederherstellungsprotokolls nach jeder vollständigen Sicherung der Datenbank entfernt.
Der Wert dieses Parameters überschreibt den Wert des Parameters num_db_backups, rec_his_retentn und num_db_backups müssen jedoch zusammenpassen. Wenn der Wert für num_db_backups groß ist, muß der Wert für rec_his_retentn groß genug sein, um die angegebene Anzahl von Sicherungen unterstützen zu können.
Unabhängig davon, wie kurz der Aufbewahrungszeitraum ist, werden die aktuellste Datenbanksicherung und die zugehörige Wiederherstellungsgruppe immer zurückbehalten, sofern Sie nicht das Dienstprogramm PRUNE mit der Angabe WITH FORCE OPTION verwenden. Weitere Informationen zu diesem Dienstprogramm finden Sie in Command Reference.
Die Tivoli Storage Manager-Verwaltungsklasse (TSM) gibt an, wie der TSM-Server die Sicherungsversionen der Objekte verwalten soll, die gesichert werden.
Standardmäßig ist keine TSM-Verwaltungsklasse festgelegt.
Die Verwaltungsklasse wird vom Tivoli Storage Manager-Administrator zugeordnet. Sobald die Zuordnung erfolgt ist, müssen Sie diesen Parameter auf den Namen der Verwaltungsklasse setzen. Bei der Durchführung einer TSM-Sicherung verwendet der Datenbankmanager diesen Parameter, um die Verwaltungsklasse an TSM zu übergeben.
Weitere Informationen zu Tivoli Storage Manager finden Sie im entsprechenden Abschnitt im Handbuch Systemverwaltung: Implementierung.
Mit diesem Parameter kann die Standardeinstellung für das Kennwort, das dem Produkt Tivoli Storage Manager (TSM) zugeordnet ist, überschrieben werden. Dieses Kennwort ist erforderlich, um eine Datenbank wiederherstellen zu können, die in TSM von einem anderen Knoten aus gesichert wurde.
Anmerkung: | Wenn der Parameter tsm_nodename bei einer Sicherung mit DB2 (z. B. mit dem Befehl BACKUP DATABASE) überschrieben wurde, muß möglicherweise auch der Parameter tsm_password festgelegt werden. |
Standardmäßig können Sie eine Datenbank in TSM nur auf dem Knoten wiederherstellen, von dem aus die Sicherung ausgeführt wurde. Es ist möglich, daß der Wert für den Parameter tsm_nodename bei einer Sicherung mit DB2 überschrieben wird.
Weitere Informationen zu Tivoli Storage Manager finden Sie im entsprechenden Abschnitt im Handbuch Systemverwaltung: Implementierung.
Mit diesem Parameter kann die Standardeinstellung für den Knotennamen, der dem Produkt Tivoli Storage Manager (TSM) zugeordnet ist, überschrieben werden. Der Knotenname ist erforderlich, um eine Datenbank wiederherstellen zu können, die von einem anderen Knoten aus in TSM gesichert wurde.
Standardmäßig können Sie eine Datenbank in TSM nur auf dem Knoten wiederherstellen, von dem aus die Sicherung ausgeführt wurde. Es ist möglich, daß der Wert für den Parameter tsm_nodename bei einer Sicherung mit DB2 (z. B. mit dem Befehl BACKUP DATABASE) überschrieben wird.
Weitere Informationen zu Tivoli Storage Manager finden Sie im entsprechenden Abschnitt im Handbuch Systemverwaltung: Implementierung.
Mit diesem Parameter kann die Standardeinstellung für den Eigner, der dem Produkt Tivoli Storage Manager (TSM) zugeordnet ist, überschrieben werden. Der Eignername ist erforderlich, um eine Datenbank wiederherstellen zu können, die von einem anderen Knoten aus in ADSM gesichert wurde. Es ist möglich, daß der Wert für den Parameter tsm_owner bei einer Sicherung mit DB2 (z. B. mit dem Befehl BACKUP DATABASE) überschrieben wird.
Anmerkung: | Beim Eignernamen muß die Groß-/Kleinschreibung beachtet werden. |
Standardmäßig können Sie eine Datenbank in TSM nur auf dem Knoten wiederherstellen, von dem aus die Sicherung ausgeführt wurde.
Weitere Informationen zu Tivoli Storage Manager finden Sie im entsprechenden Abschnitt im Handbuch Systemverwaltung: Implementierung.
Die folgenden Parameter wirken sich auf die Wiederherstellung von DUOW-Transaktionen (Distributed Unit of Work - verteilte Arbeitseinheit) aus:
Mit diesem Parameter wird der Name der Transaktionsmanagerdatenbank (TMD) für jedes DB2-Exemplar angegeben. Eine TMD kann eine der folgenden Datenbanken sein:
Es handelt sich dabei um eine Datenbank, die zu Protokoll- und Koordinierungsfunktionen verwendet wird und zur Wiederherstellung unbestätigter Transaktionen dient.
Dieser Parameter kann auf den Wert 1ST_CONN gesetzt werden, wodurch festgelegt wird, daß die Transaktionsmanagerdatenbank die erste Datenbank ist, zu der ein Benutzer eine Verbindung herstellt.
Weitere Informationen zur verteilten Arbeitseinheit finden Sie im entsprechenden Abschnitt im Handbuch Systemverwaltung: Konzept.
Empfehlung: Zur Vereinfachung der Verwaltung und des Betriebs können Sie einige exemplarübergreifende Datenbanken erstellen und diese Datenbanken ausschließlich als Transaktionsmanagerdatenbanken verwenden.
Mit diesem Parameter wird das Zeitintervall in Sekunden angegeben, während dessen ein Transaktionsmanager (TM), ein Ressourcenmanager (RM) oder ein Synchronisationspunktmanager (SPM) versuchen soll, jede ausstehende unbestätigte Transaktion, die in dem TM, RM oder SPM gefunden wird, wiederherzustellen. Dieser Parameter ist gültig, wenn Sie Transaktionen in einer Umgebung mit verteilten Arbeitseinheiten (DUOW) ausführen.
Weitere Informationen zur verteilten Arbeitseinheit finden Sie im Abschnitt zu verteilten Datenbanken im Handbuch Systemverwaltung: Konzept.
Empfehlung: Wenn in Ihrer Umgebung unbestätigte Transaktionen keine Störungen anderer Transaktionen für Ihre Datenbank verursachen, können Sie den Wert dieses Parameters auch erhöhen. Wenn Sie einen DB2 Connect-Gateway zum Zugriff auf DRDA2-Anwendungs-Server verwenden, sollten Sie die Auswirkungen bedenken, die unbestätigte Transaktionen auf Anwendungs-Servern haben können, auch wenn lokal keine Störungen beim Datenzugriff zu erwarten sind. Gibt es keine unbestätigten Transaktionen, sind die Auswirkungen auf die Leistung minimal.
Dieser Parameter gibt an, in welches Verzeichnis die SPM-Protokolle geschrieben werden. Standardmäßig werden die Protokolle in das Verzeichnis sqllib/spmlog geschrieben; dies kann in Umgebungen mit hohem Transaktionsaufkommen zu E/A-Engpässen führen. Verwenden Sie diesen Parameter, damit SPM-Protokolldateien auf eine Platte mit kürzeren Zugriffszeiten als das aktuelle Verzeichnis sqllib/spmlog geschrieben werden. Dadurch wird der gemeinsame Zugriff der SPM-Agenten optimiert.
Weitere Informationen zum Synchronisationspunktmanager finden Sie im Handbuch DB2 Installation und Konfiguration Ergänzung.
Weitere Informationen zur Wiederherstellung unbestätigter DRDA-Transaktionen finden Sie im entsprechenden Abschnitt des Handbuchs Systemverwaltung: Konzept.
Mit diesem Parameter wird der Name des Exemplars des Synchronisationspunktmanagers (SPM) gegenüber dem Datenbankmanager identifiziert.
Weitere Informationen zum Synchronisationspunktmanager finden Sie im Handbuch DB2 Installation und Konfiguration Ergänzung.
Weitere Informationen zur Wiederherstellung unbestätigter DRDA-Transaktionen finden Sie im entsprechenden Abschnitt des Handbuchs Systemverwaltung: Konzept.
Mit diesem Parameter wird die Größe der Protokolldatei für den Synchronisationspunktmanager (SPM) in 4-KB-Seiten angegeben. Die Protokolldatei befindet sich im Unterverzeichnis spmlog im Verzeichnis sqllib und wird erstellt, wenn der Synchronisationspunktmanager zum ersten Mal gestartet wird.
Weitere Informationen zum Synchronisationspunktmanager finden Sie im Handbuch DB2 Installation und Konfiguration Ergänzung.
Weitere Informationen zur Wiederherstellung unbestätigter DRDA-Transaktionen finden Sie im entsprechenden Abschnitt des Handbuchs Systemverwaltung: Konzept.
Empfehlung: Die Protokolldatei des Synchronisationspunktmanagers sollte einerseits groß genu sein, um die Leistung zu gewährleisten, andererseits aber auch klein genug, um die Verschwendung von Speicherbereich zu vermeiden. Die erforderliche Größe hängt von der Anzahl der Transaktionen ab, die geschützte Dialoge verwenden, und von der Häufigkeit, mit der COMMIT- oder ROLLBACK-Operationen ausgeführt werden.
Gehen Sie wie folgt vor, um die Größe der SPM-Protokolldatei zu ändern:
Mit diesem Parameter wird die Anzahl der Agenten angegeben, die gleichzeitig Resynchronisationsoperationen ausführen können.
Weitere Informationen zur Wiederherstellung unbestätigter DRDA-Transaktionen finden Sie im entsprechenden Abschnitt des Handbuchs Systemverwaltung: Konzept.
Weitere Informationen zum Synchronisationspunktmanager finden Sie im Handbuch DB2 Installation und Konfiguration Ergänzung.