Início / dba / Perguntas / 343770
Accepted
JohnG
Asked: 2024-11-22 03:51:54 +0800 CST

Consulta para sinalizar usuário: atualização do SQL2022 necessária

  • 772

Meu software, compatível com todas as versões do SQL2016 e superiores, incluindo o SQL Azure, trava quando o SQL 2022 é inferior à versão 16.0.1135.2 ou inferior à 16.0.4165.4 - dependendo do RTM, GDR, CU (que estou tendo dificuldade em entender a arquitetura de versão que a MS usa)

Eu escrevi este código para descobrir se uma atualização de SQL é necessária

-- 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

Meu problema é que em 16.0.YYYY.z, não acho que posso confiar no primeiro Y para me dizer qual branch devo olhar porque, olhando para versões anteriores do SQL, no mesmo branch o primeiro Y pode mudar de dígito... O que estou procurando são as 2 versões atualizadas antes de 2024-11-12. Quero ser sinalizado se a versão do SQL2022 instalada não incluir as atualizações de 2024-11-12.

  1. Existe algum padrão que eu possa seguir ou haveria uma maneira melhor de fazer isso?
  2. Devo me preocupar com o Azure ou posso presumir que o Azure está sempre atualizado?

Queremos que o usuário saiba que ele precisa de no mínimo 16.0.1135.2 ou 16.0.4165.4. Minha preocupação é selecionar o branch (='1' ou ='4') na consulta. Não acho que será confiável com o tempo (o dígito pode mudar), pois não tenho certeza da convenção que a MS usa.

O Software tem mais de 30000 scripts (mais de 30 anos de desenvolvimento) e milhares de clientes. As atualizações são feitas por especialistas (e não pelo cliente). Como ele é atualizado quatro vezes por ano, queremos adicionar um aviso durante a atualização se descobrirmos que o servidor SQL é incompatível para que o especialista possa tomar medidas.

sql-server

2 respostas

  1. Best Answer

    Existe algum padrão que eu possa seguir ou haveria uma maneira melhor de fazer isso?

    Na verdade não, pois seu problema é bem específico. Como outros mencionaram, a maneira "correta" de lidar seria consertar o bug do aplicativo que causa o travamento.

    Devo me preocupar com o Azure ou posso presumir que o Azure está sempre atualizado?

    O Banco de Dados SQL do Azure divergiu da base de código do SQL Server, então os números de versão etc. não se correlacionam mais com os números de versão do SQL Server. Se você não estiver enfrentando o problema no Azure SQL, provavelmente é seguro simplesmente ignorá-lo por enquanto.

    Meu problema é que em 16.0.YYYY.z, não acho que posso confiar no primeiro Y para me dizer qual branch devo olhar porque, olhando para versões anteriores do SQL, no mesmo branch o primeiro Y pode mudar o dígito

    Converta-os para valores INT para que você possa fazer comparações numéricas simples em vez da manipulação complicada de strings. Use SERVERPROPERTY para extrair a propriedade ProductBuild e avaliar que:

    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

    Este código converte a propriedade ProductMajorVersion (a primeira parte do número da versão) para um INT, então converte o número da compilação para um INT. Eles são então comparados com os limites superior e inferior conhecidos para o SQL 2022 para determinar se é uma versão insegura ou não.

    Como você sabe que as versões de 1135 em diante, e de 4165 em diante são seguras, você realmente só precisa verificar se o servidor de destino tem uma versão entre 1000 e 1135, ou entre 4003 e 4165. Converter para inteiros significa que você não precisa verificar vários primeiros dígitos possíveis, você pode seguramente assumir que se for acima de 1135, então está bom. Como o caminho GDR nunca excederá a marca d'água inferior 4003 para o caminho CU, não haverá nenhum conflito.

    O script também verifica a propriedade "Edição" e, se for Azure, ele ignora a verificação completamente.

    OBSERVAÇÃO: Se você encontrar outras versões posteriormente que também estejam travando, será necessário alterar o script para verificar se há um valor ProductBuild entre as novas marcas d'água superior e inferior.

    • 3

  2. Deus por que

    Isso parece um tanto tolo, no geral.

    Meu software ... trava quando o SQL 2022 é inferior à versão 16.0.1135.2 ou inferior a 16.0.4165.4

    Por quê? O que há de especial neles?

    • Seu software se comporta de forma diferente nessas CUs ou mesmo entre diferentes versões principais (incluindo instâncias de nuvem)?
    • O seu software se comporta de forma diferente entre as edições Standard e Enterprise?
    • Seu software se comporta de forma diferente dependendo do nível de compatibilidade do banco de dados?

    Talvez seus clientes tenham políticas de patch que não permitem que eles apliquem patches todo mês, ou mesmo a cada três meses. Você vai brigar com o pessoal de segurança/infraestrutura sobre isso para que seu software não trave quando não puder lidar com um número de versão?

    Eles podem ter ambientes inferiores nos quais atualizações cumulativas precisam ser testadas e validadas antes da atualização. Talvez eles tenham testado uma CU em um ambiente inferior e encontrado uma regressão e não podem implementá-la para produção e precisam esperar por outra.

    Esse tipo de coisa não é da sua conta como desenvolvedor de software. Dependências como essa só desperdiçam o tempo de todo mundo.

    • 2

relate perguntas