我们有一个 Web 应用程序，它在单个数据库服务器上使用 SQL Server 2008。所有存储都是本地的。在过去的一年里，我们一直在尝试让任何形式的 SQL Server 复制与我们的配置一起工作，但都行不通。原因是我们有超过 2,000 个数据库在不断更新（每个客户一个），所以我们的测试表明，所有形式的复制都过于耗费资源。
每次我问这个问题，人们总是关注我们的数据库太多。这是无法改变的（出于监管和其他原因），所以我想关注我们如何复制数据。
我们被告知，一种选择是将所有数据移至 SAN，然后让 SAN 复制数据（或频繁拍摄快照）。但是，如果我们的数据库服务器发生故障，在这种情况下数据库是否存在损坏的风险？是否可以利用复制到另一个 SAN 的 SAN 来提供不错的 DR 解决方案（在我们的案例中，我们最多可以丢失大约 30 分钟的数据，但我们不能丢失一整天的数据……即我们不能回到前一晚的备份）。
答案1
正如其他答案所述：
旧式数据库镜像和新式 AlwaysOn 需要线程，而 2000 个数据库肯定会耗尽线程。我依稀记得实际限制远低于 200 个数据库。（某处有一份白皮书，但我现在懒得去找，而且这个答案已经很长了。）当然，每个实例 200 个数据库。理论上，您可以启动 20 个实例，并在每个实例上运行 100 个数据库。管理所有这些会很麻烦，我怀疑管理所有这些实例之间的内存会很麻烦。
SQL Server 复制（复制表（或表的子集）而不是文件）实际上并非用于 DR。即使对于少数数据库而言，它都很难设置和管理。您可能需要更改数据模型才能使其工作，这可能意味着需要更改应用程序。您需要一种自动化的方式将相同的复制配置应用于 2000 个（可能相同或几乎相同）数据库中的每一个。配置复制所需使用的存储过程非常混乱。管理通过 GUI 配置为复制的 2000 个数据库将是一场噩梦。当/如果您进行故障转移，您可能需要进行更改以使一切重新正常工作。故障转移时，您并不想进行任何可以避免的棘手更改或工作。您希望尽快让一切恢复正常运行。这似乎只是一堆问题。
SAN 存储单元之间的复制可能非常昂贵，尤其是当您谈论来自 EMC 等公司的硬件时。一旦您开始使用某个供应商，您几乎就要依赖他们进行升级、维护、增加空间等。
建议1： 您是否看过 Steeleye 的 DataKeeper 之类的产品？它是一款基于软件的复制产品，运行在您的服务器上，利用 Windows 故障转移群集。我从未真正使用过它，除了参加一些花哨的表演外，我与公司没有任何联系。它看起来非常适合您的情况。
建议2： 如果是我，而且我完全没有预算，我会考虑一些自己开发的日志传送系统。我怀疑内置的日志传送系统能否很好地处理 2000 个数据库。编写日志传送系统并不难，它可以解决您环境中特有的所有问题。（例如，您可能需要通过 sftp 将文件发送到您的 DR 站点。）
基本上，该系统有三个部分。每个部分都需要定期运行：
一部分负责事务日志备份，将每个数据库的 tlog 备份文件放入不同的文件夹（用于文件系统扩展）。我不会为此使用维护向导，我见过它出过太多次问题，开始跳过数据库，并且通常行为不端。如果您想提供 30 分钟的保证，也许每 15 分钟运行一次。
一部分将备份文件从暂存区复制到您的 DR 站点。如果您有 VPN 连接到 DR，这可能只是一个简单的 robocopy CMD 文件。如果您需要更高级的东西（sftp 或 ssh/scp，或者如果您没有内置备份压缩，则可能是 zip/unzip），您可以编写一个包或 powershell 脚本。这可以运行得更快，可能每 5 分钟一次，以确保它获得所有内容。一旦某些东西被复制到异地，它就是“安全的”。
- 一部分会将其在 DR 站点找到的 tlog 备份还原到您的辅助服务器上。您需要确保识别已还原的 tlog 并按计划将其移出或删除，否则最终会用尽空间。这不需要频繁运行，但您需要确保它已在所有可用的 tlog 备份上运行，并在出现问题时宣布 DR 辅助服务器“处于活动状态”之前应用。
您需要审核所有三个步骤的表格、一些显示发生了什么情况的报告/脚本（特定数据库是否在您的主站点或辅助站点上运行？辅助站点上的任何数据库是否在两个小时内没有看到 tlog 恢复？）和警报方案。
除此之外，我还希望能够选择要故障转移的特定数据库，以及能够对所有数据库进行故障转移。能够选择要故障转移的数据库可以轻松进行测试（故障转移的是测试数据库，而不是客户的数据库），并且如果您遇到扩展问题，可能会为您提供基本的负载平衡方案。您还需要一种自动方式在主数据库和辅助数据库之间“重新同步”（从主数据库获取完整备份并将其应用于辅助数据库，启动 tlog 流动等）。这些功能可能更适合 2.0 版。
（大家都忘记了，MS 支持的最早的 tlog 传输是通过一些可以在 SQL 7.0 上下载并运行的脚本实现的。有 GUI，UI 是一些 SQL 报告和一些存储过程。）
除了编写一些 tsql 代码之外，这里的挑战还有：
更改为完整恢复模型（在我看来，您可能正在运行简单恢复模型）并且可能用于日志备份、数据库大小增加等的存储使用量增加。
确保您的存储系统能够处理频繁的 tlog 备份负载并及时将其复制到 DR 站点。换句话说，如果您有 2000 个数据库并且想要保证数据直到最后一小时，您需要能够对这 2000 个数据库中的每一个进行一次事务日志备份并将其放到网络存储上（不在主服务器中的某个地方）。
确保一切总体正常。
在我完成所有这些工作之后，我会开始研究自动故障转移，如何告诉我的网站特定客户数据库的实时版本正在哪里运行，等等。如果您没有运行集群系统，请确保您保持所有的登录名/密码、作业、链接服务器等同步是一个 PITA。
答案2
是的，数据库有可能被损坏，就像盒子断电一样（出现“崩溃一致性”）。
然而，数据库引擎采取了很多预防措施。每次你更改数据库中的数据时，它都会说“我要进行更改”，然后它进行更改，然后它说“我进行了更改”。粒度级别取决于它的设置方式，但你几乎总是能够通过重放日志（它打算做什么）来回滚到一致状态。
这并不意味着您不会丢失数据，而只是意味着现有数据是准确的。
在这种情况下，您可能想要的是异步复制（假设您不会因为 10 分钟后恢复而损失数千美元）（您不想等待远程存储确认对数据库的写入）。对于大多数常见的存储系统，您只需说“每 X 分钟快照一次”即可。
最后，这不是 100% 的——您仍然需要进行传统备份。但它相当可靠。这种设置非常常见，并且适用于虚拟机和数据库。
查看意图日志、回放、日志传送、高水位标记和一致性检查点以获取更多信息。
答案3
这绝对是可行的，我不知道有没有免费的方法，但我们使用这，它基本上允许 MSSQL 框使其文件静止，然后告诉 3Par 阵列进行快照 - 这本质上是一致的，然后继续。然后阵列进行快照并允许您拥有几乎任意数量的快照 - 实际上您只需要 24 小时左右，因此您只需在此基础上转储它们。正如我所说，远非免费，但每次都 100% 有效，并且专为此类情况而设计。我很确定 NetApp 做了类似/相同的事情 - 我只是不知道那个产品，抱歉。
答案4
我开发过一个类似的应用程序。我们假装它是多租户应用程序，但实际上它不是，所以每个客户只有一个数据库。太糟糕了。
您可以尝试将数据库拆分到多个 SQL 服务器上，这样您就不会耗尽工作线程或在镜像/复制/日志传送时遇到其他瓶颈之一。
我查看了 SQL 2012 中的 AlwaysOn，它看起来与 2008 镜像的工作线程有相同的要求，因此升级对您没有帮助。
您可以尝试存储层复制，正如您所问的那样。我在这方面没有太多经验。