Serwery czasu letniego i sieciowego

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 przechwytujący będzie kontynuował przechwytywanie zmian we wszystkich śledzonych tabelach. Obliczenie czasu służy do określania momentu zatwierdzenia tych zmian i udostępnienia ich komponentowi wprowadzającemu i komponentowi cyklu życia elementu źródłowego. Komponent przechwytujący najprawdopodobniej będzie miał w przyszłości wewnętrznie zaznaczony znacznik czasu. Nie zatwierdzi on transakcji, zanim zegar wewnętrzny nie przekroczy wewnętrznego zaznaczonego znacznika czasu i pewnego wewnętrznego parametru dla odstępu czasu między zatwierdzeniami. Jeśli w takim przypadku zegar systemowy zostanie przestawiony o 1 godzinę do tyłu, najgorszym skutkiem będzie to, że żadne transakcje, które wystąpią w trakcie dodatkowej godziny, nie będą dostępne przed upływem tej godziny. Jeśli zegar zostanie przestawiony o 1 rok do tyłu, nadrobienie tego zajmie systemowi 1 rok.
Uwaga: Komponent przechwytujący wykonuje zatwierdzanie po określonej liczbie transakcji; domyślną liczbą jest 120. Jest możliwe, że dane będą dostępne dla komponentu wprowadzającego i komponentu cyklu życia elementów źródłowych wcześniej niż to zdefiniowano.

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.

Oto możliwe scenariusze czasu zegara systemowego:

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

Jedną z opcji jest zmuszenie komponentu przechwytującego i wprowadzającego do zainicjowania pełnego odświeżenia, a następnie zaktualizowanie wewnętrznych znaczników czasu dla komponentu cyklu życia elementów źródłowych, komponentu cyklu życia elementów docelowych i komponentów ETL.
  1. Należy zidentyfikować wszystkie bazy danych uruchomione na serwerze, na którym czas został najpierw przestawiony do przodu, a następnie z powrotem do tyłu. Istnieją dwie możliwości: przenoszenie danych z bazy danych stanu do wykonawczej bazy danych i przenoszenie danych z wykonawczej bazy danych do bazy danych historycznych.
  2. Należy zatrzymać wszystkie serwery obsługujące usługi przenoszenia danych w systemie, w którym wystąpił problem. Podczas tego procesu należy zmodyfikować wewnętrzne parametry, a niektóre komponenty mogą nie podlegać synchronizacji, o ile można je uruchomić. Więcej informacji można znaleźć w temacie Uruchamianie i zatrzymywanie usługi przenoszenia danych.
  3. Należy zmodyfikować wewnętrzne znaczniki czasu komponentów cyklu życia elementów źródłowych i komponentów cyklu życia elementów docelowych.
    Uwaga: Ta czynność może ulec zmianie w zależności od wydania.
    1. Aktualizowanie znaczników czasu czyszczenia cyklu życia elementów źródłowych. Powoduje modyfikację ustawień dla wszystkich komponentów cyklu życia elementów źródłowych służących wszystkim modelom miar biznesowych w systemie.
      Należy sprawdzić bieżące ustawienia:
      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%'
      Uwaga: Należy przejrzeć wartości elementów LAST_PRUNED, PRUNE_INTERVAL i CURRENT TIMESTAMP. Należy określić, czy czyszczenie ma zostać wykonane natychmiast, czy w następnym przedziale czasu.
      -- 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;
    2. Aktualizowanie znaczników czasu czyszczenia cyklu życia elementów docelowych.
      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%';
      Uwaga: Należy przejrzeć wartości elementów LAST_PRUNED, PRUNE_INTERVAL i CURRENT TIMESTAMP. Należy określić, czy czyszczenie ma zostać wykonane natychmiast, czy podczas następnego przedziału czasu.
      -- 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%';
    3. Aktualizowanie harmonogramu ETL.
      Uwaga: Wpływa na wszystkie działania ETL we wszystkich modelach.
      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;
      Uwaga: Wartości ETL_0_MINUTES, NEXTSTARTTIME i LASTUPDATED są porównywane z wartością CURRENT TIMESTAMP.
      -- 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
    4. Wymusza pełne odświeżenie. Najprostszym sposobem wymuszenia pełnego odświeżenia serwerów przechwytujących i wprowadzających replikacji jest skopiowanie i zmodyfikowanie skryptów StartCapture dla każdego modelu miar biznesowych. Należy znaleźć wszystkie skrypty uruchamiające komponenty przechwytujące dla każdego modelu wdrożonego w systemie (jeśli postępowano według instrukcji znajdujących się w sekcji dotyczącej konsolidowania skryptów uruchamiających i zatrzymujących, należy po prostu znaleźć wszystkie komendy asncap), a następnie dodać parametr: STARTMODE=COLD na końcu wiersza komendy.
      Uwaga: Pełne odświeżenie jest wyjątkowym przypadkiem i może prowadzić do słabej wydajności aż do czasu zakończenia pełnego odświeżania. Jest to spowodowane dodawaniem dodatkowych nakładów pracy podczas pełnego odświeżania, które nie występują zwykle podczas normalnych operacji usług danych. Zatem istotne jest, aby pełne odświeżanie było wykonywane w czasie, gdy system nie jest mocno obciążony. Pełne odświeżanie jest silnie uzależnione od wielkości danych w źródłowej bazie danych usługi przenoszenia danych.

      Przykład:

      Przed:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      Po:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      Nastę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.

Copyright IBM Corporation 2005, 2006. Wszelkie prawa zastrzeżone.