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

  • Artigo

Aplica-se a:SQL Server – 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:

  • Como a atualização é uma operação unidirecional (não é possível fazer downgrade do formato de arquivo), é importante separar a habilitação de novos recursos em uma operação distinta dentro do banco de dados. É possível reverter uma configuração para um nível de compatibilidade anterior do banco de dados. 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.

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 como o nível de compatibilidade atual após o upgrade.
  • O banco de dados do sistema master mantém o nível de compatibilidade anterior à atualização.

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

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.

Confira também