我们公司的一位架构师设计了一个基于 64 位 SQL2005 标准版同步镜像的解决方案，在两个地理位置偏远的数据中心的物理（4 个四核，32GB RAM）服务器和虚拟 DR 服务器（4 个虚拟 CPU 和 16GB RAM）之间进行见证服务器（1 个虚拟 CPU）。存储在两个数据中心都是企业级 SAN。
前端应用程序是面向 Web 的，具有混合读/写用法。
作为一名 DBA（在设计阶段没有咨询过），我担心此配置的设计是以最小化冗余为主要标准，并且它不会作为现实世界的解决方案工作 - 网络延迟和虚拟机的性能框会导致无法接受的响应时间？如果调用故障转移，性能甚至会更差。
有没有人有类似设置的经验？
Microsoft 发布了一份关于数据库镜像的非常好的白皮书，其中包含一些很好的示例，说明同步镜像对性能的影响有多大。你是完全正确的，因为性能会受到影响。从主机器向数据库镜像执行 ping 操作，并查看以毫秒为单位的往返时间：这将是同步镜像将增加的绝对最小开销。ping 甚至没有考虑远程服务器处理每个传入事务需要多长时间 - 它纯粹是网络延迟时间。
您添加的网络延迟越多，性能就越慢，硬件就会处于空闲状态：
替代文字 http://i.technet.microsoft.com/Cc917681.dbm_fig09(en-us,TechNet.10).gif
我是异步镜像的忠实拥护者，因为这是一种添加一些保护的简单方法，但保护可能会落后。这是一件好事，也是一件坏事：这很好，因为它可以处理网络延迟，但它很糟糕，因为您可能会丢失任何尚未将其转移到故障转移站点的数据。
此外，当您设计数据库镜像解决方案（无论是同步还是异步）时，请务必考虑您的索引维护操作。如果您每周进行索引重建，那么这些绝对会杀死您的镜像积压，因为它们会产生如此多的日志活动，必须通过网络进行。
尽管网络带宽在很大程度上发挥了作用，但要考虑的绝对第一因素是主体上的事务日志生成率是多少？
如果应用程序和您的维护没有生成任何事务日志，那么网络带宽真的无关紧要。如果它确实生成了日志，那么网络带宽必须能够处理生成的日志量。
要回答您的实际问题，如果主体上没有大量 OLTP 工作负载，您的硬件配置可能会起作用（网络问题除外）。如果有，并且您有 4x4 处理器内核生成事务日志，那么无论您的网络是否能够处理日志流量，您的镜像服务器都可能无法跟上重播日志的速度。在标准版中，镜像上有一个线程处理日志的重做——所以你的重做队列在重负载下会变得相当大。
REDO 队列是已在镜像上加固但尚未在镜像数据库中重放的日志量 - 它越大，在发生故障转移时镜像数据库作为主体上线之前的时间越长. 这在标准版中尤其麻烦，因为您没有可用的并行重做和快速恢复（数据库在 REDO 之后和 UNDO 之前上线）等功能。
而且，当然，在从主体到镜像的故障转移之后，镜像将无法为与主体服务器相同的工作负载提供服务——所以你会在那里，但可能运行速度要慢得多。
希望这可以帮助。
我没有直接经验，但您应该查看OpenVMS 集群延迟文档。他们广泛讨论了距离问题。
出于主动/备用备份的目的，需要考虑一些事项，VM 不一定是一个糟糕的选择。如果 VM 的磁盘位于 SAN 上，您应该会看到相当不错的性能。
长距离同步镜像是我比较关心的。读取不应该受到影响，但是每次写入都需要等待远程提交准备好才能返回。
我还应该补充一点——虽然 OpenVMS 文档专门讨论了很多关于 OpenVMS 的内容，但延迟问题适用于任何类型的镜像或集群应用程序。对链路距离的光速延迟进行“数学计算”对于长距离的延迟和响应能力非常有启发性。
您主要关心的应该是网络链接。SAN 不应该提供太多的瓶颈，但我没有看到任何关于它们的性能数据，所以我不能真正告诉你是或否。你应该问你的建筑师和你自己以下问题：
好好看看网络链接
仔细看看 SANS
然后看看你的申请
您的 RAM 和处理器设置听起来很适合企业应用程序。这些类型的问题很难量化，尤其是在没有真实数据的情况下。
IMO，虚拟机通常不是瓶颈的原因。这在很大程度上取决于它们的设置方式和资源分配。I/O 通常是影响 VM 速度的最大因素，这些 SAN 应该对您的速度有很大帮助。
每个应用程序都不同，但您和您的架构师需要坐下来一起回答这些问题（上图）。以及在此过程中弹出的所有其他人。
如果一切都失败了，去买另一台服务器，然后删除虚拟机。