>旧式数据库镜像和新式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站点.如果您的DR有VPN,这可能就像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站点. IOW,如果您有2000个数据库并且希望保证数据直到最后一小时,您需要能够对这些2000个数据库中的每个数据库进行一次事务日志备份并将其放到网络存储(某个不在主服务器中的地方) ).
>确保一切顺利进行.

在我完成所有这些工作后,我开始考虑自动化故障转移,如何告诉我的网站特定客户数据库的实时版本在哪里运行等等.如果您没有运行集群系统,请确保您保持所有登录/密码,作业,链接服务器等同步是PITA.