SQL Server每天重新创建计划

我们的生产环境中存在这个问题。

Windows NT 6.1（内部版本7601：Service Pack 1）上的Microsoft SQL Server 2008 R2（SP1）-10.50.2500.0（X64）-企业版（64位）。

SQL Server将删除所有（几乎100％）旧的执行计划，并每天隔夜（从11:00 PM到8:00 AM）重新创建它们。当“自动更新统计信息”处于禁用状态时，甚至会发生这种情况。我们已在过去2-3周内启用了“自动更新统计信息”。但它仍在发生。

我们真的不知道是什么触发了计划的重新生成，但是我们确信我们不会手动进行。

与重新生成计划的时间真正吻合的唯一一件事是我们拥有的DB​​维护工作：每日索引重组（当碎片为5-30％时）和每日索引重建（当碎片大于30％时） ）的工作。通常，此日常维护工作仅会进行重组（因为索引碎片每天都不会超过30％）。

影响：

这些新创建的计划使一些UDF调用/查询调用（从UI /网页调用）花费的时间更长（几分钟而不是不到1秒），因此会话堆积如山，使CPU接近90％ 。

当这些卡住的会话被强制删除（在DB端）时，问题消失了； 1）当手动清除了所有相应的执行计划（对于查询）时，或者2）当UDF改变了（对于功能）时，问题就消失了。从那时起，SQL Server创建的任何新计划都可以在一整天内完美运行，直到第二天早上出现相同问题为止。同样，这种行为也不是100％一致的，我们并不是每天早上都真正看到它。但是，在一段时间内，我们连续4-5天一直在观察它。

问题似乎发生在工作时间早晨，即在更密集地访问UI /网页时。

有谁知道这是什么原因以及如何解决这个问题的线索？任何帮助将非常感激。

好吧，我有一些想法可能会导致这种现象。

1. 您是否监测自己的记忆力？也许您的查询提出了一定的限制，这将导致计划缓存的刷新。我不知道您的应用程序，但是该通讯员与您来自前端服务器的日志相对应吗？在这段时间里也有压力吗？
2. 您是否有专用的SQL Server或服务器是否与其他进程/服务共享其硬件？如果不是，请尝试考虑将您的SQL Server外包给专用计算机。这将减少其他服务的副作用。
3. 您可能要使用optimize for ad hoc workloads，它只会保存计划存根并在需要时进行编译。这将减少计划缓存的负载，从而降低计划缓存刷新的机会。您可以使用启用它sp_configure 'optimize for ad hoc workloads',1; reconfigure。如果启用了advanced optionsusing，则可以完成此操作sp_configure 'show advanced options',1; reconfigure。
4. 另一个想法可以是备份。只是简单的备份。如果它们很猛烈，则可能还会使您的机器承受压力。您提到的时间听起来像是计划备份的好时机。
5. 也许这很简单，就是维护脚本中的错误。您是否检查了是否存在导致脚本重新生成所有索引的逻辑问题，而不是仅导致符合条件的索引。这也可能导致它。

只是旁边这一切的可能性，它可能是检查的日志文件的一些更改选项很有用affinity mask，affinity I/O mask和他们的合作伙伴的x64。另一件事可以是更改MAXDOP实例选项。请也检查它们的日志。他们也需要刷新计划缓存。

最后但并非最不重要的一点是，您仍然可以运行服务器端跟踪（只需使用事件探查器对其进行设置，启动，停止它，然后使用sql命令在服务器端再次启动它）。在那旁边perfmon是你的朋友。它可以一段时间监视和监视您的性能值。也许您会发现服务器上某些动作与压力并行，这可能会导致刷新。

希望这对您有所帮助，即使稍后再回答也可以。