标签: plan-cache

我试图了解跟踪标志 2861 以及它对琐碎查询的实际作用？

简介说：

SQL Server 通常不会缓存这些简单查询的计划，因为缓存计划的成本高于为此类简单查询生成新计划的成本。

这显然是不正确的，因为我运行的每个“琐碎”查询似乎都被缓存了。所以我想知道 2861 的意义是什么，除非我误解了一个微不足道的计划实际上是什么。当我查询缓存计划并且它说它是临时的和微不足道的时，我没有理由怀疑它。

希望有人能给我解惑。

每隔几分钟到大约一小时，进程缓存就会被刷新（但不是完全！）。如果我运行：

SELECT count (*) FROM sys.dm_exec_cached_plans

……刚刚清零之后，计划的数量下降到几百个，然后逐渐增加到大约2000个，然后再次清零，依此类推。

服务器在 VMWare 上运行，它有128 GB的 RAM（SQL Server 最大服务器内存设置为102 GB，最小服务器内存设置为72 GB）。根据 SentryOne 的输出，我可以看到缓冲池消耗了~61 GB。我没有看到任何内存压力指标。

我还观察到，当我将最小服务器内存减少到 16 GB 时，进程缓存清除的频率急剧增加。

我的SQL Server版本如下：

Microsoft SQL Server 2016 (SP1-CU3) (KB4019916) - 13.0.4435.0 (X64)

还有什么：

• 我还没有尝试过 LPIM，因为它需要重新启动 SQL Server，但即使它是解决方案，我也很想了解为什么会发生这个问题。此外，Brent建议它仅在缓冲池修整的情况下有帮助。在我的情况下，缓冲池看起来完好无损，只有 proc 缓存受到影响。
• 我没有找到任何可以对此负责的工作，也找不到任何真正的模式。
• 如果有人发现这对修复/调查此问题有用，我可以访问 vCenter。但如果是这种情况，请您告诉我我应该在那里检查什么。

我怀疑 VMWare 可能在这里扮演了一些角色，但是当我检查来宾端可用的 perfmon 计数器时，我没有发现任何可疑的东西。

我还根据Brent 的建议收集了sp_Blitz的输出：

**Priority 10: Performance**:

- Query Store Disabled - The new SQL Server 2016 Query Store …

我有一个较早执行缓慢的查询。后来我发现它没有并行运行，这使得查询执行速度变慢。

查询涉及一个 big view，然后使用大量temp tablesand查询视图sub query。

我UDF从视图中删除了一个并使用inline functions并使用了一个标量TVF，然后它开始在parallel execution.

这几天一切顺利，有一天我注意到查询运行缓慢。于是查了一下执行计划，发现查询是在串行模式下执行的。我检查了查询的计划缓存，我看到了很多涉及该视图的缓存计划。我删除了不并行的计划，然后查询运行得很快。

现在我每天早上都这样做以强制查询并行运行。

额外细节：

1. SQL Server 2016 标准版
2. 查询通过 LINQ-SQL 从 dot net 应用程序生成。所以临时查询。

如何强制查询永远并行运行？

运行 SQL Server Express 2019。

有一个包含 11 条 sql 语句的复杂存储过程（当从sys.dm_exec_query_statsby 中选择时plan_handle）。

其中 9 个语句是基于传入参数的简单变量设置，最后 2 个语句 ( IF/ELSE) 完成所有工作并返回数据（例如query_hash0x111... 和 0x222...）。

基于输入参数的数据量有很大的可变性，所以我用最佳值“准备”存储过程以确保快速执行。

我注意到每隔几天（有时更频繁），我的最后 2 个语句（query_hash0x111...和 ​​0x222...）被转储sys.dm_exec_query_stats，然后根据下一个存储过程中来自用户的任何参数重新生成称呼。

我通过查看creation_time列知道这一点，它反映了前 9 个查询的“启动”时间，以及query_hash0x111... 和 0x222...的稍后时间。

据我了解，缓存计划在内存压力下被清除，较少使用的计划首先被清除。我的查询被大量使用，并且我有很多其他缓存计划，其中 1 次执行会持续一段时间。

问题：为什么我最常用的查询会转储表单缓存，我该如何阻止它发生？

即使对于相同的查询，计划缓存和查询存储也不相同。当寻找特定查询或一组相关查询的性能或监视信息时，每个查询的优点/缺点是什么？

我的在线研究表明的总体​​印象是，查询存储可以比计划缓存更快地查询（我不确定为什么），并且它的条目往往持续更长时间（这是可配置的），但我没有发现任何说法关于计划缓存优于查询存储的情况。

假设我不关心 SQL Server 2017 和 2022 引入的使用查询存储进行自动性能调优的功能。相反，假设我比较查询存储和计划缓存是出于两者可以执行的任务的目的。

我正在尝试找出具有Probe Residual.

需要了解以下内容

1. 哪个物理和逻辑运算符有这个 Probe Residual
2. 查询中该运算符的成本百分比是 多少
3. 相关执行计划
4. 查询文本

以下是我的一次尝试——但我被困在获取其他细节上。如何获取这些详细信息？

注意：我使用的是 SQL Server 2012

WITH XMLNAMESPACES
(
    DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan'
)
SELECT
    DECP.cacheobjtype,
    DECP.objtype,
    DECP.plan_handle,
    DEQP.objectid,
    DEQP.query_plan,
    DEST.[text]
FROM sys.dm_exec_cached_plans AS DECP
CROSS APPLY sys.dm_exec_query_plan(DECP.plan_handle) AS DEQP
CROSS APPLY sys.dm_exec_sql_text(DECP.plan_handle) AS DEST
WHERE
    1 = DEQP.query_plan.exist(
        '//RelOp[
            @PhysicalOp = "Hash Match"
            ]')

甲探头残余例

下面引用 Grant Fritkey 和 Rob Farley 的博客/文章

1. 哈希匹配上的探针残差 - 可怕的 DBA 之家
2. 当你有一个哈希匹配时探测残差——执行计划中的隐藏成本

当存储过程在任何时候从管理工作室运行良好时，我正在对这种情况进行故障排除，但即使对于相同的参数，相同的存储过程在其中一个网络服务器中运行得非常糟糕。可能有一些原因导致这种情况，包括阻塞等。

我想排除使用不同 SET 选项创建 2 个不同计划的可能性，并且这些计划中至少有一个使用产生错误计划的参数组合进行了优化。

引用本杰明·内瓦雷斯：

“一般来说，查询优化是一个代价高昂的操作，为了避免这种优化成本，计划缓存会尽量将生成的执行计划保存在内存中，以便它们可以被重用。但是，如果一个新的连接运行相同的存储过程有不同的SET选项，它可能会生成一个新的计划……”

为了解决这个问题，我想要一个 T-SQL 查询，它会显示为会话设置的所有值。

这可能吗？

以下 SET 选项将影响执行计划的重用：

（他们中的一些）

DATEFORMAT
LANGUAGE
NUMERIC_ROUNDABORT
FORCEPLAN

我有一个用于许多报告查询的表。我想知道以“有序”方式读取表格的次数。在聚集索引扫描的执行计划中，可以看到读取是否“有序”。此信息是否在其他地方可用，或者是搜索计划缓存的唯一解决方案？

我是 SQL 执行计划的新手，我正在尝试了解更多有关它们的信息。

我有几个问题。

1. SQL执行计划在内存中保留多长时间？如果我断开连接，下次就无法使用了？有什么办法可以改变这个吗？
2. 我可以导出执行计划并在下次重新连接到 SQL Server 时将其加载到内存中以绕过查询优化器并节省时间吗？

我们正在解决性能问题，需要维护执行计划以进行故障排除。需要维护执行计划并确保计划缓存在升级到 2019 时不会被刷新。

升级期间计划缓存是否会被清除？有没有办法维护并确保执行计划不被清除？

昨天，我运行了一个大型临时查询，但没有保存。今天，我想再看一遍。我想我应该在计划缓存中寻找。令我惊讶的是，我可以找到较旧的查询和较新的查询，但找不到我运行的查询。为什么会这样？

我知道我应该打开查询存储，但我还没有这样做。

通常 sp_execute sql 将重用缓存的计划，其中 EXEC 将为每个参数创建新计划。

在此示例中，两个查询都使用 sp_executesql - 第二个查询导致计划缓存中的计划数量较少的原因是什么？

查询1：

查询2：