标签: sql-server-2017

我们最近将生产设施升级到 SQL Server 2017，并迁移到无集群可用性组。有一个主要设备、一个现场辅助设备和一个远程辅助设备。我们遇到与远程辅助同步的周期性中断。带宽低至6G，sql流量与所有其他流量竞争。好消息是AG会在5-15分钟后“追上”。在研究是否可以采取任何措施来改善这种情况时，我通过实验发现网络 MTU 为 1400，并且 sql 的网络数据包大小设置为默认值 4092。作为实验，我将数据包大小设置为 1400 以匹配MTU。我们已经好几天没有收到有关 AG 的警报了，所以它“似乎”得到了帮助。

我的问题是这样做是否正确？我已经读过很多次，除非 MS 也建议你，否则不要更改网络数据包大小，并且永远不要将其设置为小于默认值 4096。然而......它似乎有所帮助。因此，我正在寻找类似情况下更有经验的人的意见。

我已经设置了一个新的数据库，我可以通过 SQL Server Management Studio 连接到该数据库并像平常一样执行操作。我创建了两个帐户供我的应用程序使用，并且都可以通过 SSMS 登录。我的程序正在运行 java 并使用“mssql-jdbc-6.4.0.jre8.jar”驱动程序，当我尝试连接时，我可以在数据库日志中看到以下错误：

错误：18456，严重性：14，状态：149 用户“application_read_only_user”登录失败。原因：基于登录的服务器访问验证因基础结构错误而失败。登录缺少连接端点权限。[客户端：127.0.0.1]

我查看了多个来源试图解决这个问题。微软官方文档似乎没有列出状态 149，我在网上找到的任何结果也没有列出。

我没有修改原始设置的端点，所以我只有以下项目：

• 专用管理连接
• TSQL 本地机
• TSQL 命名管道
• TSQL 默认 TCP
• TSQL 默认 VIA

我尝试将 SQL Server 服务设置为作为本地系统运行。

该网站上有很多类似的问题和堆栈溢出，但没有一个能够提供帮助。它们要么具有不同的状态，要么不列出状态。

我正在通过 PowerShell 的专用管理员连接 (DAC) 连接到 SQL Server（2016 和 2017 最新版本）。

SQL Server 错误日志中记录以下错误消息：

日期 2019 年 4 月 2 日下午 1:59:13 记录 SQL Server（当前 - 2019 年 4 月 2 日下午 1:59:00）

源登录

消息
无法连接，因为已存在最大数量“1”的专用管理员连接。在建立新连接之前，必须通过注销或结束进程来删除现有的专用管理员连接。[客户端：127.0.0.1]

查询成功运行。已经尝试了许多连接字符串管理迭代；这是迄今为止最强大的。

Stack Exchange 上有一个解决方案，该解决方案涉及在关闭连接之前终止 spid，但这也会向 SQL Server 错误日志中抛出一条令人讨厌的消息，因此没有什么乐趣。

检查sys.dm_exec_sessions没有发现任何有趣的事情；使用此技术，没有连接保持打开状态。下面的 PowerShell 有一个虚拟查询，我无法谈论为什么我们要以这种方式连接，因为它是专有的，但它是 100% 必要的，它是一个非常快速的连接，我需要每 10 次执行一次分钟。

这个错误只是噪音。DAC 查询按预期运行和工作。

即使在静止的系统上重新启动，每次都会记录该错误。没有其他 DAC 连接正在使用 - 如果有，Powershell 会在命令提示符处抛出明显的错误消息。

有趣的是，当使用 时sqlcmd，SQL Server 错误日志中不会记录任何错误消息。

#begin powershell script
$SqlServerName = "server\instance"

$DbQuery = "
INSERT INTO  master.dbo.sometable(value1,value2) …

我正在尝试找出监控这两个事件的方法

1. 记录发送队列大小 - 我可以在 perfmon 中看到这一点

2. 重做队列大小 - 我可以在 dmv 中看到，但在 perfmon 计数器中看不到

有没有什么方法可以使用 perfmon，以便我可以计算重做队列大小，即使计数器在 perfmon 中不可用？

另外，我发现这些事件在属于数据库镜像的一部分时会记录在 Windows 事件查看器中。但现在使用 AG，如何在 Windows 事件查看器中记录这 2 个超出特定范围的值？

编辑

我所说的警报是指我们在 AG 中是否有一些内容，如此处所示，作为从数据库镜像看到的消息？

我有一个带有分组的简单查询，运行良好，直到我添加了另一个连接：

select 
   [ca].Value,
   [c].cID, 
   [c].Name

from ReportingDB..Table1 [t1]

join MainDB..Companies [c] on
    [t1].CompanyID = [c].cID
    and [c].cID not in (1)

join MainDB..CompanyAttributes [ca] on -- this is the join that causes trouble
    [t1].CompanyID = caCID
    and caAttr = 26

group by [ca].Value, [c].cID, [c].Name

信息：

Companies 表是一个“查找”表，有 2254 行，cIDPK与表
CompanyAttributes有多对一关系Companies，有 4055 行
Table1，与表有多对一关系Companies，有 3,485,150 行，

估计的执行计划看起来并不异常。

• 当我尝试运行查询时，它没有完成，1 小时后我停止它，因此无法看到实际执行计划发生了什么
• 实时查询统计数据使我的 SSMS 挂起
• 如果删除“group by”子句，它会很快开始毫无问题地获取行。或者当最后一个连接被删除时，它也可以正常工作 - 通过分组
• 服务器不忙，有足够的资源，并且启动查询时我没有看到明显的 CPU 上升
• 查看sys.dm_exec_requests，对于运行查询的会话，wait_type …

我们在 DEV/QA/PROD SQL 2017 Enterprise 服务器上遇到了看似随机的错误 824。服务器运行几乎相同的代码，通过 ETL 流程将相同的日常文件摄取到我们的数据仓库中。这些错误是在 2022 年 5 月左右首次发现的，但由于日志清理，我们无法确定（供应商提供的）ETL 流程是否正在捕获这些错误、记录警告并继续处理而不是失败！

DEV/QA 已修补到 CU30（最新的 CU）——这种情况仍然存在。CU22 的生产落后了几个补丁，计划在未来几周内进行修补。

例子：

SQL Server 检测到基于逻辑不一致的 I/O 错误：校验和不正确（预期为 0xc30164e7；实际为 0x9f2bc675c）。它发生在读取文件“H:\tempdb_mssql_6.ndf”中偏移量 0x0000027de40000 处的数据库 ID 2 中的页 (7:1306400) 期间。

如前所述，这种情况在我们所有的环境中都是随机发生的。所有服务器都是虚拟化的。DEV/QA 都使用相同的 SAN。生产位于不同数据中心的单独 SAN 上。我没有 SAN 设备品牌/型号的详细信息。

在大多数情况下，当发生这种情况时，它似乎主要在 tempdb 中（但并非总是如此）。此外，suspect_pages 通常是空的。这种情况似乎在周六发生得更频繁，因为我们连续发生了 3-4 次。

另请注意，错误中列出的预期/实际值通常是相同的 - 但并非总是如此。

还注意到，特定的存储过程似乎更容易引发此错误，但是，它已经发生在 ETL 作业中的多个其他位置，再次影响不同的数据库。似乎触发此错误的存储过程最常添加一个 PERSISTED 计算列，然后添加一个基于该计算列的 ROW_NUMBER() - 到 5 个表，大小范围从 200K 到 750 万行。我们昨天（在 QA 中）修改了此过程，以限制使用 ROW_NUMBER() 值更新的行数（仅当 rownum=1 时），并将更新从一次性全部更改为 25K 批量方法。今天在 QA 中再次发生该错误 - 因此我们删除了计算列上的 PERSISTED 选项。我们实际上正在尝试在质量检查中阻止这种情况，因为它似乎受到的影响最大。

DBCC CHECKDB …

我在 SSDT 中有 CLR 程序集，并且部署它必须是可信的。据我所知，有 4 个选项如何做到这一点

第一个选项，使用 TRUSTWORTHY

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;  
  
ALTER DATABASE SourceDatabase SET TRUSTWORTHY ON;

第二个选项，禁用严格安全性

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;  
  
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;

第三个选项，使用密钥或证书对程序集进行签名

Seems complicated and I was not able to manage that yet. I will appreciate the instructions, because the workflow is not clear here.

第四个选项，使用sp_add_trusted_assembly

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;

declare @assembly varbinary(max) = 0x4D5A90000300000004000000FFFF0000... -- …

我在名为 AspNetUsers 的表的 LastName 列上创建了非聚集索引的统计直方图向量。

如果我运行查询，因为SELECT * FROM dbo.AspNetUsers WHERE LastName = 'Baker'它返回 6 行作为估计行，因为Baker是步骤之一的RANGE_HI_KEY ，因此 EQ_ROWS 值是我的估计行数。同样，如果我运行查询SELECT * FROM dbo.AspNetUsers WHERE LastName = 'Bacilia'，它会返回 1 行作为估计行，导致Bacilia落入“Baker”步长范围，因此该步长的AVG_RAGE_ROWS值是我的估计行数。

同样，根据我的理解，如果我执行查询，因为SELECT * FROM dbo.AspNetUsers WHERE LastName LIKE 'Ba%'它匹配 2 个步骤（Baker和Batagoda），所以它应该返回 27 + 51 (RANGE_ROWS) + 6 + 4 (EQ_ROWS) = 88。但它返回 99 行作为估计。

此基数估计如何与 LIKE 查询一起使用？在执行 LIKE 查询时，它是否使用不同的公式来估计行数？

Interleaved Execution 是2017 查询处理器中一系列功能的一部分，其中包括：

• 批处理模式自适应连接
• 交错执行
• 批处理模式内存授予反馈

那么交错执行是如何工作的呢？

背景：

我的部门正在从带有镜像的 SQL Server 2008R2 升级到带有无集群可用性组的 SQL Server 2017。直到最近，测试才发现没有问题或危险信号。然后我们安装了 CU1，遇到了问题，卸载了 CU1，问题就消失了。操作系统是带有最新补丁的 server 2016。

CU1 后观察到的行为：

使用 SSMS 或 tsql，我们可以创建一个 2 副本无集群同步可用性组，并向其中添加一个数据库。该组可以多次故障转移而不会出现问题。啊，但是添加第二个数据库，故障转移会出现问题。其中一个数据库总是会处于不同步状态。再多的摆弄也无法让它复活。如果我删除并重新创建整个内容，则可能是其他数据库未同步。记录器中的相关错误消息是“由于异常 35222，无法更新副本状态”。这似乎是一条与集群相关的消息，但由于我们是无集群的，我感到很困惑。在我们卸载两个副本上的 CU1 后，我能够创建 AG 并添加 22 个数据库（包括两个原始数据库）。故障转移没有问题。附带说明一下，自动播种并不总是适用于多个数据库。该操作将失败并显示“种子检查消息超时”。从 AG 中删除这些数据库并一次添加一个是成功的。

我的问题是：

在 CU1 之后，是否还有其他人遇到过无集群 AG 的问题？如果是这样，你在我没有成功的地方成功了吗？

评论/意见：

我认为 CU 将在与 SP 相同的级别进行测试。虽然我知道无论测试多么彻底，错误都会出现，但在第一个测试中发生这种情况令人不安。这将导致我们在部署之前对每个 CU 进行真正的压力测试，这意味着我们不会在它们出现时部署它们。我们只会在我们认为有必要时部署它们。我们是一个没有专门的 dba 的小型组织，需要对所采取的行动有所选择。