主页 / dba / 问题 / 268099
Accepted
blobbles
Asked: 2020-05-29 22:20:20 +0800 CST

SQL Server 2019 性能比 2012 年差……我错过了什么吗？

  • 772

我们有一个 SQL Server 2012 服务器，它在（据我所见）相同的基础架构上远远优于 SQL Server 2019 数据库。我们将这两个数据库托管在具有相同 SLA 的云平台上。两者都有 180GB RAM 和 16 个处理器。

然而，有一些关键的区别。

  1. 2012 数据库服务器是 Enterprise，2019 是 Standard。据我所知，这不应该有所作为
  2. 2012年数据库恢复到2019年服务器，版本改为150（2019）
  3. 2012 服务器上的 MAXDOP 为 0，2019 服务器根据 Microsoft 和其他人的建议设置为 8
  4. 并行度的成本阈值 = 2012 服务器上的 5，2019 服务器上的 20

编辑：我刚刚意识到的另一个主要区别 - 一个是 Windows Server 2008，另一个是 Windows Server 2019。它也可能是服务器端设置......

所有 SQL 磁盘的分配单元大小设置为 64kb，SQL 具有能够自行控制文件大小的正确权限。服务器设置为高性能模式。还有什么我应该改变服务器端的吗？

其他数据库设置没有改变，所以以下设置是 2019 年的默认设置，我相信：

  • 传统基数估计 = OFF
  • 参数嗅探 = ON
  • 查询优化器修复 = OFF

我们所做的查询类型主要是执行更新和插入的大型复杂多连接查询，偶尔还会有来自用户的小选择。我们将大文件加载到数据库中，然后在大查询中处理数据，通常一次一个。在这些大型“负载”之间，我们让用户对其他未加载/处理的数据库表进行选择，以准备未来的加载/处理步骤。通常，我们的处理性能会降低 30%-50%。我认为这是因为 MAXDOP 设置，但将其更改为 0 在一系列运行中没有任何区别。

我们的主要症状是当我们在忙于处理时尝试连接到 2019 服务器时，我们会遇到锁定超时，而 2012 服务器仍在提供连接服务，只是速度非常慢。我正在考虑将服务器上的连接超时设置设置为很高的值，但是我怀疑我们仍然不会得到服务器的响应。就好像它有点忙，它会阻止所有新的连接。

还有其他我应该尝试的事情吗？这些数据库设置值得摆弄吗？

我可以进一步深入研究并开始研究 DMV，但这似乎接近于“对等”环境升级，但性能会显着下降。在进行更大的调查之前，只需检查一下我应该检查的其他内容。

sql-server performance

4 个回答

  1. Best Answer

    相信你已经明白了为什么推荐的升级过程是升级你的数据库，启用查询存储，并在提高数据库兼容性级别之前进行测试。

    在此处输入图像描述 更改数据库兼容级别并使用查询存储

    如果您有很多计划回归，您可以在更高的数据库兼容性级别继续使用旧的基数估计器：

    ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
    • 12

  2. 我们从 Sql Server 2012 升级时遇到了类似的问题。

    我们的问题是由于 SQL Server 2014 中引入的基数估算器更改造成的

    尝试在测试环境中将 Legacy Cardinality 设置更改为 ON 并比较工作负载的性能

    https://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-legacy-cardinality-estimation/

    • 4

  3. 从 SQL Server 2008 R2 升级到 SQL Server 2019（兼容级别 150）时，我们遇到了类似的问题。

    我们的一些夜间更新作业的运行时间突然增加了 6-7 倍（从 4 分钟到 39 分钟，从 1 小时到 6 小时）。

    设置 Legacy Cardinality 设置以ON使我们恢复到通常的更新速度。

    这就是我们所做的（来源：https ://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-legacy-cardinality-estimation/ ）：

    USE [YourDB]
GO
ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO
    • 3

  4. 另一种可能性是启用全局跟踪标志 9481，您实例中的所有工作负载都将使用旧版 CE

    • 0

相关问题