标签: sql-server-2017

我们最近从 LogShippingstandby/read-only设置迁移到具有可读辅助设备的多子网 AG 设置。

通常，在旧设置中，我们会选择运行较长时间的查询，因为相关数据库超过 20 TB，并且主数据库上有混合读写工作负载。

在转移到 AG 的新设置后，我们开始看到我无法理解的阻塞。为什么辅助选择查询会阻止我的可读辅助副本实例中的其他选择查询，即使正在查询的数据库有RCSI enabled？

以下是我捕获的内容

• 主要阻止程序是一些长时间运行的SELECT查询，不会显示任何特定的等待类型，例如 SPID129

• SPID 129阻止会话 ID 45（我确信这不是用户 ID）近 6 小时，这取决于 spid129 并且等待类型是 LCK_M_SCH_M

• SPID 45当这在 6 小时的持续时间内阻止所有其他选择查询时，问题就来了。

我无法理解发生了什么。有人可以帮助我排除故障或寻找正确的方向吗？

我们最近将 AOAG 集群故障转移到了次要区域。在第一个区域，我们的盒子有 32 个核心，而在第二个区域，我们有 64 个核心。流量相似，但是在较大的机器上，我们在 sys.dm_os_workers 中运行更多数量的工作线程（以及 sys.dm_os_threads 中的线程）。这是提高 CPU 核心时的预期行为吗？还是我们应该担心所有这些闲置的工作人员？

我们正在运行 SQL Server 2017 CU 24。

max worker threads配置为0（默认值）。

max degree of parallelism在两个区域都配置为2。

在当前服务器中，我们看到以下计数：

在频繁执行的存储过程（有时每秒高达 10-15 次）中，有两个特定语句出现在累积 CPU 影响排名前 10 的最重查询中

这些是创建 #Temp 表的 DDL 语句：

1.

SELECT cast(0 as int) as rowId
     , Column1 as tColumn1
     , Column2 as tColumn2
     , ...
     , Column14 as tColumn14
     , cast(0 as datetime) as tUTC
     , -1 as tRefId
INTO #TempTable1
FROM Table1 WITH(NOLOCK)
WHERE 0=1

SELECT    tColumn1, ..., tColumn14, tUtc, tRefId
INTO    #TempTable2
FROM    #TempTable1
WHERE    0=1

上述任何 DDL 平均需要 10-15 毫秒的 CPU 时间，只需创建一个 #temp 表
更改存储过程的逻辑，使其不创建临时表，不是一个选项

问题：如何加快临时表的创建时间（就 CPU 时间而言）？

我有一个查询应用程序使用文本字段扫描整个表格。

该查询正在执行以下多次读取：

扫描计数 1、逻辑读取 170586、物理读取 3、预读读取 174716、lob 逻辑读取 7902578、lob 物理读取 8743、lob 预读读取 0。

具有 lob 逻辑读取的查询计划

如果我从选择中删除文本字段，则读数将变为以下内容：

扫描计数 1、逻辑读取 170588、物理读取 0、预读读取 0、lob 逻辑读取 0、lob 物理读取 0、lob 预读读取 0。

没有 lob 逻辑读取的查询计划

我不明白的是 lob 读取是如何工作的：

如果我用 lob 逻辑读取来总结逻辑读取，我总共得到8.073.164 逻辑读取，如果我是正确的，大约是 64GB。

但整个数据库只有7GB！

我可能遗漏了一些有关添加逻辑读取和 lob 逻辑读取的信息。

lob 逻辑读取数实际代表什么？

我们的一位 DBA 向我们的团队抱怨说，他注意到大约有十几个睡眠连接实际上是永久性的。它们中的每一个都表示一个非常短的查询（单个记录中的单个记录通过其集群 PK 过滤返回）。

我的假设是，原因是 ADO.NET 连接池的使用以及经常进行相同查询的应用程序。

我试图找出这些睡眠连接是否会对 SQL Server 性能产生有意义的影响。默认情况下，ADO.NET 连接池的连接数限制为 100 个，因此我的假设是十几个休眠连接应该可以忽略不计。

我只能在这个线程中找到信息：

每次睡眠的最低成本约为 32kb RAM - 非常非常适中！

CPU 开销可能会产生一些微小的额外成本，但即使对于 10,000 个会话，也几乎无法检测到。

在会话/连接开销方面，SQL Server 表现得非常好！

这些信息准确吗？

在这里，我面临着存储过程中的特定语句出现的性能问题，该存储过程有时有很多语句

SP 每秒执行一次，通常完成时间不到 50 毫秒，但在出现问题时（可能每月一次，或每周几次 - 随机）要长得多，直到重新编译

SP有2个输入参数
SP供不同的应用使用

每个语句通常在约 1 毫秒内完成，但在出现问题时需要更长的时间

我必须承认我对什么是参数嗅探以及如何修复它只有初学者的了解。
绝对应该在教育上投入更多的时间，但在我的国家发生的所有事情都很难做到，请不要对我太严格

最常出现问题的一种说法：

UPDATE MyTable SET tMax = 0 
      WHERE tMax = 1
      and tID in (SELECT b8 FROM #e538)

在出现问题时，此更新语句有大量 LCK_M_U 等待，并开始与从不同会话执行的完全相同的语句发生死锁

另外两个说法：

INSERT #e534 (b4, d4, s4, r4)
SELECT tID, tDate, tStatusID, ID
FROM MyTable
WHERE tStatusID = (SELECT min(tStatusID) 
                    FROM MyTable as f, LMyTable 
                    WHERE tID = MyTable.tID 
                          and tType = 1 
                          and ltID = tStatusID 
                          and ltComplete = 1 AND tActive = 1)
and …

我有一张小桌子，只有几行

create table dbo.p(i int);
insert dbo.p(i)
values (1), (2), (3), (4), (4);

我创建了统计数据；没有索引，只有统计数据。

create statistics p_c on dbo.p(i) with fullscan;

我正在调查各种事情，所以我尝试将 ROWCOUNT 设置为 bigint 的上限。

update statistics dbo.p p_c with rowcount = 9223372036854775807;

此操作失败并显示错误消息

消息 3739，级别 11，状态 3，第 346 行
无法更新索引“p_c”，因为它不是统计信息集合。

ROWCOUNT = 1;尽管成功了，但它也失败了update statistics dbo.p p_c。

该错误不在文档中。我在网上找不到任何相关的内容。

与普通的表统计数据相比，什么是统计数据收集？为什么设置 ROWCOUNT 可能会在这里失败？

SQL Server 2017 (RTM-CU31-GDR) (KB5021126)

我有一个 SQL Server 2017 之前的数据库，我恢复到/升级到 SQL Server 2017。在这个数据库中，我有一个 SQLCLR 程序集。程序集被标记为SAFE因为它不执行任何需要更高级别权限的操作，并且数据库已TRUSTWORTHY禁用 / OFF。SQLCLR 函数和存储过程在迁移到 SQL Server 2017 之前按预期工作，但现在当我尝试执行其中任何一个时，我收到以下错误：

消息 10314，级别 16，状态 11，服务器 XXXXXXXXXXX，行 YYYYYY
      在 Microsoft .NET Framework 中尝试加载程序集 ID ZZZZZ 时出错。服务器可能会耗尽资源，或者程序集可能不受信任。再次运行查询，或检查文档以了解如何解决程序集信任问题。有关此错误的更多信息：
      System.IO.FileLoadException：无法加载文件或程序集“{assembly_name}”，版本=0.0.0.0，Culture=neutral，PublicKeyToken=null”或其依赖项之一。发生与安全相关的错误。（来自 HRESULT 的异常：0x8013150A）

我已确认已在服务器/实例上启用 CLR 集成/SQLCLR。

升级还是新建？有什么建议？有没有人有任何关于这个过程的陷阱或战争故事要分享？

我们在 Prod 中有一个 2012 实例，它同时具有 OLTP 和 OLAP 数据库。我们正在创建两个实例，一个专用于这些任务中的每一个。OLAP 实例是一个新版本，但是为了最大限度地减少最终用户停机时间，我们正在考虑升级将容纳 OLAP 数据库的实例。

我正在寻找超出我在 Microsoft 文档中阅读的内容的一般建议。

我有一个在 SQL Server 2017 Express 上运行的测试环境，它只使用最近的数据（一个作业每月一次删除超过三个月的数据）。

该作业执行以下操作：

1. 使用 while 循环，它删除了超过三个月的数据
2. 缩小数据库，如果其大小高于某个阈值
3. 重新索引所有表

这篇文章描述了由于索引碎片而缩小数据库是多么糟糕，以及为什么重新索引也需要额外的空间。

上次运行从 9GB 数据库开始。删除需要 3-4 分钟，重新索引大约需要 30 秒。数据库减少到大约 5GB。

由于这是一个测试环境，我可以承受这种停机时间而不会出现任何问题。

问题：在删除了很大一部分数据后收缩 + 重新索引是不是很糟糕？