日光節約時間及網路時間伺服器皆會影響伺服器機器上目前的時間。 在資料移動服務中,系統會以時間戳記來決定伺服器要檢查新建資料及執行資料移動的時間。 變更系統時鐘會影響資料服務元件及其效能表現。
以手動方式移動系統時鐘也會影響時間。無論使用何種方式來移動時鐘,都會影響系統的行為。 當您將系統時鐘移動到過去時間,資料移動服務會發生不必要的延遲。雖然資料移動服務元件會很快地達到排程間隔,但如果將系統時鐘往前提早,便不會發生延遲。
變更時間對元件的影響
如果將系統時鐘的時間往後延後,則受影響的元件會將其內部時間戳記設定在未來時間,而將系統時鐘設定在過去時間。 系統時鐘、內部時間戳記及指出間隔的參數,都會因系統時鐘變更而受到影響。
如果將系統時鐘的時間往前提早,則受影響的元件會將其內部時間戳記設定在過去時間,而將系統時鐘的現行時間戳記設定在未來時間。 這與系統時鐘的常態行為相似; 其差異為包括決定下一個排程的執行或決定資料庫記錄的生命週期之部分時間測量將會受到影響。實際經歷時間會比計算經歷時間短。
範例:記錄在可刪除之前,會在系統上保留 24 小時。 假設一項記錄可在星期二下午 3 點刪除。 此時由於 24 小時的保留原則,您可於星期三下午 3 點之後的任何時間刪除此記錄。 又假設在星期二下午 3:01 時,將系統時鐘向前設定為接著的星期五下午 3:01。 雖然實際經歷時間只經過 1 分鐘,但系統經歷時間將是 3 天又 1 分鐘,因此該記錄便已經符合 24 小時的保留期間。這表示由於時間變更,您可比系統時鐘未變更時更快速的移除該記錄。
另一個範例:每 24 小時會執行特定的 ETL 元件,且執行之後系統時鐘會立即向前撥快 26 小時。 ETL 元件在下次執行前,會盡快地再次啟動,無須等待必備的 24 小時實際時間。這是由於系統計算自前次執行以來,至少已經過 26 小時。 實際上,在此情況下將時鐘往前提早已經減少了 ETL 間隔。 只要系統時鐘沒有進行其他變更,ETL 元件便會在執行定義間隔之後回復正常。
以下段落僅會著重在將時鐘往後延後,這會在時鐘往回調整前且已經執行元件後進行。
「套用」元件也會維護決定新建記錄檢查時間的內部時間戳記。 在此範例情況中,此內部時間戳記會大於系統現行時間戳記。 即使可使用新記錄,「套用」元件會等到系統時間戳記達到其內部時間戳記為止。 一旦達到現行時間戳記,便會開始尋找可用於資料移動的記錄。
時間戳記不會決定要抄寫的列。那是由內部值決定,不會受系統時鐘影響。「來源」元件及「目標生命週期」元件也會使用時間戳記來決定要開始的時間及準備要刪改的記錄。
「狀態至執行期間」資料移動服務的「來源生命週期」元件僅使用時間戳記來決定開始的時間。 它不是使用時間戳記來決定要刪改的記錄。 在此服務中的元件不支援保留原則功能,此功能可容許要刪改的資訊存在某保留原則期間。 然而,此功能的確存在於「執行時期至歷程」資料移動服務的「來源生命週期」元件。 有些記錄在達到現行系統時鐘時間之後,才會符合保留原則的準則。 兩種資料移動服務的「目標生命週期」元件均支援保留原則定義,因此,任何時間的變更都會影響元件執行的時間及刪改的記錄。
ETL 元件會使用時間戳記作為其內部排程的一部分。 當排程啟動時,這些元件會預期遞增時間。當系統時鐘移至過去時間時,ETL 排程會受影響,且在系統時間趕上之後才可執行 ETL。
回復
在時間伺服器進行變更的期間,因為只有數分鐘的時間差異,回復應是不必要的。 若在元件達到時間時沒有發生任何變更,則影響的時間範圍較小。 因為日光節約時間的變更,在時間變更的期間往回調整時間會導致元件停止抄寫一小時,而之後元件將需要趕上系統。 這樣是否會造成問題則視系統而定。
在元件伺服器執行時,當錯誤已經發生且系統時間已經設在未來很久之後的時間的情況下,等待會是一個重要動作。 那麼,無論伺服器是否在執行中,此時間會還原為目前的時間。 在此情況下,元件會將其內部時間戳記設定在未來時間,但會在目前的時間範圍內執行。 在資料移動服務再次處理任何列之前,會有長時間的延遲。 此延遲會在系統上擴大而影響回復時間。 管理者可能必須採取更正動作。
更正動作
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%'
-- 「執行」盡可能快速。 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;
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%';
-- 「執行」盡可能快速。 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%';
CONNECT TO <TARGET> -- 此查詢會顯示 SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED, CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
-- 「執行」於下一個間隔 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
範例:
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。 此完整更新會讓「擷取」元件及「套用」元件重設其所有的內部時間戳記,但這會造成移動及重新處理資料的額外成本。 在系統趕上的同時,對效能可能降低有所計劃是很重要的。