我们有一个客户，它在地理上分布在偏远社区，每个物理位置之间的网络/互联网连接有些不可靠。有一个中央位置和 52 个卫星位置。
通常，我们的应用程序部署为一个中央解决方案，其中只有一个数据库，所有位置都连接到一个数据库。数据本身由大多数表中的位置列进行分区（一些数据是集中式的），并且应用程序运行使得在一个物理位置接触数据不会接触到另一个物理位置的数据，包括集中式数据（至少，我们很确定它不会——如果是这样，那很可能是一个错误）。我们的客户想做集中报告（我们通常支持），并在整个企业中同步几个集中配置表（同样，因为通常只有一个表副本）。
每个位置都有自己的数据中心，并获得 SQL Server 2008 R2 Enterprise 的许可。
目标是部署我们的应用程序，使网络/互联网连接中断不能阻止本地读/写操作，因为我们的应用程序是关键任务。
我的第一个想法是使用一个巨大的点对点拓扑来复制数据库中的每个对象。我无法找到任何使用这种方法进行如此大规模扩展的任何安装的文档或参考资料，所以我不知道它在技术上是否可行，如果可行，将需要什么硬件。这是否适用于集中式分发数据库（为了便于管理）？这甚至是一个好主意吗？如何部署数据库架构更改？索引维护是否会产生大量的网络开销？
还可以选择创建一个自己滚动的解决方案，我认为这将涉及将数据库的单独副本（每个非中心位置仅包含其数据的分区部分）的日志传送到中心位置，然后使用用于创建报告数据库的合并工具（我们已经拥有）。配置表更改将由其他机制推出，可能是合并复制，可能是自制解决方案。
我考虑并测试了在整个数据库上使用合并复制，但我们需要大量的数据库和应用程序更改/重新设计/等。为了使这项工作正常进行，因此由于时间限制，我已经排除了这一点。（对此有什么想法？）
我在这里寻找的是有更多经验的人的一些指导。显然，为此做好计划至关重要。我在正确的道路上吗？还有其他选择吗？（网址？）
对于仅仅 52 个客户端站点，复制就可以了。将您的本地副本视为“主”站点，并始终让应用程序仅在本地副本上运行。使用复制将数据聚合到中央存储库以进行聚合报告。索引维护操作通常不会产生复制流量。通过应用程序部署迁移管理架构更改，即。每个发布版本都有升级脚本。
随着站点数量的增加，管理复制变得越来越困难。许可也将推动在外围部署 Express。当涉及复制时，SQL Server 升级绝对是一件痛苦的事情，因为升级组件（发布者、分发者、订阅者）的顺序很关键，但很难与许多站点协调。我所知道的 +1500 个站点的部署使用基于 Service Broker 的自定义数据移动。有关示例，请参阅使用 Service Broker 而不是复制。我什至看到过使用 Service Broker 将新位（应用程序更改）推送到外围的设计，这些新位（应用程序更改）反过来又在激活时部署迁移和架构更改，从而使整个部署从中心运行。
为什么只有一个数据库？似乎让每个位置在本地为自己的读/写操作和自己的数据切片保留数据库模式的副本会更有意义，并且可以集中复制数据的报告部分。站点 A 是否有任何理由必须将其非报告数据提供给站点 B，反之亦然？可以使用多种技术将报告数据分发回中心位置，包括自己动手（如果您想了解更多信息，我有一些经验）。或者，如果报告数据是大部分数据大小，您可以只使用日志传送或 copy_only 备份，保留整个数据库的副本，并在多个数据库恢复时使用视图或其他技术进行集中报告。
架构更改很容易。我在以前的工作中处理了很多这个问题，我们有大约 500 个具有相同架构的数据库。部署更改的关键是确保更改向后兼容。如果您可以构建一个不会破坏一个数据库的脚本，您可以编写一个循环将这些更改部署到 n 个数据库/服务器/环境。我们使用 Red Gate 来构建基于 beta 和生产之间的比较的部署脚本，然后
sp_msforeachdb在每个实例上自行开发（因为您不能信任内置的 - 请参阅此处和此处）。还可以很好地混合源代码控制。在这种情况下，我不确定索引维护会如何导致网络开销。索引维护只应在源上进行，如果可以避免，则不应“重放”。