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