我有一个DELETE针对具有全文索引列的表运行的语句，少数cascade启用的外键。它看起来像这样：
DELETE FROM dbo.STUDENTS WHERE STUDENTID=@STUDENTID
有时会编译一个计划，其中包括对所有索引操作的非常高的行估计，这样会DELETE花费很长时间并导致锁定。
我试图在 QueryStore 中强制执行一个好的计划，但这实际上不起作用，显示last forced plan failure description.NO_PLAN
我已确保没有可能使计划无效的架构更改。
查看执行计划，我看到这DELETE涉及到一个包含 FT 索引的系统表的连接：
加入 FT 索引是否意味着不支持计划强制？
我继承了一个可用性组，发现可用性组的两个节点之间设置了一个链接服务器。sa不幸的是，它用于身份验证。
同时，一些团队的开发人员使用sa查询实时数据库。我希望这停止。
我的问题是：
可用性组是否以任何方式要求链接服务器？我知道我有一些定制的活动部件，例如使用链接服务器在两个节点之间同步作业的代理作业。我更关心 SQL Server 内部的一些我可能不知道的东西。仅进行正常的尽职调查并将链接服务器用户更改为使用非 sa 并更改sa密码有什么问题吗？
我有一个看起来像这样的 xml 列：
<document>
<item>
<key>
<string>Michael Burry</string>
</key>
<value>
<string>CDO</string>
</value>
</item>
<item>
<key>
<string>Adam Smith</string>
</key>
<value>
<string>£20</string>
</value>
</item>
<item>
<key>
<string>World Cup 2018</string>
</key>
<value>
<string>football</string>
</value>
</item>......
我不想列出列的全部内容，而是只列出<string>football</string>第一个值为 的值<string>World Cup 2018</string>。
value('(/document/item/key/string)[7]', 'nvarchar(max)')不适合使用，因为“World Cup 2018”可以出现在任何地方。
今天早上，收到以下电子邮件提醒：
日期/时间：2018 年 2 月 28 日上午 9:26:42
描述：尝试在数据库 9 中获取逻辑页面 (1:3948712) 失败。它属于分配单元72057594045857792而不是72059184917512192。
评论：（无）
作业运行：SQL Sentry 2.0 警报陷阱
查看次要副本的事件日志，有 3 次出现相同的消息：
源 spid138
消息尝试在数据库 9 中获取逻辑页面 (1:3948712) 失败。它属于分配单元72057594045857792而不是72059184917512192。
在辅助副本（2 节点同步可用性组）上运行以下命令：
DBCC TRACEON(3604)
dbcc page (9, 1,3948712,3)
go
DBCC TRACEOff(3604)
来自任一副本的结果片段：
Page @0x00000070DAB8C000
m_pageId = (1:3948712) m_headerVersion = 1
m_type = 3 m_typeFlagBits = 0x0 m_level = 0
m_flagBits = 0x8200 m_objId (AllocUnitId.idObj) = 129 m_indexId
(AllocUnitId.idInd) = 256 Metadata: AllocUnitId = 72057594046382080
Metadata: PartitionId = 72057594040811520
Metadata: IndexId = 1 Metadata: ObjectId = 197575742
m_prevPage = 0:0) m_nextPage = (0:0) pminlen = 0
m_slotCnt = 2 m_freeCnt = 1634 m_freeData = 6568
m_reservedCnt = 0 m_lsn = (46041:1506360:18)
m_xactReserved = 0 m_xdesId = (0:0)
m_ghostRecCnt = 0 m_tornBits = -99702035 DB Frag ID = 1
在主副本上运行以下命令：
select OBJECT_NAME (197575742)
plan_persist_plan
plan_persist_plan作为查询存储一部分的表的聚集索引损坏？是运行以下内容的最佳/唯一修复：
ALTER DATABASE MyDatabase SET QUERY_STORE CLEAR;
如果 #2 是最好的解决方法，是否有任何好的方法可以保留查询存储中将被删除的数据？
我已按照指南检查了 Windows 系统事件日志。这仅产生“信息”事件，没有错误。
DBCC CHECKTABLE ('sys.plan_persist_plan');
结果：
DBCC results for 'sys.plan_persist_plan'. There are 12562 rows in 240 pages for object "sys.plan_persist_plan". DBCC execution completed. If DBCC printed error messages, contact your system administrator.
我无法建立正确的命令来重建索引，以下不起作用：
ALTER INDEX PK_plan_persist_plan_cidx ON sys.plan_persist_plan REBUILD;
我有一个涉及全文搜索的查询，如下所示：
SELECT TOP 30 PersonId,
PersonParentId,
PersonName,
PersonPostCode
FROM dbo.People
WHERE PersonDeletionDate IS NULL
AND PersonCustomerId = 24
AND CONTAINS(ContactFullText, '"mr" AND "ch*"')
AND PersonGroupId IN(197, 206, 186, 198)
ORDER BY PersonParentId,
PersonName;
这会生成两个主要计划，一个在所有情况下都非常快，另一个在大多数情况下非常慢。
我对这个查询进行了试验，因此不包括 FT 搜索，我发现行估计总是比它们应该的低得多。
如果我运行，update statistics...with fullscan我仍然会从执行计划中的 NC 索引查找操作中看到极其不准确的行估计。
当行估计足够低时，选择循环连接，这通常非常慢（30 多秒）。较高的估计似乎会产生一个涉及合并连接而不是循环连接的好计划。
尽管仍然有最新的统计信息，为什么 SQL Server 仍然不估计行数？
计划：https ://www.brentozar.com/pastetheplan/?id=rkXtE0jzX
当我删除该CONTAINS部分，从而省略全文搜索时，查询速度很快，但索引查找的行估计仍然是 1 估计，实际 2195。
在@Kin 的建议下，我使用了 CONTAINSTABLE，它立即运行并生成了以下计划：https ://www.brentozar.com/pastetheplan/?id=S1hKainzQ 有趣的是没有全文搜索运算符。
在这种情况下， Containstable 需要RANK生成相同的结果集，我用AND RANK > 0它WHERE来生成我想要的结果，它生成了这个计划：https ://www.brentozar.com/pastetheplan/?id=B1U7AA2zm
我现在唯一的问题是为什么行估计仍然不准确，但我现在不那么关心了，因为我的 FT 查询看起来更快、更可靠。很高兴！ https://www.brentozar.com/pastetheplan/?id=B1U7AA2zm
@EvanCarroll 统计直方图在这里：https ://pastebin.com/p7s0NvX5
一些后续信息——针对所支持的应用程序的一些典型 FT 搜索查询的执行计划之前/之后
一个
乙
C
丁
最近我注意到我公司的应用程序使用AddWithValue将参数值传递给动态的参数化查询。例子：
cmd.Parameters.AddWithValue("@VehicleId", Vehicles.VehicleId);
在数据库中，数据类型VehicleID为INT.
据我了解，由于 AddWithValue（已弃用）未指定数据类型/长度，因此此“@VehicleID”已转换并且可能转换不正确。在“INT”的情况下，这种转换会影响 SQL Server 的性能吗？
这会导致超出计划缓存污染的问题吗？转换是否会导致性能下降？
用户“domain\localMachineName$”登录失败。原因：找不到与提供的名称匹配的登录名。[客户： ]
在我将它添加到现有 Windows 集群后，它立即出现在我的新 SQL Server 上。它恰好每 5 分钟发生一次。似乎本地资源正在尝试登录，但我看不出它可能与什么有关。
具有两个节点的 Always On 可用性组，同步提交。
辅助副本上的重做线程争用会定期创建一个非常大的重做队列。我已经确认等待类型类似于以下内容：
在我的例子中，这是一个扩展事件会话（在重做队列很大时捕获）输出分组和聚合，如上面的链接所示：
我的问题：
如何找出导致 LCK_M_SCH_M 等待的 DDL 操作的确切来源？
我有一张这样的桌子：
Lat1 Lng1 Lat2 Lng2 ---- ---- ---- ---- 1 1 2 2 2 2 5 5 3 3 4 4 4 4 3 3 5 5 4 4
是否可以按以下顺序返回行？
Lat1 Lng1 Lat2 Lng2 ---- ---- ---- ---- 1 1 2 2 2 2 5 5 5 5 4 4 4 4 3 3 3 3 4 4
有一个独特的rowid专栏。
(Lat1,Lng1)和对将(Lat2,Lng2)始终是唯一的。
lat1and long1of rown+1必须与lat2and long2of row相同n。
我最近接管了一个包含两个节点的可用性组的管理，同步提交模式。
组的配置如下所示：
我的理解是，当Yes两个副本上的 Readable Secondary 选项都设置为时，任何带有 applicationIntent=ReadOnly 的连接字符串都将路由到 Node1。
同样，如果我将 Node2 的 Readable Secondary 选项更改为“Read-intent”，任何带有 applicationIntent=ReadOnly 的连接字符串都将路由到 Node2。
那么，为什么当两个节点都设置为“Readable Secondary = Yes”时，此连接字符串会路由到 Node2：
'数据源=redacted.domain.com；初始目录= MyDatabase；ApplicationIntent=只读；用户 ID=用户；密码=********；MultiSubnetFailover=True'
基本上，将“ReadOnly”参数更改为“ReadWrite”会导致连接转到 Node1。改回“只读”会导致连接路由到 Node2。如果没有 'Readable Secondary= Read-intent' 选项，这怎么可能？
编辑：输出
SELECT ag.name as "Availability Group", ar.replica_server_name as "When Primary Replica Is",
rl.routing_priority as "Routing Priority",
ar2.replica_server_name as "RO Routed To",
ar.secondary_role_allow_connections_desc,
ar2.read_only_routing_url
FROM sys.availability_read_only_routing_lists rl
inner join sys.availability_replicas ar on rl.replica_id = ar.replica_id
inner join sys.availability_replicas ar2 on rl.read_only_replica_id = ar2.replica_id
inner join sys.availability_groups ag on ar.group_id = ag.group_id
ORDER BY ag.name, ar.replica_server_name, rl.routing_priority
对于其他需要帮助理解这一点的人，我发现以下内容很有帮助：
两个节点 Always On 可用性组，一个同步副本。
我的同步副本经常不同步。我看到一种模式，当次要副本上发生日志备份时，会出现短暂的延迟，在此期间 redo_queue_size 会迅速填满，如下所示：
![[1]：https://i.sta](https://isstatic.askoverflow.dev/6GQrH.jpg)
查看以下链接中的指导，似乎我的问题主要是由于尝试强化事务时重做线程遇到的争用：
https://technet.microsoft.com/en-us/library/dn135335(v=sql.110).aspx
当事务日志备份运行时，副本会进一步不同步，并且在辅助副本上运行的报告也会加剧此问题。
一直以来，我的事务日志备份都很大——平均为 1.2GB，但可能更大。
据我所知，我的日志备份会很大，因为我在数据库上启用了 TDE，但我真的没想到它们会这么大。我怀疑这是导致次要副本上缓慢提交的最大原因。
是否有推荐的性能计数器来诊断同步副本上的慢速提交？我还能做些什么来验证我的理论？
我的问题似乎与此处描述的问题相同： https ://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread
我可以仅在辅助副本上启用此跟踪标志还是需要将其应用于两个节点？
编辑：我在早上 6 点检查了重做队列，发现了一个巨大的数字，恢复时间为 15-20 分钟，并且一直在略微增加。然后我应用了 traceflagDBCC TRACEON (3459, -1)并在几分钟后发现，重做命令的数量下降得非常快。到目前为止，这个跟踪标志似乎已经缓解了这个问题，但大概这会将所有事务强化到辅助副本的日志中，例如 SQL Server 2014，因此，辅助副本仍有可能落后作为非并行线程的结果，当主要的写入负载很重时。
我有一个带有同步副本的 2 节点 AG。我想知道是否可以安全地将另一个数据库添加到同步副本节点，而无需将其添加到可用性组。
这样做有什么注意事项吗？
一直在与我公司的应用程序供应商就并行性进行辩论。他们坚持认为 Maxdop = 1 对应用程序/数据库有显着的性能改进，但他们绝对没有提供任何证据。
我测试了各种 DOP/CT 设置，发现在使用 Maxdop 4（8 个超线程内核）和 CT 150 时，自动化测试的整体性能提高了 28%。
供应商的 DBA 最近说：“MSSQL 的内部进程存在一个问题，即使 DOP 为‘1’，MSSQL 的内部进程也能使用这个值，在使用它的 MSSQL 服务器中有低于 51 的 SPID，幽灵清理等这个。”
我对此进行了研究，尽管信息很少，但 Paul Randall 至少说 ghost 清理始终是单线程的，所以显然供应商的 dba 不正确？
当 Maxdop = 1 时，对 CT 的影响有什么想法吗？
我了解 SQL Server 2005 不支持DATE，因此无法将日期时间转换为日期。
我想要做的是列出当前一周一整天内具有日期时间的所有记录。
所以我需要在本周的星期一创建的所有记录忽略时间戳。目前我正在使用以下内容，它确实显示了本周的周一至周五，但包括时间戳，这意味着我将看到不同的输出，具体取决于查询的运行时间：
set datefirst 1
select
DATEADD(day, 1 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Monday,
DATEADD(day, 2 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Tuesday,
DATEADD(day, 3 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as wednesday,
DATEADD(day, 4 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Thursday,
DATEADD(day, 5 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Friday
有人可以帮忙吗？
我的预期输出将是当周每一天的一列，该周从星期一开始（即：Datefirst 1）。最终，我将在一个案例陈述中使用它，例如：
CASE
WHEN DateColumn >= DATEADD(day, 1 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) and DateColumn < DATEADD(day, 2 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE()))
THEN IntegerColumn
ELSE 0
END AS Monday
...重复一周中的每一天。我需要容纳整个星期一添加的 IntegerColumn 值。如果在星期一的几个小时内没有出现 DateColumn 条目，则显示零。
我公司使用的应用程序存在相当大的性能问题。我正在处理的数据库本身存在许多问题，但其中许多问题纯粹与应用程序相关。
在我的调查中，我发现有数百万个查询命中查询空表的 SQL Server 数据库。我们有大约 300 个空表，其中一些表每分钟查询高达 100-200 次。这些表格与我们的业务领域无关，本质上是原始应用程序的一部分，当供应商与我公司签约为我们生产软件解决方案时，供应商没有删除这些表格。
除了我们怀疑我们的应用程序错误日志中充斥着与此问题相关的错误之外，供应商向我们保证，对应用程序或数据库服务器的性能或稳定性没有影响。错误日志被淹没到我们看不到超过 2 分钟的错误来进行诊断的程度。
这些查询的实际成本在 CPU 周期等方面显然会很低。但是有人可以建议对 SQL Server 和应用程序的影响吗？我怀疑发送请求、确认请求、处理请求、返回请求以及应用程序确认接收的实际机制本身会对性能产生影响。
我们为该应用程序使用 SQL Server 2008 R2、Oracle Weblogic 11g。
@Frisbee-长话短说，我创建了一个包含查询文本的表，该表命中了应用程序数据库中的空表，然后查询它以查找我知道的所有空表名并得到一个很长的列表。最高命中率是在 30 天的正常运行时间内执行了 270 万次，请记住该应用程序通常在上午 8 点至下午 6 点使用，因此这些数字更集中于运行时间。多个表，多个查询，可能有些是通过连接相关的，有些不是。最高命中率（当时为 270 万）是从带有 where 子句的单个空表中进行的简单选择，没有连接。我希望连接到空表的更大查询可能包括对链接表的更新，但我会检查并尽快更新此问题。
更新：有 1000 个查询，执行次数在 1043 - 4622614 之间（超过 2.5 个月）。我将不得不深入挖掘以找出缓存计划的来源。这只是为了让您了解查询的范围。大多数都相当复杂，有超过 20 个连接。
@srutzky- 是的，我相信有一个日期列与计划的编制时间相关，所以我会感兴趣，所以我会检查一下。我想知道当 SQL Server 位于 VMware 集群上时，线程限制是否会成为一个因素？谢天谢地，很快就会成为专用的 Dell PE 730xD。
@Frisbee - 抱歉回复晚了。正如您所建议的，我使用 SQLQueryStress 在 24 个线程上从空表中运行了 select * 10,000 次（实际上是 240,000 次迭代）并立即达到 10,000 个批处理请求/秒。然后我在 24 个线程上减少到 1000 次并且达到每秒 4,000 个批处理请求。我还仅在 12 个线程上尝试了 10,000 次迭代（因此总迭代次数为 120000 次），这产生了持续的 6,505 批次/秒。对 CPU 的影响实际上很明显，在每次测试运行期间大约占总 CPU 使用率的 5-10%。网络等待可以忽略不计（比如我工作站上的客户端等待 3 毫秒），但 CPU 的影响肯定存在，就我而言，这是非常确定的。它似乎归结为 CPU 使用率和一些不必要的数据库文件 IO。每秒执行的总数略低于 3000，这比生产中的要多，但是我只测试了几十个这样的查询中的一个。因此，当涉及到 CPU 时间时，数百个查询以每分钟 300-4000 次的速度命中空表的净影响是不可忽略的。所有测试均针对具有双闪存阵列和 256GB RAM、12 个现代内核的闲置 PE 730xD 进行。
@srutzky- 好主意。SQLQueryStress 似乎默认使用连接池，但我还是看了一下，发现是的，连接池的框被选中了。后续更新
@srutzky- 连接池显然没有在应用程序上启用——或者如果是，它不工作。我进行了探查器跟踪，发现连接具有用于审核登录事件的 EventSubClass“1 - Nonpooled”。
RE: 连接池 - 检查了 weblogics 并发现连接池已启用。对实时运行更多跟踪并发现汇集没有正确/根本没有发生的迹象：
这是当我运行单个查询时的样子，但没有针对填充的表进行连接；异常读取“建立与 SQL Server 的连接时发生与网络相关或特定于实例的错误。找不到服务器或无法访问服务器。验证实例名称是否正确以及 SQL Server 是否配置为允许远程连接。 （提供程序：命名管道提供程序，错误：40 - 无法打开与 SQL Server 的连接）”注意批处理请求计数器。在异常生成期间对服务器执行 ping 操作会导致成功的 ping 响应。
更新 - 两次连续的测试运行，相同的工作负载（select*fromEmptyTable），启用/未启用池。稍微多一点的 CPU 使用率和很多失败，并且永远不会超过 500 个批处理请求/秒。测试显示 10,000 批次/秒并且在启用池时没有失败，大约 400 批次/秒然后由于禁用池而导致大量失败。我想知道这些失败是否与缺乏连接可用性有关？
@srutzky- 从 sys.dm_exec_connections 中选择 Count(*)；
启用池：始终为 37，即使在负载测试停止后也是如此
禁用池：11-37，取决于 SQLQueryStress 上是否
发生异常即：当 Batches
/sec 图表上出现这些波谷时，SQLQueryStress 上发生异常，
连接数下降到 11，然后逐渐回升到 37当批次开始达到峰值并且没有发生异常时。非常非常有趣。
两个测试/实时实例上的最大连接数设置为默认值 0。
已检查应用程序日志，但找不到连接问题，但是，由于错误的数量和大小很大，因此只有几分钟的日志记录可用，即：大量堆栈跟踪错误。一位应用程序支持同事建议，大量 HTTP 错误的发生与连接有关。似乎基于此，由于某种原因，应用程序未正确汇集连接，结果，服务器反复耗尽连接。我会更多地查看应用程序日志。我想知道是否有一种方法可以证明这种情况发生在 SQL Server 端的生产环境中？
@srutzky- 谢谢。我明天会检查 weblogic 配置并更新。我在考虑仅仅 37 个连接——如果 SQLQueryStress 在 10,000 次迭代中执行 12 个线程 = 120,000 个非池化的选择语句，难道这不意味着每个选择都创建一个到 sql 实例的不同连接吗？
@srutzky- Weblogics 配置为连接池，因此它应该可以正常工作。连接池的配置如下，在 4 个负载平衡的 weblogics 中的每一个上：
当我增加执行 select from empty table 查询的线程数时，连接数峰值约为 47。在禁用连接池的情况下，我始终看到较低的最大批处理请求/秒（从 10,000 下降到大约 400）。每次都会发生的是 SQLQueryStress 上的“异常”发生在 batches/sec 进入低谷后不久。它与连接性有关，但我不明白为什么会这样。当没有测试运行时，#connections 下降到大约 12。
禁用连接池后，我无法理解为什么会发生异常，但也许这是 Adam Machanic 的另一个 stackExchange 问题/问题？
@srutzky 我想知道为什么在没有启用池的情况下发生异常，即使 SQL Server 没有用完连接？
谁能告诉我为什么这对我不起作用？
CREATE TABLE #UndistributedCmds
(
pendingcmdcount int,
estimatedprocesstime INT
)
INSERT INTO #UndistributedCmds
EXEC sp_replmonitorsubscriptionpendingcmds ...
错误：
消息 8164，级别 16，状态 1，过程 sp_replmonitorsubscriptionpendingcmds，第 152 行
INSERT EXEC 语句不能嵌套。
该错误似乎暗示存储过程定义的第 152 行是问题所在，但我无法理解这一点。发生这种情况是因为存储过程本身有多个存储过程吗？
我最近将一个数据库恢复到从（SQL Server 2008 R2 Enterprise）备份的同一个实例，发现我无法访问数据库属性。
我做了以下事情：
sp_helpdb。sa. 不是修复。sysadmin用户。不是修复。DBCC updateusage针对受影响的数据库发出。不是修复。DBCC CheckDB在恢复到另一个实例的副本上运行。没有发现腐败。访问数据库属性窗口时，恢复的副本（来自同一个备份文件）没有引发任何错误。任何人都可以帮忙吗？
尝试查看属性时收到的错误消息是：
无法显示请求的对话框。(SqlMgmt)
属性大小不适用于数据库“[DBNAME]”。
此对象的此属性可能不存在，或者由于访问权限不足而无法检索。(Microsoft.SqlServer.Smo)
我是sysadmin这个例子。
更新：按照建议，我创建了一个新用户，将其设为 sysadmin 并将数据库所有者更改为它。不幸的是，这不是修复。我会看看探查器跟踪是否产生任何有用的东西。
更新：Aaron - 原始数据库已重命名并脱机，但仍在该实例上。然后使用原始名称恢复该数据库的备份。新数据库文件的文件名与原始文件名不同，因为它们与原始 mdf/ldf 位于同一文件夹中。恢复的数据库目前正在正常驱动我们的关键应用程序。
当查询优化器计算执行计划的成本时，您能否预期该计划会根据可用资源量而有所不同？
采取以下情况：
我对 SQL VM 为什么在有更多 CPU 资源可用时执行速度变慢的解释是，过程缓存包含在 CPU 可用性较低的环境下计算/优化的计划。当额外资源可用时，过程缓存将提供次优计划，这些计划可能执行得不太好。
这有意义吗？几周前我们遇到了这种情况，一旦我们停止了主机上的 CPU 抖动，我们就收到了很多关于性能的抱怨。我运行了 dbcc freeprocache，此后性能似乎有所提高 - 或者用户已经习惯了。
想法？谢谢
SQL Server 2005，我在 SSMS 的 SQL Agent>jobs 节点中看到大约 100 个“作业”。它们显示为十六进制字符串，而不是真实姓名：
如果我查询 msdb..sysjobs，我会看到一个小得多的作业列表及其对应的 JobName。
那么这些工作是什么，我怎样才能让它们显示为他们的真实工作名称而不是 JobID？
谢谢，彼得