夏時間調整とネットワーク・タイム・サーバーは、両方ともサーバー・マシンの現在時刻に影響を与えます。データ移動サービスでは、サーバーが新規データを確認するタイミングや、それらがデータ移動を実行するタイミングを判別するために、タイム・スタンプが使用されます。システム・クロックを変更すると、Data Services コンポーネントに影響し、これにともなって認識されるパフォーマンスにも影響します。
また、手動でシステム・クロックを動かした場合も時間に影響を与えます。クロックを動かすために使用した方法に関係なく、システムの動作は同様に影響を受けます。システム・クロックが過去に戻されると、データ移動サービスに望ましくない遅延が発生します。システム・クロックが進められると、データ移動サービスのコンポーネントはスケジュールされた間隔に早く到達しますが、遅延は発生しません。
時間変更がコンポーネントに与える影響
システム・クロックの時間が戻されると、影響を受けるコンポーネントの内部タイム・スタンプは未来に設定されますが、システム・クロックは過去に設定されます。システム・クロック、それらの内部タイム・スタンプ、および間隔を示すパラメーターは、すべてシステム・クロックの変更の影響を受けます。
システム・クロックの時間が進められると、影響を受けるコンポーネントの内部タイム・スタンプは過去に設定され、システム・クロックは未来に設定されます。これはシステム・クロックの通常の動作に類似しています。異なる点は、次のスケジュールされた実行の決定、データベース・レコードのライフ・サイクルの決定などの時間測定が、影響を受けることです。実際の経過時間は計算された経過時間よりも短くなります。
例: レコードはそれが削除対象となってから 24 時間システム上に残存します。レコードが火曜日の午後 3 時に削除対象になると想定します。この時点で、24 時間保存ポリシーにより、レコードは水曜日の 3 時以後の任意の時間に削除できます。また、火曜日の午後 3 時 1 分に、システム・クロックが同じ週の金曜日の午後 3 時 1 分に進められると想定します。それに従い、実際の経過時間では 1 分しか経過していないにもかかわらず、システム経過時間は 3 日と 1 分となり、そのレコードに対する 24 時間の保存期間が満たされています。これは、時間変更により、システム・クロックが変更されなかった場合よりも早くレコードが削除可能になることを意味します。
別の例: ある特定の ETL コンポーネントは 24 時間ごとに実行され、その実行の直後にシステム・クロックが 26 時間先にジャンプします。次の実行まで実際の時間で前提条件の 24 時間待機する代わりに、ETL コンポーネントはできるだけ早く再開します。これは、前回の実行から少なくとも 26 時間が経過しているというシステムの計算によります。事実上、クロックを進めることによってこの場合 ETL 間隔が減少します。 その他のシステム・クロックの変更が行われない限り、ETL コンポーネントはこの実行後、定義された間隔で通常どおり再開します。
以下のセクションでは、クロックが戻される前までコンポーネントが実行された後でクロックを戻すことについてのみ説明します。
また、Apply コンポーネントは、新規レコードをチェックするタイミングを決定する内部タイム・スタンプも保守しています。このシナリオでは、この内部タイム・スタンプはシステムの現在のタイム・スタンプよりも大きくなります。Apply コンポーネントは、新規レコードが使用可能な場合でも、システム・タイム・スタンプが内部タイム・スタンプに取り戻すまで待機します。現在のタイム・スタンプが遅れを取り戻すと、データ移動に使用可能なレコードの検索を開始します。
タイム・スタンプは、複製される行は決定しません。これは、システム・クロックの影響を受けない内部値によって決定されます。 ソース・ライフ・サイクル・コンポーネントとターゲット・ライフ・サイクル・コンポーネントも、いつ開始するか、およびどのレコードが整理の準備ができているかを決定するために、タイム・スタンプを使用します。
状態データベースからランタイム・データベースへのデータ移動サービスのソース・ライフ・サイクル・コンポーネントは、開始するタイミングを決定する目的のみでタイム・スタンプを使用します。整理する対象の決定にはタイム・スタンプを使用しません。このサービスのこのコンポーネントは、整理に適格な情報が特定の保存ポリシー期間存在することを可能にする保存ポリシー機能をサポートしていません。ただし、この機能はランタイム・データベースからヒストリー・データベースへのデータ移動サービスのソース・ライフ・サイクル・コンポーネントには存在しています。現在のシステム・クロックが遅れを取り戻すまで保存ポリシー基準を満たさないレコードがあります。両方のデータ移動サービスのターゲット・ライフ・サイクル・コンポーネントは保存ポリシーの定義をサポートしているため、時間を変更すると、実行するタイミングと整理対象に影響を与えます。
ETL コンポーネントは、内部スケジューリングの一部としてタイム・スタンプを使用します。 開始されると、これらのコンポーネントは、時間は進んでいくものと認識します。システム・クロックが過去に戻されると、ETL スケジューリングが影響を受け、システムが遅れを取り戻すまで ETL は実行されません。
リカバリー
タイム・サーバーによって行われる変更中のリカバリーは必要ありません。時間の差分が非常に小さい (数分) ためです。 影響は、コンポーネントが遅れを取り戻す間に何も発生しない短い時間フレームとして現れます。夏時間調整のために時間を変更している間、時間が戻されるとコンポーネントは複製を 1 時間停止します。その後、コンポーネントはシステムからの遅延を取り戻す必要があります。これが問題であるかどうかはシステムによって異なります。
この待機が重大になる 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%'
-- TO RUN As soon as possible. UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME LIKE 'APP%'; -- TO RUN at the next interval 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%';
-- TO RUN As soon as possible. UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES) WHERE TABLE_NAME NOT LIKE 'APP%'; -- TO RUN at the next interval UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp) WHERE TABLE_NAME NOT LIKE 'APP%';
CONNECT TO <TARGET> -- This query shows SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED, CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
-- TO Run at the next interval UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)= (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP); -- To Run as soon as possible 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その後、すべてのスクリプトを開始します。このフル・リフレッシュにより Capture コンポーネントと Apply コンポーネントは内部タイム・スタンプをすべてリセットしますが、データの移動および再処理に余分なコストがかかります。システムが取り戻す間、パフォーマンスが低下する可能性があることを考慮しておくことが重要です。