Serwery czasu letniego i sieciowego mają wpływ na bieżący czas na serwerze. W usługach przenoszenia danych znaczniki czasu są używane do określania czasu sprawdzenia przez serwer nowych danych i czasu przenoszenia danych. Zmiany w zegarze systemowym wpływają na komponenty usług danych i na ich dostrzegalną wydajność.
Ręczne przestawianie zegara systemowego również wpływa na czas. Oddziaływanie zmiany czasu na zachowanie systemu jest takie same, bez względu na sposób przestawienia zegara. Niepożądane opóźnienia w usługach przenoszenia danych występują w przypadku przestawienia czasu zegara systemowego wstecz. Opóźnienia nie wystąpią, gdy czas na zegarze systemowym zostanie przestawiony do przodu, jednakże komponenty usług przenoszenia danych osiągną zaplanowane odstępy czasu wcześniej.
Skutki zmiany czasu w komponentach
Jeśli czas na zegarze systemowym zostanie przesunięty do tyłu, wewnętrzne znaczniki czasu zależnych komponentów pozostaną ustawione na moment późniejszy, a czas na zegarze systemowym będzie wskazywać moment wcześniejszy. Zegar systemowy, wewnętrzne odstępy czasu i parametry wskazujące odstępy czasu będą uzależnione od zmiany czasu zegara systemowego.
Jeśli czas na zegarze systemowym zostanie przestawiony do przodu, wewnętrzne znaczniki czasu zależnych komponentów pozostaną ustawione na moment wcześniejszy, a bieżący znacznik czasu zegara systemowego będzie wskazywać moment późniejszy. Jest to podobne do normalnego zachowania zegara systemowego; różnicą jest to, że niektóre miary obejmujące określanie następnego zaplanowanego wykonania lub określające cykl życia rekordu bazy danych będą zależne od zegara. Bieżący upływający czas będzie krótszy niż obliczony upływający czas.
Przykład: Rekord powinien pozostać w systemie przez 24 godziny po tym, jak stanie się gotowy do usunięcia. Załóżmy, że rekord staje się gotowy do usunięcia we wtorek o godzinie 15:00. Wtedy ze względu na zasadę przechowywania rekordów przez 24 godziny rekord może zostać usunięty w dowolnym momencie po godzinie 15:00 w środę. Załóżmy również, że we wtorek o godzinie 15:01 zegar systemowy zostanie przestawiony do przodu na godzinę 15:01 w najbliższy piątek. Mimo że w rzeczywistości minęła tylko jedna minuta, na skutek tej zmiany czas, który upłynął w systemie, będzie wynosić 3 dni i 1 minutę, dlatego 24-godzinny okres przechowywania rekordu będzie zakończony. Oznacza to, że na skutek zmiany czasu rekord może zostać usunięty szybciej, jeśli czas zegara systemowego zostanie zmieniony.
Inny przykład: Określony komponent ETL jest uruchamiany co 24 godziny, a natychmiast po jego uruchomieniu zegar systemowy jest przestawiany o 26 godzin do przodu. Zamiast oczekiwania w czasie rzeczywistym wymaganych wstępnie 24 godzin do następnego uruchomienia ten komponent ETL zostanie ponownie uruchomiony jak najszybciej. Jest to spowodowane obliczeniem systemowym, które wskazuje, że od ostatniego uruchomienia minęło co najmniej 26 godzin. W rezultacie w tym przypadku przesunięcie zegara do przodu powoduje skrócenie odstępu czasu komponentu ETL. Po tym uruchomieniu komponent ETL będzie wznawiany normalnie w zdefiniowanych odstępach czasu, o ile nie będzie żadnych zmian w zegarze systemowym.
Poniższe sekcje dotyczą tylko przesuwania zegara wstecz w przypadku, gdy komponenty zostały uruchomione przed cofnięciem zegara.
Komponent wprowadzający obsługuje również wewnętrzny znacznik czasu, który określa moment sprawdzania, czy są nowe rekordy. W tym scenariuszu wewnętrzny znacznik czasu będzie miał wyższą wartość niż bieżący znacznik czasu systemu. Nawet, gdy dostępne są nowe rekordy, komponent wprowadzający oczekuje, aż znacznik czasu systemu dogoni wewnętrzny znacznik czasu. Po wyrównaniu bieżący znacznik czasu rozpocznie wyszukiwanie rekordów dostępnych dla usługi przenoszenia danych.
Znaczniki czasu nie określają, które wiersze mają być replikowane. Jest to określane przez wewnętrzną wartość, na którą nie ma wpływu zegar systemowy. Komponenty cyklu życia elementów źródłowych i docelowych używają również znaczników czasu do określania czasu uruchomienia i rekordów gotowych do usunięcia.
Komponent cyklu życia elementów źródłowych podczas wykonywania usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych używa znaczników czasu tylko do określania czasu uruchomienia. Nie używa on znaczników czasu do określenia elementów do usunięcia. Komponent tej usługi nie obsługuje funkcji strategii czasu przechowywania, która dopuszcza istnienie informacji gotowych do usunięcia przez pewien okres strategii czasu przechowywania. Jednak ta funkcja nie istnieje w komponencie cyklu życia elementów źródłowych usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych. Niektóre rekordy nie spełniają kryteriów strategii czasu przechowywania przed zrównaniem się z czasem bieżącego zegara systemowego. Komponenty cyklu życia elementów docelowych obu usług przenoszenia danych obsługują definicję strategii czasu przechowywania, zatem wszystkie zmiany czasu wpływają na moment uruchomienia i wybór elementów do usunięcia.
W komponentach ETL znaczniki czasu stanowią część wewnętrznego harmonogramu. Po uruchomieniu tych komponentów oczekuje się, że czas będzie wzrastał. Jeśli zegar systemowy zostanie przestawiony do tyłu, wpłynie to na harmonogram ETL i żaden z komponentów ETL nie zostanie wykonany przed zrównaniem się z czasem systemowym.
Odtwarzanie
Odtwarzanie podczas zmiany wykonanej przez serwer czasu nie powinno być konieczne, ponieważ różnice czasu są zwykle bardzo małe i wynoszą zaledwie kilka minut. Efektem będzie krótki przedział czasu, w trakcie którego nie dzieje się nic poza operacją zrównywania się komponentów z systemem. Podczas zmiany czasu na czas letni przestawienie czasu do tyłu powoduje zatrzymanie na godzinę replikacji przez komponenty. Po tej godzinie komponenty będą musiały zrównać swój czas względem systemu. W zależności od systemu może to stanowić problem lub nie.
Jednym ze scenariuszy, w których to oczekiwanie może być istotne, jest popełnienie błędu i przestawienie czasu systemowego na moment w odległej przyszłości podczas działania serwerów komponentów. Wtedy (niezależnie od tego, czy serwery są uruchomione) następuje przywrócenie czasu na czas bieżący. W takim przypadku wewnętrzne znaczniki czasu komponentów zostaną przestawione do przodu, ale komponenty będą działały w bieżącym zakresie czasu. Spowoduje to duże opóźnienie w przetwarzaniu wierszy przez usługi przenoszenia danych. To opóźnienie może narastać w systemie i wpływać na czas odtwarzania. Może być konieczne wykonanie przez administratora czynności korygującej.
Czynność korygująca
connect to <source_database> 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%'
-- Uruchomić jak najszybciej. UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME LIKE 'APP%'; -- Uruchomić podczas następnego przedziału czasu UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp) WHERE TABLE_NAME LIKE 'APP%'; connect reset;
CONNECT TO <target_database> 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%';
-- Uruchomić jak najszybciej. UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME NOT LIKE 'APP%'; -- Uruchomić podczas następnego przedziału czasu UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp) WHERE TABLE_NAME NOT LIKE 'APP%';
CONNECT TO <TARGET> -- To zapytanie powoduje wyświetlenie SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED, CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
-- Uruchomić podczas następnego przedziału czasu UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)= (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP); -- Uruchomić jak najszybciej UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)= (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES); CONNECT RESET
Przykład:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."Po:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLDNastępnie należy uruchomić wszystkie skrypty. Pełne odświeżenie spowoduje zresetowanie przez komponenty przechwytujące i wprowadzające wszystkich wewnętrznych znaczników czasu, ale wywoła dodatkowy koszt przenoszenia i ponownego przetwarzania danych. Ważne jest, aby przygotować się na potencjalny spadek wydajności podczas operacji wyrównywania czasu systemowego.