主页 / dba / 问题 / 343770
Accepted
JohnG
Asked: 2024-11-22 03:51:54 +0800 CST

查询标记用户：需要 SQL2022 更新

  • 772

我的软件与 SQL2016 及更高版本（包括 SQL Azure）兼容，当 SQL 2022 低于版本 16.0.1135.2 或低于 16.0.4165.4 时会崩溃 - 取决于 RTM、GDR、CU（我很难理解 MS 使用的版本架构）

我编写此代码是为了查明是否需要 SQL 更新

-- if it's Version 16
IF (select substring(convert(varchar(20),SERVERPROPERTY('productversion')),1,charindex('.',convert(varchar(20),SERVERPROPERTY('productversion')))-1))='16'
-- If so is it 16.0.1xxxxxxx or 16.0.4xxxxxxxx
    IF (select substring(convert(varchar(20),SERVERPROPERTY('productversion')),1,charindex('16.0.',convert(varchar(20),SERVERPROPERTY('productversion')))))='1'
-- if 16.0.1 it needs to be < 16.0.1135.2 
BEGIN 
        if (select substring(convert(varchar(20),SERVERPROPERTY('productversion')),charindex('16.0.',convert(varchar(20),SERVERPROPERTY('productversion'))),len(convert(varchar(20),SERVERPROPERTY('productversion')))))<'16.0.1135.2'
 select 1
END
ELSE 
BEGIN 
-- if 16.0.4 it needs to be < 16.0.4165.4 
        IF (select substring(convert(varchar(20),SERVERPROPERTY('productversion')),1,charindex('16.0.',convert(varchar(20),SERVERPROPERTY('productversion')))))='4'
            if (select substring(convert(varchar(20),SERVERPROPERTY('productversion')),charindex('16.0.',convert(varchar(20),SERVERPROPERTY('productversion'))),len(convert(varchar(20),SERVERPROPERTY('productversion')))))<'16.0.4165.4'
            select 1 
END

我的问题是，在 16.0.YYYY.z 中，我认为我不能依赖第一个 Y 来告诉我应该查看哪个分支，因为查看以前的 SQL 版本，在同一个分支中，第一个 Y 可以更改数字...我要查找的是 2024-11-12 之前更新的 2 个版本，如果安装的 SQL2022 版本不包含 2024-11-12 的更新，我希望被标记

  1. 是否存在我可以遵循的标准或者是否有更好的方法来做到这一点？
  2. 我是否应该担心 Azure 或者我可以假设 Azure 始终是最新的？

我们想让用户知道他们至少需要 16.0.1135.2 或 16.0.4165.4。我担心的是在查询中选择分支（='1' 或 ='4'）。我不认为它会随着时间的推移而变得可靠（数字可能会改变），因为我不确定 MS 使用的惯例。

该软件拥有超过 30,000 个脚本（开发时间超过 30 年）和数千个客户。升级由专家完成（而不是由客户完成）。由于它每年更新四次，因此如果我们发现 SQL 服务器不兼容，我们希望在升级过程中添加警告，以便专家可以采取行动。

sql-server

2 个回答

  1. Best Answer

    是否存在我可以遵循的标准或者是否有更好的方法来做到这一点？

    不是，因为你的问题很具体。正如其他人提到的，‘正确’的处理方式是修复导致崩溃的应用程序错误。

    我是否应该担心 Azure 或者我可以假设 Azure 始终是最新的？

    Azure SQL 数据库已与 SQL Server 代码库分道扬镳，因此版本号等实际上不再与 SQL Server 版本号相关。如果您在 Azure SQL 上没有遇到此问题，那么现在可能可以安全地忽略它。

    我的问题是，在 16.0.YYYY.z 中，我认为我不能依赖第一个 Y 来告诉我应该查看哪个分支，因为查看以前的 SQL 版本，在同一个分支中，第一个 Y 可以更改数字

    将它们转换为 INT 值，这样您就可以进行简单的数字比较，而不必进行复杂的字符串操作。使用SERVERPROPERTY提取 ProductBuild 属性并评估：

    DECLARE @MajorVersion INT
    , @ProductBuild INT

SELECT @MajorVersion = CAST(SERVERPROPERTY('ProductMajorVersion') AS INT)
    , @ProductBuild = CAST(SERVERPROPERTY('ProductBuild') AS INT)

IF (@MajorVersion) = 16 AND CAST((SELECT SERVERPROPERTY('Edition')) AS VARCHAR(255)) NOT LIKE '%Azure%'
BEGIN
    IF (@ProductBuild) >= 1000 AND (@ProductBuild) < 1135
        OR (@ProductBuild) >= 4003 AND (@ProductBuild) < 4165
    BEGIN
        PRINT 'Unsafe version of SQL 2022'
    END
    ELSE
    BEGIN
        PRINT 'Safe version of SQL 2022'
    END
END
ELSE
BEGIN
    PRINT 'Not SQL 2022'
END

    此代码将 ProductMajorVersion 属性（版本号的第一部分）转换为 INT，然后将 Build Number 转换为 INT。然后将它们与 SQL 2022 的已知上限和下限进行比较，以确定它是否为不安全版本。

    由于您知道 1135 及以上版本和 4165 及以上版本是安全的，因此您实际上只需要检查目标服务器的版本是否在 1000 到 1135 之间，或者在 4003 到 4165 之间。转换为整数意味着您不必检查各种可能的首位数字，您可以放心地假设如果它高于 1135，那么它就没问题。由于 GDR 路径永远不会超过 CU 路径的 4003 下限，因此不会有任何冲突。

    该脚本还会检查“Edition”属性，如果是 Azure，则完全跳过检查。

    注意：如果您稍后发现其他版本也崩溃，则需要修改脚本以检查新的上水位和下水位之间的 ProductBuild 值。

    • 3

  2. 天啊为什么

    总而言之，这看起来相当愚蠢。

    我的软件...当 SQL 2022 低于版本 16.0.1135.2 或低于 16.0.4165.4 时崩溃

    为什么？这些有什么特别之处？

    • 您的软件在这些 CU 上的行为是否不同，甚至在不同主要版本（包括云实例）之间行为是否不同？
    • 你们的软件的标准版和企业版的行为是否不同？
    • 您的软件是否会根据数据库兼容级别而表现不同？

    也许您的客户的修补政策不允许他们每月甚至每三个月修补一次。您是否会与安全/基础设施人员就此进行争斗，以免您的软件在无法处理版本号时崩溃？

    他们可能拥有较低的环境，因此在更新之前需要测试和验证累积更新。也许他们在较低的环境中测试了 CU，但发现了回归问题，因此无法将其推广到生产环境，需要等待另一个环境。

    作为一名软件开发人员，这种事情几乎不关你的事。这样的依赖关系只会浪费大家的时间。

    • 2

相关问题