Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: SQL Server em Windows
No SQL Server 2016 (13.x) e posterior, algumas alterações só são habilitadas quando o nível de compatibilidade do banco de dados for alterado. Isto foi feito por várias razões:
Como a atualização é uma operação unidirecional (não é possível fazer downgrade do formato de arquivo), há valor em separar a ativaçã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 de banco de dados anterior. O novo modelo reduz o número de coisas que devem acontecer durante uma janela de interrupção.
As alterações no processador de consultas podem ter efeitos complexos. Mesmo que uma "boa" alteração no sistema possa 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 recursos, como o Repositório de Consultas, atenuem rapidamente as regressões de escolha de plano ou até mesmo as evitem completamente em servidores de produção.
Os seguintes comportamentos são esperados para o SQL Server 2017 (14.x) quando um banco de dados é 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 superior antes da atualização, ele permanece o mesmo após a atualização.
- Se o nível de compatibilidade de um banco de dados de usuário era 90 antes da atualização, no banco de dados atualizado, o nível de compatibilidade é definido como 100, que é o nível de compatibilidade com suporte mais baixo no SQL Server 2017 (14.x).
- Os níveis de compatibilidade dos bancos de
tempdbdados ,model,msdbeResourcesão definidos para o nível de compatibilidade atual após a atualização. - O
masterbanco de dados do sistema mantém o nível de compatibilidade que tinha antes da atualização.
O processo de atualização para habilitar a nova funcionalidade do processador de consultas está relacionado ao modelo de serviço pós-lançamento do produto. Algumas dessas correções são lançadas sob a bandeira de rastreamento 4199. Os clientes que precisam de correções podem optar por essas correções sem causar regressões inesperadas para outros clientes. O modelo de serviço pós-lançamento para hotfixes de processadores de consulta está documentado em KB974006. A partir do SQL Server 2016 (13.x), mudar para um novo nível de compatibilidade implica que o sinalizador de rastreamento 4199 não é mais necessário, porque essas correções agora estão habilitadas por padrão no nível de compatibilidade mais recente. 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 quaisquer novas correções do processador de consulta lançadas após o RTM, se aplicável.
Para obter informações sobre o fluxo de trabalho recomendado para atualizar o processador de consultas para a versão mais recente do código, consulte Manter a estabilidade de desempenho durante a atualização para o SQL Server mais recente da seção Cenários de uso do repositório de consultas.
A partir do SQL Server Management Studio 18, os usuários podem ser guiados pelo fluxo de trabalho recomendado usando o Assistente de Otimização de Consulta. Para obter mais informações, consulte Atualizar bancos de dados usando o Assistente de Ajuste de Consulta.