问题标签 [sql-query-store]

我为我的两个数据库（验收和生产）启用了查询存储，它们都在 SQL Server 2016 标准版的同一个实例上运行。查询存储在验收数据库上记录查询历史，但在生产数据库上它不记录任何数据。

两个数据库的配置相同，除了只为生产数据库启用的镜像。使用的镜像模式是“具有自动故障转移（同步）的高安全性”。

假设以下是层次结构：

我正在通过5，所以我除了 5,4,2,1 我该怎么做。提前致谢。

在将应用程序从托管 VPS 移动到 Azure 应用程序服务后，Azure SQL DB 性能大幅下降的原因是什么？

这是过去两周 Query Store 的 High Variation 图表中的典型图表。红色箭头表示我将生产应用程序从另一个托管服务提供商移动到 Azure 应用程序的时间。在移动应用程序之前，我经历了零超时。现在，使用相同的 Azure SQL DB，超时会频繁触发较长的查询（但绝不是太费力）。

我所做的唯一其他更改是更改连接字符串中的用户原则。此用户只有 SELECT、INSERT、UPDATE、DELETE 和 EXECUTE 权限。

我的理论是： - 与应用程序和数据库之间的网络有关。弹性？但是我指定了一个 SQL 执行计划——我设置的用户有问题吗？- 糟糕的计划回归（我现在启用了自动 FORCE PLAN 调整） - 由 Hangfire 同时在两台服务器上运行引起的问题（现在通过将 HF 表移动到新数据库来缓解） - 某些事情正在触发某种我无法弄清楚的节流.

以下是 Log Analytics 的超时图表：

所有帮助表示赞赏。注意：该站点在过去 30 天内的流量几乎相同。

事实上，从过去一周的 SQL DB 指标看一下：

这是一些等待信息 - 过去 6 小时：

蓝色 = PARALLELISM 橙色 = BUFFERIO

我们最近将我们的 SQL 服务器升级到 2016，我打开了 QueryStore 来进行它提供的分析。我遇到了一个问题，即使报告的时间段是最后一小时，即使在数据库服务器本身上运行它也会生成一条消息，显示“无法连接到数据库”。有时，如果我不断刷新报告，它最终会显示一些数据，但充其量只是间歇性的。我在 sql server 2016 服务器上运行 SSMS 17.5。

我们在连接到有时无法连接的数据库的另一个程序上遇到了类似的问题，但是每次我在 SSMS 中运行查询、在 SSRS 中运行报告甚至使用活动监视器时，我都看不到任何连接断开，所以我不确定它是否相关。

预先感谢您的任何帮助！

启用查询存储后，如何查找执行查询的人员。例如，在跟踪收集的情况下，有一个 TRC 文件将获取主机名和程序详细信息以供查询，在扩展事件的情况下，我们有 XEL 文件将获取主机名和程序详细信息。我们尝试了代码

低于 DMV 的查询哈希（query_hash）返回空值，因此上述查询没有数据

我一直在研究 SQL Server 的查询存储，特别是整体资源消耗视图。它有一个“总持续时间”字段。我在服务器上放置了 60 分钟的工作负载，该字段报告了 25 小时的持续时间。这是被线程跟踪的吗？这就是它报道如此之高的原因吗？

我有一个主数据库和一个辅助地理复制数据库。在主服务器上，服务器自动调整已打开。

在复制品上，当我尝试做同样的事情时，我遇到了以下问题。

数据库正在从服务器继承设置，但服务器处于未指定状态。请指定服务器上的自动调整状态。

和

自动推荐管理被禁用，因为查询存储已达到其容量限制并且没有收集新数据。详细了解用于维护查询存储以便收集新数据的保留策略。

但是，在服务器上，调整选项是on所以我不理解“未指定状态”。此外，为什么我要查看 SSMS 中两个数据库属性中设置的查询存储，它们与 10MB 中的 9MB 可用空间完全相同。

注意：两个数据库都是在 5 个 DTU 基本定价计划中设置的。

更新

主数据库查询存储操作模式为读写，副本为只读。看来我无法更改它（我无法从 SSMS 中数据库的属性对话框中更改）。

很公平，但是相同的查询如何在主数据库上比在副本上快 10 倍。优化不是复制过来的吗？

更新 2

实际上查询存储在 SSMS 上是可见的，我可以看到它们在两个数据库中是相同的。我认为我观察到的响应时间差异不相关。

更新 3

我将@vCillusion的帖子标记为答案，因为他/她值得称赞。但是，就实际问题而言，它太详细了。

我的副本是只读的，因此无法自动调整，因为这需要写入查询存储。Azure 无法将任何数据收集到只读查询存储中，从而导致有关查询存储达到其容量的误导性（和错误）错误消息。

几周前，我确实在我们的一个主要环境中运行了从 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 = 0

17 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。

有任何想法吗 ？你以前见过这个吗？

感谢和问候

哈维尔·维勒加斯

什么是等效的 sql server 查询

我想知道快照表中不存在哪种“类型”，但总是出错：-

有人可以帮帮我吗？