我正在使用 Brent Ozar 的 sp_BlitzCache 存储过程，并试图确定它报告的原因：
“您计划中的某些内容强制进行串行查询。如果这不是设计使然，则需要进一步调查。”
经过调查，我发现服务器配置已设置：
'Max Degree of Parallelism = 1'
（这是我正确配置的洗衣清单。这是无知的日子。）
这是设置布伦特报告强制序列化的原因吗？
对于 ETL 报告系统，15 分钟无数据拉取的总执行时间类似于 24 小时有数据拉取的总执行时间是否正常？
我曾预计没有数据时 ETL 的总时间会更短，但这不是 15 分钟到 24 小时拉动之间的情况。但我必须承认，我对报表服务器中 T 和 L 阶段的内部结构一无所知。
有人可以阐明 T 和 L 阶段的持续时间是否通常是固定的（直到某个点）？
我承认每个人的经验和能力都不同。话虽如此，我想避免通过行动为 DBA 设定过高（或过低）的期望；似乎是“管理员”。
鉴于：
- 我是一名深入研究 SQL Server 故障排除和性能问题的开发人员。晚上我用一桶爆米花看 Brent Ozar 的视频。
- 一家有多个部门的公司，这个部门有大约 100 名团队成员
- 许多客户的数据库拥有数百万行的 ETL
- 一个小型 DBA 团队，负责处理这些相同的客户。为新客户或升级客户处理 HAG 问题、备份、恢复、创建新部署。
我不是试图证明我自己的观点。我希望调整我或公司其他人的意见。
问题：
鉴于上述情况，是否应该期望 DBA 只是一个“管理员”？这是你经常看到的吗？
我进入这部肥皂剧（请参阅我最近的其他问题），期望 DBA 被“期望”深入研究。我开始相信我误解了，我倾向于成为一名 DBA——成为一名“管理员”。
我欢迎其他人的经验，也许是关于完善这个问题的建议。
OPTION (RECOMPILE)用于生产？
这个选项似乎得到了很多坏消息。这是应得的吗？
我有一个 DBA，到目前为止，他不喜欢OPTION (RECOMPILE)Report ETL ssis 代理查询这一想法。这些查询（据我所知）按计划的时间间隔按顺序执行。
返回历史：
- SQL 服务器 2016
- 通过 ssis 代理运行时导致聚集索引扫描的 ETL 查询。这些查询需要几分钟才能完成并造成严重影响。
- 通过本地存储过程运行的相同查询和参数在不到一秒的时间内执行。
等等，你确定 OPTION (RECOMPILE) 是答案吗？
- 未知。
- 但在我尝试之前，我需要知道这是否是一个非常糟糕的主意。
我知道的风险：
- 过去至少有两个与 OPTION (RECOMPILE) 相关的严重错误。同时运行的两个查询可以交换结果集。啊！！ https://support.microsoft.com/en-us/topic/fix-rare-possibility-of-incorrect-results-when-you-use-option-recompile-for-queries-inside-a-procedure-in- sql-server-2014-或-sql-server-2012-c247fbb5-4125-dd0f-7789-7b1c126f8241
因此，鉴于上述情况 - 这个选项实际上是否在现实世界中使用？我推荐（并测试）它作为生产环境的一个选项是否可以接受？
我被要求提供更多细节。我提到我确实有其他与该主题相关的帖子。让我提供更多信息：
- 根本问题是来自应用服务器的查询花费的时间超过 60 秒。通常这些查询需要 4 到 10 秒。经过很多痛苦，我确定超时与 ETL 查询一致。15 个查询中有 4 个是具体的。
- 在应用程序服务器中发现了导致问题的因素。具体而言，隔离级别设置为
serializable休眠层内；我了解到，这对于大批量生产环境来说并不是最佳选择。
让我分享其他问题：
我看到了经典的“在工作室管理器中运行速度快但在应用程序中运行缓慢”的问题。听起来可能是参数嗅探。但是，我在 ETL 和 SSIS 方面的经验为零。
从 DBA 我收到了以下查询，它以 ? 而不是一个参数。这是查询的混淆示例：
SELECT
tablex.x_id,
tablex.create_ts,
tablex.update_ts,
tablex.myStatus,
tablex.x_type,
tablex.ami_uploaded,
tablex.work_id,
tablex_capture_ts,
[column1],
[column2],
[column3],
[column4]
FROM sqltable..tablex
INNER JOIN
sqltable..tableWork ON tablex.work_id = tableWork.work_id
WHERE
(tablex.update_ts >= ?)
- 根据 DBA，问号被替换为过去一小时的“时间/日期”参数。
- 当我从存储过程在本地执行相同的查询时，传入一个过去一小时的参数，它会在不到一秒的时间内返回。（对我来说，这意味着它“可以”使用现有索引）
- 从 ETL 看这个执行，它需要几分钟，执行计划显示表扫描。
- 有一个 update_ts 索引。
查询引擎推荐第二个包含多个包含列的 update_ts 索引。如果可能的话，我想避免这种情况，因为它会增加内存压力，而且我不相信它可以解决真正的问题。想法？
这似乎是查询统计信息出现偏差的情况，当查询引擎嗅探参数时，它会避免使用现有索引，因为估计的行数超出了阈值。
我的问题：
- 怎么样？在 SSIS 查询中得到由 sql server 处理吗？我知道参数嗅探是一个复杂的问题。我一直在研究这个： http: //www.sommarskog.se/query-plan-mysteries.html
- 如果是查询引擎嗅探参数（过去一小时）并认为估计的行数超出了触发点，我该怎么做才能解决这个问题？DBA 拒绝了 OPTIMIZE for RECOMPILE 作为选项的提示，我不能说我不同意。（他有关于错误历史的观点）但是，这些查询仅在计划时间从 ETL 发生，也许这足以有理由使用提示而不管潜在的错误？
此外，这是我一直在努力解决的一个长期问题。所有这些帖子都与同一问题有关。多么奇妙的发现之旅：
SQL Server - 我可以手术删除一个糟糕的缓存查询计划还是我追求错误的想法？
任何意见是极大的赞赏。
这应该是本地存储过程版本的实际执行计划。此版本在 1 秒内返回，并表现出我希望 ETL 具有的行为：
https://www.brentozar.com/pastetheplan/?id=ry4wy6dBO
现在，这是 ETL 版本的屏幕截图，需要几分钟才能完成。抱歉，我无法提供有关此特定查询的更多详细信息：
这是一个小时内完成的分析器跟踪的屏幕截图。我认为这就是 ETL 命令的执行方式。我还不知道，为什么这些都有相同的时间。我还需要找到准备工作。看看那些 cpu、reads 和 duration 列！
鉴于：
- 生产环境
- 使用 Hibernate 的应用服务器
- SQL Server Studio 管理器 v17.5
- 群集 HAG 设置中的 SQL Server 2016
- SQL Server 未启用查询存储功能
- 这个问题的作者是一位软件工程师，拥有足够的 SQL Server 知识，可以归类为几乎无害
更新 1
- 数据库增长设置：无限制，1024000 KB，仅数据
- instant_file_initialization_enabled - 是
- is_auto_update_stats_async_on - 否
更新 2
- 服务器有 4 个 CPU 核心
- 等待任务的峰值超过 3,000,000。我还不知道它们是什么。这一定是大“锁定”时间的原因。
- 这些尖峰每 10 或 15 秒出现一次。我有以下图表每秒更新一次：
问题：
根本问题是，在忙碌的一天中看似随机的时间，几个 SQL 查询超时，但是，出于这个问题的目的，我对屏幕抓取是否表明本身存在问题感兴趣。也许这是主观的，但我对这个值没有经验。
行动：
失败本身并没有直接指向具体问题，因此我目前正在收集证据并尽可能尝试消除过程。目前我正在调查是否过长的等待时间和查询的“完美风暴”会导致级联锁，从而导致查询超时。
收集到的证据：
- 几个查询会导致全索引扫描或全表扫描。
- 几个带有执行计划的屏幕截图，显示了表扫描。粗略检查表明索引确实存在 - 但尚未使用。如果它们被证明有用，我也许可以对屏幕抓取进行消毒。
- 下面的屏幕截图显示了较长的等待时间。
问题：
还有哪些其他信息可以帮助确定锁定和等待时间是否可能是查询超时的原因？例如，我从 sql server studio manager 活动监视器获取了以下屏幕截图。这个价值让我感到惊讶。
我需要帮助理解我的选择。鉴于：
- 由 DBA 维护的 SQL 服务器集群设置。
- 系统尚未投入生产（未移交给客户）。
- 最初的大量数据推送，连续几天没有中断
- 我可以随时停止和启动数据推送并更改数据库。基本上我可以停止所有输入。
我建议我们的 DBA 切换到简单模式，因为我们在活动监视器中看到一堆处于等待状态的查询，最终导致应用程序服务器出错。
我以前从未遇到过这个问题，在消除过程中我看到我们处于完全恢复模式而不是简单模式。
我要求我们从 FULL 切换到 SIMPLE，这就是我得到的答复。是否有其他选择可能是 DBA 不知道的？
我能提供什么帮助？
“我们无法在 SQL 中使用 AlwaysOn 切换到简单模式。”
我可以在初始加载阶段关闭 AlwaysOn 还是我不走运？
- - 添加 - -
让我设置舞台：
- SQL 服务器 > 2016
- 具有相同架构的多个数据库
- 数据相似但不相同
- 存在相同的索引等，除一个以外的所有系统都按预期工作
- 检查执行计划建议创建一个索引，其中所有列都作为 INCLUDE。没有包含的相同基列已经存在。
问题：
- 在其中一个数据库上，查询引擎不利用现有索引并使用全表扫描
- 手动执行查询（使用参数）——全表扫描！
- 手动执行不带参数的查询（使用固定日期） - 使用索引。
- 使用参数手动执行查询并添加
WITH (INDEX(update_ts_INDEX))- 使用索引。查询时间从 2 分钟缩短到不到 1 秒。
假设：
- 我相信查询缓存可能已损坏 - 但我不知道这是否可能。顺便说一句，我是一名 Java 开发人员，过去 3 年一直在研究 SQL Server 性能调优等。
- 不带参数手动执行查询的事实——查询引擎选择正确的索引——让我大吃一惊。想法？
笔记：
- 在运行相同代码和查询的其他服务器上，我找不到任何证据表明同一查询需要任何时间。他们必须使用索引。
- 我只是在另一个带有参数的区域中手动执行了命令，它使用了索引，所以问题确实只存在于一个区域 - 一个数据库中。
查询示例：
DECLARE @P1 DATETIME = GETDATE() - .1;
SELECT value_1, update_ts, value_2 FROM PRODUCTION_TABLE
WHERE (PRODUCTION_TABLE.update_ts > @P1);
如果我删除变量并手动编码日期，它将使用索引。
问题： 我可以通过外科手术删除此特定查询的错误缓存查询计划吗？
- - 更新 - -
UsingOPTION (RECOMPILE)导致查询引擎选择正确的索引。
给定以下 SQL，“ONLY”、“OPERATOR(pg_catalog.=)”和“FOR KEY SHARE”是做什么的？
SELECT 1
FROM ONLY "public"."acmeinstanceinfo" x
WHERE "widgetid" OPERATOR(pg_catalog.=) $1
FOR KEY SHARE OF x
我对 Microsoft SQL 服务器有相当多的经验，但对 PostgreSQL 零经验。对此查询所做的任何见解都会很棒。
我在一个 sql server 数据库中有 3000 万行，我在其中添加了一个简单的标记列。一个字符允许为空。我确实为该列添加了一个索引。
我用它来跟踪哪些行已被处理以进行数据提取。在初始开发期间，我将从头开始（多次）重新启动提取过程，并且需要将值重置为“1”。
作为新手数据库开发人员（我在跟谁开玩笑……），我的第一次尝试是使用一个简单的更新脚本将“2”（我已经处理过这一行）的值重置为“1”。我第一次运行脚本时，它在大约 5 分钟内执行完毕。我最后一次执行 - 花了 45 分钟。一定有更好的方法。
我是否可以通过完全删除该列并使用默认值“1”重新创建它来加快速度？速度会保持一致吗？
- 更新 - -
下次我需要这样做时，我将尝试以下操作：
ALTER TABLE acmewidgets DROP COLUMN LegacyExtract;
ALTER TABLE acmewidgets
ADD LegacyExtract CHAR NOT NULL DEFAULT (1);