几周前，我确实在我们的一个主要环境中运行了从 SQL Server 2016 到 SQL Server 2017 CU 5 的就地升级。我使用了 Slipstream 升级，所以它是一枪。这是一个 2 节点共享存储 FCI，具有单个实例和远程数据中心上的 1 个副本（因此总共 2 个实例，1 个 AG，AG 中的多个数据库，异步）。升级基本没问题
下一步是在最关键的数据库（2 TB 数据文件、100 GB Tr 日志文件、高负载）中启用查询存储和自动查询调整。这是升级的主要目的之一
几天后，我注意到该数据库的事务日志使用率约为 80%，并且还在增长。Log_reuse_wait_desc 是 ACTIVE_TRANSACTION
运行 DBCC OPENTRAN 并得到以下结果
数据库“MyDatabase”的事务信息。
最早的活动事务：SPID（服务器进程 ID）：62s UID（用户 ID）：-1 名称：QDS 嵌套事务 LSN：（6017515:1461640:1）开始时间：2018 年 4 月 9 日 3:01:06:073AM SID：0x0 DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。
这是会话 ID 62
spid kpid blocked waittype waittime
lastwaittype waitresource dbid uid cpu
physical_io memusage login_time
last_batch ecid open_tran status sid
hostname program_name hostprocess cmd nt_domain
nt_username net_address net_library loginame
context_info sql_handle stmt_start stmt_end
request_id 62 -12076 21 0x0005 454 LCK_M_X
MD: database_id = 17 QDS_STATEMENT_STABILITY(qds_statement_key = 0xd1c26b6) , lockPartitionId = 017 1 3857719 179918 0 2018-04-09
03:01:05.947 2018-04-09 03:01:05.947
0 1 background
0x0100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 QUERY STORE BACK
sa
0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0x0000000000000000000000000000000000000000 0 0
0
即使试图杀死 spid 62 也是不允许的，因为它说“只能杀死用户进程”。即使超过 spid 50
除了看到事务日志使用率上升之外，我无能为力，所以我决定禁用自动查询调整和查询存储
禁用自动查询调整很快，但不适用于查询存储。我使用 T-SQL 做到了。该语句运行了 3 个小时，只是阻止了该数据库的所有系统对象。事务日志使用率超过 95%
禁用或清理 QDS 被此 spid 62 阻止
难道我取消了声明。最后我重新启动了实例，当它重新上线时，我能够立即禁用 QDS。
有任何想法吗 ？你以前见过这个吗？
感谢和问候
哈维尔·维勒加斯