SQL Server定期清除计划缓存和执行状态

将SQL Server 2014升级到2016后，服务器每隔几个小时会不断重置缓存的执行计划和dm*视图（如dm_exec_query_stats）等。

就像有人执行DBCC FREEPROCCACHE并DBCC DROPCLEANBUFFERS手动执行一样（除了没有人执行之外，它会自动发生）。

相同的数据库在SQL Server 2014和Windows Server 2012上都可以正常工作，在迁移到SQL Server 2016（和Windows Server 2016）之后一切都变了。

事情我检查：数据库并没有具备“自动关闭”标志。SQL Server ad hoc optimized设置为true（我认为这会有所帮助，但没有帮助）。“查询存储”为“关闭”。服务器有16 GB内存。

“ SQL Server日志”中也没有任何帮助。只是每周的备份消息...

我还检查了这篇文章https://docs.microsoft.com/zh-cn/sql/t-sql/statements/alter-database-transact-sql-set-options（向下滚动到“示例”部分，并在上面它）有自动清除计划的情况清单。这些都不适用。

更新：

不幸的是，这些建议都没有帮助。授予LPIM权限，检测并修复为同一查询生成大量计划的非参数化查询，从而降低“最大服务器内存” ...计划保持随机重置，从每隔几个小时到每5-10分钟一次。如果服务器“内存不足”，那么2014版在同一台机器上运行正常。

这是请求的sp_Blitz输出

**Priority 10: Performance**:

- Query Store Disabled - The new SQL Server 2016 Query Store feature has not been enabled on this database.

    * xxx


**Priority 50: Server Info**:

- Instant File Initialization Not Enabled  - Consider enabling IFI for faster restores and data file growths.


**Priority 100: Performance**:

- Resource Governor Enabled  - Resource Governor is enabled.  Queries may be throttled.  Make sure you understand how the Classifier Function is configured.


**Priority 120: Query Plans**:

- Implicit Conversion Affecting Cardinality - One of the top resource-intensive queries has an implicit conversion that is affecting cardinality estimation.

    * 

- Missing Index - One of the top resource-intensive queries may be dramatically improved by adding an index.

    * 

- RID or Key Lookups - One of the top resource-intensive queries contains RID or Key Lookups. Try to avoid them by creating covering indexes.

    * 

**Priority 170: File Configuration**:

- System Database on C Drive
    * master - The master database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * model - The model database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * msdb - The msdb database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.


**Priority 200: Backup**:

- MSDB Backup History Not Purged msdb - Database backup history retained back to Jun 10 2017  9:47PM


**Priority 200: Informational**:

- Backup Compression Default Off  - Uncompressed full backups have happened recently, and backup compression is not turned on at the server level. Backup compression is included with SQL Server 2008R2 & newer, even in Standard Edition. We recommend turning backup compression on by default so that ad-hoc backups will get compressed.


**Priority 200: Non-Default Server Config**:

- Agent XPs  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- max server memory (MB)  - This sp_configure option has been changed.  Its default value is 2147483647 and it has been set to 15000.

- optimize for ad hoc workloads  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- show advanced options  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- xp_cmdshell  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.


**Priority 200: Performance**:

- Buffer Pool Extensions Enabled  - You have Buffer Pool Extensions enabled, and one lives here: Z:\sql_buffer_pool.BPE. It's currently 60.00000000000 GB. Did you know that BPEs only provide single threaded access 8KB (one page) at a time?

- cost threshold for parallelism  - Set to 5, its default value. Changing this sp_configure setting may reduce CXPACKET waits.

**Priority 240: Wait Stats**:

- No Significant Waits Detected  - This server might be just sitting around idle, or someone may have cleared wait stats recently.

**Priority 250: Informational**:

- SQL Server Agent is running under an NT Service account  - I'm running as NT Service\SQLSERVERAGENT. I wish I had an Active Directory service account instead.

- SQL Server is running under an NT Service account  - I'm running as NT Service\MSSQLSERVER. I wish I had an Active Directory service account instead.

**Priority 250: Server Info**:

- Default Trace Contents  - The default trace holds 125 hours of data between Aug 19 2017 11:55AM and Aug 24 2017  4:59PM. The default trace files are located in: C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log

- Hardware  - Logical processors: 2. Physical memory: 15GB.

- Hardware - NUMA Config  - Node: 0 State: ONLINE Online schedulers: 2 Offline schedulers: 0 Processor Group: 0 Memory node: 0 Memory VAS Reserved GB: 29

- Locked Pages In Memory Enabled  - You currently have 12.02534484863 GB of pages locked in memory.

- Memory Model Unconventional  - Memory Model: LOCK_PAGES

- Server Last Restart  - Aug 20 2017 12:32PM

- Server Name  - xx

- Services
 - Service: SQL Full-text Filter Daemon Launcher (MSSQLSERVER) runs under service account NT Service\MSSQLFDLauncher. Last startup time: not shown.. Startup type: Manual, currently Running.

 - Service: SQL Server (MSSQLSERVER) runs under service account NT Service\MSSQLSERVER. Last startup time: Aug 20 2017 12:32PM. Startup type: Automatic, currently Running.

 - Service: SQL Server Agent (MSSQLSERVER) runs under service account NT Service\SQLSERVERAGENT. Last startup time: not shown.. Startup type: Automatic, currently Running.

- SQL Server Last Restart  - Aug 20 2017 12:33PM

- SQL Server Service  - Version: 13.0.4446.0. Patch Level: SP1. Edition: Enterprise Edition (64-bit). AlwaysOn Enabled: 0. AlwaysOn Mgr Status: 2

- Virtual Server  - Type: (HYPERVISOR)

- Windows Version  - You're running a pretty modern version of Windows: Server 2012R2 era, version 6.3


**Priority 254: Rundate**:

 - Captain's log: stardate something and something...

首先，获取清除计划缓存的确切时间。这是最简单的方法-它应该几乎立即运行，并且不会阻止任何人：

SELECT TOP 1 creation_time
FROM sys.dm_exec_query_stats WITH (NOLOCK)
ORDER BY creation_time;

如果您认为该日期/时间比您预期的要早，则仅清除计划缓存的一部分。例如，也许有人正在执行索引重建或更新统计信息工作，这将刷新受影响的特定对象的计划缓存-但其他对象仍会存在。当系统查询（例如DMV查询）仍然存在时，我会看到很多东西，但是用户数据库计划却清晰明了。

如果该日期/时间按特定的时间间隔更新，例如似乎每2小时精确更新一次，例如说6：00、8：00、10：00等，则可能有人正在运行某个作业或查询，导致计划缓存清除。一旦知道确切的频率，就可以：

• 查看您的工作计划，看看在此间隔内运行什么
• 在该时间段内运行Profiler跟踪或Extended Events跟踪以找出奥秘（我通常不喜欢在生产中进行跟踪，但是如果您确切知道杀手何时出击，则很容易发出警报。 -正在运行的开销示例）
• sp_WhoIsActive在此期间登录到表（最简单的方法，但是将其范围缩小到导致它的确切查询的可能性最小）

如果每次运行查询时该日期/时间都在不断变化，则服务器可能处于内存压力之下。运行此命令以生成基本的健康检查信息，然后您可以将其复制/粘贴到您的Stack问题中，以便我们进行诊断：

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1, @CheckUserDatabaseObjects = 1

（公开：我是的作者之一sp_Blitz。）

使用您的sp_Blitz数据更新了2017/08/25-感谢您运行sp_Blitz并将其添加到您的问题中，它确实有助于显示一些内容。您正在具有2个核心和16GB RAM的VM上运行SQL Server 2016 Enterprise Edition。首先，关于许可的简要说明：如果您是由来宾进行许可的，则最低购买要求是4核，而不是2核。（有关更多详细信息，请参阅《SQL Server许可指南》。）Enterprise Edition的4核约为$ 28K USD ，而仅在16GB RAM上花费大量许可费用是很不寻常的。如果您要在主机级别上许可SQL Server Enterprise Edition，则可以忽略它并运行较小的VM。

看起来您的SQL Server受到外部内存的压力。您拥有16GB的RAM，并且已将最大服务器内存设置为15GB。不幸的是，操作系统剩余的1GB内存还不够（加上您将要在该操作系统上运行的任何其他软件，例如备份软件和SSMS。）在《 SQL Server安装指南》中，我们建议保留4GB或10％的可用空间，以任何一个为准更大-在您的情况下为4GB，因此您的最大服务器内存设置应为12GB，而不是15GB。

当前的内存分配中显示了更多证据：您已锁定内存中的页面（LPIM），但是您只有12.02GB的页面已锁定在内存中。这可能（但不能保证）意味着其他应用程序需要内存，因此Windows发送了内存压力通知，而SQL Server放弃了其他3GB的内存，让其他应用程序执行此操作。更有力的证明，您不能真正使用最大15GB的存储空间-您需要内存来存储其他内容。

当您的SQL Server受到外部内存压力并且需要释放内存供其他应用程序使用时，您的计划缓存将受到影响。

因此，您有几种选择：

• 适当设置最大内存 -例如12GB（如果要在服务器上运行其他应用程序，则更低。）这样，SQL Server不必大肆出售内存并清除东西，而不必因为其他原因应用需要2-3GB的RAM-它已经可用
• 停止在服务器上运行其他应用程序 -如果其他系统管理员远程桌面化并运行SSMS之类的东西，这可能会很困难。我已经为打开的RDP会话数设置了Perfmon计数器警报，并在它不是0时发出警报-这可以帮助抓住问题的根源。
• 向VM添加更多内存 -但我认为您并不是真正需要它。sp_Blitz报告显示“没有发现重大等待”的一些证据。我认为您不会承受频繁的内存压力，尤其是因为您报告说它只会不时发生。这是成本效益最低的选择。

好的，在这里，我终于通过将SQL Server 2016更新到最新版本来解决此问题。我有SP1，昨天我安装了Cumulative Update 6。

我也像布伦特的答案所建议的那样适当地设置“最大内存”。顺便说一句好答案，我敦促每个人都赞成它。

已经过了36个小时，而且还没有结算计划。

Brent Ozar在这里也有一个非常不错的网站：https ://sqlserverupdates.com/ 来帮助确定您需要哪些更新。

另一件事是帮助检测并解决了“不受信任的外键”问题。布伦特有一篇非常好的文章（哈哈，是的，布伦特，我知道是对的），关于如何解决它，只是谷歌，他是第一名

我在家庭测试框中遇到了这个问题，我发现通过向SQL Server服务帐户添加“内存中的锁定页面”权限可以解决此问题，但是我不确定这是否是最佳建议。

请参阅在内存选项中启用锁定页面（Windows）