A nyári időszámítás és a hálózati időszolgáltatók

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.

A rögzítési összetevő folytatni fogja a változtatások rögzítését valamennyi nyomkövetésre jelölt táblán. A rendszer időszámítás alapján határozza meg, hogy mikor történjen ezen változtatások véglegesítése, és mikor álljanak az alkalmazási és a forrásélettartam összetevő rendelkezésére. A rögzítési összetevő belsőleg minden valószínűség szerint egy jövőbeli időbélyeget jelölt meg. Mindaddig nem fogja véglegesíteni a tranzakciót, míg a belső óra értéke nagyobb nem lesz a megjelölt belső időbélyeg értékénél (emellett figyelembe veszi a véglegesítések közötti időtartamra vonatkozó belső paraméterek beállítását is). Ebben az esetben a rendszerórát 1 órával visszaállították, így a legrosszabb esetben az új óra szerint egy óra elteltéig nem fog tranzakciókra sor kerülni. Ha az órát 1 évvel állítják vissza, akkor 1 év is eltelhet a rendszer „feléledéséig”.
Megjegyzés: A rögzítési összetevő előírt számú tranzakció véglegesítését hajtja végre, ennek alapértelmezett értéke 120. Így előfordulhat, hogy az alkalmazási és a forrásélettartam összetevő mégis a vártnál korábban megkapja az adatokat.

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”.

A rendszerórára felállítható esetek a következők:

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

Az egyik lehetőség a rögzítési és az alkalmazási összetevők kényszerítése a teljes frissítés elindítására, majd a forrásélettartam, a célélettartam és az adatelőkészítési összetevőknél a belső időbélyegek frissítésére.
  1. Azonosítsa az előreállított órát tartalmazó kiszolgálón futó összes adatbázist, majd állítsa vissza az órát. Két lehetőség van: állapot és futásidejű, illetve futásidejű és előzmény.
  2. Állítsa le az érintett rendszeren az adatáthelyezési szolgáltatást támogató összes kiszolgálót. Az eljárás során belső paraméterek módosítására kerül sor, és néhány összetevő kieshet a szinkronizálásból, ha ezt futás közben hajtják végre. A további tudnivalókat lásd: Adatáthelyezési szolgáltatások indítása és leállítása.
  3. Módosítsa a forrásélettartam és a célélettartam összetevők belső időbélyegeit.
    Megjegyzés: A művelet a verziótól függően változhat.
    1. A forrásélettartam tisztítási időbélyegeinek frissítése. A művelet az összes üzleti mérőszámmodellekt kiszolgáló összes forrásélettartam összetevő beállítását módosítja a rendszeren.
      Ellenőrizze az aktuális beállításokat:
      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%'
      Megjegyzés: Nézze át a LAST_PRUNED és a PRUNE_INTERVAL és a CURRENT TIMESTAMP értékét. Döntse el, hogy azonnal vagy a következő esedékes időpontban kívánja-e végrehajtani a tisztítást.
      -- 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;
    2. A célélettartam tisztítási időbélyegeinek frissítése.
      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%';
      Megjegyzés: Nézze át a LAST_PRUNED és a PRUNE_INTERVAL és a CURRENT TIMESTAMP értékét. Döntse el, hogy azonnali tisztításra van-e szükség, vagy elég ezt a következő esedékes időpontban végrehajtani.
      -- 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%';
    3. Az adatelőkészítési ütemezés frissítése.
      Megjegyzés: Ez az összes modell összes adatelőkészítési tevékenységét érinti.
      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;
      Megjegyzés: Az ETL_0_MINUTES, a NEXTSTARTTIME és a LASTUPDATED értéke a CURRENT TIMESTAMP értékéhez viszonyítva.
      -- 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
    4. Teljes frissítés kikényszerítése. A többszörözést végző rögzítési és alkalmazási kiszolgálók teljes frissítése a legegyszerűbben úgy hajtható végre, hogy másolja és módosítja az egyes üzleti mérőszámmodellekhez tartozó StartCapture parancsfájlt. Keresse meg a rendszeren működő valamennyi modellhez a parancsfájlt (ha követte az indítási és leállítási parancsfájlok egyesítéséről szóló rész utasításait, egyszerűen keresse meg az egyes asncap parancsokat), és a végére vegye fel a STARTMODE=COLD paramétert.
      Megjegyzés: A teljes frissítés különleges eset, és befejezéséig csökkenhet a teljesítmény. Ennek oka az, hogy a teljes frissítés az adatszolgáltatási műveleteknél szokásos esetben nem jelentkező külön terhelést jelent. Fontos tehát a rendszer nem leterhelt állapotában végrehajtani a teljes frissítést. A teljes frissítés teljesítménye erősen függ az adatáthelyezési szolgáltatás forrásadatbázisában lévő adatok mennyiségétől.

      Példa:

      Előtte:
      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=COLD
      Ezutá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.

Copyright IBM Corporation 2005, 2006. Minden jog fenntartva.