DBCC DBINFO返回dbi_dbccLastKnownGood值与错误日志不符问题排查

我之前在处理AlwaysOn异步副本的DBCC问题时，刚好碰到过一模一样的情况，结合你给出的环境细节，我来帮你拆解下这个矛盾点：

一、先明确下核心环境与现象 #

• 环境：只读访问的异步提交AlwaysOn AG副本（Secondary Replica）
• 作业情况：2018年2月5日21:00成功执行了仅包含DBCC CHECKDB(myDB)的作业，耗时2小时22分21秒，按道理结束时间应该是2018-02-05 23:22左右
• 矛盾点：执行DBCC DBINFO('myDB') WITH TABLERESULTS时，dbi_dbccLastKnownGood的值是2018-02-05 00:00:40.113，和预期的作业结束时间完全对不上

二、问题的核心原因（异步AG副本的特殊行为） #

这里的关键是异步副本上的DBCC CHECKDB不会更新自身的元数据，具体逻辑是这样的：

1. dbi_dbccLastKnownGood这个字段是存储在数据库元数据里的，而AlwaysOn副本的元数据（除了少数副本专属的内容）都是通过主库的事务日志同步过来的。
2. 只有在AG主副本上执行的DBCC CHECKDB成功完成后，主库才会更新自己的dbi_dbccLastKnownGood值，然后把这个更新操作写入日志，同步到所有副本。
3. 你这次是在副库上跑的DBCC作业，这个操作只会检查副本的数据一致性，但不会修改副本的元数据——所以你看到的dbi_dbccLastKnownGood其实是主库上次同步过来的、主库自己执行DBCC的时间（也就是2018-02-05 00:00:40那次）

三、几个验证步骤帮你确认 #

你可以做这几件事来验证这个结论：

• 登录到AG主副本，执行DBCC DBINFO('myDB') WITH TABLERESULTS，查看主库的dbi_dbccLastKnownGood，应该和你在副库上看到的完全一致（因为副库是同步主库的元数据）
• 去主库的作业历史或错误日志里查，2018-02-05 00:00左右肯定有一次DBCC CHECKDB的执行记录
• 如果在主库上重新跑一次DBCC CHECKDB(myDB)，等日志同步到异步副本后，再去副库查dbi_dbccLastKnownGood，就会更新为主库这次执行的时间了

四、额外的注意事项 #

如果你的目的是在副库上做一致性检查（减轻主库压力），这个做法本身是没问题的，但要记住：

• 副库上的DBCC结果不会更新dbi_dbccLastKnownGood，所以不能用这个字段来验证副库上的检查是否完成
• 要确认副库的DBCC是否成功，只能看该副本自己的SQL Server错误日志或者作业执行历史（你提到“查看错误日志时发现...”，如果日志里有副库上DBCC完成的记录，那说明检查确实执行了，只是元数据没更新而已）

内容的提问来源于stack exchange，提问作者S3S