标签: sql-server-2019

我们一直在 SQL Server 2019 (CU2) 机器上试验 Polybase，使用 SQL Server 外部数据源，但性能并不好 - 在大多数情况下提高了 1400%。在每种情况下，我们查询的所有表/视图都来自指向同一外部数据源的外部表。我们尝试过运行在本地框上分解的查询，并使用与作为外部表拉入的视图相同的查询。我们还将来自远程服务器的每个统计数据脚本化到外部表上，没有任何变化。您可以使用示例查询在下面看到性能差异。

服务器在资源方面设置相同：32GB 的 RAM、8 个 vCPU、SSD 磁盘，并且没有其他正在运行的查询。我尝试过两台不同的远程服务器，一台运行带有最新 SP/CU 的 SQL Server 2016，另一台运行 CU2 的单独 2019 机器。服务器是在同一台主机上运行的虚拟机，我们已经排除了任何类型的主机争用。

示例查询：

SELECT
     StockItem_StockNumber, BlanktypeId, NameHTML, BackgroundStrainName, IsExact, IsConditional
     ,ROW_NUMBER() Over(Partition By StockItem_StockNumber, BlanktypeId Order By pt.Name, p.Name, gptr.Text) as row_num
     ,pt.Name as Level1, p.Name as Level2, gptr.Text as Level3, MGIReference_JNumber
     ,gptr.Type as Level3Type  
FROM
     StockItemBlanktypes sig
     INNER JOIN Blanktypes g on g.BlanktypeId = sig.Blanktype_BlanktypeId
     INNER JOIN BlanktypeStockTerms gpt on gpt.Blanktype_BlanktypeId = g.BlanktypeId …

升级到 SQL Server 2019 后，我们在 beta 环境中遇到异常错误。从标量值函数中进行选择时会发生这种情况。在我们运行 SQL 2014 的生产环境中不会发生此错误。

声明是：

select function(1234567)

错误信息是：

消息 229，级别 14，状态 5，第 1 行
对象“函数”、数据库“数据库”、架构“dbo”的 SELECT 权限被拒绝。

功能是：

CREATE FUNCTION [dbo].[function](@var1 INT)
RETURNS BIT
BEGIN
    DECLARE @var2 BIT, @var3 BIGINT, var4 INT
    SET @var2 = 0

    SELECT @var3= ISNULL(tbl2.field1,tbl3.field1) FROM tbl1 
    LEFT OUTER JOIN tbl2 WITH (NOLOCK) ON tbl2.field2 = tbl1.field2 
    LEFT OUTER JOIN tbl3 WITH (NOLOCK) ON tbl3.field2 = tbl1.field2
    WHERE tbl1.field2 = @var1

    SELECT @var4 = ISNULL(field4,1) FROM linked_server.database.dbo.tbl4 WHERE field5=Convert(VARCHAR(20),@var3)
    IF(@var4 …

设想\n我们正在将 SQL 资产升级到 SQL Server 2019，并已设置生产环境。

来自：\nSQL2008R2 Standard/Windows Server 2008R2 - 主服务器/辅助服务器（Windows 故障转移群集）和报表服务器（事务复制）。

至：\nSQL2019 Standard/Windows Server 2019 - 主服务器/辅助服务器（始终开启）和报表服务器（事务复制）

2008R2 的备份已于 2019 年恢复，兼容性级别设置为最新。始终在线设置相对顺利，针对当前应用程序的初步测试未显示兼容性问题。

问题纯粹在于设置事务复制。有 2 个数据库需要复制，每个数据库都有一个发布，主数据库作为发布者和分发者。

问题\n在报告服务器上每个数据库的订阅初始化期间，它运行良好，直到到达创建函数并产生以下错误为止。

第一个数据库：

\n

消息：选项“INLINE=ON”对此功能无效。检查函数中 INLINE 选项支持的构造的文档。\n 命令文本：CREATE FUNCTION [dbo].[f_clienttels - 镜像复制 ce2d3663eb494f3589bd5000dad1bf1f](@ClientID [int])\n RETURNS varchar WITH INLINE = ON, EXECUTE AS CALLER\n AS \n BEGIN ......

\n

第二个数据库：

\n

消息：为语句“CREATE/ALTER FUNCTION”指定了无效选项。\n 关键字“with”附近的语法不正确。如果此语句是公用表表达式、xmlnamespaces 子句或更改跟踪上下文子句，则前一个语句必须以分号终止。\n \')\' 附近的语法不正确。\n 命令文本: CREATE FUNCTION [dbo] .[GetGroupAndDescendantGroupsSelective - 镜像复制 46f329d5eed444428f45b052f07c7ea8](@GroupId …

我们刚刚从 SQL Server 2008 R2 升级到 SQL Server 2019（兼容性级别 150）。

我们有两个不同的存储过程在升级后开始失败，错误消息如下：

Msg 8632, Level 17, State 2, Procedure BuildSelfSaleStats, Line 14 [Batch Start Line 4]
Internal error: An expression services limit has been reached. Please look for potentially complex expressions in your query, and try to simplify them.

真正奇怪的是，这个特定的存储过程不带任何参数，当我们简单地在 SSMS 中执行 SQL 代码主体时，它工作得很好（！？）。

什么可能会导致某些在 SSMS 中执行时工作正常的 SQL 代码在包装在存储过程中时突然开始失败？

我们设法将错误隔离到我们拥有的日期格式化函数：

这在 SSMS 中运行时有效：

select dbo.fn_formatdatetime(DATEADD(month, -6, GETDATE()), 'yyyy-mm')
output:
(No column name)
2019-12

但是当在 testproc 中调用时，它失败了：

CREATE PROCEDURE testproc
AS
BEGIN …

重现问题的步骤

创建具有内存优化文件组和容器的数据库 使用非集群 pk 创建仅模式内存表 模拟插入和删除活动。我的结果是我有高索引未使用的内存，不会下降。

 USE master
 go
 DROP DATABASE IF EXISTS MemoryOptimizedTest
 CREATE DATABASE MemoryOptimizedTest
 GO
 USE MemoryOptimizedTest
 GO
 ALTER DATABASE MemoryOptimizedTest 
 ADD FILEGROUP imoltp_mod CONTAINS MEMORY_OPTIMIZED_DATA
 GO 
 
 ALTER DATABASE MemoryOptimizedTest ADD FILE (name='imoltp_mod1', filename='c:\imoltp_mod1') TO FILEGROUP imoltp_mod
 GO
 
 
 DROP TABLE IF EXISTS dbo.MyCache
 CREATE TABLE dbo.MyCache
 (
    PK int NOT NULL, 
    SecondInt int NOT NULL,
    ThirdInt int NOT NULL,
     CONSTRAINT PK_MyCache PRIMARY KEY NONCLUSTERED (PK)
 ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY)
 
 go

/* Generate activity …

我们正在将多个 ETL 过程从 SQL Server 2016、Windows 2012 服务器转换为 Windows 2019、SQL Server 2019 (CU8) 环境。

一个进程在 SQL Server 2019 中的运行时间比在 SQL Server 2016 中的运行时间长。该进程执行一个INSERT into B, select x from A, wherex是一系列子字符串和 case 语句。

表 A 基本上包含 1 个数据列，6,000 字节长。表 B 由 950 多个数据列组成。我将平面文件中的数据批量插入到表 A 中，然后使用各种子字符串命令将数据解析到表 B 中。

表 A 包含 470 万行并在 47 分钟内加载，为了测试目的我拆分了 100 万行，并在 10 分钟内加载。

在我的 SQL Server 2016、Windows 2012 服务器上，满载运行时间为 12 - 14 分钟，而 100 万次采样运行时间为 1 分 51 秒。

为了咧嘴笑，我在我的 ETL 2019 …

在过去的几个月里，我的 SQL Server 2019 服务器运行良好，但自上周五以来它开始自行停止。今天早上，我在上面安装了最新的累积更新。

这是我的版本

Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64) 2020 年 11 月 2 日 18:35:09 版权所有 (C) 2019 Microsoft Corporation Developer Edition（64 位），Windows Server 2019 Standard 10.0（内部版本 17763：）（管理程序）

我也遇到了 SQL Server 2019 标准版 (RTM-CU8-GDR) 的问题。

每次都会创建一个小型转储。分析转储后，我可以看到内核基础异常。

这台服务器只运行 SQL Server，我没有在机器上运行更多的东西。

在 SQL 的日志文件中，我看到在此消息之后进行了转储。

在 Windows 事件查看器中，我只有一条错误消息，指出 SQL 正在停止。

就在那个错误之前，我有关于 SQLException64 的树“Windows 错误报告”错误。

重新启动 SQL Server 不会改变任何东西。但是，如果我打开 SQL 管理控制台并启动 SQL 服务，它就可以正常启动。

我真的不知道在哪里检查，如何进一步诊断。

这是迷你转储文件。

2021-01-18 10:15:18.56 spid58      ex_terminator: Possible termination due to exception during stack unwinding. …

有什么方法可以识别哪个存储过程在 tempDB 中创建表变量？

我正在查看 sys.dm_db_index_operational_stats 中的 forward_fetch_count，我们有几个表的计数非常大（最大的超过 1.33 亿）。表名以 # 后跟 8 个十六进制字符的形式出现在 tempDB 中。有没有办法将其追溯到原始流程，以便我们修复它？

我们在 Linux 上运行 SQL 2019。

谢谢，埃文

可以在模型数据库上启用查询存储，并确保每个新数据库都具有与模型数据库相同的设置。

缺少 GUI 选项

但可以使用 TSQL 启用它

ALTER DATABASE model
SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);

由于没有 GUI，我无法检查那里的默认设置。

再次使用TSQL

USE model;
select * from sys.database_query_store_options;

返回空结果

当我创建一个新数据库（使用模型作为模板并查询设置时，它会显示结果）

create database TestQs;
go
use TestQs;
select * from sys.database_query_store_options;

此外，设置必须保存在某处，因为当我更改查询存储选项时，更改会传播到新数据库

ALTER DATABASE model
SET QUERY_STORE (INTERVAL_LENGTH_MINUTES = 22);

我尝试过使用 SMO 来找到这些选项，但没有成功。

$SqlServer = New-Object Microsoft.SqlServer.Management.Smo.Server -ArgumentList 'localhost'
$sqlServer.Databases['TestQs'].QueryStoreOptions

但对模型数据库进行相同的查询不会产生任何结果

$SqlServer = New-Object Microsoft.SqlServer.Management.Smo.Server -ArgumentList 'localhost'
$sqlServer.Databases['model'].QueryStoreOptions

有没有一种方法可以检查模型数据库上的查询存储设置，而无需创建新数据库并在那里进行检查？