这是一个奇怪的情况，但我希望有人有答案。

在一些性能故障排除期间，我们按照sp_BlitzIndex. 第二天我们检查了它的使用情况，它显示0 次读取（0 次扫描/搜索，0 次单例查找），因此我们禁用了它。

就在下一分钟，我们收到了与我们在添加 INDEX 时首先尝试检查和解决的应用程序缓慢（性能问题）相同的投诉。

现在，我知道理论上，这听起来纯属巧合。INDEX 是可证明的，可衡量的，NOT USED。禁用它不应该导致查询性能下降。但它几乎TOO巧合。

题

所以我的问题很简单，就是这样：

是否有可能，一个未使用的索引（来自 DMV / sp_BlitzIndex）的使用统计数据显示没有使用，仍然以某种方式帮助受影响表上的查询性能？

我正在尝试创建一个新表，其中的列后跟它们的约束，如下所示。

Create tblTest(
columns..
..
..
Gender int,
Constraint DF_tblTest_Gender Default 3 For Gender,
..
..
..
)

但是，我在默认约束附近收到一条错误消息，

'for' 附近的语法不正确

我制作了一个脚本，一次一个，从数据库中删除所有外键，就像这样：

ALTER TABLE MyTable1 DROP CONSTRAINT FK_MyTable1_col1
ALTER TABLE MyTable2 DROP CONSTRAINT FK_MyTable2_col1
ALTER TABLE MyTable2 DROP CONSTRAINT FK_MyTable2_col2

让我感到惊讶的是脚本需要很长时间：平均每个 DROP FK 需要 20 秒。现在，我明白创建 FK 可能是一件大事，因为服务器必须去检查 FK 约束是否从一开始就没有被侵犯，而是下降了？当丢弃需要这么长时间的 FK 时，服务器会做什么？这既是为了我自己的好奇心，也是为了了解是否有办法让事情变得更快。能够删除 FK（不仅仅是禁用它们）将使我在迁移过程中更快，从而最大限度地减少停机时间。

我有一个非常大的地理LINESTRING数据表，我要从 Oracle 移动到 SQL Server。在 Oracle 中有许多针对此数据执行的评估，并且它们也需要针对 SQL Server 中的数据执行。

问题：SQL Server 对有效的要求LINESTRING比 Oracle更严格；“LineString 实例不能在两个或多个连续点的间隔内重叠”。 碰巧我们的LINESTRINGs的百分比不符合该标准，这意味着我们需要评估数据的函数失败。我需要调整数据，以便它可以在 SQL Server 中成功验证。

例如：

验证一个非常简单的LINESTRING自我加倍：

select geography::STGeomFromText(
    'LINESTRING (0 0 1, 0 1 2, 0 -1 3)',4326).IsValidDetailed()

24413: Not valid because of two overlapping edges in curve (1).

Run Code Online (Sandbox Code Playgroud)

MakeValid针对它执行函数：

select geography::STGeomFromText(
    'LINESTRING (0 0 1, 0 1 2, 0 -1 3)',4326).MakeValid().STAsText()

LINESTRING (0 -0.999999999999867, 0 0, 0 0.999999999999867)

Run Code Online (Sandbox Code Playgroud)

不幸的是，该MakeValid函数更改了点的顺序并删除了第三维，这使我们无法使用它。我正在寻找另一种无需重新排序或删除第三维即可解决此问题的方法。

有任何想法吗？

我的实际数据包含数百/数千个点。

通过在此处阅读此LIKE 字符长度限制，看起来我无法在 LIKE 子句中发送超过 ~4000 个字符的文本。

我正在尝试从特定查询的查询计划缓存中获取查询计划。

SELECT *
FROM sys.dm_exec_cached_plans AS cp 
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) AS qp 
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) AS st
where st.text like '%MY_QUERY_LONGER_THAN_4000_CHARS%' ESCAPE '?'

如果里面的查询LIKE超过 4000 个字符，那么即使我的查询在缓存计划中，我也会得到 0 个结果。（我期待至少有一个错误）。

有没有办法解决这个问题或采取不同的方式？我有可能是 >10000字符长的查询，看起来我无法通过LIKE.

我在 Always On 可用性组中有一对 Microsoft SQL Server 2016 节点。我正在尝试对BULK INSERT位于 Windows Server 2016 文件服务器故障转移群集上的文件执行（使用 SQL Server 2016 Management Studio 查询），但出现以下错误：

消息 4861，级别 16，状态 1
无法批量加载，因为无法打开文件“\nas2.my.domain\Microsoft SQL Server 2016 Enterprise\test.txt”。操作系统错误代码 5（访问被拒绝。）。

无论我使用活动节点名称 ( nas2.my.domain) 还是故障转移群集侦听器 ( nas.my.domain)，都会发生这种情况。

环顾四周后，我发现这是由于 SQL Server 由于与BULK INSERT.

如果您使用 Windows 身份验证连接到 SQL Server，则 SQL Server 服务帐户在连接到文件服务器时会尝试模拟您的用户帐户。如果您使用 SQL Server 身份验证进行连接，它将以 SQL Server 服务帐户的身份连接到文件服务器。

如果委派和模拟配置不正确（默认状态），SQL Server 服务将无法模拟您的用户帐户，并将退回尝试以匿名用户身份连接到文件服务器。

这可以通过查看文件服务器上的安全事件日志来确认。这些事实以及有关配置无约束和约束委派的指南记录在以下链接中：

• 如何：具有约束委派的 SQL Server 大容量插入（访问被拒绝）

• 批量插入和 Kerberos

我已经尝试按照thesqldude的指南中的说明进行操作，但它仍然无法正常工作。

我尝试使用的数据库BULK INSERT不是可用性组的一部分，因此只有 MSSQL1 节点应该相关。文件服务器在 …

我有一个查询在我们的服务器上运行大约需要 3 个小时——而且它没有利用并行处理。（大约 115 万条记录dbo.Deidentified， 300 条记录dbo.NamesMultiWord）。服务器可以访问 8 个内核。

  UPDATE dbo.Deidentified 
     WITH (TABLOCK)
  SET IndexedXml = dbo.ReplaceMultiWord(IndexedXml),
      DE461 = dbo.ReplaceMultiWord(DE461),
      DE87 = dbo.ReplaceMultiWord(DE87),
      DE15 = dbo.ReplaceMultiWord(DE15)
  WHERE InProcess = 1;

和ReplaceMultiword是一个过程定义为：

SELECT @body = REPLACE(@body,Names,Replacement)
 FROM dbo.NamesMultiWord
 ORDER BY [WordLength] DESC
RETURN @body --NVARCHAR(MAX)

是呼吁ReplaceMultiword阻止形成平行计划吗？有没有办法重写它以允许并行？

ReplaceMultiword 以降序运行，因为某些替换是其他替换的简短版本，我希望最长的匹配成功。

例如，可能有“乔治华盛顿大学”和另一个来自“华盛顿大学”。如果“华盛顿大学”比赛是第一场，那么“乔治”就会被甩在后面。

从技术上讲，我可以使用 CLR，只是我不熟悉如何使用。

查询存储强制计划功能似乎没有执行该计划。

我知道Query Store - Forced 并不总是意味着 Forced；然而，我的计划可能不会发生微不足道的变化，但查询优化器可能会继续选择不正确的索引、循环选择等。

基本上：它不尊重我被迫的计划选择。我强迫了很多计划，但它根本行不通。

1. 当我查看sys.query_store_plan force_failure_count.
2. 扩展事件query_store_plan_forcing_failed不会产生任何结果。0 事件。

例如，在 20.09 强制执行的计划。只有 1 个编译碰巧使用了强制计划。

计划大相径庭，一个使用带有 INDEX 1 的 Hash Match join，另一个使用带有 INDEX 2 的 Loop Join。

版本：Microsoft SQL Server 2016 (SP1-GDR) (KB3210089) - 13.0.4202.2 (X64)

我在这里缺少什么？

我们正在尝试让 Service Broker 在我们的环境中工作以解决业务案例。我不知道消息标题是否合适，但我的问题如下。但这可能不是一个好问题，所以在那之后是我们正在做的事情以及为什么我认为这是一个正确的问题。

在结束对话之前，应该在对话中发送多少条消息？

我们想使用 Service Broker 来异步更新结果表。结果表变平且快速。我们在基表上有触发器，它们发送带有表和主键的消息。我们有三个队列：

• 低延迟 - 目标是处理 15 秒。它处理与特定项目相关的更改项目。
• 批量队列 - 目标是处理 5 分钟。它处理影响数百（或数千）项的变化。它会列出受影响的项目并将它们提供给延迟低延迟队列。
• 延迟低延迟 - 目标是处理 30 分钟。这会处理项目，但仅来自批量队列。

基本上，如果客户的信息更新，则会影响许多产品，因此会被发送到批量队列以进行较慢的处理。但是，如果产品更新，则会将其发送到低延迟队列。

我们重用类似于 Remus Rusanu 的博客http://rusanu.com/2007/04/25/reusing-conversations/ 的对话，除了我们根据主键的模数来做。这具有辅助主键重复数据删除的附带好处。

因此，我们正在重复使用对话并且符合我们的指导方针。使用两个线程，我能够每秒处理 125 条消息（人工丢弃数千条消息），这足以跟上生产速度（估计为 15 条消息/秒）。

但是，我们遇到的问题是，经过一段时间（约 4 小时或 120K 条消息）后，我们开始在 sysdesend 和队列表中看到阻塞和高争用。锁是 LCK_M_U 和 KEY 锁。有时，hobt 解析为 sysdesend，有时解析为特定的队列表 (queue_)。

我们有一个流程可以在 24 小时或 30 分钟不活动后结束对话，我们可以增加对话循环之前的时间。

我们使用的是 SQL 2016 Enterprise (13.0.4001.0)

1. 触发火灾（发送到低延迟或批量）
2. 查找或创建会话句柄。
3. 发信息
4. 队列激活程序
5. 更新结果表

清理过程每 10 分钟运行一次，以查看是否有任何空闲对话。ltd 它连续发现它们超过 3 次，它将其标记为不活动并结束对话。

如果有任何可能有益的其他细节，请告诉我。我对 Service Broker 没有太多经验，所以我不知道我们的消息/秒是低、高还是无动于衷。

更新

所以我们今天再次尝试，遇到了同样的问题。我们将对话生命周期更改为 2 小时，但没有任何影响。所以我们然后实现了 …

我想看看是否有办法欺骗 SQL Server 为查询使用某个计划。

1. 环境

想象一下，您有一些在不同进程之间共享的数据。因此，假设我们有一些占用大量空间的实验结果。然后，对于每个过程，我们知道我们想要使用哪一年/哪月的实验结果。

if object_id('dbo.SharedData') is not null
    drop table SharedData

create table dbo.SharedData (
    experiment_year int,
    experiment_month int,
    rn int,
    calculated_number int,
    primary key (experiment_year, experiment_month, rn)
)
go

现在，对于每个过程，我们都将参数保存在表中

if object_id('dbo.Params') is not null
    drop table dbo.Params

create table dbo.Params (
    session_id int,
    experiment_year int,
    experiment_month int,
    primary key (session_id)
)
go

2. 测试数据

让我们添加一些测试数据：

insert into dbo.Params (session_id, experiment_year, experiment_month)
select 1, 2014, 3 union all
select 2, 2014, 4 
go

insert into …