用于报告和 CRUD 操作的单独表/数据库答案

【问题标题】：Separate tables/databases for reporting and CRUD operations用于报告和 CRUD 操作的单独表/数据库
【发布时间】：2010-02-22 16:41:30
【问题描述】：

运行报告的用户定期阻止用户执行 CRUD 操作并导致超时。我想为报表用户创建当前表的重复位置。

我正在考虑创建一个备份我的应用程序数据库的作业，并将其还原到同一服务器上的报告数据库，以便将运行报告的用户与执行 CRUD 操作的用户分开。该作业将每 10 分钟左右运行一次。初始测试显示从开始到结束大约需要 30 秒。磁盘空间不是问题。

这是一个好主意还是坏主意？我应该注意哪些陷阱？有没有更好的方法来做到这一点？

【问题讨论】：

【解决方案1】：

这听起来是个好主意。我唯一担心的是你需要每 10 分钟更新一次吗？这也可能会在更新运行时减慢速度。通常这些是在一夜之间完成（对他人的影响最小），或者如果在白天，只在 3 个固定点（比如上午 10 点、下午 1 点和下午 4 点）。

【讨论】：

备份/恢复期间谁会受到影响？那只是恢复部分的报告用户吗？
另外，如果我将数据库恢复到暂存数据库，完成后删除报告数据库并将暂存数据库重命名为报告数据库，该怎么办？
@Gern Blandston：我认为这两个数据库的用户可能会受到备份/恢复的影响。我对 MSSSQL Server 了解得不够多，不知道它是否能够保护一个组，但我会很悲观并假设它不能（除非另有证明）。

【解决方案2】：

在进行叉车升级之前，您可能会看到是否放置

...from sometable WITH (NOLOCK)

您的报告查询可以缓解问题。它至少可以为您争取一些时间来弄清楚什么是最佳的。

【讨论】：

但请记住，这样会导致脏读，这可能是报告中的问题。
@HLGEM - 是的，但数据在当前计划中已经存在 10 分钟！过去，我们在针对企业规模的数据库运行非常大的查询时遇到过类似的问题，而 NOLOCK 产生了HUGE的不同。 PK :-)
只是指出它可以产生不同的结果。如果你能忍受脏读，那是一回事，但发帖人需要知道这就是他会得到的。

【解决方案3】：

对于大多数企业级应用程序来说，交易数据库自然与报告数据库是分开的。事务系统针对 OLTP 进行了调整，并且报告数据库可能会被非规范化以适应报告场景的需要。所以这几乎是一个自然的建议。

【讨论】：

【解决方案4】：

注意频繁备份——这可能会导致大量停机！

常见解决方案

为报告创建单独的实例确实是一种常见的做法。

有些人甚至更进一步，将报告放在单独的物理机器或集群上，以进一步隔离这部分负载。

这两者都可以通过复制（避免停机问题）来处理。或者你可以只做一个夜间备份并针对它进行报告。

我还想提一下，解决此问题的高端方法是数据仓库，您可以在其中将这个新的报告数据库转换为读取优化的存储库，以便更有效地进行报告。这往往是非常耗时的实施，所以它不是您正在寻找的快速修复。

最后的想法

最后一件事：我看到一些处于这个问题风口浪尖的商店试图避免处理它。要点如下：报告往往会在一个月或一年中的某些时间出现高峰，因此，如果您通常处于关闭数据库服务器的边缘，则该月的最后一周可能会让您超过边缘！

【讨论】：