标签: sql-server-2017

以纤程模式（轻量级池）运行 SQL Server会禁用 SQL CLR：

轻量级池不支持公共语言运行时 (CLR) 执行。禁用以下两个选项之一：“启用 clr”或“轻量级池化”。依赖 CLR 且在光纤模式下无法正常工作的功能包括层次结构数据类型、复制和基于策略的管理。

在另一方面，禁用SQL CLR单独（无实现了轻型池）并没有禁用内置的CLR类型，如geometry，和geography（虽然hierarchyid上面提到的），如图哪有“HIERARCHYID”类型的工作时，“CLR”被禁用?

现在一些新的语言特性依赖于CLR，例如该FORMAT功能：

FORMAT 依赖于 .NET Framework 公共语言运行时 (CLR) 的存在。

在光纤模式下运行 SQL Server 是否禁用该FORMAT功能和/或使用 CLR 类型？

如果我有一批两个不同的SELECT语句，是否可以并行执行它们（如果 SQL 优化器认为它是最有效的执行方法）？

如果第一个SELECT语句选择到临时表中，SELECT然后第二个语句插入到同一个临时表中，这是否会阻止两个语句并行运行？

（我猜答案是肯定的，是的 :)。

所以我正在研究一个代码高尔夫拼图，需要在保持当前顺序的同时向结果添加一个 INT“数字”列n。

假设我的源数据是：

SELECT value
FROM STRING_SPLIT('one,two,three,four,five', ',')

它以原始（所需）顺序返回项目：

value
-----
one
two
three
four
five

如果我尝试使用ROW_NUMBER()或RANK()我被迫指定一个ORDER BY，这value是唯一合法的选择：

SELECT value, n = ROW_NUMBER() OVER(ORDER BY value)
FROM STRING_SPLIT('one,two,three,four,five',',')

但这（如预期）按value字母顺序排序，而不是按所需的原始顺序排列：

value   n
------ ---
five    1
four    2
one     3
three   4
two     5

连接到数字表不起作用，因为如果没有WHERE子句，我将获得完整的外部连接。

我能想到的最好的方法是使用带有标识字段的临时表：

CREATE TABLE #argg (n INT IDENTITY(1,1), v VARCHAR(99))

INSERT #argg 
SELECT value v
FROM STRING_SPLIT('one,two,three,four,five',',')

SELECT *
FROM #argg …

这两个设置似乎相互矛盾。One 强制计划参数化，以便只创建一个计划。另一个允许多个计划

如果您有参数化 = 强制，参数嗅探应该是假的，还是优先？

额外细节

关于下面的评论，参数嗅探是SS 2016的数据库范围选项。（我也很惊讶）。另请参阅：SQLShack：SQL Server 2016 参数嗅探

查询：

    SELECT Object1.Column1, Object2.Column2 AS Column3, Object2.Column4 AS Column5, 
Object3.Column6, Object3.Column7,Object1.Column8, Object1.Column9, 
Object1.Column10, Object1.Column11, Object1.Column12, Object1.Column13, 
Object1.Column14, Object1.Column15 as Column15, Object1.Column16, 
Object4.Column4 AS Column17, Object4.Column2 AS Column18, Object1.Column19,
 Object1.Column20, Object1.Column21, Object1.Column22, Object1.Column23, 
Object1.Column24, Object1.Column25, Object1.Column26, Object5.Column4, 
Object1.Column27, Object1.Column28, Object1.Column29, Object3.Column30, 
Object3.Column1 as Column31, Object3.Column32 as Column33, Object1.Column34 
as Column34, ? AS Column35 , Object3.Column36 as Column37 
FROM Object6 AS Object1 
INNER JOIN Object7 AS Object3 ON Object1.Column38 = Object3.Column1 
INNER JOIN Object8 AS Object2 ON Object3.Column30 = Object2.Column1 
LEFT JOIN …

我创建了一个分区表（如下所示），并播种了 4.8 亿行 - 每个帐户大约 181 行。

我在添加索引之前运行基线查询。我很惊讶地看到，即使在添加option(recompile). 分区表就是这样吗？在我看来，这更像是现实生活，而不是对谓词的分区列值进行硬编码。

• 出现分区消除的查询的实际执行计划。

• 未消除分区的查询的实际执行计划。

最终，如果我对此有疑问，我将添加索引并在此处发回。在我对这篇文章中给出的答案感到满意之前，我不想继续。

    --step 2 (after creating db)
    ALTER DATABASE partitionresearch
    ADD FILEGROUP January
    GO
    ALTER DATABASE partitionresearch
    ADD FILEGROUP February
    GO
    ALTER DATABASE partitionresearch
    ADD FILEGROUP March
    GO
    ALTER DATABASE partitionresearch
    ADD FILEGROUP April
    GO
    ALTER DATABASE partitionresearch
    ADD FILEGROUP May
    GO
    ALTER DATABASE partitionresearch
    ADD FILEGROUP June
    GO
    ALTER DATABASE partitionresearch
    ADD FILEGROUP July
    GO
    ALTER DATABASE partitionresearch
    ADD FILEGROUP August
    GO
    ALTER …

我有一个客户，他拥有一个现有的 1.5Tb 数据仓库，目前正计划在新环境中完全更新 DW。他们的基础架构经理组织了 2 个服务器，每个服务器都采用 SQL 2017 标准，现在要求我为新的 DW 数据库/实例规划一个 HA/DR 计划。

我立即想到了使用 AlwaysOn 可用性组，尽管我以前从未使用过它们，而且我读过的文章都没有讨论典型的数据仓库工作负载——都是 OLTP 应用程序。在当前 DW 上运行大型每日 ETL 流程和较小的日内 ETL 流程时，这是否会影响我们处理此问题的方式？

谢谢 - 在这里为我指明正确方向的任何帮助都是有益的！

我有一个非常大的表（> 10M 行），经常进行 crud 操作。它有适当的索引，但它们很快就会碎片化。如果没有定期的索引重组/重建维护计划，索引碎片很容易超过 90%。

现在我已经通过每天重新组织索引和每周重建来解决这个问题。我还使用了填充因子等来降低碎片化。

我的主要问题是，当索引过于分散时，SQL Server 会忽略索引并执行全表扫描。当这种情况发生时，它几乎杀死了应用程序，因为重复扫描如此大的表真的很繁重。我很确定在这些情况下使用碎片索引会更快。

有没有办法让 SQL Server 使用索引而不管它的碎片如何？

我有一项任务要更新生产表中的 500 万行，而无需长时间锁定整个表

所以，我使用了多次帮助我的方法 - 一次更新前 (N) 行，块之间的间隔为 1-N 秒

这次从一次更新前 (1000) 行开始，监视扩展事件会话中的lock_escalation事件

lock_escalation在每次更新操作期间出现，所以我开始将每个块1000 -> 500 -> 200 -> 100 -> 50行的行数降低到 1

之前（不是使用这个表，并且对于删除操作 - 不是更新），将行数降低到 200 或 100，有助于摆脱lock_escalation事件
但是这一次，即使每 1 次更新操作有 1 行，表lock_escalation仍然显示。每次更新操作的持续时间大致相同，无论是一次 1 行还是 1000 行

在我的情况下如何摆脱表锁升级？

@@TRANCOUNT 为零

扩展事件：

代码：

set nocount on

declare 
    @ChunkSize              int = 1000,                         -- count rows to remove in 1 chunk 
    @TimeBetweenChunks      char(8) = '00:00:01',               -- interval between chunks
    
    @Start                  datetime,
    @End …

为了防止XY 问题，这是我们要解决的实际问题：

问题：

不幸的是，我们有一堆查找表，它们是在主键上使用标识列创建的，这是一个int. 我们希望可以简单地删除身份，但是，我们有一些带有指向身份列的外键的大型表，我的理解是在这种情况下删除身份很困难。我们对身份感到遗憾的原因是因为这些表需要跨多个环境同步，而开发人员通过编写脚本将数据插入到这些表中，而我们在多个环境上运行这些脚本但不一定总是按照相同的顺序，所以我们问开发人员始终：

1. 启用身份插入
2. 插入具有硬编码整数 ID 的行
3. 禁用身份插入

如果每个人都这样做，数据要么保持同步，要么脚本失败，我们可以立即采取纠正措施来解决冲突。当然，有时开发者忘记遵守规则，直接无标识地插入，不同环境下以不同顺序运行的不同脚本的自动增量导致它们不同步，从而出现问题。

一个想法：

我们可以强制开发人员始终指定标识列吗？我认为没有办法简单地禁用这些表上的身份。如果我们将身份重新播种到较低的数字会怎样？当种子值已经存在时，任何未指定所有列的插入都会失败，并且会继续失败，直到插入尝试的次数超过现有（连续）行的数量。但是，在一次正确的插入之后，就会重新为表设定种子，下一次不正确的插入将再次使用自动增量。因此，这个想法的推断是在每次插入后（也许使用触发器，这感觉很奇怪，但可能有效？），或者按计划，或者可能每次我们运行开发人员的脚本时，将表重新设置为一个较低的现有数字。

这是一个合理的想法，和/或有更好的解决方案吗？

旁注：我们确实有一些其他想法，我认为这些想法超出了这个问题的范围，例如：

1. 门控签入将解析脚本以插入某些表而不指定标识列，如果我们检测到这一点，则会失败。
2. 将所有这些数据存储在源中并在部署时更新整个表。（而不是使用运行一次插入脚本。）
3. 不要运行在所有环境上更改这些表的数据脚本，而是使用复制或其他同步机制。

尽管从长远来看，这些其他想法可能会更好，但似乎最容易实现的目标只是重新播种这些表，因此不正确的插入将会失败。