夏時間調整とネットワーク・タイム・サーバー

夏時間調整とネットワーク・タイム・サーバーは、両方ともサーバー・マシンの現在時刻に影響を与えます。データ移動サービスでは、サーバーが新規データを確認するタイミングや、それらがデータ移動を実行するタイミングを判別するために、タイム・スタンプが使用されます。システム・クロックを変更すると、Data Services コンポーネントに影響し、これにともなって認識されるパフォーマンスにも影響します。

また、手動でシステム・クロックを動かした場合も時間に影響を与えます。クロックを動かすために使用した方法に関係なく、システムの動作は同様に影響を受けます。システム・クロックが過去に戻されると、データ移動サービスに望ましくない遅延が発生します。システム・クロックが進められると、データ移動サービスのコンポーネントはスケジュールされた間隔に早く到達しますが、遅延は発生しません。

時間変更がコンポーネントに与える影響

システム・クロックの時間が戻されると、影響を受けるコンポーネントの内部タイム・スタンプは未来に設定されますが、システム・クロックは過去に設定されます。システム・クロック、それらの内部タイム・スタンプ、および間隔を示すパラメーターは、すべてシステム・クロックの変更の影響を受けます。

システム・クロックの時間が進められると、影響を受けるコンポーネントの内部タイム・スタンプは過去に設定され、システム・クロックは未来に設定されます。これはシステム・クロックの通常の動作に類似しています。異なる点は、次のスケジュールされた実行の決定、データベース・レコードのライフ・サイクルの決定などの時間測定が、影響を受けることです。実際の経過時間は計算された経過時間よりも短くなります。

例: レコードはそれが削除対象となってから 24 時間システム上に残存します。レコードが火曜日の午後 3 時に削除対象になると想定します。この時点で、24 時間保存ポリシーにより、レコードは水曜日の 3 時以後の任意の時間に削除できます。また、火曜日の午後 3 時 1 分に、システム・クロックが同じ週の金曜日の午後 3 時 1 分に進められると想定します。それに従い、実際の経過時間では 1 分しか経過していないにもかかわらず、システム経過時間は 3 日と 1 分となり、そのレコードに対する 24 時間の保存期間が満たされています。これは、時間変更により、システム・クロックが変更されなかった場合よりも早くレコードが削除可能になることを意味します。

別の例: ある特定の ETL コンポーネントは 24 時間ごとに実行され、その実行の直後にシステム・クロックが 26 時間先にジャンプします。次の実行まで実際の時間で前提条件の 24 時間待機する代わりに、ETL コンポーネントはできるだけ早く再開します。これは、前回の実行から少なくとも 26 時間が経過しているというシステムの計算によります。事実上、クロックを進めることによってこの場合 ETL 間隔が減少します。 その他のシステム・クロックの変更が行われない限り、ETL コンポーネントはこの実行後、定義された間隔で通常どおり再開します。

以下のセクションでは、クロックが戻される前までコンポーネントが実行された後でクロックを戻すことについてのみ説明します。

Capture コンポーネントは、トラッキングしているすべてのテーブルへの変更をキャプチャーし続けます。それらの変更をコミットして Apply コンポーネントおよびソース・ライフ・サイクル・コンポーネントで使用できるようにするタイミングを決定するために、時間計算が使用されます。Capture コンポーネントは、内部的に未来のタイム・スタンプとしてマークされている可能性が高くなります。内部クロックが、マークされている内部タイム・スタンプに一部のコミット間隔内部パラメーターを加えたものよりも大きくなるまでは、トランザクションをコミットしません。この場合、システム・クロックが 1 時間戻されると、最悪の場合、新規の 1 時間内に発生しているすべてのトランザクションが、戻された 1 時間が経過するまで使用できないという結果になってしまいます。クロックが 1 年過去に戻されると、システムが遅れを取り戻すまで 1 年かかります。
注: Capture コンポーネントは定められたトランザクション数の後でコミットします。デフォルトは 120 です。データが、定義されているよりも早く、Apply コンポーネントおよびソース・ライフ・サイクル・コンポーネントで使用できるようになる可能性があります。

また、Apply コンポーネントは、新規レコードをチェックするタイミングを決定する内部タイム・スタンプも保守しています。このシナリオでは、この内部タイム・スタンプはシステムの現在のタイム・スタンプよりも大きくなります。Apply コンポーネントは、新規レコードが使用可能な場合でも、システム・タイム・スタンプが内部タイム・スタンプに取り戻すまで待機します。現在のタイム・スタンプが遅れを取り戻すと、データ移動に使用可能なレコードの検索を開始します。

タイム・スタンプは、複製される行は決定しません。これは、システム・クロックの影響を受けない内部値によって決定されます。 ソース・ライフ・サイクル・コンポーネントとターゲット・ライフ・サイクル・コンポーネントも、いつ開始するか、およびどのレコードが整理の準備ができているかを決定するために、タイム・スタンプを使用します。

状態データベースからランタイム・データベースへのデータ移動サービスのソース・ライフ・サイクル・コンポーネントは、開始するタイミングを決定する目的のみでタイム・スタンプを使用します。整理する対象の決定にはタイム・スタンプを使用しません。このサービスのこのコンポーネントは、整理に適格な情報が特定の保存ポリシー期間存在することを可能にする保存ポリシー機能をサポートしていません。ただし、この機能はランタイム・データベースからヒストリー・データベースへのデータ移動サービスのソース・ライフ・サイクル・コンポーネントには存在しています。現在のシステム・クロックが遅れを取り戻すまで保存ポリシー基準を満たさないレコードがあります。両方のデータ移動サービスのターゲット・ライフ・サイクル・コンポーネントは保存ポリシーの定義をサポートしているため、時間を変更すると、実行するタイミングと整理対象に影響を与えます。

ETL コンポーネントは、内部スケジューリングの一部としてタイム・スタンプを使用します。 開始されると、これらのコンポーネントは、時間は進んでいくものと認識します。システム・クロックが過去に戻されると、ETL スケジューリングが影響を受け、システムが遅れを取り戻すまで ETL は実行されません。

システム・クロック時間について考えられるシナリオは以下のとおりです。

リカバリー

タイム・サーバーによって行われる変更中のリカバリーは必要ありません。時間の差分が非常に小さい (数分) ためです。 影響は、コンポーネントが遅れを取り戻す間に何も発生しない短い時間フレームとして現れます。夏時間調整のために時間を変更している間、時間が戻されるとコンポーネントは複製を 1 時間停止します。その後、コンポーネントはシステムからの遅延を取り戻す必要があります。これが問題であるかどうかはシステムによって異なります。

この待機が重大になる 1 つのシナリオとしては、コンポーネントのサーバーが実行しているときに、誤ってシステム時間が大幅に進められた場合です。その後 (サーバーが実行されているかどうかに関係なく)、時間は現在時刻に復元されます。この場合、コンポーネントは内部タイム・スタンプを未来に設定していると考えられますが、現在の時間フレームで実行されています。データ移動サービスが行を再処理するまでに、長い遅延が生じます。この遅延が、リカバリー時間に影響を与えるシステムへの負荷蓄積の原因となる可能性があります。管理者が修正処置をとる必要があります。

修正処置

1 つの修正処置は、Capture コンポーネントと Apply コンポーネントにフル・リフレッシュを開始させてから、ソース・ライフ・サイクル・コンポーネント、ターゲット・ライフ・サイクル・コンポーネント、および ETL コンポーネントの内部タイム・スタンプを更新することです。
  1. 時間が未来に進められた後で過去に戻されたサーバー上で実行されているすべてのデータベースを識別します。2 つの可能性 (状態とランタイム、ランタイムとヒストリー) があります。
  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 の値を確認してください。即時に整理するか、または次の間隔で整理するかを決定してください。
      -- 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;
    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 の値を確認してください。即時に整理するか、または次の間隔で整理するかを決定してください。
      -- 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%';
    3. ETL スケジュールの更新。
      注: これは、すべてのモデル間のすべての ETL アクティビティーに影響を与えます。
      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;
      注: ETL_0_MINUTES、NEXTSTARTTIME、および LASTUPDATED は、CURRENT TIMESTAMP と比較した値。
      -- 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
    4. フル・リフレッシュを強制します。Capture サーバーと Apply サーバーのレプリケーションのフル・リフレッシュを強制する最も簡単な方法は、それぞれのビジネス指標モデルに対して、StartCapture スクリプトをコピーおよび変更することです。システム上にデプロイされているすべてのモデルに対するすべての開始キャプチャー・スクリプトを検索し (開始および停止スクリプトの統合セクションにある指示に従った場合は、単にそれぞれの asncap コマンドを検索)、コマンド行の末尾にパラメーター STARTMODE=COLD を追加します。
      注: フル・リフレッシュは極端な例であるため、フル・リフレッシュが完了するまでパフォーマンスが低下する可能性があります。これは、フル・リフレッシュが通常の Data Services 操作中は存在しない余分なオーバーヘッドが発生することが原因です。 したがって、フル・リフレッシュはシステムがあまり使用されていないときに行なうことが重要です。フル・リフレッシュのパフォーマンスは、データ移動サービスのソース・データベース内のデータのサイズによって大きく異なります。

      例:

      前:
      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 コンポーネントは内部タイム・スタンプをすべてリセットしますが、データの移動および再処理に余分なコストがかかります。システムが取り戻す間、パフォーマンスが低下する可能性があることを考慮しておくことが重要です。

Copyright IBM Corporation 2005, 2006. All Rights Reserved.