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

Question

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

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

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

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

问题

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

目标

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

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

方法

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

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

(1) 上面的(1) 对我们来说似乎效果不佳，因为似乎不可能在事务隔离快照中执行合并 (2) 上面看起来很麻烦，每天在一个海量事务中复制数百GB的批量数据。

实现我们目标的最佳做法是什么？ 我们很乐意从社区获得一些建议..！

Answer 1

我想到的几件事/在帖子中不太清楚：

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

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

• 如果阻塞和/或访问相同的表不会成为问题，那么性能是否还可以？您能否在不同表上的同一台服务器上构建它，也许通过调整 MAXDOP 使其不会占用太多资源。

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

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

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