为报表数据库和应用程序前端选择最佳高可用性解决方案

Question

我继承了一个系统，其中有3个数据库运行在一台服务器上( server 2012)：

• StagingDB (250)
• ReportingDB (350)
• AppDB (500)。

每天都会发生以下情况：

1. 几GB的纯文本CSV数据通过第三方进程存储在服务器上。
2. Server代理获取数据并将其导入StagingDB
3. Server代理运行几个作业，这些作业根据ReportingDB的当前内容从头开始重新生成StagingDB。这个建筑需要5-6个小时。
4. Server代理在ReportingDB上运行聚合摘要KPI，并将它们存储在AppDB中。这个过程需要1-2个小时。

问题

1. 当上面(3)在运行时，我们必须从最终用户访问中关闭应用程序的一个部分，因为本节使用来自Availability：的活动数据显示网格。当(4)运行时，我们必须完全关闭应用程序。
2. Performance：由于所有DB都在一台服务器上，在构建过程运行时在ReportingDB或AppDB上操作的任何存储过程的性能对最终用户来说都是一种糟糕的体验。

目标

我们正在探索解决办法，为我们解决这个问题。即我们想：

1. 持续提供以前构建的数据，直到所有最新数据都可用为止。
2. 通过将构建分离到另一个物理服务器来确保在构建期间的性能。

逼近

我们正在探索这些潜在的解决方案：

1. 使用合并复制。在发布服务器上生成所有数据，然后通过使用按需复制调用合并代理将其同步到订阅服务器。
2. 在Build服务器实例上构建所有数据，然后手动将表复制到Production服务器实例。
3. 根本不要复制任何每日构建数据。在指定active数据库的表中设置两个带有标志的server实例。在服务器上完成日常构建时，只将用户事务数据从active实例复制到服务器，然后将新构建的实例设置为active，将另一个设置为inactive。应用程序将在每次加载时检查活动服务器。

(1)上面似乎不太适合我们，因为在事务隔离快照(2)中执行合并似乎是不可能的，上面的快照(2)似乎相当麻烦，每天都要在一个大型事务中复制几百GB的大容量数据。

实现我们的目标的最佳实践是什么？我们希望得到社区的一些建议。

Answer 1

有几件事在我的脑海中/在帖子中没有那么清楚：

• 你为什么要完全重建整个数据库？难道没有任何方法只构建已经改变的部分，或者整个数据会发生变化吗？
• 您必须部分/完全关闭应用程序的问题仅仅是因为访问相同的表吗？
• 如果阻塞和/或访问相同的表不会成为问题，否则性能会正常吗？您能不能只在同一台服务器上构建不同的表，也许可以通过调整MAXDOP，使其不会对资源造成太大负担。
• 如果您只有一个数据库，那么可以将数据构建成一个单独的表，然后用新的数据替换旧的数据吗？

- If you're using enterprise edition, partition switching might provide an easy trick.
- Otherwise I can just come up with small or bigger hacks depending on your environment (installing new versions of views / aliases / procedure that access the tables, sp\_rename, different schema etc) 

​

这个问题相当广泛，而且与编程没有多大关系，因此dba站点可能更适合这一点。