A nyári időszámítás és a hálózati időszolgáltatók egyaránt befolyásolják az aktuális időt a kiszolgálógépeken. Az adatáthelyezést magában foglaló szolgáltatásoknál időbélyegeket használnak annak meghatározásához, hogy a kiszolgálók mikor ellenőrzik az új adatokat, és mikor hajtják végre az adatáthelyezést. A rendszerórában bekövetkezett változások hatással vannak az adatszolgáltatások összetevőire és ezek teljesítményére.
A rendszeróra kézi állítása is befolyásolja az időt. Ez a rendszer viselkedését az állítás módjától függetlenül azonos módon érinti. A rendszeróra visszaállítása nem kívánt késleltetéseket okoz az adatáthelyezést magában foglaló szolgáltatásoknál. A rendszeróra előreállításánál nem lesznek késések, de az adatáthelyezést magában foglaló szolgáltatások hamarabb érik el az ütemezett időközöket.
A rendszeridő módosításának hatása az összetevőkre
Ha a rendszerórát visszaállítják, az érintett összetevőknél a belső időbélyegek jövőbeli értéket kapnak, de a rendszeróra beállítása múltbeli lesz. A rendszeróra módosítása egyaránt érinteni fogja a rendszeridőt, a belső időbélyegeket és az időközöket jelző paramétereket.
Ha a rendszerórát előreállítják, az érintett összetevőknél a belső időbélyegek múltbeli értéket kapnak, míg a rendszeróra aktuális időbélyegének beállítása jövőbeli lesz. Ez hasonló a rendszeróra normál viselkedéséhez, a különbség annyi, hogy érinteni fogja a következő ütemezett futtatás, illetve az adatbázisrekordok élettartamának meghatározását tartalmazó időméréseket. A ténylegesen eltelt idő kisebb lesz a számítottnál.
Példa: A rekordnak a törlésre jelölés után még 24 óráig kell a rendszeren maradniuk. Tegyük fel, hogy egy rekord kedden délután 3 órakor válik törlésre jelöltté. A 24 órás megtartási házirendnek megfelelően a rekord a szerda délután 3 órát követően bármikor törölhető. Tegyük fel továbbá, hogy kedden délután 3:01-kor a rendszerórát péntek délután 3:01-re előreállítják. Ennek megfelelően, jóllehet a ténylegesen eltelt idő mindössze 1 perc, a rendszer eltelt ideje 3 nap és 1 perc lesz, így az adott rekordra teljesül a 24 órás megtartási házirend. Ez azt jelenti, hogy a rendszeróra módosítása következtében a rekord a normálisnál jóval korábban válik eltávolíthatóvá.
Másik példa: Adott adatelőkészítési összetevő 24 óránként fut, és egyik futása után a rendszerórát 26 órával előreállítják. Ekkor a következő futásig előírt 24 órás tényleges idő kivárása helyett az adatelőkészítési összetevő a lehető leghamarabb újból el fog indulni. Ennek oka az, hogy a rendszer számítása szerint legalább 26 óra telt el az utolsó futás óta. Gyakorlatilag a rendszeróra előreállítása ebben az esetben lerövidítette az adatelőkészítési összetevő időközét. Az adatelőkészítési összetevő ezt követően normális időközönként fog elindulni, feltéve, hogy nem módosítják a rendszerórát.
Az alábbiakban olyan eseteket vizsgálunk, amikor az összetevők futnak, mielőtt visszaállítják a rendszerórát.
Az alkalmazási összetevő is fenntart egy belső időbélyeget, amely az új rekordok ellenőrzésének idejét határozza meg. Ebben az esetben a belső időbélyeg értéke nagyobb lesz a rendszer aktuális időbélyege értékénél. Az alkalmazási összetevő várakozni fog, amíg a rendszer „utoléri” belső időbélyegét, még akkor is, ha már új rekordok állnak rendelkezésre. Az aktuális időbélyeg időpontjának elérésekor az összetevő az adatáthelyezésre rendelkezésre álló rekordokat fog keresni.
Az időbélyegek azt nem határozzák meg, hogy mely sorokat kell többszörözni. Ezt egy belső érték alapján állapítja meg a rendszer, amelyre nincs hatással a rendszeróra. A forrás- és a célélettartam összetevő is időbélyegeket használ annak meghatározásához, hogy mikor történjen az indítás, és mely rekordok állnak készen a tisztításhoz.
Az állapot- és a futásidejű adatbázis adatáthelyezési szolgáltatásában a forrásélettartam összetevő csak az indítás meghatározásához használ időbélyegeket, a tisztítandó rekordokhoz nem. Ennél a szolgáltatásnál ez az összetevő nem támogatja a megtartási házirend szolgáltatást, amely lehetővé teszi a tisztításra jelölt adatok bizonyos ideig való létezését. Ez a szolgáltatás azonban nem létezik a futásidejű és az előzmény-adatbázis adatáthelyezési szolgáltatásának forrásélettartam összetevőjében. Néhány rekord mindaddig nem nem fog megfelelni a megtartási házirend feltételének, míg a rendszeróra aktuális értéke „utol nem éri”. A célélettartam összetevő mindkét adatáthelyezési szolgáltatásnál támogatja a megtartási házirendet, így a rendszeróra módosítása érinteni fogja futásának idejét, valamint a tisztított rekordokat.
Az adatelőkészítési összetevők belső ütemezésük részeként időbélyegeket használnak. Elindulásuk után ezek az összetevők a növelési időt várják. A rendszeróra visszaállítása érinteni fogja az adatelőkészítést, amelynek végrehajtására mindaddig nem kerül sor, míg a rendszeróra „be nem hozza a lemaradást”.
Helyreállítás
Az időszolgáltatók által okozott változtatás során nincs szükség helyreállításra, mivel az időeltérés csak nagyon kicsi lehet, legfeljebb pár perc. Hatása mindössze egy kis időkeret, amelyben semmi sem történik az összetevők „feléledéséig”. A nyári időszámításra való áttérésnél az óra visszaállítása miatt az összetevők egy órára felfüggesztik a többszörözést, de ezután helyre kell állni a normál működésnek. A rendszertől függ, hogy ez problémát okoz-e.
Az egyik olyan eset, amikor ez a várakozás jelentős lehet az, amikor hibásan nagy idővel előreállítják a rendszerórát, miközben az összetevő kiszolgálók futnak. Ekkor (a kiszolgálók futásától függetlenül) az idő aktuális időre lesz beállítva. Ebben az esetben az összetevők belső időbélyegeiket jövőbeli időpontra állítják, de az aktuális időkeretben fognak futni. Hosszú idő fog eltelni, mire az adatáthelyezési szolgáltatás újból sorokat fog feldolgozni. Ez a késleltetés felhalmozódhat a rendszeren, ami érintheti a helyreállítási időt. Ekkor javító műveletek végrehajtására lehet szükség.
Javító művelet
connect to <forrásadatbázis> 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%'
-- Végrehajtás a lehető leghamarabb UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME LIKE 'APP%'; -- Végrehajtás a következő esedékes időpontban UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp) WHERE TABLE_NAME LIKE 'APP%'; connect reset;
CONNECT TO <céladatbázis> 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%';
-- Végrehajtás a lehető leghamarabb UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME NOT LIKE 'APP%'; -- Végrehajtás a következő esedékes időpontban UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp) WHERE TABLE_NAME NOT LIKE 'APP%';
CONNECT TO <CÉL> -- A lekérdezés a következőket jeleníti meg SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED, CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
-- Végrehajtás a következő esedékes időpontban UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)= (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP); -- Végrehajtás a lehető leghamarabb UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)= (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES); CONNECT RESET
Példa:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."Utána:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLDEzután indítsa el az összes parancsfájlt. A teljes frissítés nyomán a rögzítési és az alkalmazási összetevők visszaállítják az összes belső időbélyeget, de ez az adatok áthelyezésével és újrafeldolgozásával jár. Fontos a felkészülés a teljesítmény várható csökkenésére.