Servery letního času a síťového času

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 Capture bude i nadále zachytávat změny všech tabulek, které sleduje. Je použit výpočet času pro určení okamžiku, kdy se mají tyto změny potvrdit a zpřístupnit komponentě Apply a komponentě Source Life Cycle. Komponenta Capture s největší pravděpodobností interně označila časové razítko v budoucnosti. Nepotvrdí transakci, dokud nemají interní hodiny větší hodnotu, než označené interní časové razítko plus některý interní parametr pro interval mezi potvrzeními. V tomto případě platí, že pokud se systémové hodiny posunou vzad o 1 hodinu, nejhorší výsledek bude ten, že jakékoliv transakce probíhající v další hodině nebudou dostupné, dokud tato hodina neuplyne. Pokud byly hodiny nastaveny na 1 rok vzad, bude provedení trvat systému 1 rok.
Poznámka: Komponenta Capture se potvrdí po předepsaném počtu transakcí; výchozí nastavení je 120. Je možné, že data budou komponentě Apply a komponentě Source Life Cycle k dispozici dříve, než jak je definováno.

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.

Možné scénáře času systémových hodin jsou:

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

Jednou volbou je jednoduše donutit komponenty Capture a Apply k zahájení úplného obnovení a poté aktualizovat interní časová razítka pro komponenty Source Life Cycle, Target Life Cycle a ETL.
  1. Určete všechny databáze, které běží na serveru, kde byl čas posunut do budoucna a poté byl vrácen zpět do minulosti. Existují dvě možnosti: Stavová databáze a běhová databáze nebo běhová databáze a databáze historie.
  2. Zastavte všechny servery podporující služby přesunu dat v ovlivněném systému. V průběhu tohoto procesu budete upravovat interní parametry a u některých komponent může být narušena synchronizace, pokud bude umožněno jejich spuštění. Další informace viz Spuštění a zastavení služby přesunu dat.
  3. Upravte interní časová razítka komponent Source Life Cycle a Target Life Cycle.
    Poznámka: Tato akce podléhá u jednotlivých verzí určitým změnám.
    1. Aktualizace časových razítek vyřazování komponenty Source Life Cycle. Tímto postupem se upraví nastavení u všech komponent Source Life Cycle, sloužících pro všechny modely obchodních ukazatelů v systému.
      Ověřte aktuální nastavení:
      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%'
      Poznámka: Přezkoumejte hodnoty LAST_PRUNED a PRUNE_INTERVAL a CURRENT TIMESTAMP. Rozhodněte se, zda chcete vyřazení provést okamžitě nebo v následujícím intervalu.
      -- 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;
    2. Aktualizace časových razítek vyřazování komponenty Target Life Cycle.
      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%';
      Poznámka: Přezkoumejte hodnoty LAST_PRUNED a PRUNE_INTERVAL a CURRENT TIMESTAMP. Rozhodněte, zda je vhodné provést vyřazení okamžitě nebo v následujícím intervalu.
      -- 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%';
    3. Aktualizace plánu ETL.
      Poznámka: Tímto budou ovlivněny všechny aktivity ETL ve všech modelech.
      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;
      Poznámka: Hodnoty ETL_0_MINUTES, NEXTSTARTTIME a LASTUPDATED v porovnání s hodnotou CURRENT TIMESTAMP.
      -- 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
    4. Vynutit úplné obnovení. Nejjednodušším způsobem vynucení úplného obnovení replikačních serverů Capture a Apply je zkopírování a úprava skriptů StartCapture pro každý model obchodních ukazatelů. Vyhledejte každý skript zahájení zachytávání pro každý model implementovaný v systému (Pokud jste postupovali dle pokynů v oddíle konsolidace skriptů spuštění a zastavení, jednoduše vyhledejte všechny příkazy asncap) a přidejte parametr: STARTMODE=COLD na konec příkazového řádku.
      Poznámka: Úplné obnovení je extrémní případ a může vést ke snížení výkonnosti, dokud není úplné obnovení dokončeno. To je způsobeno skutečností, že úplné obnovení způsobí zvýšení zatížení, které při běžných operacích datových služeb nenastává. Proto je důležité, aby se úplné obnovení provádělo v době, kdy systém není intenzivně používán. Výkonnost úplného obnovení závisí velmi na objemu dat ve zdrojové databázi služby přenosu dat.

      Příklad:

      Před:
      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
      Poté 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.

Copyright IBM Corporation 2005, 2006. Všechna práva vyhrazena.