退回主要计算机
在退回主要计算机之前，需要确保已在主要计算机上成功启动了 DB2 UDB 服务器，然后在主要计算机上发出以下命令，以便从备用计算机接管数据库。
db2 takeover hadr on db
仔细检查主要计算机上的数据库是否具有正确的角色：
db2 get snapshot for database on | grep Role
它会返回“Primary”状态。而且，备用计算机和主要计算机上数据库的状态现在都应该处于“Peer”状态。
故障排除
作为参考，下面列出了在使用 DB2 HADR 时可能遇到的问题的原因和解决办法：
SQL1768N 无法启动 HADR。原因代码 =“7”（在启动主要数据库或备用数据库时）。
此问题的可能原因是，在 HADR 超时间隔内主要数据库无法建立与其备用数据库的连接。您可以通过调整时间间隔来适应您的环境。
SQL1768N 无法启动 HADR。原因代码 =“8”（在启动主要数据库或备用数据库时）。
检查下面所需的 HADR 变量（参见清单 3）这些变量必须正确而且不能为空：
HADR 数据库角色
HADR 本地主机名称
HADR 远程主机名称
HADR 远程服务名称
远程服务器的 HADR 实例名称
HADR 超时值
HADR 日志写入同步模式
SQL1768N 无法启动 HADR。原因代码 =“99”（在启动主要数据库或备用数据库时）。
在 /etc/services 文件中检查用于每个数据库的 HADR 端口和名称。它们应具有相同的 hadr_remote_svc 和 hard_local_svc 设置（如上文所述）。
SQL1769N 停止 HADR 无法完成。原因代码 =“2”（在停止主要数据库或备用数据库时）。
在此情况下，您可以先禁用数据库，然后再停止 HADR： db2 deactivate db
db2 stop hadr on db
SQL30081N 在主要计算机或备用计算机上启动 HADR 时检测到通信错误。
检查关键参数，确保这些参数在所有 DB2 UDB 服务器计算机上的配置都正确。使用 DB2 UDB 用户帐户登录到数据库计算机（例如：db2inst1），然后在用户提示符处键入下列命令： db2start (if DB2 is not running)
db2set DB2COMM=TCPIP
db2set DB2AUTOSTART=YES
db2 update dbm cfg using SVCENAME DB2_db2inst1
db2stop
db2start
（SVCENAME 是您的配置中 TCP/IP 服务的名称，位于 /etc/services 文件中。）
SQL2406N 由于数据库需要前滚，无法执行备份。SQLSTATE=57019（在备份数据库时）。
您需要使用此命令前滚数据库（请参阅清单 17）。
db2 rollforward db to end of logs and stop
清单 17. 数据库前滚 >db2 rollforward db sample to end of logs and stop
Rollforward Status
Input database alias = sample
Number of nodes have returned status = 1
Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000000.LOG - S0000006.LOG
Last committed transaction = 2006-10-06-16.22.35.000000
DB20000I The ROLLFORWARD command completed successfully
接管在主要计算机或备用计算机上不能正常运行。您可以强制发出接管命令：
db2 takeover hard on db by force
结束语
DB2 Universal Database (UDB) 高可用性灾难恢复 (HADR) 为其客户端应用程序提供了一种高可用性解决方案。作为客户端应用程序，WebSphere Application Server 能够区分数据库失败和接管情况。当 DB2 HADR 接管发生时，WebSphere Application Server 将利用 DB2 自动客户端重新路由功能自动重新建立与备用 HADR 服务器的连接。
本文使用 WebSphere Application Server Network Deployment V6.1 和 DB2 UDB HADR 演示了在这两种产品之间是如何发生接管的。您已经了解到启用 DB2 和 HADR 以及配置 WebSphere Application Server ND 以便连接到 DB2 HADR 的步骤。还学习了有关接管的行为以及接管过程中在 WebSphere Application Server 日志文件中记录的预期消息。另外，还向您介绍了有关若干常见错误情况的一些疑难解答提示和技巧。
在 WebSphere Application Server 上不需要任何额外配置步骤即可成功进行 HADR 故障转移。WebSphere Application Server 利用了 DB2 UDB HADR 提供的技术和自动客户端重新路由功能为您的应用程序提供了高可用性环境。
在退回主要计算机之前，需要确保已在主要计算机上成功启动了 DB2 UDB 服务器，然后在主要计算机上发出以下命令，以便从备用计算机接管数据库。
db2 takeover hadr on db
仔细检查主要计算机上的数据库是否具有正确的角色：
db2 get snapshot for database on
它会返回“Primary”状态。而且，备用计算机和主要计算机上数据库的状态现在都应该处于“Peer”状态。
故障排除
作为参考，下面列出了在使用 DB2 HADR 时可能遇到的问题的原因和解决办法：
SQL1768N 无法启动 HADR。原因代码 =“7”（在启动主要数据库或备用数据库时）。
此问题的可能原因是，在 HADR 超时间隔内主要数据库无法建立与其备用数据库的连接。您可以通过调整时间间隔来适应您的环境。
SQL1768N 无法启动 HADR。原因代码 =“8”（在启动主要数据库或备用数据库时）。
检查下面所需的 HADR 变量（参见清单 3）这些变量必须正确而且不能为空：
HADR 数据库角色
HADR 本地主机名称
HADR 远程主机名称
HADR 远程服务名称
远程服务器的 HADR 实例名称
HADR 超时值
HADR 日志写入同步模式
SQL1768N 无法启动 HADR。原因代码 =“99”（在启动主要数据库或备用数据库时）。
在 /etc/services 文件中检查用于每个数据库的 HADR 端口和名称。它们应具有相同的 hadr_remote_svc 和 hard_local_svc 设置（如上文所述）。
SQL1769N 停止 HADR 无法完成。原因代码 =“2”（在停止主要数据库或备用数据库时）。
在此情况下，您可以先禁用数据库，然后再停止 HADR： db2 deactivate db
db2 stop hadr on db
SQL30081N 在主要计算机或备用计算机上启动 HADR 时检测到通信错误。
检查关键参数，确保这些参数在所有 DB2 UDB 服务器计算机上的配置都正确。使用 DB2 UDB 用户帐户登录到数据库计算机（例如：db2inst1），然后在用户提示符处键入下列命令： db2start (if DB2 is not running)
db2set DB2COMM=TCPIP
db2set DB2AUTOSTART=YES
db2 update dbm cfg using SVCENAME DB2_db2inst1
db2stop
db2start
（SVCENAME 是您的配置中 TCP/IP 服务的名称，位于 /etc/services 文件中。）
SQL2406N 由于数据库需要前滚，无法执行备份。SQLSTATE=57019（在备份数据库时）。
您需要使用此命令前滚数据库（请参阅清单 17）。
db2 rollforward db
清单 17. 数据库前滚 >db2 rollforward db sample to end of logs and stop
Rollforward Status
Input database alias = sample
Number of nodes have returned status = 1
Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000000.LOG - S0000006.LOG
Last committed transaction = 2006-10-06-16.22.35.000000
DB20000I The ROLLFORWARD command completed successfully
接管在主要计算机或备用计算机上不能正常运行。您可以强制发出接管命令：
db2 takeover hard on db
结束语
DB2 Universal Database (UDB) 高可用性灾难恢复 (HADR) 为其客户端应用程序提供了一种高可用性解决方案。作为客户端应用程序，WebSphere Application Server 能够区分数据库失败和接管情况。当 DB2 HADR 接管发生时，WebSphere Application Server 将利用 DB2 自动客户端重新路由功能自动重新建立与备用 HADR 服务器的连接。
本文使用 WebSphere Application Server Network Deployment V6.1 和 DB2 UDB HADR 演示了在这两种产品之间是如何发生接管的。您已经了解到启用 DB2 和 HADR 以及配置 WebSphere Application Server ND 以便连接到 DB2 HADR 的步骤。还学习了有关接管的行为以及接管过程中在 WebSphere Application Server 日志文件中记录的预期消息。另外，还向您介绍了有关若干常见错误情况的一些疑难解答提示和技巧。
在 WebSphere Application Server 上不需要任何额外配置步骤即可成功进行 HADR 故障转移。WebSphere Application Server 利用了 DB2 UDB HADR 提供的技术和自动客户端重新路由功能为您的应用程序提供了高可用性环境。