DB2 的 “内部时钟”

最近，在测试 NBU备份恢复方案时，发现个有趣的问题：
NBU工程师调试成功的备份、恢复策略，过几天，我再一点，诶诶诶~~~ ╮(╯▽╰)╭ ，报错了：

SQL2062N An error occurred while accessing media
"/usr/openv/netbackup/bin/nbdb2.sl64".  Reason code:  "516".

我初以为是NBU media 端的通信问题，把相关通信端口检查了一遍，没问题。看看NBU官网的报错场景描述，也不符合。后来，干脆把NBU备份策略，配置文件检查了个遍，还是报错。。。
一不做二不休，直接重新自己按照官方文档配置了备份策略，一跑还是报原先的错误：“SQL2062N An error occurred while accessing media”

最逗比的是同一台服务器上的 Oracle 的dump文件在 NBU media上下来去自如，无奈后来去开了个 NBU 的pmr，回复是：
“NBU client 端（DB2数据库服务器）与 NBU master 和 NBU media的系统时间不一致！”

我一查 DB2 服务器的操作系统时间果然被切到了未来时 2020-01-02 ，系统时间被切回当前日期 2019-04-13，备份成功，但是备份时间戳为 20200102102125，再次备份， 备份时间戳为 20200102102127，再备份，时间戳为 20200102102129。

20200102102125 ——>  20200102102127  ——>  20200102102129

看到规律没？每个备份时间戳每隔 2秒递增，下一次的备份时间戳应该为 20200102102131。
大家一定疑惑？为啥备份时间戳不是当前的系统时间呢？而是一个未来的时间点呢？
啰嗦了半天，终于上“主菜”了，DB2 内部时钟

DB2 内部时钟

DB2 使用自己的内部时钟来跟踪备份，尤其是增量备份和差异增量备份。
一旦 DB2内部时钟 随系统时间被更改为未来的时间（相对于当前时间），就无法将其更改回来，DB2内部时钟 的时间线只能往前走，不能往回走，即使操作系统时间被从未来时间切回到当前日期，它的内部时间点也会停留在未来的时间点，
例如：上面NBU例子中DB2内部时钟的时间点为 2020-01-02-10:21:25！
DB2内部时钟显示未来时间，并将等待系统时钟，直到两个时钟都指示相同的时间。在此期间创建的所有备份将具有不同的时间戳，并且两个后续时间戳之间相差2秒。
正如我们上面实验所验证的那样。

对 DPF 环境的影响
其实，在非分区数据库环境 non-DPF中，反复切系统时间影响很小。但是，在 DB2 DPF环境中，将各个节点系统时间切换到未来时间 T + n（T为当前时间），运行一段时间，然后再切回当前时间 T。此时，对 DB2数据库进行 DML、DLL、Load、reorg、Alter tablespace 等操作时，肯定会报错：

SQL0903N  COMMIT statement failed, transaction rolled back.  Reason code: "2".
SQLSTATE=40504

为什么会这样呢？
因为每个节点的 DB2内部时钟 会在日志控制文件记录一个虚拟时间戳 VTS(Virtual Timestamps), 当系统时间切至 T + n，VTS会跟着调至 T + n，此时数据库并不会出现问题，但是当系统时间切回原来的时间 T，VTS是不会跟着改回来的，它还是 T + n。如果 VTS和当前系统时间的差超过了 MAX_TIME_DIFF，那就会出现SQL0903N, Reason Code “2”的报错。（MAX_TIME_DIFF为分区数据库环境中各个节点间允许的最大时间差，最多为24小时）

要想解决这个问题：
如果 DB2内部时间戳 VTS 和当前系统的时间差超过24小时，只能

1. 重建数据库，或者
2. 把日志控制文件发给IBM售后技术支持，让他们修改一下 VTS，然后替换当前日志控制文件，再做一个全库离线备份

其实，DB2 内部时钟对 restore、rollforward、HADR standby log replay 等工作影响都很大，还需要实验研究，学海无涯，慢慢来吧，先把知道的分享给大家，希望大家少趟些坑O(∩_∩)O~