目前，我想将我部门的 SQL Server 合并为一个分布在两台服务器上的大型 SQL Server 2008 实例（出于冗余的原因）。
如何/什么是解决这个问题的最佳方法？是通过集群、日志传送还是 VMware（虚拟机管理程序）高可用性功能？
注意：此数据库服务器不能关闭，因为它还托管 VCenter 数据库和服务器监控数据库。
SQL Server 分布在几台较小的服务器 3-4 SQL Server 2000 和 2005 上，这些服务器内部总共有 70 个数据库，我想要做/构建的是将它们全部迁移到 SQL Server 2008 中，在其中我必须使其冗余，以便如果一台服务器由于某种原因出现故障，另一个实例可以立即接管它。
因此，从几个较小的 SQL Server，我想将它们全部合并为一个更强大的 SQL Server 2008 x64。但到目前为止，还不知道哪种技术适合这样做，或者是否可以在 SQL Server 2008 Standard 中做到这一点。
任何建议和意见都将非常感谢。
答案1
是通过集群、日志传送还是 VMware（虚拟机管理程序）高可用性功能？
不不不。
镜像，3台服务器（一台可以是小型免费服务器，只需决定哪台保持活跃工作）。
日志传送很慢/延迟，集群/vmware 留下一个数据库作为弱点，仍然可能被破坏。
答案2
TomTom 的说法是正确的，但让我阐述一下几个关键点：
日志传送非常适合灾难恢复，但不适合最新数据。您的数据是总是15 分钟到 1 小时甚至更久，具体取决于您的设置。重新连接是不是无缝。您需要重新配置应用程序以指向新系统。此外，第二个数据库不在线，它通常处于恢复模式（应用日志），因此您需要将其从恢复模式中取出才能使用它。这就是为什么它通常仅用于灾难恢复的原因。
当你与任何完全没有延迟。它提供了高可用性 SQL 接口，但它不会使您的数据具有高可用性，除非您的 SAN 可以为您做到这一点。我永远不会尝试在 DC 之间进行集群。
镜像。在这种情况下，镜像是您的好朋友。镜像有两种基本模式：同步或非同步。两种模式的共同点是：每个 SQL 服务器都有自己的数据库本地副本，但只有一个 SQL 服务器可以“拥有”它。换句话说，即使您有三个 SQL 服务器，但实际上只有其中一个正在使用。其他服务器都处于待机模式，等待激活。
在同步模式下，当收到写入事务时，所有 SQL 服务器都会同时执行该事务，直到每个 SQL 服务器都报告已提交事务后才会处理下一个事务。这可确保每个 SQL 服务器都拥有完全最新的数据。这对于高速、低延迟的链接非常有用，但对于高延迟的链接则不太好，因为它会有效地将数据库速度降低到最慢的合作伙伴的速度。
在异步模式下，SQL 服务器会不是等待所有其他 SQL 合作伙伴提交事务。它只是在本地提交事务并继续前进。然后，每个其他 SQL 服务器可能会落后几个事务，特别是当它们之间的链接负载很重时。这意味着您可以全速访问活动数据库，但在发生故障转移时，您可能会丢失一些数据。此外，此模式仅适用于 SQL Enterprise 版本。
VMWare HA。好吧，这真是一大堆麻烦。它很好，但同样，您需要共享同一个 SAN 才能工作。或者您是在谈论 VMWare FT（容错）？如果是，我建议您暂时忘掉 SQL 服务器的 FT。FT 在理论上很棒，我甚至在一台 VM 上使用它，但对于大多数部署来说，您需要做出的牺牲太大了。此外，由于 VM 彼此同步，带宽问题会损害性能。
为了管理自动故障转移的能力，群集为您提供了一个虚拟实例，您可以连接到该实例，并且所有操作对用户都是不可见的。对于镜像，您可以通过运行网络负载平衡角色轻松实现这一点，:1433这样当 SQL 服务器脱离网络时，虚拟实例就会切换到其他节点。或者，根据您的应用支持情况，您可以在 SQL 连接字符串中指定备用镜像服务器。
你可能对我的问题的答复感兴趣，SQL Server 2008 R2 100% 可用性。