标签: sql-server-2019

我目前正在努力升级到 SQL Server 2019，以便利用其中可用的图形功能。我们的数据库存储文件及其子文件的记录，图形特征使我们能够快速找到文件在任一方向的所有关系。我们当前的开发环境在 Linux 服务器上使用 SQL Server 2019 Standard (15.0.4023.6)。

我在运行图形查询时注意到一个令人担忧的问题。服务器的“内部”资源池在图形查询后似乎没有释放所有资源。如果不选中，这会填满资源池。在重新启动 SQL Server 进程之前，较大的查询将失败。根据服务器负载，这可能会在短短 1-2 小时内发生。这也会填满 tempdb 并威胁填满存储驱动器。在服务器重新启动之前，tempdb 的文件也不能显着缩小/截断。在配置中，'memory.memorylimitmb'没有设置，所以当资源池开始使用默认80%的系统内存（12.8GB，16GB系统内存）中的大部分时，就会出现这个问题

要在演示数据库中设置表：

CREATE TABLE FileNode (ID BIGINT NOT NULL CONSTRAINT PK_FileNode PRIMARY KEY) AS NODE

GO

CREATE TABLE FileNodeArchiveEdge AS EDGE

GO

CREATE INDEX [IX_FileNodeArchiveEdge_ChildFile] ON [dbo].[FileNodeArchiveEdge] ($from_id)

GO

CREATE INDEX [IX_FileNodeArchiveEdge_ParentFile] ON [dbo].[FileNodeArchiveEdge] ($to_id)

GO

填充演示数据库表：

INSERT INTO [FileNode] (ID) VALUES
            (1),(2),(3),(4),(5),
            (6),(7),(8),(9),(10),
            (11),(12),(13),(14),(15)

-- Convenient intermediate table
DECLARE @bridge TABLE (f BIGINT, t BIGINT)
INSERT INTO @bridge (f, t) …

前几天有人问我，如果 SQL Server 想要运行一个查询，而该查询被授予的内存多于实例可用的内存，会发生什么情况。我最初的想法是我可能会看到RESOURCE_SEMAPHORE等待并且查询永远不会开始。

我做了一些测试来试图找出答案。

我的实例以 4000MB RAM 启动：

EXEC sys.sp_configure N'max server memory (MB)', N'4000'
GO
RECONFIGURE WITH OVERRIDE
GO

如果我然后运行我的（故意可怕的）查询：

USE StackOverflow
SELECT      CONVERT(NVARCHAR(4000), u.DisplayName) AS DisplayName,
            CONVERT(NVARCHAR(MAX), u.DisplayName) AS Disp2,
            CONVERT(NVARCHAR(MAX), u.DisplayName) AS Disp3
FROM        dbo.Users AS u
            JOIN dbo.Posts p
                ON LTRIM(u.DisplayName) = LTRIM(p.Tags)
WHERE       u.CreationDate >= '2008-12-25'
            AND u.CreationDate < '2010-12-26'
ORDER BY    u.CreationDate;

执行计划显示授予的内存为 732,008KB。

然后，我将实例可用的内存设置为低于此数字，然后重新启动实例：

EXEC sys.sp_configure N'max server memory (MB)', N'500' /* a value lower than the previous memory …

比方说

您有一个接受日期时间数组的存储过程，这些数组被加载到临时表中，并用于过滤表中的日期时间列。

\n
• 可以插入任意数量的值作为开始日期和结束日期。
\n
• 日期范围有时可能会重叠，但这不是我经常依赖的情况。
\n
• 也可以提供带有时间的日期。
\n

编写查询来执行过滤的最有效方法是什么？

设置

USE StackOverflow2013;\n\nCREATE TABLE\n    #d\n(\n    dfrom datetime,\n    dto datetime,\n    PRIMARY KEY (dfrom, dto)\n)\nINSERT\n    #d\n(\n    dfrom,\n    dto\n)\nSELECT\n    dfrom = \'2013-11-20\',\n    dto =   \'2013-12-05\'\nUNION ALL\nSELECT\n    dfrom = \'2013-11-27\',\n    dto =   \'2013-12-12\'; \n\nCREATE INDEX\n    p\nON dbo.Posts\n    (CreationDate)\nWITH\n    (SORT_IN_TEMPDB = ON, DATA_COMPRESSION = PAGE);\n

询问

我能得到的最好的就是EXISTS像这样使用：

SELECT\n    c = COUNT_BIG(*)\nFROM dbo.Posts AS p\nWHERE EXISTS\n(\n    SELECT\n        1/0\n    FROM #d AS d\n    WHERE p.CreationDate …

我在 MSSQL 2019 Enterprise CU1 之上安装了全新的 SQL Server Reporting Services 2019。除了应使用的服务帐户外，SSRS 已使用默认设置进行安装和配置。AD 和 MSSQL 实例都仅以最低权限配置（或接近此状态）。当我访问 Web 门户时，我收到一条错误消息，提示“请稍后再试”，这没有多大帮助。我发现许多类似的帖子就同一问题寻求帮助，但想在这里看到答案。

我们在 2 台新物理机上的新 SQL Server 2019 有一个非常奇怪的问题：

基础结构：在 2 台新物理机（用于 AlwaysOn 副本）上开始新安装 SQL Server 2019 Enterprise（Windows Server 2019 Standard 10.0 / Build 17763 上的 15.0.2000.5 / X64）。新机器是联想：

• ThinkSystem SR630 – [7X02CTO1WW]
• 1 个 CPU：1 个 Xeon Gold 6208U – 2.90 Ghz（16 核 x 2 – 超线程）
• 256 Gb 内存 (32 Gb x 8)

该问题系统地出现在 2 台新机器上......

测试：产生故障的测试如下：

1. 创建数据库
2. 扩大数据库文件并切换到简单恢复模式
3. 表的创建
4. 用 100 万行填充表格
5. 测试请求的执行（聚合时间间隔的计算 - 折叠）

正是最后一个查询（执行了近 10 次）经常导致出现以下消息的错误：

消息 601，级别 12，状态 1，行……由于数据移动，无法使用 NOLOCK 继续扫描。

当然，我们从未实现过NOLOCK提示或 …

我正在 SQL Server 2019 CU14 上进行测试。考虑针对兼容级别为 130 或 140 的 SQL Server 数据库创建的以下表值函数：

-- requires database compat 130 or 140 to see the issue
CREATE OR ALTER FUNCTION [dbo].[TVF_BUG_REPRO_2] (@O DateTime, @Z varchar(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
SELECT
CAST(
       CASE
              WHEN SZ.Zone1 > '' THEN (@O at time zone SZ.Zone1) at time zone 'Pacific Standard Time' 
              WHEN LEN(@Z) > 3 THEN (@O at time zone @Z) at time zone 'Pacific Standard Time'
              ELSE @O
       END AS DATETIME
) …

问题陈述我刚刚在示例 WideWorldImporters 数据库上
运行。dbcc checkdb当我运行此命令时，我收到了 (4) 个有关统计数据损坏的错误，我不记得过去曾见过这些错误。虽然这只是一个示例数据库，但我很好奇，因为我不想在真实的数据库中看到类似的错误。

SSMS 和 Windows 版本
SSMS：18.10 (15.0.18390.0) / Windows 10：版本 21H1（操作系统内部版本 19043.1526）

SQL Server 开发人员版本
Microsoft SQL Server 2019 (RTM-CU13) (KB5005679) - 15.0.4178.1 (X64) 2021 年 9 月 23 日 16:47:49 版权所有 (C) 2019 Microsoft Corporation Developer Edition（64 位），适用于 Windows 10 Pro 10.0 （内部版本 19043：）

SSMS 中发出的命令：

dbcc checkdb ([WideWorldImporters]) with all_errormsgs, data_purity, extended_logical_checks , no_infomsgs;  
go

错误信息

消息 9122，级别 16，状态 201，第 10 行
统计信息“sys.TT_OrderIDList_22AA2996.PK__TT_Order__C3905BAE80B57D6F”已损坏。
消息 9122，级别 16，状态 201，第 10 行 …

我正在尝试将存储过程配置为 EXECUTE AS 具有 sysadmin 权限的用户，以允许非特权用户从未记录的 TVF 获取结果sys.fn_dump_dblog。

我正在作为角色成员创建该过程sysadmin，但是当我随后尝试使用该子句运行该过程时WITH EXECUTE AS SELF，出现以下错误：

消息 9011，级别 14，状态 1，过程 dbo.read_log，第 16 行 [批处理开始第 65 行] 用户无权使用虚拟表 DBLog 查询备份文件。只有 sysadmin 固定服务器角色的成员才有此权限

这对我来说似乎很奇怪，因为我是服务器角色的成员sysadmin，并且WITH EXECUTE AS SELF在过程定义中指定子句应该会导致使用我的用户帐户执行该过程。根据学习网站：

EXECUTE AS SELF 相当于 EXECUTE AS user_name，其中指定的用户是创建或更改模块的人。创建或修改模块的人员的实际用户 ID 存储在 sys.sql_modules 或 sys.service_queues 目录视图的execute_as_principal_id 列中。

如果我WITH EXECUTE AS SELF从过程的定义中删除该子句，TVF 将按预期返回结果。

以下是SQL Server 2019 中的最小、完整且可验证的示例。

首先，证明我们是该sysadmin角色的成员：

USE [master];
GO
SELECT 
      [roles].[name]
FROM sys.server_principals [members] …

我对为什么我的查询没有使用我认为是选择性索引的东西感到非常困惑。

我的模型由索赔、联系人和电话号码组成。每个索赔有 1 个联系人，每个联系人都有许多电话号码。索赔可以有状态，电话号码有类型。

我在状态的 Claim 上添加了一个索引，它包括 ContactID。

create index Status on tClaim(Status) include (Name,ContactID)

我在电话上为 ContactID 和类型添加了一个索引，其中包括号码。

create index ContactID_Type on tContactPhone(ContactID,Type) include (Number)

我正在尝试编写一个查询，该查询返回状态为“赢得”的所有索赔以及索赔联系人的相应“家庭电话”。我已经尝试了 2 种方法。一种包括加入通讯录，另一种没有。两者都不会产生我期望的计划。

select 
    c.ID,
    c.Name,
    p.Number 
from
     tClaim c 
     left join tContactPhone p on
        c.ContactID=p.ContactID and p.Type='Home'
where
    c.Status = 'Won'

select 
    c.ID,
    c.Name,
    p.Number
from
     tClaim c
     inner join tContact co on  
        co.id=c.ContactID
     left join tContactPhone p on
        co.ID=p.ContactID and p.Type='Home'
where
    c.Status = 'Won'

我回来的计划拒绝使用 tContactPhone.ContactID_Type。它建议按类型索引，这没有意义，因为它似乎没有 ContactId 选择性。

粘贴计划

这是我用来创建要测试的示例数据集的脚本。请注意我的实际数据集要大得多，命名得更好，并且有更多的字段；但这被提炼出来以复制我的情况 [AKA 我什至不喜欢命名约定和数据生成，但它完成了工作:)] …

我正在考虑以下场景：

• 在 Windows Server 2016 上运行的 MSSQL Server 2019 Standard。
• sys.dm_os_schedulers 显示 12 个可用的逻辑 CPU 核心。
• 这 12 个核心分布在 2 个插槽中。
• 尽管它们位于 2 个套接字上，但它们似乎位于同一个 NUMA 节点上（服务器由 VMWare 虚拟化）（coreinfo 输出）：

*-----------  Physical Processor 0
-*----------  Physical Processor 1
--*---------  Physical Processor 2
---*--------  Physical Processor 3
----*-------  Physical Processor 4
-----*------  Physical Processor 5
------*-----  Physical Processor 6
-------*----  Physical Processor 7
--------*---  Physical Processor 8
---------*--  Physical Processor 9
----------*-  Physical Processor 10
-----------*  Physical Processor 11

Logical Processor to …