是从快照查询还是使用备份进行报告？

Question

为了报告目的，我有一个非常大的选择查询，运行时间长达1-2小时。

这个查询有几个问题。

1. 它占用了太多的系统资源，而这个服务器无法处理负载，数据库也与其他30个dbs共享在同一台服务器上。
2. 查询非常大，读写性能受到影响，有时表被锁定，因此我无法更新。

数据库用于应用程序和报告目的。我们有另一台服务器位于不同的位置，我们可以在那里托管DB。

应用程序运行良好，就像在此服务器上一样，报告中会出现问题。我的解决办法是

解决方案1：

1. 在另一个服务器上为报告目的创建相同的DB。
2. 运行定时作业将备份文件放置在共享位置。
3. 从存储在共享位置的备份文件备份DB。

其中一个DBA告诉我这是太多的工作，除非

解决方案2：

1. 我们将应用程序DB移动到另一个服务器。
2. 创建副本DB并在同一服务器上承载两个DB。
3. 为备份运行一个定时作业
4. 然后备份报告数据库。

我看不出这是怎么回事。我一直在做DB备份，但从未在共享位置的文件中备份过。但对我来说，这似乎是同样的过程。

如果解决方案2实际上是一个更无麻烦的解决方案，为什么会这样呢？

Answer 1

解决方案2在编写时非常混乱，您的问题似乎是从查询性能开始，然后进入备份最佳实践。在解决方案2中，应用程序DB和新的reporting仍然在同一台服务器上。这意味着您仍然具有相同的资源争用(内存、CPU)。您将不会有相同的阻塞问题，因为您确实创建了您的报告副本。不过，这与备份无关。

解决方案1非常常见。您甚至可以通过日志传送来保持数据更“最新”。这个网站上有很多关于这方面的信息。

关于备份，一些一般性建议是

• 从App运行备份(至少)。这是你真正关心的数据。
• 回到你想要的任何地方。理想情况下，数据文件所在的驱动器不相同。这些驱动器上的损坏可能意味着数据文件和备份的损坏，导致您在恢复过程中死而复生。
• 安排你的备份。你不应该手动这么做。备份的频率应该基于RPO和RTO。