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

Question

我继承了一个在单个服务器上运行3个数据库的系统（SQL Server 2012）：

• StagingDB（250GB）
• ReportingDB（350GB）
• AppDB（500GB）。

每天都会发生以下过​​程：

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

问题

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

目标

我们正在探索可以为我们解决这个问题的解决方案。即我们想：

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

APPROACH

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

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

（1）对我们似乎不太好用，因为它似乎不可能在事务隔离快照中执行合并 （2）上面看起来相当麻烦，并且涉及每天在一次大规模交易中复制数百GB的批量数据。

实现目标的最佳做法是什么？ 我们希望得到社区的一些建议..！

Answer 1

我想到的一些事情/在帖子中并不清楚：

• 为什么要完全重建整个数据库？有没有办法只构建已更改的部分或整个数据是否发生变化？

• 问题是您是否因为访问相同的表而部分/完全关闭应用程序？

• 如果阻止和/或访问相同的表不会有问题，那么性能是否正常？您是否可以在单独的表上的同一服务器上构建它，也许可以通过调整MAXDOP使其在资源上不会那么重。

• 如果您只有一个数据库，是否可以将数据构建到单独的表中，然后只用新数据替换旧数据？

  • 如果您正在使用企业版，分区切换可能会提供一个简单的技巧。
  • 否则，我可以根据您的环境（安装访问表的新版本的视图/别名/过程，sp_rename，不同的架构等）来提出小的或更大的黑客攻击。

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