Elevar compatibilidade: uma implantação medida e verificável

Instalar um mecanismo SQL Server mais recente e elevar o nível de compatibilidade são mudanças relacionadas, mas diferentes. Misturá-las com alterações de esquema, manutenção de índices e uma nova aplicação dificulta explicar regressões. Uma atualização controlada cria pontos de comparação para identificar qual mudança alterou o comportamento das consultas importantes.

Estabeleça duas referências separadas

Registre versão exata do mecanismo, compatibilidade, configurações da base e ajustes importantes da aplicação. Restaure uma cópia representativa no destino com um nível anterior ainda suportado e avalie esse estado antes de elevá-lo. Manter o nível não emula completamente o mecanismo antigo: infraestrutura, correções e outros comportamentos podem diferir.

O inventário somente de leitura executa na base avaliada. A visão Query Store exige permissões de consulta adequadas à versão instalada. Preserve o resultado com data e identificação da carga de teste.

SELECT SERVERPROPERTY('ProductVersion') AS EngineVersion;
SELECT name, compatibility_level
FROM sys.databases WHERE database_id=DB_ID();
SELECT actual_state_desc, desired_state_desc, readonly_reason,
       current_storage_size_mb, max_storage_size_mb
FROM sys.database_query_store_options;

O estado desejado READ_WRITE não comprova gravação atual no Query Store. Confira estado real, consumo de espaço e motivo de eventual leitura somente. Captura e retenção devem preservar a referência durante toda a comparação. Um repositório cheio pode parar de registrar justamente quando as evidências são mais necessárias.

Escolha uma carga que cubra distribuições importantes de parâmetros e um ciclo de negócio completo. Inclua maior cliente, resultados vazios, fechamento mensal e concorrência. Repetir buscas pontuais do dia não qualifica relatórios noturnos. Mantenha comparáveis dados, estatísticas, recursos e concorrência, ou registre explicitamente as diferenças.

Mude o nível como experimento próprio

Em uma instância de teste SQL Server 2022, uma base mantida em 150 pode ser avaliada separadamente em 160. O modelo comentado nomeia uma base de prática de propósito. Confirme suporte no mecanismo real antes de adaptar: o número de compatibilidade não instala uma versão ausente.

-- Example only: SQL Server 2022, isolated practice database.
-- ALTER DATABASE [CompatibilityPractice]
-- SET COMPATIBILITY_LEVEL = 160;

Registre o horário da mudança para não misturar intervalos anteriores e posteriores do Query Store. A transição pode causar recompilação. Separe compilação inicial e aquecimento do comportamento sustentado. Não limpe rotineiramente o cache de planos de toda a instância, pois isso cria outro evento e afeta bases não relacionadas.

Compare contagens de execução e custo juntos. Uma média melhor pode esconder uma consulta crítica rara muito mais lenta. Mais CPU total pode representar somente mais solicitações. Examine duração, CPU, leituras, planos e concorrência para cada consulta importante. Use telemetria da aplicação para distribuições de latência percebida, sem presumir que agregados do Query Store fornecem todos os percentis.

Quando houver regressão, investigue linhas estimadas e reais, escolhas de junção, concessões de memória e sensibilidade a parâmetros. Preserve ambos os planos e teste a hipótese sobre os mesmos dados. Um plano anterior pode mitigar um caso específico, mas confirme sucesso do forçamento e adequação a parâmetros variados. A medida precisa de responsável e data de revisão, não de permanência automática.

Defina aceitação e retorno verdadeiro

Escreva critérios mensuráveis antes da mudança: latência crítica, prazo do lote, taxa de erros e folga de recursos na carga esperada. Nomeie quem decide e o período de observação. Um processamento mensal não fica validado por uma manhã bem-sucedida. Preserve verificações funcionais junto das medidas de desempenho.

Voltar a um nível anterior suportado pode mitigar certas mudanças no processamento de consultas. Não reverte o formato dos arquivos nem permite restaurar um backup do mecanismo novo em um antigo. O retorno do mecanismo precisa de plano próprio testado de migração e conciliação, principalmente após novas gravações.

Considere ainda código que passe a usar funções dependentes do novo nível. Reverter apenas a configuração pode quebrar a aplicação. Evite essa dependência no primeiro ensaio ou coordene sua reversão. Depois da aceitação, preserve a referência, remova medidas temporárias somente por avaliação e acompanhe o próximo ciclo completo. O resultado é uma decisão de desempenho documentada, não apenas um número maior.

Referências técnicas: Microsoft Learn: Upgrade workflow · Microsoft Learn: Compatibility levels · Microsoft Learn: Query Store state.