Troubleshooting
Problem
在配置了高可用性灾难恢复（HADR）的系统中，事务日志数据通过网络从主数据库传输到备用数据库。 如果在网络传输期间事务日志数据被破坏，则备用数据库可能会出现各种错误症状，这通常包括备用数据库的异常终止和关闭。 由于某些完整性检查已在备用数据库上以记录日志记录重放的方式异步的进行，因此db2diag.log通常会包含错误消息 “Log page checksum mismatch.pageLso xxxxxx，CheckSum xxxxxx”：
2017-08-29-14.45.16.809825-240 I99805E781 LEVEL: Error
PID : <pid#> TID : <tid#> PROC : db2sysc
INSTANCE: <instname> NODE : <node#> DB : <db2name>
HOSTNAME: hostname1
EDUID : 316 EDUNAME: db2lfr.0 (<dbname>)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrGetBlock, probe:40100
MESSAGE : ZRC=0x87800148=-2021654200=HDR_ZRC_BAD_LOG
"HADR standby found bad log"
DATA #1 : <preformatted>
Log page checksum mismatch. pageLso xxxxxx, CheckSum xxxxxx
其他可能的错误消息包括：
"Bad page detected. The bytecount is incorrect."
和
"Bad page detected. Checksum mismatch. pageLso / Checksum / Calculated Checksum"
更重要的是，由于损坏的日志数据可能已在备用数据库上刷新到磁盘，因此备用数据库的后续重新启动将以相同的条件失败。 通常通过使用主数据库中的有效备份手动替换备用数据库活动日志路径中的已损坏日志文件来解决此问题。
Resolving The Problem
从版本 10.5 Fix Pack 9 和版本11.1 Mod Pack 3（v11.1.3.3）开始，可以配置Db2以执行事务日志数据的扩展完整性检查， 并在检测到完整性检查失败时自动重新传输数据， 从而避免备用数据库故障和中断。 仅在V10.5 FP9中，要启用事务日志数据的扩展完整性检查，请在主数据库实例和备用数据库实例上使用以下数据库注册表变量： db2set DB2_ENABLE_HADR_LOG_PAGE_INTEGRITY_CHECK=3 （注册表变量不需要重新启动数据库实例即可生效。但是，备用数据库上需要数据库停用和激活，并且主数据库上需要 STOP HADR和START HADR操作）。 在V10.5 Fix Pack 9之后（不包括Fix Pack 9）和版本11.1 Mod Pack 3（v11.1.3.3）和更新的Mod Pack， 默认情况下启用事务日志数据的扩展完整性检查，而不是要求明确启用。 执行的完整性检查的类型包括在备用数据库上接收的每个事务日志页面的事务字节计数校验和验证。 启用或禁用后，会在db2diag..log文件中记录一条消息。 启动："Log Page Integrity Check is enabled ..." 或 禁用："Log Page Integrity Check is disabled ..." 从完整性检查失败中自动恢复 启用扩展完整性检查并且备用数据库上的完整性检查失败时，将在db2diag.log中输出错误消息（如上所述）， 并且备用数据库将自动尝试再次从主数据库中检索日志数据。这将在不需要任何用户或管理员操作的情况下发生，并且对应用程序没有影响。 性能影响 启用完整性检查后，将对备用数据库上收到的每个日志页进行字节计数校验和验证。 这些是适度的计算操作，因此对于大多数数据库工作负载而言，影响应该可以忽略不计。 对于极端性能工作负载，可以观察到cpu利用率和/或事务提交时间的小幅增加。 与所有更改一样，建议在生产环境中启用之前在测试环境中测试该功能。
Related Information
Was this topic helpful?
Document Information
Modified date:
09 October 2018
UID
ibm10734357