Servery letního času a síťového času ovlivňují aktuální čas na počítači se serverem. Ve službách přesunu dat se používají časová razítka k určování doby, kdy servery zjišťují nová data a kdy provádějí přesun dat. Změny systémových hodin ovlivňují komponenty datových služeb a jejich zjištěnou výkonnost.
Ruční posun systémových hodin také ovlivní čas. Chování systému je ovlivněno stejným způsobem, bez ohledu na použitý způsob posunu hodin. Při posunu systémových hodin vzad dojde k nechtěným zpožděním služeb přesunu dat. Při posunu systémových hodin vpřed ke zpoždění nedochází, ačkoli komponenty služeb přesunu dat dosáhnou naplánované intervaly dříve.
Vliv změny času na komponenty
Pokud jsou systémové hodiny posunuty vzad, ovlivněné komponenty budou mít interní časová razítka nastavena do budoucnosti, ale systémové hodiny budou nastavené do minulosti. Změna systémových hodin ovlivní systémové hodiny, tato interní časová razítka a parametry indikující intervaly.
Při posunu systémových hodin vpřed budou mít ovlivněné komponenty interní razítka nastavená do minulosti a aktuální časové razítko systémových hodin bude nastaveno do budoucnosti. To se podobá běžnému chování systémových hodin; rozdíl je v tom, že budou ovlivněna některá měření času, která zahrnují určení dalšího naplánovaného spuštění, nebo určení životního cyklu záznamu databáze. Skutečný uplynulý čas bude kratší než vypočtený uplynulý čas.
Příklad: Záznam musí zůstat v systému po dobu 24 hodin poté, co se stane způsobilým pro odstranění. Předpokládejme, že záznam se stane způsobilým pro odstranění v úterý v 15.00 hodin. V tomto okamžiku může být kvůli zásadě 24hodinového uchování záznam odstraněn kdykoli po 15.00 ve středu. Také předpokládejme, že v úterý v 15:01 budou systémové hodiny posunuty vpřed na 15:01 na následující pátek. Proto i když uplynula pouze 1 minuta skutečného času, uplynulý čas systému bude 3 dny a 1 minuta a 24hodinová doba uchování pro tento záznam je splněna. To znamená, že kvůli této změně času může být záznam odebrán rychleji, než kdyby systémové hodiny nebyly změněny.
Další příklad: Konkrétní komponenta ETL se spustí každých 24 hodin a okamžitě po jejím spuštění se systémové hodiny posunou vpřed o 26 hodin. Namísto nezbytného čekání po dobu 24 hodin před dalším spuštěním se komponenta ETL spustí znovu co nejdříve. Je to způsobeno systémovým výpočtem, že od posledního spuštění uběhlo alespoň 26 hodin. Ve skutečnosti posunutí hodin vpřed v tomto případě snížilo interval ETL. Komponenta ETL se po tomto spuštění jako normálně vrátí k definovanému intervalu, pokud již nejsou provedeny další změny systémových hodin.
Následující oddíly se zaměřují pouze na posunutí hodin vzad poté, co komponenty běží před vrácením hodin zpět.
Komponenta Apply také udržuje interní časové razítko, které určuje, kdy bude komponenta kontrolovat nové záznamy. V tomto scénáři bude toto interní časové razítko také větší, než aktuální časové razítko systému. Komponenta Apply počká, dokud časové razítko systému nedosáhne interního časového razítka, i když jsou k dispozici nové záznamy. Jakmile je dosaženo aktuální časové razítko, začnou se vyhledávat záznamy, které jsou k dispozici pro přesun dat.
Časová razítka neurčují, které řádky mají být replikovány. To je určeno interní hodnotou, která není ovlivněna systémovými hodinami. Komponenty Source Life Cycle a Target Life Cycle také používají časová razítka pro určení okamžiku zahájení, a které záznamy jsou připraveny k vyřazení.
Komponenta Source Life Cycle ve službě přesunu dat stavové databáze do běhové databáze používá časová razítka pouze k určení okamžiku zahájení. Nepoužívá časová razítka k určení záznamů k vyřazení. Tato komponenta této služby nepodporuje funkci zásady uchování, která umožňuje, aby informace způsobilé k vyřazení existovaly po určitou dobu zásady uchování. Avšak tato funkce neexistuje v komponentě Source Life Cycle ve službě přesunu běhových dat na data historie. Některé záznamy nesplňují kritéria zásad uchování, dokud nejsou dosaženy aktuální systémové hodiny. Komponenty Target Life Cycle na obou službách přesunu dat podporují definici zásady uchování, a proto jakékoliv změny času ovlivní dobu jejich spuštění a to, co vyřazují.
Komponenty ETL používají časová razítka jako součást svého interního plánování. Po spuštění tyto komponenty očekávají zvětšení času. Pokud se systémové hodiny posunou vzad, je ovlivněno plánování ETL a žádná komponenta ETL není provedena, dokud není dostižen systém.
Obnovení
Obnovení během změny provedené časovým serverem by nemělo být nutné, protože časové rozdíly by měly být velmi malé - pouze několik minut. Výsledkem bude malý časový rámec, kde se nic nepřihodí, dokud se komponenty nedosáhnou. Kvůli přechodu na letní čas způsobí posun času vzad během změny času to, že se komponenty přestanou replikovat po dobu jedné hodiny a poté budou muset dosáhnout systému. Závisí na systému, zda se jedná o problém.
Jeden scénář, kde by toto čekání mohlo být významné, je případ, kdy dojde k chybě a systémový čas je nastaven o mnoho napřed, zatímco servery komponent jsou spuštěny. Poté (bez ohledu na to, zda jsou servery spuštěny) se čas obnoví na aktuální čas. V tomto případě by komponenty nastavily svá interní časová razítka do budoucna, ale budou spuštěny v aktuálním časovém rámci. Dojde k velké prodlevě předtím, než služba přesunu dat zpracuje znovu některý z řádků. Tato prodleva by mohla způsobit nárůst v systému, který by mohl ovlivnit dobu obnovení. Administrátor bude možná muset provést nápravnou akci.
Nápravná akce
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%'
-- SPUSTIT Co nejdříve. UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME LIKE 'APP%'; -- SPUSTIT v dalším intervalu 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%';
-- SPUSTIT Co nejdříve. UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME NOT LIKE 'APP%'; -- SPUSTIT v dalším intervalu UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp) WHERE TABLE_NAME NOT LIKE 'APP%';
CONNECT TO <TARGET> -- Zobrazí se tento dotaz SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED, CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
-- SPUSTIT v dalším intervalu UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)= (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP); -- SPUSTIT co nejdříve UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)= (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES); CONNECT RESET
Příklad:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."Po:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLDPoté spusťte všechny skripty. Toto úplné obnovení způsobí, že komponenty Capture a Apply resetují všechna svá interní časová razítka, ale povedou ke vzniku dalších nákladů na přesun a opakované zpracování dat. Je důležité naplánovat možné snížení výkonnosti při dohánění systému.