关于 DB2 LUW 的 Windows 或 Linux 大辩论

我想说，添加一个额外的bullit：
4) 高可用性和灾难恢复
虽然相当不错，但从Windows 2000、Windows 2003、Windows2008开始，微软的“Failover Cluster”实际上是高可用的唯一选择；在 Windows 上运行 DB2 时，替代 DB2 的 HADR 实际上是不可能的（Windows 缺乏适当/健壮的 TSM 用于故障转移；更糟糕的是：在 Windows 2012 上它根本不起作用：DB2 的 HADR 需要“TSAMP”，在 Windows 上为“TSAMP”需要 Microsoft 的“SUA”（用于移植的 POSIX unic），并且从 Windows 2012 开始不再支持/弃用）

发布者：Erwin Hattingh | 2016 年 5 月 4 日 6:42:40

Erwin，我发现 DB2 LUW 的 DR\HA 在 Linux 上更加可靠和可支持。 Linux、TSAMP、DB2 LUW 的组合非常出色，尤其是从 DB2 10.1 开始

发表者： 杰克·瓦姆瓦斯 | 2016 年 6 月 1 日 4:58:48

对 DB2 HADR on Windows 讨论的评论。
我试过在 Windows 2008 R2 上通过 SUA 部署 TSAMP。它真的奏效了！每次大约一个半星期......在那段时间之后，Windows 和 SUA 之间的某种计时问题导致 TSAMP 半疯了，并无缘无故地迁移资源。我们将此事报告给了 IBM，后者指责微软，后者转过身说：“太糟糕了。无论如何，我们无论如何都要停止 SUA。”

但是，我刚刚完成了一个在 Windows 2012 R2 下通过 MS 故障转移集群自动化 DB2 HADR 的项目。它结合使用 VBS 包装器和 PowerShell 脚本。需要 VBS（或 JSCript）包装器，因为此方法使用 MSFC 的“通用脚本资源”，不幸的是，它仅适用于基于 WSH 的脚本语言，因此不能直接使用 PowerShell。这很奇怪，因为 WSH 已经多年没有更新了，而且看起来已经被微软完全抛弃而支持 PowerShell，但我离题了……
无论如何，我的脚本解决方案可以在主节点重启或主实例崩溃的情况下进行优雅的接管以及自动故障转移。它将在接管时重新整合，并在重新启动后尝试重新整合；然而，MSFC 似乎缺乏必要的智慧来尝试在将资源转移到新的主节点后重新启动现在备用的主节点上的服务，因此需要手动干预来重新启动 HADR 并尝试重新集成。无论如何，那时应该有人应该看看为什么 DB2 崩溃了，不是吗？

发布者：Luke Numrych | 2017 年 12 月 11 日上午 11:13:17