日光節約時間及網路時間伺服器

日光節約時間及網路時間伺服器皆會影響伺服器機器上目前的時間。 在資料移動服務中,系統會以時間戳記來決定伺服器要檢查新建資料及執行資料移動的時間。 變更系統時鐘會影響資料服務元件及其效能表現。

以手動方式移動系統時鐘也會影響時間。無論使用何種方式來移動時鐘,都會影響系統的行為。 當您將系統時鐘移動到過去時間,資料移動服務會發生不必要的延遲。雖然資料移動服務元件會很快地達到排程間隔,但如果將系統時鐘往前提早,便不會發生延遲。

變更時間對元件的影響

如果將系統時鐘的時間往後延後,則受影響的元件會將其內部時間戳記設定在未來時間,而將系統時鐘設定在過去時間。 系統時鐘、內部時間戳記及指出間隔的參數,都會因系統時鐘變更而受到影響。

如果將系統時鐘的時間往前提早,則受影響的元件會將其內部時間戳記設定在過去時間,而將系統時鐘的現行時間戳記設定在未來時間。 這與系統時鐘的常態行為相似; 其差異為包括決定下一個排程的執行或決定資料庫記錄的生命週期之部分時間測量將會受到影響。實際經歷時間會比計算經歷時間短。

範例:記錄在可刪除之前,會在系統上保留 24 小時。 假設一項記錄可在星期二下午 3 點刪除。 此時由於 24 小時的保留原則,您可於星期三下午 3 點之後的任何時間刪除此記錄。 又假設在星期二下午 3:01 時,將系統時鐘向前設定為接著的星期五下午 3:01。 雖然實際經歷時間只經過 1 分鐘,但系統經歷時間將是 3 天又 1 分鐘,因此該記錄便已經符合 24 小時的保留期間。這表示由於時間變更,您可比系統時鐘未變更時更快速的移除該記錄。

另一個範例:每 24 小時會執行特定的 ETL 元件,且執行之後系統時鐘會立即向前撥快 26 小時。 ETL 元件在下次執行前,會盡快地再次啟動,無須等待必備的 24 小時實際時間。這是由於系統計算自前次執行以來,至少已經過 26 小時。 實際上,在此情況下將時鐘往前提早已經減少了 ETL 間隔。 只要系統時鐘沒有進行其他變更,ETL 元件便會在執行定義間隔之後回復正常。

以下段落僅會著重在將時鐘往後延後,這會在時鐘往回調整前且已經執行元件後進行。

「擷取」元件會繼續對追蹤的所有表格擷取變更。 時間計算可用來決定這些變更的確定時間,並使其可用於「套用」元件及「來源生命週期」元件。 「擷取」元件很可能在未來標記內部時間戳記。只有在內部時鐘大於標記的內部時間戳記時,才會確定交易,以及確定之間的部分間隔內部參數。 在此情況下,如果將系統時鐘往後延後 1 小時,則最差的輸出結果是新的 1 小時中所發生的全部交易,將會在該小時過了之後才可使用。 如果將時鐘設為 1 年以前,則系統要花 1 年的時間來趕上。
註: 「擷取」元件會在指定的交易號碼後進行確定;其預設值為 120。而該資料則可能在定義的時間之前,即可供「套用」元件及「來源生命週期」元件使用。

「套用」元件也會維護決定新建記錄檢查時間的內部時間戳記。 在此範例情況中,此內部時間戳記會大於系統現行時間戳記。 即使可使用新記錄,「套用」元件會等到系統時間戳記達到其內部時間戳記為止。 一旦達到現行時間戳記,便會開始尋找可用於資料移動的記錄。

時間戳記不會決定要抄寫的列。那是由內部值決定,不會受系統時鐘影響。「來源」元件及「目標生命週期」元件也會使用時間戳記來決定要開始的時間及準備要刪改的記錄。

「狀態至執行期間」資料移動服務的「來源生命週期」元件僅使用時間戳記來決定開始的時間。 它不是使用時間戳記來決定要刪改的記錄。 在此服務中的元件不支援保留原則功能,此功能可容許要刪改的資訊存在某保留原則期間。 然而,此功能的確存在於「執行時期至歷程」資料移動服務的「來源生命週期」元件。 有些記錄在達到現行系統時鐘時間之後,才會符合保留原則的準則。 兩種資料移動服務的「目標生命週期」元件均支援保留原則定義,因此,任何時間的變更都會影響元件執行的時間及刪改的記錄。

ETL 元件會使用時間戳記作為其內部排程的一部分。 當排程啟動時,這些元件會預期遞增時間。當系統時鐘移至過去時間時,ETL 排程會受影響,且在系統時間趕上之後才可執行 ETL。

系統時鐘時間的可能範例情況如下:

回復

在時間伺服器進行變更的期間,因為只有數分鐘的時間差異,回復應是不必要的。 若在元件達到時間時沒有發生任何變更,則影響的時間範圍較小。 因為日光節約時間的變更,在時間變更的期間往回調整時間會導致元件停止抄寫一小時,而之後元件將需要趕上系統。 這樣是否會造成問題則視系統而定。

在元件伺服器執行時,當錯誤已經發生且系統時間已經設在未來很久之後的時間的情況下,等待會是一個重要動作。 那麼,無論伺服器是否在執行中,此時間會還原為目前的時間。 在此情況下,元件會將其內部時間戳記設定在未來時間,但會在目前的時間範圍內執行。 在資料移動服務再次處理任何列之前,會有長時間的延遲。 此延遲會在系統上擴大而影響回復時間。 管理者可能必須採取更正動作。

更正動作

有個選擇即是強制「擷取」及「套用」元件起始完整更新,然後更新「來源生命週期」、「目標生命週期」及 ETL 元件的內部時間戳記。
  1. 確定在伺服器上執行的所有資料庫,其時間已被移動至未來時間並接著推回至過去時間。 有兩種可能:「狀態至執行時期」或「執行時期至歷程」。
  2. 在受影響的系統上,停止所有支援資料移動服務的伺服器。 在此程序期間,您將會修改內部參數,且當允許部分元件執行時,無法進行同步化。如需相關資訊,請參閱啟動及停止資料移動服務
  3. 修改「來源生命週期」元件及「目標生命週期」元件的內部時間戳記。
    註: 此動作會因版本之間的變更而有所不同。
    1. 更新「來源生命週期」刪改時間戳記。這會針對系統上負責處理所有商業測量模型的所有「來源生命週期」元件,修改其設定。
      驗證現行設定:
      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%'
      註: 複查 LAST_PRUNED,PRUNE_INTERVAL 及 CURRENT TIMESTAMP 的值。決定您是否要立即刪改或在下一個間隔刪改。
      -- 「執行」盡可能快速。
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME LIKE 'APP%';
      -- 「執行」於下一個間隔
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME LIKE 'APP%';
      connect reset;
    2. 更新「目標生命週期」刪改時間戳記。
      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%';
      註: 複查 LAST_PRUNED,PRUNE_INTERVAL 及 CURRENT TIMESTAMP 的值。決定是否需要立即刪改,或在下一個間隔刪改。
      -- 「執行」盡可能快速。
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME NOT LIKE 'APP%';
      -- 「執行」於下一個間隔
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME NOT LIKE 'APP%';
    3. 更新 ETL 排程。
      註: 這會影響橫跨所有模型的所有 ETL 活動。
      CONNECT TO <TARGET>
      -- 此查詢會顯示
      SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
      註: ETL_0_MINUTES、NEXTSTARTTIME 及 LASTUPDATED 的值是與 CURRENT TIMESTAMP 相比較。
      -- 「執行」於下一個間隔
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP);
      -- 「執行」盡可能快速
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES);
      CONNECT RESET
    4. 強制完整更新。若要強制執行抄寫「擷取」及「套用」伺服器的完整復新作業,最簡單的方法是針對每一個商業測量模型複製並修改 StartCapture Script。針對每個在系統上部署的模型來尋找每個啟動擷取 Script (若您已遵循合併啟動和停止 Script 區段上的指示,則僅需尋找每一個 asncap 指令),並將參數STARTMODE=COLD 新增至指令行的結尾。
      註: 完整更新是特別情況,而在完整更新完成之前,可能會導致效能不佳。 這是由於完整更新會新增額外負荷,但在一般「資料服務作業」期間通常不會出現額外負荷。 因此,完整更新在系統的使用負荷不大時完成,是相當重要的。 完整更新的效能主要是依「資料移動服務」來源資料庫中的資料大小而定。

      範例:

      之前:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      之後:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      接著啟動全部的 Script。 此完整更新會讓「擷取」元件及「套用」元件重設其所有的內部時間戳記,但這會造成移動及重新處理資料的額外成本。 在系統趕上的同時,對效能可能降低有所計劃是很重要的。

Copyright IBM Corporation 2005, 2006. All Rights Reserved.