夏令时和网络时间服务器

夏令时和网络时间服务器都影响服务器的当前时间。在数据移动服务中,时间戳记用于确定服务器何时检查新数据,以及它们何时执行数据移动。对系统时钟所作的更改会影响数据服务组件,以及检测到的性能。

手工调整系统时钟也会影响时间。系统的行为也会同样受到影响,而不管用于更改时钟的方法是什么。如果回拨系统时钟,数据移动服务会出现非预期的延迟。系统时钟往前拨时不会出现延迟,尽管数据移动服务组件不久就会到达预订的时间间隔。

对组件上更改时间的效果

如果系统时钟的时间往回拨,受影响的组件的内部时间戳记会设置成未来时间,但系统时钟会设置成过去时间。系统时钟、这些时间间隔时间戳记和指定时间间隔的参数都将受到系统时钟更改的影响。

如果系统时钟的时间往前拨,受影响的组件的内部时间戳记会设置成过去时间,而系统时钟的当前时间戳记会设置成未来时间。这类似于系统时钟的常规行为;不同的是某些时间度量方式(包括确定运行下一次预订运行或确定数据库记录生命周期的时间度量)会受到影响。实际的消耗时间将少于计算得出的消耗时间。

示例:记录在可以删除之后,会在系统上保留 24 小时。假定可以在星期二下午 3 点删除某个记录。在这个时间点,根据保留 24 小时的策略,该记录可能会在星期三下午 3 点之后删除。同样,假定在星期二下午 3:01,系统时钟被设置成下个星期五的 3:01。这样,即使实际消耗时间只是 1 分钟,系统显示的消耗时间将是 3 天零 1 分钟,这样就满足了该记录的 24 小时保留期。这意味着,由于时间的变化,记录删除的速度要比系统时钟未更改时快。

又如:某特殊 ETL 组件每 24 小时运行一次,在它运行之后,系统时钟立即往前跳了 26 小时。该 ETL 组件不会在它下一次运行之前等待必需的 24 小时,而是立即再次启动。这是因为系统计算出在上一次运行之后,过去了至少 26 小时。实际上,在这种情况下,将时钟前拨减少了 ETL 时间间隔。只要没有对系统时钟进行其他更改,ETL 组件就会在此次运行之后恢复成已定义的时间间隔。

以下部分只着重介绍组件在没有恢复时钟的情况下运行之后,将时钟向回拨。

“捕获”组件将继续捕获其跟踪的部分或全部表的更改。时间计算用于确定何时落实这些更改,以及何时使它们可用于“应用”组件和“源生命周期”组件。“捕获”组件最可能将内部时间戳记标记成将来。在内部时钟大于标记的内部时间戳记加上落实之间的某些时间间隔内部参数之前,该组件不会提交事务。在这种情况下,如果系统时钟向回拨 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 的值。决定是立即删除,还是在下一个时间间隔删除。
      -- 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. 强制执行完整的刷新。复制“捕获”和“应用”服务器强制执行完整刷新最简单的方法是复制和修改每个业务度量模型StartCapture 脚本。查找系统上部署的每个模型的所有启动捕获脚本(如果已按照整合启动和停止脚本章节中的指示信息执行,则只需查找每个 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
      然后启动所有脚本。此次完整刷新使“捕获”和“应用”组件复位所有内部时间戳记,但会引起移动和重新处理数据的额外成本。为系统追上设定时间的过程中,对可能的性能降低作好规划是非常重要的。

Copyright IBM Corporation 2005, 2006. All Rights Reserved.