Sommerzeit und Netzzeitserver

Die aktuelle Zeit auf einer Servermaschine wird sowohl durch die Sommerzeit als auch durch Netzzeitserver beeinflusst. Bei Services zum Versetzen von Daten wird mit Hilfe von Zeitmarken bestimmt, wenn die Server prüfen, ob neue Daten vorhanden sind, und wann das Versetzen der Daten stattfindet. Änderungen an der Systemuhr wirken sich auf die Datenbankservicekomponenten und ihre wahrgenommene Leistung aus.

Ein manuelles Verstellen der Systemuhr wirkt sich ebenfalls auf die Zeit aus. Der Einfluss auf das Verhalten des Systems ist identisch, und zwar ungeachtet des Verfahrens, mit dem die Uhr verstellt wird. Wird die Systemuhr zurückgestellt, führt dies bei Services zum Versetzen von Daten zu unerwünschten Verzögerungen. Wenn die Systemuhr vorgestellt wird, treten keine Verzögerungen auf, aber die Komponenten der Services zum Versetzen von Daten erreichen die geplanten Intervalle zu einem früheren Zeitpunkt.

Einfluss von Zeitänderungen auf Komponenten

Falls die Systemuhr zurückgestellt wird, sind die internen Zeitmarken der betroffenen Komponenten auf einen Zeitpunkt in der Zukunft gesetzt, die Systemuhr ist jedoch auf einen Zeitpunkt in der Vergangenheit gesetzt. Die Systemuhr, diese internen Zeitmarken und die Parameter, mit denen Intervalle angegeben werden, sind alle von einer Änderung der Systemuhr betroffen.

Falls die Systemuhr vorgestellt wird, sind die internen Zeitmarken der betroffenen Komponenten auf einen Zeitpunkt in der Vergangenheit gesetzt, und die aktuelle Zeitmarke der Systemuhr ist auf einen Zeitpunkt in der Zukunft gesetzt. Dieses Verhalten hat Ähnlichkeit mit dem normalen Verhalten der Systemuhr. Der Unterschied besteht jedoch darin, dass einige Zeitmessungen, beispielsweise zur Bestimmung der nächsten geplanten Ausführung oder zur Ermittlung des Lebenszyklus' eines Datenbanksatzes hiervon betroffen sind. Die tatsächlich abgelaufene Zeit ist kleiner als die berechnete abgelaufene Zeit.

Beispiel: Ein Datensatz soll für die Dauer von 24 Stunden auf dem System erhalten bleiben, nachdem er zum Löschen ausgewählt werden kann. Angenommen, ein Datensatz wird am Dienstag um 15.00 Uhr zum Löschen verfügbar. Zu diesem Zeitpunkt kann der Datensatz nach der Richtlinie für die vierundzwanzigstündige Beibehaltung jederzeit nach Mittwoch, 15.00 Uhr, gelöscht werden. Nun wird am Dienstag um 15.01 Uhr die Systemuhr auf 15.01 Uhr am folgenden Freitag vorgestellt. Obwohl die abgelaufene Zeit in der Realität nur 1 Minute beträgt, sind gemäß der Systemzeit 3 Tage und 1 Minute abgelaufen. Die für diesen Satz festgelegte Beibehaltungsdauer von 24 Stunden wurde hiermit erfüllt. Dies bedeutet, dass der Satz aufgrund der Zeitänderung früher gelöscht werden kann, als dies der Fall gewesen wäre, wenn keine Änderung der Systemuhr stattgefunden hätte.

Weiteres Beispiel: Eine bestimmte ETL-Komponente wird alle 24 Stunden ausgeführt. Unmittelbar nach ihrer Ausführung wird die Systemuhr um 26 Stunden vorgestellt. Statt die vorgesehenen 24 Stunden in realer Zeit vor der nächsten Ausführung abzuwarten, startet die ETL-Komponente nun so bald wie möglich erneut. Dies liegt daran, dass gemäß der Berechnung des Systems seit der letzten Ausführung mindestens 26 Stunden verstrichen sind. Das Vorstellen der Uhr hat somit in diesem Fall das ETL-Intervall verkürzt. Nach dieser Ausführung nimmt die ETL-Komponente den normalen Betrieb im definierten Intervall wieder auf, sofern keine weiteren Änderungen an der Systemuhr vorgenommen werden.

Die folgenden Abschnitte beschäftigen sich ausschließlich mit einem Zurückstellen der Uhr nach der Ausführung der Komponenten.

Die Capture-Komponente erfasst weiterhin Änderungen an allen Tabellen, die von ihr protokolliert werden. Mit einer Zeitberechnung wird ermittelt, wann diese Änderungen festgeschrieben und der Apply-Komponente sowie der Komponente für den Quellenlebenszyklus verfügbar gemacht werden müssen. Die Capture-Komponente enthält höchstwahrscheinlich eine intern markierte Zeitmarke in der Zukunft. Die Transaktion wird erst dann festgeschrieben, wenn die interne Taktzeit größer als die intern markierte Zeitmarke ist, zuzüglich einiger interner Parameter für das Intervall zwischen Festschreibungen. Wird in diesem Fall die Systemuhr um eine Stunde zurückgestellt, hat dies schlimmstenfalls die Folge, dass alle Transaktionen, die in der neuen Stunde stattfinden, erst nach Ablauf dieser Stunde verfügbar sind. Falls die Uhr um 1 Jahr zurückgestellt wird, könnte es 1 Jahr dauern, bis das System wieder angeglichen ist.
Anmerkung: Die Capture-Komponente nimmt nach einer vorgeschriebenen Anzahl von Transaktionen eine Festschreibung vor; der Standardwert beträgt 120. Es ist möglich, dass Daten für die Apply-Komponente und die Komponente für den Quellenlebenszyklus früher als definiert verfügbar sind.

Die Apply-Komponente verwaltet ebenfalls eine interne Zeitmarke, die festlegt, wann geprüft werden soll, ob neue Datensätze vorhanden sind. In diesem Szenario ist die interne Zeitmarke größer als die aktuelle Zeitmarke des Systems. Selbst wenn neue Datensätze verfügbar sind, wartet die Apply-Komponente, bis die Zeitmarke des Systems an ihre interne Zeitmarke angeglichen ist. Sobald die aktuelle Zeitmarke erreicht wurde, beginnt die Suche nach Datensätzen, die versetzt werden können.

Die Zeitmarken bestimmen nicht, welche Zeilen repliziert werden müssen. Dies wird durch einen internen Wert vorgenommen, der von der Systemuhr nicht beeinflusst wird. Die Komponenten für den Quellen- und den Ziellebenszyklus verwenden ebenfalls Zeitmarken, um festzustellen, wann der Start ausgeführt wird und welche Datensätze bereinigt werden können.

Die Komponente für den Quellenlebenszyklus im Datenversetzungsservice "Status an Laufzeit" verwendet Zeitmarken nur, um den Startzeitpunkt zu ermitteln. Die zu bereinigenden Objekte werden nicht mit Hilfe von Zeitmarken ermittelt. Diese Komponente in diesem Service unterstützt nicht die Richtlinienfunktion für die Beibehaltung, nach der Informationen, die zur Bereinigung ausgewählt werden können, für eine bestimmte Beibehaltungsdauer vorhanden sind. In der Komponente für den Quellenlebenszyklus des Datenversetzungsservices "Laufzeit an Protokoll" ist diese Funktion jedoch vorhanden. Manche Datensätze erreichen die Bedingungen für die Beibehaltungsrichtlinie erst dann, wenn die aktuelle Systemuhr angeglichen ist. Die Komponenten für den Ziellebenszyklus unterstützen in beiden Datenversetzungsservices die Definition der Beibehaltungsrichtlinie. Jede Zeitänderung wirkt sich daher auf den Zeitpunkt ihrer Ausführung und die von ihnen bereinigten Objekte aus.

Die ETL-Komponenten verwenden Zeitmarken im Rahmen ihrer internen Terminierung. Sobald sie gestartet wurden, gehen diese Komponenten davon aus, dass die Zeit voranschreitet. Wird die Systemuhr zurückgestellt, wirkt sich dies auf die ETL-Terminierung aus, und es werden keine ETL-Operationen ausgeführt, bis die Systemuhr angeglichen ist.

Mögliche Szenarien für die Zeit der Systemuhr:

Fehlerbehebung

Bei einer Änderung, die durch einen Zeitserver vorgenommen wird, sollte keine Fehlerbehebung erforderlich sein, da der Zeitunterschied in der Regel sehr gering ist und nur einige Minuten beträgt. Dies hat einen kurzen Zeitraum zur Folge, in dem nichts ausgeführt wird, während die Komponenten sich an die neue Zeit angleichen. Bei einer Umstellung von Sommer- auf Winterzeit stellen die Komponenten die Replikation aufgrund der zurückgestellten Zeit für die Dauer von einer Stunde ein, nach der sie sich an das System angleichen müssen. Es ist vom System abhängig, ob dies ein Problem darstellt oder nicht.

Ein Szenario, in dem dieser Wartestatus problematisch sein könnte, tritt ein, wenn ein Fehler verursacht wird und die Systemzeit weit in die Zukunft vorgestellt wird, während die Komponentenserver ausgeführt werden. Anschließend wird die Zeit (unabhängig davon, ob die Server ausgeführt werden) wieder auf die aktuelle Zeit gesetzt. In diesem Fall sind die internen Zeitmarken der Komponenten auf einen Zeitpunkt in der Zukunft gesetzt, die Komponenten selbst werden jedoch gemäß der aktuellen Uhrzeit ausgeführt. Daher kommt es zu einer langen Verzögerung, bis die Services zum Versetzen von Daten wieder Zeilen verarbeiten. Diese Verzögerung könnte einen Aufbau im System verursachen, der die Wiederanlaufzeit beeinflusst. Möglicherweise muss der Administrator eine Korrekturmaßnahme ergreifen.

Korrekturmaßnahme

Eine Option besteht darin, einfach die Einleitung einer vollständigen Aktualisierung durch die Capture- und Apply-Komponente zu erzwingen und dann die internen Zeitmarken der Komponenten für den Quellenlebenszyklus und für den Ziellebenszyklus sowie der ETL-Komponenten zu aktualisieren.
  1. Geben Sie alle Datenbanken an, die auf dem Server ausgeführt werden, auf dem die Zeit vorgestellt und dann wieder zurückgestellt wurde. Es gibt zwei Möglichkeiten: "Status und Laufzeit" oder "Laufzeit und Protokoll".
  2. Stoppen Sie auf dem betreffenden System alle Server, die Services zum Versetzen von Daten unterstützen. Während dieses Prozesses ändern Sie interne Parameter. Manche Komponenten sind möglicherweise nicht mehr synchron, wenn ihre Ausführung zulässig ist. Weitere Informationen finden Sie im Abschnitt über das Starten und Stoppen eines Services zum Versetzen von Daten.
  3. Ändern Sie die internen Zeitmarken der Komponente für den Quellenlebenszyklus und der Komponente für den Ziellebenszyklus.
    Anmerkung: Im Hinblick auf diese Aktion bleiben in jedem Release Änderungen vorbehalten.
    1. Aktualisieren Sie den Quellenlebenszyklus unter Bereinigung der Zeitmarken. Dies ändert die Einstellungen aller Komponenten für den Quellenlebenszyklus für alle Business Measures-Modelle auf dem System.
      Prüfen Sie die aktuellen Einstellungen:
      connect to <quellendatenbank>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL, CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME LIKE 'APP%'
      Anmerkung: Prüfen Sie die Werte von LAST_PRUNED, PRUNE_INTERVAL und CURRENT TIMESTAMP. Legen Sie fest, ob die Bereinigung sofort oder beim nächsten Intervall erfolgen soll.
      -- Sofortige Ausführung:
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME LIKE 'APP%';
      -- Ausführung beim nächsten Intervall:
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME LIKE 'APP%';
      connect reset;
    2. Aktualisieren Sie den Ziellebenszyklus unter Bereinigung der Zeitmarken.
      CONNECT TO <zieldatenbank>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME NOT LIKE 'APP%';
      Anmerkung: Prüfen Sie die Werte von LAST_PRUNED, PRUNE_INTERVAL und CURRENT TIMESTAMP. Legen Sie fest, ob die Bereinigung sofort oder beim nächsten Intervall erfolgen soll.
      -- Sofortige Ausführung:
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME NOT LIKE 'APP%';
      -- Ausführung beim nächsten Intervall:
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME NOT LIKE 'APP%';
    3. Aktualisieren Sie den ETL-Zeitplan.
      Anmerkung: Dies wirkt sich auf alle ETL-Aktivitäten in allen Modellen aus.
      CONNECT TO <TARGET>
      -- Abfrage zeigt an:
      SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
      Anmerkung: Die Werte ETL_0_MINUTES, NEXTSTARTTIME und LASTUPDATED sind in Bezug auf den Wert für CURRENT TIMESTAMP angegeben.
      -- Ausführung beim nächsten Intervall:
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP);
      -- Baldmögliche Ausführung:
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES);
      CONNECT RESET
    4. Erzwingen Sie eine vollständige Aktualisierung. Eine vollständige Aktualisierung der Capture- und Apply-Server für die Replikation erreichen Sie am einfachsten dadurch, dass Sie die Scripts StartCapture für jedes Business Measures-Modell kopieren und ändern. Suchen Sie für jedes auf dem System implementierte Modell nach dem Script für den Erfassungsstart (falls Sie die Anweisungen im Abschnitt über die Konsolidierung von Start- und Stoppscripts befolgt haben, können Sie einfach nach jedem Befehl asncap suchen), und fügen Sie den Parameter STARTMODE=COLD am Ende der Befehlszeile hinzu.
      Anmerkung: Eine vollständige Aktualisierung stellt einen Extremfall dar und kann bis zum vollständigen Abschluss zu einer verringerten Leistung führen. Dies liegt daran, dass die vollständige Aktualisierung einen zusätzlichen Systemaufwand verursacht, der während des normalen Betriebs von Datenservices in der Regel nicht entsteht. Daher muss eine vollständige Aktualisierung unbedingt dann vorgenommen werden, wenn das System nicht stark ausgelastet ist. Die Leistung bei der vollständigen Aktualisierung ist wesentlich von der Größe der Daten in der Quellendatenbank für einen Service zum Versetzen von Daten abhängig.

      Beispiel:

      Vorher:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      Nachher:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      Starten Sie anschließend alle Scripts. Diese vollständige Aktualisierung setzt alle internen Zeitmarken in den Capture- und Apply-Komponenten zurück. Mit ihr ist jedoch zusätzlicher Aufwand für das Versetzen und erneute Verarbeiten der Daten verbunden. Es sollte unbedingt damit gerechnet werden, dass es bis zum Angleichen des Systems zu Leistungseinbußen kommen kann.

Copyright IBM Corporation 2005, 2006. Alle Rechte vorbehalten.