Questions tagged «query-store»

SQL Server 2016中引入的查询存储功能可收集执行计划和运行时性能指标，以进行分析，故障排除和测试。

1
SQL Server 2016错误查询计划每周锁定数据库一次
在过去的5周中，大约每天的同一时间（清晨，可能取决于人们开始使用时的用户活动），每周一次，SQL Server 2016（AWS RDS，已镜像）开始超时查询。 所有表上的UPDATE STATISTICS始终会立即对其进行修复。 第一次之后，我让它每晚（而不是每周）更新所有表上的所有统计信息，但是仍然发生（更新统计信息运行后大约8小时，但并非每天运行）。 上一次，我启用了查询存储，以查看是否可以找到具体的查询/查询计划。我想我可以将其缩小到一个： 找到该查询后，我添加了一个推荐索引，该索引在此不常用的查询中丢失了（但它确实涉及很多常用表）。 错误的查询计划正在执行索引扫描（在只有1万行的表上）。不过，其他返回的查询计划（以毫秒为单位）也用于进行相同的扫描。创建新索引后，最新查询计划仅查找。但是，即使没有该索引，也有99％的时间在几毫秒内返回了索引，但是每周要花40秒以上的时间。 超时的坏消息：http : //brentozar.com/pastetheplan/?id=rymaWt56e 以前不会超时的计划：http : //brentozar.com/pastetheplan/?id=HyN7ftcpe 具有新索引的最新计划：http : //brentozar.com/pastetheplan/?id=ryLuGKcag 从2012年迁移到SQL Server 2016之后，这种情况开始发生。 DBCC CHECKDB不返回任何错误。 新索引会解决问题，使其不再选择错误的计划吗？ 我应该“强制”现在行之有效的计划吗？ 如何确保其他查询/计划不会发生这种情况？ 这是更大问题的征兆吗？ 我刚刚添加的索引： CREATE NONCLUSTERED INDEX idx_AppointmetnAttendee_AttendeeType ON [dbo].[AppointmentAttendee] ([UserID],[AttendeeType]) CREATE NONCLUSTERED INDEX [idx_appointment_start] ON [dbo].[Appointment] ( [ProjectID] ASC, [Start] ASC ) INCLUDE ( …
1
强制性的可读二级计划
如果计划是针对可用性组中的主数据库执行的，则该计划是否适用于在辅助数据库上运行的查询？ 我正在寻找涵盖计划强制的两种可能性的答案： 计划指南 查询存储强制计划 我阅读了以下内容，这些内容表明QS强制计划不会继续存在，但找不到文档中的权威内容或有关计划指南的任何内容。 Erin Stellato的查询存储和可用性组 在 Vikas Rana的AlwaysOn可读辅助数据库上查询数据存储强制计划行为 强迫的结论性证据将是二级执行计划中存在Use Plan或PlanGuideName和PlanGuideDB属性。
1
查询存储强制计划功能不起作用
查询存储强制计划功能似乎没有执行该计划。 我知道查询存储-强制并不总是意味着强制；但是，我的计划可能不会发生重大变化，但是查询优化器可能会继续选择错误的索引，循环选择等。 基本上：它不符合我的强制计划选择。我强迫了许多计划，但没用。 当我查看时，有0个失败计数或原因sys.query_store_plan force_failure_count。 扩展事件query_store_plan_forcing_failed不会产生任何结果。0活动。 例如，一个计划在20.09开始实施。只有1次编译碰巧使用了强制计划。 这些计划大相径庭，一个计划与INDEX 1一起使用哈希匹配联接，另一个计划与INDEX 2一起使用循环联接。 版本：Microsoft SQL Server 2016（SP1-GDR）（KB3210089）-13.0.4202.2（X64） 我在这里想念什么？
1
什么是SQL的“难提词”？
什么是SQL的“无提词”？ 我正在阅读sys.query_store_query_text（Transact-SQL），看到了以下内容，因此我在Google {SQL“ unmentionable”一词}上进行了搜索 has_restricted_text 位 查询文本包含密码或其他不易提及的单词。 其他3个链接将我带回到找到它的位置，我找不到任何看起来与密码相关的内容或SQL可能关心的任何内容。
1
为什么不能使用sys.query_store_plan加入消除功能？
以下是查询存储遇到的性能问题的简化： CREATE TABLE #tears ( plan_id bigint NOT NULL ); INSERT #tears (plan_id) VALUES (1); SELECT T.plan_id FROM #tears AS T LEFT JOIN sys.query_store_plan AS QSP ON QSP.plan_id = T.plan_id; 该plan_id列被记录为的主键sys.query_store_plan，但是执行计划未按预期使用联接消除： 没有从DMV投影任何属性。 DMV主键plan_id不能复制临时表中的行 使用A LEFT JOIN，因此无法T消除中的任何行。 执行计划 为什么会这样？在这里如何做才能消除连接？
2
永不结束查询存储搜索
我从一开始说，我的问题/问题类似于此之前的一个，但因为我不知道的原因或起始信息是一样的，我决定后，我的问题有一些更多的细节。 当前问题： 在一个奇怪的时刻（工作日临近结束），生产实例开始出现异常行为： 实例的CPU较高（从约30％的基准开始，它增加了约一倍，并且仍在增长） 每秒增加的事务数（尽管应用程序负载未发生任何变化） 空闲会话数增加 从未显示此行为的会话之间发生奇怪的阻止事件（即使读取未提交的会话也导致了阻止） 等待间隔的最长时间是第一页上的非页面锁，第二名是锁 初步调查： 使用sp_whoIsActive，我们看到了由监视工具执行的查询决定运行速度非常慢，并占用大量CPU，这在以前是没有发生的。 隔离级别未提交； 我们查看了看到古怪数字的计划：StatementEstRows =“ 3.86846e + 010”，其中约150 TB的估计数据已返回 我们怀疑原因是监视工具的查询监视功能引起了，因此我们禁用了该功能（我们还与提供程序一起打开了一张票证，以检查他们是否知道任何问题） 从第一个事件开始，它又发生了几次，每次我们终止会话时，一切都恢复正常； 我们意识到查询极为相似的一个查询在BOL使用MS用于查询存储监测-查询，最近在性能倒退（在时间上比较不同点） 我们手动运行相同的查询并看到相同的行为（使用的CPU不断增加，闩锁等待时间增加，意外锁定等。） 有罪查询： Select qt.query_sql_text, q.query_id, qt.query_text_id, rs1.runtime_stats_id AS runtime_stats_id_1, interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), p1.plan_id AS plan_1, rs1.avg_duration AS avg_duration_1, rs2.avg_duration AS avg_duration_2, p2.plan_id AS plan_2, interval_2 = …
4
SQL Server查询存储-什么是“临时”查询？
我一直在深入研究SQL Server查询存储，并且经常看到对“临时”查询的引用。但是，我还没有看到查询存储确定什么是即席查询。我已经看到了可以将其推断为没有参数的查询或仅执行一次查询的地方。为此是否存在正式定义？我的意思不是一般。我的意思是，它与查询存储有关。 例如，此页面显示了一个从查询存储中删除临时查询的示例，但是它所使用的条件似乎是执行计数仅为一个。这似乎是临时查询的奇怪定义。顺便说一句，如果您转到页面，请搜索“删除临时查询”。
2
在msdb上启用查询存储有什么好处？
在SQL系统数据库（主数据库，模型数据库，msdb数据库，tempdb数据库）中，查询存储只能在msdb上使用。我查看了，没有找到有关msdb上查询存储的任何文档。 虽然您无法在GUI中看到它，但可以在您的SQL 2016实例上对其进行验证 验证查询存储已关闭 USE msdb SELECT * FROM sys.database_query_store_options; 开启查询存储 USE [master] GO ALTER DATABASE msdb SET QUERY_STORE = ON GO ALTER DATABASE msdb SET QUERY_STORE (OPERATION_MODE = READ_WRITE , INTERVAL_LENGTH_MINUTES = 30 , MAX_STORAGE_SIZE_MB = 1000 , QUERY_CAPTURE_MODE = AUTO) GO 验证查询存储已打开 USE msdb SELECT * FROM sys.database_query_store_options; …
1
SQL Server查询存储是否捕获参数值？
SQL Server 2016中引入的新查询存储很棒。它是我以前使用较旧的Profiler工具所做的大部分工作的理想替代品。但是，我还没有找到一种方法来捕获与嗅探到的高资源消耗查询的各个调用相关的参数值。这可能吗？ 我知道查询存储处理的是聚合数据而不是单个调用，因此我怀疑我在这里可能不走运。当我发现一个慢查询时，我发现它很方便进行故障排除，使其参数也与其最慢的调用之一相关联。我想知道如何使用最新最好的工具来执行此操作。（我不会错过使用Profiler！） 从安全角度来看，查询存储的锁定程度是否低于Profiler？我认为它需要从某个级别的单个调用中捕获数据才能计算聚合。只是不确定是否存储了其中的任何一个。
1
由查询存储引起的阻塞。无法清除或禁用
我最近将2016 SQL Server更新为SP2，并于2018年8月发布了最新的CU（KB4458621）。就在最后一天左右，我注意到我正在进行一些阻止。我无法杀死SPID b / c，这不是用户进程。根据SP_WHO2，命令为“查询存储ASYN”。我尝试通过Script和UI清除数据并禁用查询存储。似乎没有任何效果，它只是旋转然后开始引起更多阻塞。还有其他人遇到这个问题吗？谁能帮我弄清楚如何成功禁用查询存储吗？SP_WhoIsActive @show_System_SPIDS =以下1个结果（仅查询存储结果） 更新-这现在导致TempDB驱动器填满。尝试在几个小时后重新启动，看看是否可以解决问题。会及时向大家发布。 谢谢，内特
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.