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 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.
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
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%'
-- 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;
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%';
-- 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%';
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;
-- 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
Beispiel:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."Nachher:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLDStarten 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.