我们一直遇到 SQL Server 的内存问题。
当我们开始出现超时和登录错误时，我们首先意识到我们遇到了问题：
已成功与服务器建立连接，但随后在登录过程中出现错误。（提供者：TCP 提供者，错误：0 - 指定的网络名称不再可用。）
在我们的 sqlbox 上查看事件查看器，我们注意到大量内存不足错误：
系统内存不足，无法运行此查询。
有关详细信息，请参阅http://go.microsoft.com/fwlink/events.asp 上的帮助和支持中心。
在此之前唯一的即时警告是以下消息：
AppDomain 119 (Alerts.dbo[runtime].118) 已卸载。
在此之前大约 20 分钟，我们收到了许多与性能相关的消息和错误：
信息：
此计算机上的 Microsoft Operations Manager 代理从其 MOM 服务器收到新规则和配置设置。管理组：GGC警告：
“ASP”服务的性能库“C:\WINDOWS\system32\aspperf.dll”的配置信息与存储在注册表中的可信性能库信息不匹配。此库中的函数不会被视为受信任的。错误：
Microsoft Operations Manager 性能提供程序无法访问计算机上的性能计数器等等。Microsoft Operations Manager 不会监视这台计算机上的性能计数器，直到它们可用。信息：
Microsoft Operations Manager 在上次失败后成功加载了计算机上的性能计数器，并将开始监视它们。
我怀疑上面的性能警报/错误与两个小时的“内存不足异常”有什么关系，但为了以防万一，我已经包含了这些消息。
最后，经过两个小时的红色内存错误后，以下信息消息预示着内存不足警报的结束：
由于“DBCC FREEPROCCACHE”或“DBCC FREESYSTEMCACHE”操作，SQL Server 遇到了 2 次出现“绑定树”缓存存储（计划缓存的一部分）的缓存存储刷新。
所以我们的 DBA 在某个时候调用了 freeprocache。尽管最终修复了内存不足的异常，我们注意到我们的执行计划仍然没有被存储。这个“问题”现在已经持续了整整 3 天，这意味着使用具有复杂计划的查询的应用程序面临着严重的性能困难。在某些情况下，计划开始再次被采用，但它们不会在缓存中停留很长时间。
我想知道是否有人可以帮助确定关注的领域。
A 部分代表查询计划被保留时的系统（计划被保留，但只保留一个小时左右），B 部分代表计划根本没有被缓存（检查 dm_exec_query_stats）
甲部
DBCC MemoryStatus 结果：
Memory Manager KB
VM Reserved 1828768 …