是否有任何选项可以查看查询存储中的已终止会话？
我在问，因为我们有一个额外的工具，如果会话运行时间超过 30 分钟（KILL命令），它就会终止会话。
我想检查查询存储中的执行计划是否有已终止的查询。我在查询存储会话/查询中找不到被这个附加应用程序杀死的。
我在查询存储中强制执行计划。计划与每天运行一次的作业中的程序相关联。这项工作的步骤之一就是：
EXEC [schema].[LoadData]
过程 [schema].[LoadData] 看起来像
TRUNCATE TABLE [schema].[Data];
INSERT INTO [schema].[Data]
([A1],
[A2],
.
.
.,
[A49]
)
SELECT *
,CURRENT_TIMESTAMP AS [Insert TimeStamp]
FROM [schema].[View]
其中 view 是一个包含一些 CTE 并使用同义词的视图（连接到来自不同数据库的表）。
在查询存储执行看起来像：
要测试强制计划是否有效，我按照以下步骤操作：
- 在 SSMS 中运行查询 ->
EXEC [schema].[LoadData] - 上面的执行被视为不同的查询，因此在查询存储中没有看到任何新的查询 = 7
- DBA 只需使用正在运行查询的步骤创建一个新作业 ->
EXEC [schema].[LoadData] - 运行上述新创建的工作原因计划 ID = 29800
质疑为什么不强制执行计划？在“强制计划失败计数”列中为 0。
我能够找到是否启用了查询存储：
SELECT name, is_query_store_on from sys.databases
我能够查询特定数据库以确定查询存储读/写状态：
SELECT actual_state_desc from sys.database_query_store_options
如何连接两个结果以将信息放在一个表中？他们没有共同的字段，我想我可以写一个CROSS JOIN来匹配这两个表，但我不确定如果没有那个共同的字段。
我现在做了几次都不成功。在 UI 中，我能够成功地将 Query Store Retention 设置中的查询存储大小从 250 提升到 1000 mb。我进行了更改，关闭数据库属性窗口，重新打开，看起来更改成功，显示 1000 mb。然后当我再次查看它时（可能是第二天左右），它又恢复到 250 mb。
版本为 Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4。
这里会发生什么？
我只对资源消耗感兴趣（QUERY_CAPTURE_MODE = AUTO），间隔相当短（例如INTERVAL_LENGTH_MINUTES = 5）。我将定期（例如每天）从查询存储中获取数据，检索以前未检索到的所有已完成间隔的统计信息。我担心的是文档说“基于大小的清理首先删除最便宜和最旧的查询”。 我当然想丢弃旧查询的统计信息（比我的检索间隔更早），但是如果在我尚未检索的时间间隔内执行了大量低资源查询，我不希望那些被丢弃，因为它们可以添加高达总消费量。
有什么方法可以强制删除旧查询的统计信息，或者我可以做些什么来确保在清理发生时它不会删除我尚未检索到的时间间隔的统计信息？
我在数据库上启用了查询存储。我有一个要跟踪的特定查询。我有很多关于 sp_BlitzCache 查询的详细信息（如 SQL 文本、SQL 句柄、SQL 哈希、计划缓存句柄/哈希等）。
我可以使用 sp_BlitzCache 中的信息搜索查询存储以追踪那里的查询吗？我想强制执行特定的执行计划，因为查询遇到参数嗅探问题。
我们正在使用 SQL Server 2016 标准版 (SP2-CU2)。我们有几台服务器，每台服务器托管几十到数百个数据库。我们从未在我们的数据库上启用查询存储。
我知道打开查询存储进行调优有很多好处。我想知道，是否存在不应该打开查询存储的情况？或者我应该在所有数据库上打开它吗？
已编辑
以防万一它可以帮助其他人。我最终所做的是启用查询存储一些数据库的时间，每天，并进行监控。到目前为止，我已经在我的几乎所有数据库上启用了查询存储，而没有任何性能影响。事实证明，它在调查问题时很有用。
我在网上广泛搜索，没有看到其他人发帖，所以我想我会的。我正在尝试审核查询存储何时进行清理并从查询存储中清除。
我发现有两个扩展的事件会话，我认为是事件，但即使查询存储清除了陈旧的查询数据，我也没有获取任何数据：
- query_store_db_cleanup_started
- query_store_db_cleanup_finished
想知道当查询存储清除其数据时，是否还有其他人遇到过同样的问题并且和我一样好奇？
以下是我用于设置当前审计的代码：
CREATE EVENT SESSION [QueryStore_Cleanup_Audit] ON SERVER ADD EVENT qds.query_store_db_cleanup__finished (ACTION ( package0.last_error, package0.process_id, sqlos.cpu_id, sqlos.system_thread_id, sqlos.task_time, sqlserver.client_app_name, sqlserver.client_connection_id, sqlserver.client_hostname, sqlserver.client_pid, sqlserver.context_info, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.server_instance_name, sqlserver.session_id, sqlserver.session_nt_username, sqlserver.sql_text, sqlserver.transaction_id, sqlserver.username ) WHERE ([database_id] = (5)) ), ADD EVENT qds.query_store_db_cleanup__started (ACTION ( package0.last_error, package0.process_id, sqlos.cpu_id, sqlos.system_thread_id, sqlos.task_time, sqlserver.client_app_name, sqlserver.client_connection_id, sqlserver.client_hostname, sqlserver.client_pid, sqlserver.context_info, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.server_instance_name, sqlserver.session_id, sqlserver.session_nt_username, sqlserver.sql_text, sqlserver.transaction_id, sqlserver.username ) WHERE ([database_id] = (5)) ) WITH ( MAX_MEMORY = 40096KB, EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS, MAX_DISPATCH_LATENCY = 30 SECONDS, MAX_EVENT_SIZE = 0KB, MEMORY_PARTITION_MODE = NONE, TRACK_CAUSALITY = OFF, STARTUP_STATE = ON ); GO query_store_db_cleanup_started
编辑 - 10/8/18 - 我终于能够通过 EE 跟踪清理事件！下面是我的代码，因为我缺少“query_store_plan_removal”和“query_store_size_retention_cleanup_update”EE 事件：
CREATE EVENT SESSION [QueryStore_Cleanup_Audit] ON SERVER ADD EVENT qds.query_store_db_cleanup__finished (ACTION ( package0.last_error, package0.process_id, sqlos.cpu_id, sqlos.system_thread_id, sqlos.task_time, sqlserver.client_app_name, sqlserver.client_connection_id, sqlserver.client_hostname, sqlserver.client_pid, sqlserver.context_info, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.server_instance_name, sqlserver.session_id, sqlserver.session_nt_username, sqlserver.sql_text, sqlserver.transaction_id, sqlserver.username ) ), ADD EVENT qds.query_store_db_cleanup__started (ACTION ( package0.last_error, package0.process_id, sqlos.cpu_id, sqlos.system_thread_id, sqlos.task_time, sqlserver.client_app_name, sqlserver.client_connection_id, sqlserver.client_hostname, sqlserver.client_pid, sqlserver.context_info, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.server_instance_name, sqlserver.session_id, sqlserver.session_nt_username, sqlserver.sql_text, sqlserver.transaction_id, sqlserver.username ) ), ADD EVENT qds.query_store_execution_runtime_info_discarded (ACTION ( sqlos.task_time, sqlserver.database_id, sqlserver.database_name, sqlserver.plan_handle, sqlserver.query_hash, sqlserver.session_id, sqlserver.sql_text, sqlserver.username ) ), ADD EVENT qds.query_store_flush_failed (ACTION ( sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.query_hash, sqlserver.query_plan_hash_signed, sqlserver.sql_text, sqlserver.username ) ), ADD EVENT qds.query_store_plan_removal (ACTION ( sqlos.task_time, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.query_plan_hash_signed, sqlserver.sql_text, sqlserver.username ) ), ADD EVENT qds.query_store_size_retention_cleanup_finished (ACTION ( sqlos.task_time, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.query_hash, sqlserver.query_plan_hash_signed, sqlserver.username ) ), ADD EVENT qds.query_store_size_retention_cleanup_skipped (ACTION ( sqlos.task_time, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.query_plan_hash_signed, sqlserver.session_id, sqlserver.sql_text, sqlserver.username ) ), ADD EVENT qds.query_store_size_retention_cleanup_started (ACTION ( sqlos.task_time, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.query_hash, sqlserver.query_plan_hash_signed, sqlserver.username ) ), ADD EVENT qds.query_store_size_retention_cleanup_update (ACTION ( sqlos.task_time, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.query_plan_hash_signed, sqlserver.sql_text, sqlserver.username ) ), ADD EVENT qds.query_store_size_retention_query_deleted (ACTION ( sqlos.task_time, sqlserver.database_id, sqlserver.database_name, sqlserver.nt_username, sqlserver.plan_handle, sqlserver.query_hash, sqlserver.sql_text, sqlserver.username ) ) WITH ( MAX_MEMORY = 40096KB, EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS, MAX_DISPATCH_LATENCY = 30 SECONDS, MAX_EVENT_SIZE = 0KB, MEMORY_PARTITION_MODE = NONE, TRACK_CAUSALITY = OFF, STARTUP_STATE = ON ); GO
我们有一个 SQL Server 2016 SP1 CU7 Enterprise 服务器，我们在其中启用了数据库上的查询存储。这是一个高度使用的数据库。
已Max Size设置为 200MB，Stale Query Threshold为 1 天。
我曾经sys.database_query_store_options检查过查询存储的属性，只要the current_storage_size_mb保持在 200MB 以下，一切都会完美无缺。
我已设置Size Based Cleanup Mode为自动，但没有进行清理，通常当查询存储已满 90% 时应触发清理。接下来发生的是查询存储进入只读模式，因为没有剩余可用空间。
我试过更改Query Store Capture Mode为自动但没有任何变化。
如果我随后更改Stale Query Threshold为 30 天，则actual_state_desc对 READ_WRITE 的更改和查询存储将再次开始捕获。这current_storage_size_mb只是变得比 高max_storage_size_mb，过了一会儿actual_state_desc又回到 READ_ONLY。
谁能解释这种行为？