Alterar o nível de compatibilidade do banco de dados e usar o Repositório de Consultas

Aplica-se a: simSQL Server (todas as versões compatíveis) – Somente Windows

No SQL Server 2016 (13.x) e posterior, algumas alterações são habilitadas somente quando o nível de compatibilidade do banco de dados é alterado. Isso foi feito por vários motivos:

  • Uma vez que a atualização é uma operação unidirecional (não é possível fazer downgrade do formato de arquivo), há valor em separar a habilitação de novos recursos para uma operação separada dentro do banco de dados. É possível reverter uma configuração para um nível de compatibilidade do banco de dados anterior. O novo modelo reduz o número de itens que devem ocorrer durante uma janela de interrupção.

  • Alterações no processador de consulta podem ter efeitos complexos. Até mesmo uma alteração "boa" para o sistema pode ser ótima para a maioria das cargas de trabalho – ela pode causar uma regressão inaceitável em uma consulta importante para outros. Separar essa lógica do processo de atualização permite que determinados recursos, assim como o Repositório de Consultas, façam rapidamente a mitigação das escolhas de plano ou até mesmo evitem-nas completamente em servidores de produção.

Importante

Os comportamentos a seguir são esperadas para SQL Server 2017 (14.x) quando um banco de dados for anexado ou restaurado e após uma atualização in-loco:

  • Se o nível de compatibilidade de um banco de dados de usuário era 100 ou mais alto antes da atualização, ele permanecerá o mesmo depois da atualização.
  • Se o nível de compatibilidade de um banco de dados do usuário era 90 antes da atualização, no banco de dados atualizado esse nível será definido como 100, que é o mais baixo com suporte no SQL Server 2017 (14.x).
  • Os níveis de compatibilidade dos bancos de dados tempdb, model, msdb e Resource são definidos para o nível de compatibilidade atual após o upgrade.
  • O banco de dados do sistema mestre retém o nível de compatibilidade anterior ao upgrade.

O processo de atualização para habilitar a nova funcionalidade do processador de consulta está relacionado ao modelo de manutenção pós-lançamento do produto. Algumas dessas correções são liberadas sob o sinalizador de rastreamento 4199. Clientes que precisam de correções podem optar por aceitar essas correções sem causar regressões inesperadas para outros clientes. O modelo de manutenção pós-lançamento para hotfixes do processador de consulta é documentado aqui. Começando com o SQL Server 2016 (13.x), a mudança para um novo nível de compatibilidade implica no sinalizador de rastreamento 4199 não ser mais necessário, porque essas correções agora estão habilitadas por padrão no último modo de compatibilidade. Portanto, como parte do processo de atualização, é importante validar que o 4199 não está habilitado quando o processo de atualização for concluído.

Observação

No entanto, o sinalizador de rastreamento 4199 ainda é necessário para habilitar qualquer nova correção de processador de consulta lançada após o RTM, se aplicável.

O fluxo de trabalho recomendado para atualizar o processador de consulta para a versão mais recente do código está documentado em Manter a estabilidade do desempenho durante a atualização para a seção do SQL Server mais recente de Cenários de uso do repositório de consultas, conforme mostrado abaixo.

Diagrama que mostra o fluxo de trabalho recomendado para atualizar o processador de consultas para a versão mais recente do código.

Do SQL Server Management Studio v18 em diante, os usuários podem ser guiados por meio do fluxo de trabalho recomendado usar o Assistente de Ajuste de Consulta. Para obter mais informações, veja Atualizando bancos de dados usando o Assistente de Ajuste de Consulta.

Consulte Também

Exibir ou alterar o nível de compatibilidade de um banco de dados
Cenários de uso do Repositório de Consultas
Nível de compatibilidade de ALTER DATABASE (Transact-SQL)
Atualizando bancos de dados usando o Assistente de Ajuste de Consulta