两天前，我们在 Reporting Services 中的一份报告开始需要更长的时间才能生成。它的生成时间从 4 秒增加到 2 分钟。
调查发现：
存储过程运行时间为 1 秒，查询计划可接受
报告在 Visual Studio 的开发机器上按预期在 4 秒内运行
一旦报告发布到生产服务器，它的运行速度就会慢得多。
使用活动监视器显示报告被锁“LCK_M_S”阻止
我打开跟踪 1222 来检查死锁，但没有报告死锁。
关于发生的事情，我能获得的唯一信息是 ReportServer 数据库的“按锁计数排列的顶级事务”报告。它列出了 ReportServerTempDB 上的锁定事务。
这种模式在受影响的报告中可重复两天，您将运行它，在活动监视器中查看阻止过程，并且报告需要更长的 2 分钟。
就在我们进一步研究问题时，它突然消失了，团队中没有人改变任何东西，代码或数据，现在报告在 3-4 秒内恢复运行。
发生了什么？
在没有开发人员干预的情况下，重复运行 2 分钟并运行了 2-3 天的报告突然在 4 秒内恢复运行，并且在活动监视器中看到的阻塞过程消失了？
我们希望在我们的本地站点使用 SQL Express，但仍然能够使用 Service Broker 将数据推送回我们的总部。总部的SQL Server是2008 R2 Standard。
查看 SQL Express 2008 R2 for Express 的功能列表，上面写着“仅限客户端”，这对我们的需求意味着什么？
作为公司软件的一部分，我们运行工作跟踪服务。报告通常由 SQL Server（标准）报告服务生成，但通常在会议之前需要时等。
随着作业的进展，它们的状态会发生变化，报告的详细信息也会发生变化。由于前端应用程序和数据库的遗留问题，我们没有存储管理人员回顾历史报告所需的尽可能多的里程碑。
经理们经常问“我们能看到 XYZ 上周在哪里吗？” 或诸如“让我们看看 Project1 去年 6 月的表现如何？”之类的东西。但是在 Project1 数据库备份上运行报告都显示 100% 完成，因为它现在已完成。
使用 SQL Server Standard 在日常级别启用历史报告的最佳方法是什么？
理想情况下，如果可能的话，我们希望每天存储 3 个月的 5 个不同的报告？