Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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. Embora uma alteração "boa" no sistema possa ser ótima para a maioria das cargas de trabalho, isso pode causar uma regressão inaceitável em uma consulta importante para outras pessoas. Separar essa lógica do processo de atualização permite que recursos, como o Repositório de Consultas, reduzam as regressões de escolha do plano rapidamente ou até mesmo evitem-nas completamente nos servidores de produção.
Os seguintes comportamentos são esperados para o SQL Server 2017 (14.x)SQL Server 2017 (14.x)SQL Server 2017 (14.x)SQL Server 2017 (14.x)SQL Server 2017 (14.x)SQL Server 2017 (14.x)SQL Server 2017 (14.x)SQL Server 2017 (14.x)SQL
- 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
eResource
são definidos como o nível de compatibilidade atual após a atualização. - 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.
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 do desempenho durante a atualização para a seção mais recente do SQL Server dos 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 Ajuste de Consulta. Para obter mais informações, consulte Atualizar bancos de dados usando o Assistente de Ajuste de Consulta.