我目前托管了大约 400-500 个大小各异（1-10 GB）的 SQL 2005 数据库。我知道大多数可用的不同方法以及镜像、日志传送、复制和集群的一般优缺点，但我不知道当它们以我指定的大小（400-500）使用时它们的性能如何独特的数据库）。
有谁能对通过这种设置将故障转移到另一台服务器的最佳方法有什么好的建议吗？
故障转移不需要立即进行，我只是在寻找比每天备份并将其移动到存储更好的方法。我最好寻找一种可以轻松批量管理数据库的方法（而不是一次一个）。
感谢您的输入！
答案1
您应该与存储供应商沟通，看看他们是否提供基于硬件的复制。这将比您可能想到的任何其他解决方案都要快得多。
我运行 3 个相当大的数据库，并通过 SAN 复制它们，用于备份（备份在副本上完成）、dbcc 检查和热备用。一开始设置起来很麻烦，但设置完成后效果非常好。
我有 3 个 8-12 TB 的数据库，每个都托管在 EMC SAN 上，每个都在不同的服务器上运行。我们首先在同一个 SAN 上复制它，然后将其安装在连接到 SAN 的不同主机上，并使用复制的副本进行脱机备份和 DBCC 检查以及批量报告。我们使用复制管理器来实现这一点。
我们还每 3 天进行一次 SAN 到 SAN 的复制，以进行第二线备份。
设置过程简直是一场噩梦——花了我们相当长的时间。我们从 EMC 转到了 Dell，然后又转回来。在对他们大喊大叫之后，他们终于派了一个真正懂行的人来。我想使用 Netapp，因为我对它有相当多的经验，但被老板否决了。显然 Dell 为他们提供了更好的租赁协议。
公平地说，它在过去两年里为我们提供了非常好的帮助。
高血压
答案2
猜测你的目标解决方案将围绕你真正追求的是什么这个问题？
如果您追求 HA，那么在我看来，您可能希望考虑集群，同时考虑单个实例上的数据库数量（我假设是这种情况）。
如果您追求 DR 功能并担心存储基础设施会让您失望，那么我们实际上谈论的是第二个站点（逻辑或物理）以及围绕该场景可用的选项。在这种情况下，镜像对于许多数据库来说都是不可行的。日志传送是一种选择，但可管理性将是一个问题，正如 Farseeker 正确指出的那样。此外，复制也因类似的担忧而失败。
我想这让我们无法使用基于硬件的复制，正如 Farseeker 和 no_one 所建议的那样。这可以与 Windows2008 地理集群功能相结合，为您提供出色的 HA 和 DR 功能。虽然在经济困难时期，这可能是一个更昂贵的解决方案。
另一个激进的选择可能是投资于惠普 Polyserve或者Xkoto 的网格尺度。
希望这可以帮助。
答案3
我们使用日志传送到备用服务器，由于它通过日志文件运行，所以对服务器的影响（除初始副本外）可以忽略不计。
我们每 15 分钟运行一次（我们有大约 75 个数据库），但是我怀疑在 500 个数据库中每 15 分钟运行一次意味着当最后一个数据库完成时，第一个数据库就会逾期，所以你可能需要把你的数据库运行得稍微分散一点。
您可以编写日志传送配置脚本，但是需要在两端（原始和目标）进行配置。我怀疑这可能相当麻烦。
另一个选项是块级备份，正如没有人建议的那样。恍然大悟有一个产品可以对你的 SQL 服务器进行块级复制（我相信对于一个已经很昂贵的产品来说这是一个非常昂贵的选择） - 你只需将它指向你的数据和日志文件夹，它就会处理剩下的事情。
我们将 DoubleTake 用于其他非 SQL 数据库（BTrieve），其运行非常良好，复制延迟仅为 20 秒左右。
答案4
大约在过去一年里，我一直在使用 DoubleTake。它使我们能够以相当快的速度将 70 到 90 个（数量每月都在增长）数据库复制到 DR，并且压缩率很高。正如 Farseeker 所说，它允许块级复制，效果非常好。它还允许在事务负载繁重时进行排队。
对于您的实例，我真正看到的唯一问题是这些数据库有多重？我有至少 5 个数据库超过 10gb，在高峰时段和作业期间有大量事务数据，每个数据库每天大约 1 到 3gb。总共每月通过网络传输 800+gb（当然，压缩后要少得多）。自从在过去 15 个月内添加了另外 20 多个数据库以来，我发现与磁盘排队相关的 IO 过高。因此，如果大多数数据库都非常繁忙，尝试使用这样的方法可能会有问题。如果排队太多并且链接断开，您最终可能会丢失数据或接收端。当然，这只对 DR 部署有影响。但密切关注它并调整带宽将极大地有助于降低排队速度。