【问题标题】:SQL Server 2008 plan cache is almost always emptySQL Server 2008 计划缓存几乎总是空的
【发布时间】:2016-04-21 05:46:36
【问题描述】:

为了调查查询计划的使用情况,我试图了解内存中存储了哪种查询计划。

使用这个查询:

SELECT objtype AS 'Cached Object Type', 
COUNT(*) AS 'Numberof Plans', 
SUM(CAST(size_in_bytes AS BIGINT))/1048576 AS 'Plan Cache SIze (MB)', 
AVG(usecounts) AS 'Avg Use Counts' 
FROM sys.dm_exec_cached_plans 
GROUP BY objtype  
ORDER BY objtype 

我的计划缓存结构几乎是空的。 .

服务器上有 128Gb 的 RAM,大约 20% 是空闲的。 SQL Server 实例不受内存限制。

是的,基本上我有即席查询(未参数化,未存储过程)。 但是为什么 SQL Server 如此频繁地清空查询计划缓存呢?我有什么样的问题?

【问题讨论】:

  • 我不太清楚。但我能猜到几件事,就像你们大多数人都在使用 WITH RECOMPILE 或者大多数 proc 是动态的。
  • @KumarHarsh 不。我没有使用 WITH RECOMPILE 也没有使用动态 SQL。
  • 您是否设置了“特别优化”设置?
  • @AllanS.Hansen 没有。它设置为false

标签: sql-server sql-server-2008


【解决方案1】:

最后,只有实例重启解决了我的问题。现在计划缓存看起来更健康了。

【讨论】:

    【解决方案2】:

    如果服务器没有内存压力,那么plan caching white paper 的其他一些可能性如下。

    这些操作是否经常安排?是否启用了自动关闭功能?

    以下操作会刷新整个计划缓存,因此, 导致首次提交的批次的新编译 之后:

    1. 分离数据库
    2. 将数据库升级到 SQL Server 2005
    3. 将数据库升级到 SQL Server 2008
    4. 恢复数据库
    5. DBCC FREEPROCCACHE 命令
    6. 重新配置命令
    7. ALTER DATABASE ,,, MODIFY FILEGROUP 命令
    8. 使用 ALTER DATABASE … COLLATE 命令修改排序规则

    以下操作会刷新计划缓存条目,这些条目引用 特定的数据库,并在之后引起新的编译。

    1. DBCC FLUSHPROCINDB 命令
    2. ALTER DATABASE … MODIFY NAME = 命令
    3. ALTER DATABASE … SET ONLINE 命令
    4. ALTER DATABASE … SET OFFLINE 命令
    5. ALTER DATABASE … SET EMERGENCY 命令
    6. 删除数据库命令
    7. 数据库自动关闭时
    8. 使用 CHECK OPTION 创建视图时,会刷新创建视图的数据库的计划缓存条目。
    9. 运行 DBCC CHECKDB 时,会创建指定数据库的副本。作为 DBCC CHECKDB 执行的一部分,一些针对 副本被执行,它们的计划被缓存。在 DBCC 结束时 CHECKDB 的执行,副本被删除,查询计划也被删除 对副本提出的查询。

    以下sp_configure/reconfigure操作also clear the procedure cache

    • 访问检查缓存桶计数
    • 访问检查缓存配额
    • 已启用 clr
    • 并行性的成本阈值
    • 跨数据库所有权链接
    • 索引创建内存
    • 最大并行度
    • 最大服务器内存
    • 最大文本复制大小
    • 最大工作线程数
    • 每个查询的最小内存
    • 最小服务器内存
    • 查询调速器成本限制
    • 查询等待
    • 远程查询超时
    • 用户选项

    【讨论】:

    • 没有。这些操作未安排。
    • 并且自动关闭设置为 false。
    • sys.dm_exec_query_stats 中的最小创建时间是多少?那个时候服务器里有什么日志吗?应用程序发送的任何查询是否会发送重新配置或任何其他问题命令?
    • 最小创建时间就是现在。服务器日志中没有可疑活动,应用程序不会发送问题命令。
    • 该服务器上的其他实例感觉不错。而且他们的查询计划缓存非常持久。
    【解决方案3】:

    大约一周前我遇到了同样的问题,并且还发布了几个问题。尽管我实际上还没有找到问题的答案,但我对这个过程有了一些了解。听起来很愚蠢,SQL Server 服务重新启动有助于但引发了另一个问题 - 恢复过程持续了 4 小时。似乎有一笔相当大的交易已经到位......

    empty-plan-cache-problem

    Almost empty plan cache

    Almost empty plan cache

    【讨论】:

      猜你喜欢
      • 2014-06-20
      • 1970-01-01
      • 2011-03-22
      • 1970-01-01
      • 2018-01-14
      • 2011-03-06
      • 1970-01-01
      • 1970-01-01
      • 2012-01-09
      相关资源
      最近更新 更多