Nível de compatibilidade ALTER DATABASE (Transact-SQL)

Aplica-se a:Servidor SQLBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure

Define comportamentos de Transact-SQL e processamento de consultas para serem compatíveis com a versão especificada do mecanismo SQL. Para outras opções ALTER DATABASE, consulte ALTER DATABASE.

Para obter mais informações sobre as convenções de sintaxe, consulte Transact-SQL convenções de sintaxe.

Sintaxe

ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 170 | 160 | 150 | 140 | 130 | 120 | 110 | 100 }

Argumentos

database_name

O nome do banco de dados a ser modificado.

COMPATIBILITY_LEVEL { 170 | 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }

A versão do SQL Server com a qual o banco de dados deve ser compatível. Os seguintes valores de nível de compatibilidade podem ser configurados (nem todas as versões suportam todos os níveis de compatibilidade listados acima):

Produto	Versão do Mecanismo de Banco de Dados	Designação do nível de compatibilidade padrão	Valores de nível de compatibilidade suportados
Base de Dados SQL do Azure	17	170	170, 160, 150, 140, 130, 120, 110, 100
Instância Gerenciada SQL do Azure	16	150	160, 150, 140, 130, 120, 110, 100
Visualização do SQL Server 2025 (17.x)	17	170	170, 160, 150, 140, 130, 120, 110, 100
SQL Server 2022 (16.x)	16	160	160, 150, 140, 130, 120, 110, 100
SQL Server 2019 (15.x)	15	150	150, 140, 130, 120, 110, 100
SQL Server 2017 (14.x)	14	140	140, 130, 120, 110, 100
SQL Server 2016 (13.x)	13	130	130, 120, 110, 100
SQL Server 2014 (12.x)	12	cento e vinte	120, 110, 100
SQL Server 2012 (11.x)	11	110	110, 100, 90
SQL Server 2008 R2 (10.50.x)	10.5	100	100, 90, 80
SQL Server 2008 (10.0.x)	10	100	100, 90, 80
SQL Server 2005 (9.x)	9	90	90, 80
SQL Server 2000 (8.x)	8	80	80

Importante

Os números de versão do mecanismo de banco de dados para SQL Server e Banco de Dados SQL do Azure não são comparáveis entre si e, em vez disso, são números de compilação internos para esses produtos separados. O mecanismo de banco de dados do Banco de Dados SQL do Azure é baseado na mesma base de código que o mecanismo de banco de dados do SQL Server. Mais importante ainda, o mecanismo de banco de dados no Banco de Dados SQL do Azure sempre tem os bits mais recentes do mecanismo de banco de dados SQL. A versão 12 da Base de Dados SQL do Azure é mais recente do que a versão 15 do SQL Server.

Práticas recomendadas para atualizar o nível de compatibilidade do banco de dados

Para obter o fluxo de trabalho recomendado para atualizar o nível de compatibilidade, consulte Manter a estabilidade de desempenho durante a atualização para o SQL Server mais recente. Além disso, para obter uma experiência assistida com a atualização do nível de compatibilidade do banco de dados, consulte Atualizar bancos de dados usando o Assistente de Ajuste de Consulta.

Observações

Para todas as instalações do SQL Server, o nível de compatibilidade padrão está associado à versão do Mecanismo de Banco de Dados. Novos bancos de dados são definidos para esse nível, a menos que o model banco de dados tenha um nível de compatibilidade mais baixo. Para bancos de dados anexados ou restaurados de qualquer versão anterior do SQL Server, o banco de dados mantém seu nível de compatibilidade existente, se for pelo menos o mínimo permitido para essa instância do SQL Server. Mover um banco de dados com um nível de compatibilidade inferior ao permitido pelo Mecanismo de Banco de Dados define automaticamente o banco de dados para o nível de compatibilidade mais baixo permitido. Isso se aplica aos bancos de dados do sistema e dos usuários.

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, msdbe Resource são definidos como o nível de compatibilidade padrão para uma determinada versão do Mecanismo de Banco de Dados.
• O master banco de dados do sistema mantém o nível de compatibilidade que tinha antes da atualização. Isso não afetará o comportamento do banco de dados do usuário.

Para bancos de dados pré-existentes executados em níveis de compatibilidade mais baixos, desde que o aplicativo não precise usar aprimoramentos que só estão disponíveis em um nível de compatibilidade de banco de dados mais alto, é uma abordagem válida manter o nível de compatibilidade de banco de dados anterior. Para novos trabalhos de desenvolvimento, ou quando um aplicativo existente exigir o uso de novos recursos, como processamento inteligente de consultas em bancos de dados SQL e alguns novos Transact-SQL, planeje atualizar o nível de compatibilidade do banco de dados para o mais recente disponível. Para obter mais informações, consulte Níveis de compatibilidade e atualizações do Mecanismo de Banco de Dados.

Observação

Se não houver objetos de usuário e dependências, geralmente é seguro atualizar para o nível de compatibilidade padrão. Para obter mais informações, consulte Recomendações - banco de dados mestre.

Use ALTER DATABASE para alterar o nível de compatibilidade do banco de dados. A nova configuração de nível de compatibilidade para um banco de dados entra em vigor quando um USE <database> comando é emitido ou um novo logon é processado com esse banco de dados como o contexto de banco de dados padrão.

Para exibir o nível de compatibilidade atual de um banco de dados, consulte a compatibility_level coluna na exibição do catálogo sys.databases .

Um banco de dados de distribuição que foi criado em uma versão anterior do SQL Server e é atualizado para o SQL Server 2016 (13.x) RTM ou Service Pack 1 tem um nível de compatibilidade de 90, que não é suportado para outros bancos de dados. Isso não afeta a funcionalidade da replicação. A atualização para service packs e versões posteriores do SQL Server resultará no aumento do nível de compatibilidade do banco de dados de distribuição para corresponder ao master do banco de dados.

Para usar o nível de compatibilidade de banco de dados 120 ou superior para um banco de dados em geral, mas optar pelo modelo de estimativa de cardinalidade do SQL Server 2012 (11.x), que mapeia para o nível de compatibilidade de banco de dados 110, consulte ALTER DATABASE SCOPED CONFIGURATION e, em particular, sua palavra-chave LEGACY_CARDINALITY_ESTIMATION = ON.

Comentários para o Azure SQL

O nível de compatibilidade padrão é 170 para bancos de dados recém-criados no Banco de Dados SQL do Azure e no Banco de Dados SQL no Microsoft Fabric.

O nível de compatibilidade padrão é 150 para bancos de dados recém-criados na política de atualização do SQL Server 2022 da oferta de Instância Gerenciada SQL do Azure.

O nível de compatibilidade padrão é 170 para bancos de dados recém-criados na política de atualização sempreup-todata da oferta da Instância Gerenciada SQL do Azure.

A Microsoft não atualiza automaticamente o nível de compatibilidade do banco de dados para bancos de dados existentes. Cabe aos clientes fazê-lo a seu critério.

A Microsoft recomenda vivamente que os clientes planeiem atualizar para o nível de compatibilidade mais recente para poderem utilizar as melhorias de otimização de consultas mais recentes. Para obter dicas sobre como avaliar as diferenças de desempenho de suas consultas mais importantes entre dois níveis de compatibilidade diferentes no Banco de Dados SQL do Azure, consulte Desempenho de consulta aprimorado com nível de compatibilidade 130 no Banco de Dados SQL do Azure. Este artigo refere-se ao nível de compatibilidade 130 e ao SQL Server, mas a mesma metodologia se aplica a atualizações para níveis 140 ou superiores no SQL Server e no Banco de Dados SQL do Azure.

Nem todos os recursos que variam de acordo com o nível de compatibilidade são suportados no Banco de Dados SQL do Azure.

Encontrar o nível de compatibilidade atual

Para determinar o nível de compatibilidade atual, consulte a compatibility_level coluna de sys.databases.

SELECT [name],
       compatibility_level
FROM sys.databases;

Para determinar a versão do Mecanismo de Banco de Dados à qual você está conectado, execute a consulta a seguir.

SELECT SERVERPROPERTY('ProductVersion');

Níveis de compatibilidade e atualizações do mecanismo de banco de dados

O nível de compatibilidade do banco de dados é uma ferramenta valiosa para ajudar na modernização do banco de dados, permitindo que o Mecanismo de Banco de Dados do SQL Server seja atualizado, mantendo o mesmo status funcional para conectar aplicativos mantendo o mesmo nível de compatibilidade de banco de dados pré-atualização. Isso significa que é possível atualizar de uma versão mais antiga do SQL Server (como o SQL Server 2008 (10.0.x)) para o SQL Server ou o Banco de Dados SQL do Azure (incluindo a Instância Gerenciada SQL do Azure) sem alterações no aplicativo (exceto para conectividade de banco de dados). Para obter mais informações, consulte Certificação de compatibilidade.

Contanto que o aplicativo não precise usar aprimoramentos que só estão disponíveis em um nível de compatibilidade de banco de dados mais alto, é uma abordagem válida atualizar o Mecanismo de Banco de Dados do SQL Server e manter o nível de compatibilidade de banco de dados anterior. Para obter mais informações sobre como usar o nível de compatibilidade para compatibilidade com versões anteriores, consulte Certificação de compatibilidade.

Níveis de compatibilidade e procedimentos armazenados

Quando um procedimento armazenado é executado, ele usa o nível de compatibilidade atual do banco de dados no qual está definido. Quando a configuração de compatibilidade de um banco de dados é alterada, todos os seus procedimentos armazenados são automaticamente recompilados de acordo.

Usar o nível de compatibilidade para compatibilidade com versões anteriores

A configuração de nível de compatibilidade de banco de dados fornece compatibilidade com versões anteriores do SQL Server no que se refere a comportamentos de otimização de Transact-SQL e consulta somente para o banco de dados especificado, não para todo o servidor.

A partir do modo de compatibilidade 130, qualquer novo plano de consulta que afete correções e recursos foi intencionalmente adicionado apenas ao novo nível de compatibilidade. Isso foi feito para minimizar o risco durante as atualizações decorrentes da degradação do desempenho devido a alterações no plano de consulta potencialmente introduzidas por novos comportamentos de otimização de consulta.

Do ponto de vista do aplicativo, use o nível de compatibilidade inferior como um caminho de migração mais seguro para contornar as diferenças de versão, nos comportamentos controlados pela configuração de nível de compatibilidade relevante. O objetivo ainda deve ser atualizar para o nível de compatibilidade mais recente em algum momento, a fim de herdar alguns dos novos recursos, como o processamento inteligente de consultas em bancos de dados SQL, mas para fazê-lo de forma controlada.

Para obter mais informações, incluindo o fluxo de trabalho recomendado para atualizar o nível de compatibilidade do banco de dados, consulte Práticas recomendadas para atualizar o nível de compatibilidade do banco de dados.

• A funcionalidade descontinuada introduzida em uma determinada versão do SQL Server não é protegida pelo nível de compatibilidade. Isso se refere à funcionalidade que foi removida do Mecanismo de Banco de Dados do SQL Server. Por exemplo, a dica foi descontinuada FASTFIRSTROW no SQL Server 2012 (11.x) e substituída OPTION (FAST n ) pela dica. Definir o nível de compatibilidade do banco de dados como 110 não restaurará a dica descontinuada. Para obter mais informações sobre a funcionalidade descontinuada, consulte Funcionalidade descontinuada do Mecanismo de Banco de Dados no SQL Server.

• As alterações recentes introduzidas em uma determinada versão do SQL Server podem não estar protegidas pelo nível de compatibilidade. Isso se refere a alterações de comportamento entre versões do Mecanismo de Banco de Dados do SQL Server. Transact-SQL comportamento geralmente é protegido pelo nível de compatibilidade. No entanto, objetos de sistema alterados ou removidos não são protegidos pelo nível de compatibilidade.

  Um exemplo de uma alteração de quebra protegida pelo nível de compatibilidade é uma conversão implícita de tipos de dados datetime para datetime2 . No nível de compatibilidade do banco de dados 130, eles mostram maior precisão ao contabilizar os milissegundos fracionários, resultando em diferentes valores convertidos. Para restaurar o comportamento de conversão anterior, defina o nível de compatibilidade do banco de dados como 120 ou inferior.

  Exemplos de alterações de quebra não protegidas pelo nível de compatibilidade são:

  • Nomes de coluna alterados em objetos do sistema. No SQL Server 2012 (11.x), a coluna single_pages_kb in sys.dm_os_sys_info foi renomeada para pages_kb. Independentemente do nível de compatibilidade, a consulta SELECT single_pages_kb FROM sys.dm_os_sys_info produzirá o erro 207 (Nome da coluna inválido).

  • Objetos do sistema removidos. No SQL Server 2012 (11.x) o sp_dboption foi removido. Independentemente do nível de compatibilidade, a instrução EXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE'; produz o erro 2812 (Could not find stored procedure 'sp_dboption').

    Para obter mais informações sobre alterações de quebra, consulte:

    • Alterações significativas nos recursos do Mecanismo de Banco de Dados no SQL Server 2019
    • Alterações significativas nos recursos do Mecanismo de Banco de Dados no SQL Server 2017
    • Alterações significativas nos recursos do Mecanismo de Banco de Dados no SQL Server 2016

Diferenças entre os níveis de compatibilidade

Para todas as instalações do SQL Server, o nível de compatibilidade padrão está associado à versão do Mecanismo de Banco de Dados, conforme mostrado nesta tabela. Para novos trabalhos de desenvolvimento, planeje sempre certificar aplicativos no nível de compatibilidade de banco de dados mais recente.

A sintaxe do novo Transact-SQL não é limitada pelo nível de compatibilidade do banco de dados, exceto quando eles podem quebrar aplicativos existentes criando um conflito com o código de Transact-SQL do usuário. Essas exceções estão documentadas nas próximas seções deste artigo, que descrevem as diferenças entre níveis de compatibilidade específicos.

O nível de compatibilidade do banco de dados também fornece compatibilidade com versões anteriores do SQL Server, porque os bancos de dados anexados ou restaurados de qualquer versão anterior do SQL Server mantêm seu nível de compatibilidade existente (se igual ou superior ao nível mínimo de compatibilidade permitido). Isso foi discutido na seção Usando o nível de compatibilidade para compatibilidade com versões anteriores deste artigo.

A partir do nível de compatibilidade de banco de dados 130, quaisquer novas correções e recursos que afetem os planos de consulta foram adicionados apenas ao nível de compatibilidade mais recente disponível, também chamado de nível de compatibilidade padrão. Isso foi feito para minimizar o risco durante as atualizações decorrentes da degradação do desempenho devido a alterações no plano de consulta, potencialmente introduzidas por novos comportamentos de otimização de consulta.

As alterações fundamentais que afetam o plano adicionadas apenas ao nível de compatibilidade padrão de uma nova versão do Mecanismo de Banco de Dados são:

1. As correções do Otimizador de Consulta lançadas para versões anteriores do SQL Server sob o sinalizador de rastreamento 4199 tornam-se automaticamente habilitadas no nível de compatibilidade padrão de uma versão mais recente do SQL Server.

   Aplica-se a: SQL Server (a partir da versão SQL Server 2016 (13.x)), Banco de Dados SQL do Azure.

   Por exemplo, quando o SQL Server 2016 (13.x) foi lançado, todas as correções do Otimizador de Consulta lançadas para versões anteriores do SQL Server (e respetivos níveis de compatibilidade de 100 a 120) foram automaticamente habilitadas para bancos de dados que usam o nível de compatibilidade padrão do SQL Server 2016 (13.x) (130). Somente as correções do Otimizador de Consulta pós-RTM precisam ser explicitamente habilitadas.

   Para habilitar as correções do Otimizador de Consulta, você pode usar os seguintes métodos:

   • No nível do servidor, com sinalizador de rastreamento 4199.
   • No nível do banco de dados, com a QUERY_OPTIMIZER_HOTFIXES opção em ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL).
   • No nível da consulta, com a USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' de consulta modificando a consulta.
   • No nível da consulta, com as USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' alterações sem código, usando o recurso de dicas do Repositório de Consultas .

   Mais tarde, quando o SQL Server 2017 (14.x) foi lançado, todas as correções do Otimizador de Consulta lançadas após o SQL Server 2016 (13.x) RTM se tornaram automaticamente habilitadas para bancos de dados usando o nível de compatibilidade padrão do SQL Server 2017 (14.x) (140). Este é um comportamento cumulativo que inclui todas as correções de versões anteriores também. Novamente, apenas as correções do Otimizador de Consulta pós-RTM precisam ser explicitamente habilitadas.

   A tabela a seguir resume esse comportamento:

   Versão do Mecanismo de Banco de Dados (DE)	Nível de compatibilidade do banco de dados	TF 4199	Alterações de QO de todos os níveis de compatibilidade de banco de dados anteriores	Alterações de QO para a versão (DE) pós-RTM
   13 (SQL Server 2016 (13.x))	100 a 120 130	Desativado Ligado Desativado Ligado	Desabilitado Ativado(a) Ativado Ativado(a)	Desabilitado Ativado(a) Desabilitado Ativado(a)
   14 (SQL Server 2017 (14.x))	100 a 120 130 140	Desativado Ligado Desativado Ligado Desativado Ligado	Desabilitado Ativado(a) Ativado Ativado(a) Ativado Ativado(a)	Desabilitado Ativado(a) Desabilitado Ativado(a) Desabilitado Ativado(a)
   15 (SQL Server 2019 (15.x)) e (Banco de Dados SQL do Azure)	100 a 120 130 a 140 150	Desativado Ligado Desativado Ligado Desativado Ligado	Desabilitado Ativado(a) Ativado Ativado(a) Ativado Ativado(a)	Desabilitado Ativado(a) Desabilitado Ativado(a) Desabilitado Ativado(a)
   16 (SQL Server 2022 (16.x)) e (Banco de Dados SQL do Azure)	100 a 120 130 a 150 160	Desativado Ligado Desativado Ligado Desativado Ligado	Desabilitado Ativado(a) Ativado Ativado(a) Ativado Ativado(a)	Desabilitado Ativado(a) Desabilitado Ativado(a) Desabilitado Ativado(a)
   17 (SQL Server 2025 (17.x) Preview, Banco de Dados SQL do Azure e Banco de Dados SQL no Microsoft Fabric)	100 a 120 130 a 160 170	Desativado Ligado Desativado Ligado Desativado Ligado	Desabilitado Ativado(a) Ativado Ativado(a) Ativado Ativado(a)	Desabilitado Ativado(a) Desabilitado Ativado(a) Desabilitado Ativado(a)

   As correções do Otimizador de Consulta que abordam resultados errados ou erros de violação de acesso não são protegidas pelo sinalizador de rastreamento 4199. Essas correções não são consideradas opcionais.

2. As alterações no estimador de cardinalidade lançadas no SQL Server, no Banco de Dados SQL do Azure e no Banco de Dados SQL no Microsoft Fabric são habilitadas somente no nível de compatibilidade padrão de uma nova versão do Mecanismo de Banco de Dados, mas não nos níveis de compatibilidade anteriores.

   Por exemplo, quando o SQL Server 2016 (13.x) foi lançado, as alterações no processo de estimativa de cardinalidade estavam disponíveis apenas para bancos de dados usando o nível de compatibilidade padrão do SQL Server 2016 (13.x) (130). Os níveis de compatibilidade anteriores mantiveram o comportamento de estimativa de cardinalidade disponível antes do SQL Server 2016 (13.x).

   Mais tarde, quando o SQL Server 2017 (14.x) foi lançado, alterações mais recentes no processo de estimativa de cardinalidade estavam disponíveis apenas para bancos de dados usando o nível de compatibilidade padrão do SQL Server 2017 (14.x) (140). O nível de compatibilidade de banco de dados 130 manteve o comportamento de estimativa de cardinalidade do SQL Server 2016 (13.x).

   A tabela a seguir resume esse comportamento:

   Versão do Mecanismo de Banco de Dados	Nível de compatibilidade do banco de dados	Nova versão CE alterações
   13 (SQL Server 2016 (13.x))	< 130 130	Desabilitado Ativado(a)
   14 (SQL Server 2017 (14.x))1	< 140 140	Desabilitado Ativado(a)
   15 (SQL Server 2019 (15.x))1	< 150 150	Desabilitado Ativado(a)
   16 (SQL Server 2022 (16.x))1	< 160 160	Desabilitado Ativado(a)
   17 (SQL Server 2025 (17.x) Preview)1	< 170 170	Desabilitado Ativado(a)

   ¹ Também aplicável ao Banco de Dados SQL do Azure e ao Banco de Dados SQL no Microsoft Fabric.

Outras diferenças entre níveis de compatibilidade específicos estão disponíveis nas próximas seções deste artigo.

Diferenças entre o nível de compatibilidade 160 e o nível 170

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 170.

Configuração de nível de compatibilidade de 160 ou inferior	Definição do nível de compatibilidade de 170
Para proteger o material da chave simétrica, a chave mestra do banco de dados e a chave mestra de serviço, o SQL Server e o SQL do Azure armazenam o material da chave em formato criptografado. A encriptação utiliza o modo de preenchimento PKCS#1 v1.5.	Para proteger o material da chave simétrica, a chave mestra do banco de dados e a chave mestra de serviço, o SQL Server e o SQL do Azure armazenam o material da chave em formato criptografado. A criptografia usa o modo de preenchimento OAEP-256. No dm_database_encryption_keys, o encryptor_type será exibido como CERTIFICATE_OAEP_256 em vez de CERTIFICATE.
As expressões regulares podem ser usadas para corresponder a padrões complexos e manipular dados no SQL Server e no banco de dados SQL do Azure. Foi adicionado suporte a expressões regulares no T-SQL. Algumas funções de expressão regular não estão disponíveis em todos os níveis de compatibilidade de banco de dados Para obter mais informações, consulte Funções de expressões regulares.	Funções de expressão regular, como REGEXP_LIKE, REGEXP_MATCHES e REGEXP_SPLIT_TO_TABLE foram introduzidas para permitir a correspondência de padrões, extração e divisão diretamente no T-SQL.
A capacidade de criar incorporações de IA (matrizes vetoriais) a partir de expressões de texto foi adicionada ao mecanismo de banco de dados. Para obter mais informações, consulte Funções de IA.	Introduz a função AI_GENERATE_CHUNKS, que permite fragmentar a entrada de texto para consumo de modelos de IA, melhorando a integração com serviços de IA.
Tradicionalmente, o Mecanismo de Banco de Dados protege as instruções DML do problema de Halloween introduzindo um operador Spool no plano de consulta ou aproveitando outro operador de bloqueio já presente no plano, como um Sort ou um Hash Match.	A proteção otimizada contra o Dia das Bruxas remove operadores de bobina desnecessários e melhora o desempenho da consulta durante as operações DML em que a proteção contra o Dia das Bruxas é necessária.
As consultas parametrizadas podem ter vários planos de consulta armazenados em cache para diferentes categorias de seletividade de um parâmetro. A otimização do plano sensível a parâmetros é ativada por padrão no nível de compatibilidade 160 apenas para consultas selecionadas	Quando a otimização do plano sensível a parâmetros está operando no nível de compatibilidade 170, o suporte a consultas DML, bem como o suporte para tempdb também estão disponíveis
Consultas parametrizadas que têm parâmetros opcionais podem sofrer de planos subótimos devido à deteção de parâmetros.	Otimização do plano de consulta para parâmetros opcionais, melhorando o desempenho gerando planos mais apropriados para valores NULL e non-NULL.

Diferenças entre o nível de compatibilidade 150 e o nível 160

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 160.

Configuração de nível de compatibilidade de 150 ou inferior	Definição do nível de compatibilidade de 160
As consultas parametrizadas têm um único plano de consulta com base nos parâmetros usados para a primeira execução. Apenas um plano de consulta é armazenado em cache e usado para todos os valores de parâmetro. Isso pode fazer com que um plano de consulta seja ineficiente para alguns valores do parâmetro, também conhecido como plano sensível a parâmetros.	As consultas parametrizadas podem ter vários planos de consulta armazenados em cache para diferentes categorias de seletividade de um parâmetro. A otimização do plano sensível a parâmetros é ativada por padrão no nível de compatibilidade 160. Para obter mais informações, consulte Otimização PSP.
A estimativa de cardinalidade usa apenas um conjunto padrão de pressupostos de modelo sobre a distribuição de dados subjacentes e padrões de uso para todos os bancos de dados e consultas. A única maneira de alterar ou ajustar qualquer uma dessas suposições é quando o usuário realiza um processo manual para indicar explicitamente quais suposições de modelo devem ser usadas, usando dicas de consulta. Nenhum ajuste interno pode ser feito nesse modelo padrão depois que um plano de consulta é gerado.	A estimativa de cardinalidade começa com o conjunto padrão de pressupostos de modelo sobre a distribuição de dados subjacentes e os padrões de uso, mas após algumas execuções para uma determinada consulta, o Mecanismo de Banco de Dados aprende quais conjuntos diferentes de pressupostos de modelo podem produzir estimativas mais precisas e, portanto, ajusta as suposições em uso para corresponder melhor ao conjunto de dados que está sendo consultado. O CE Feedback é ativado por padrão no nível de compatibilidade 160. Para obter mais informações, consulte Feedback da estimativa de cardinalidade (CE).
Nenhuma determinação automática do grau ideal de paralelismo é tentada pelo Mecanismo de Banco de Dados. Para obter informações sobre como controlar manualmente o grau máximo de paralelismo (MAXDOP) nos níveis de instância, banco de dados, consulta ou carga de trabalho, consulte Configuração do servidor: grau máximo de paralelismo	O feedback do Grau de Paralelismo (DOP) melhora o desempenho da consulta, identificando ineficiências de paralelismo para consultas repetidas, com base no tempo decorrido e nas esperas. Se o uso de paralelismo for considerado ineficiente, o DOP Feedback reduzirá o DOP para a próxima execução da consulta, seja qual for o DOP configurado, e verificará se isso ajuda. O DOP Feedback não está habilitado por padrão. Para habilitar o DOP Feedback, habilite a configuração do escopo do DOP_FEEDBACK banco de dados em um banco de dados. Para obter mais informações, consulte Feedback do Grau de paralelismo (DOP).

Diferenças entre o nível de compatibilidade 140 e o nível 150

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 150.

Definição do nível de compatibilidade igual ou inferior a 140	Definição do nível de compatibilidade de 150
O data warehouse relacional e as cargas de trabalho analíticas podem não ser capazes de usar índices columnstore devido à sobrecarga OLTP, falta de suporte do fornecedor ou outras limitações. Sem índices columnstore, essas cargas de trabalho não podem se beneficiar do modo de execução em lote.	O modo de execução em lote agora está disponível para cargas de trabalho analíticas sem exigir índices columnstore. Para obter mais informações, consulte Modo de lote no armazenamento de linhas.
As consultas de modo de linha que solicitam tamanhos de concessão de memória insuficientes que resultam em derramamentos para o disco podem continuar a ter problemas em execuções consecutivas.	As consultas de modo de linha que solicitam tamanhos de concessão de memória insuficientes que resultam em derramamentos para o disco podem ter melhorado o desempenho em execuções consecutivas. Para obter mais informações, consulte Feedback de concessão de memória no modo de linha.
As consultas de modo de linha que solicitam um tamanho excessivo de concessão de memória que resulta em problemas de simultaneidade podem continuar a ter problemas em execuções consecutivas.	As consultas de modo de linha que solicitam um tamanho excessivo de concessão de memória que resulta em problemas de simultaneidade podem ter melhorado a simultaneidade em execuções consecutivas. Para obter mais informações, consulte Feedback de concessão de memória no modo de linha.
As consultas que fazem referência a UDFs escalares T-SQL usarão invocação iterativa, falta de custeio e forçarão a execução serial.	UDFs escalares do T-SQL são transformadas em expressões relacionais equivalentes que são "embutidas" na consulta de chamada, geralmente resultando em ganhos de desempenho significativos. Para obter mais informações, consulte T-SQL scalar UDF inlining.
As variáveis da tabela usam um palpite fixo para a estimativa de cardinalidade. Se o número real de linhas for muito maior do que o valor estimado, o desempenho das operações a jusante pode ser prejudicado.	Novos planos usarão a cardinalidade real da variável de tabela encontrada na primeira compilação em vez de um palpite fixo. Para obter mais informações, consulte compilação diferida da variável de tabela.

Para obter mais informações sobre os recursos de processamento de consultas habilitados no nível de compatibilidade de banco de dados 150, consulte Novidades no SQL Server 2019 e Processamento inteligente de consultas em bancos de dados SQL.

Diferenças entre o nível de compatibilidade 130 e o nível 140

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 140.

Definição de nível de compatibilidade igual ou inferior a 130	Definição do nível de compatibilidade de 140
As estimativas de cardinalidade para instruções que fazem referência a funções com valor de tabela de várias instruções usam uma estimativa de linha fixa.	As estimativas de cardinalidade para instruções elegíveis que fazem referência a funções com valor de tabela de várias instruções usarão a cardinalidade real da saída da função. Isso é habilitado por meio da execução intercalada para funções com valor de tabela de várias instruções.
Consultas em modo de lote que solicitam tamanhos de concessão de memória insuficientes que resultam em vazamentos para o disco podem continuar a ter problemas em execuções consecutivas.	As consultas em modo de lote que solicitam tamanhos de concessão de memória insuficientes que resultam em derramamentos para o disco podem ter melhorado o desempenho em execuções consecutivas. Isso é ativado por meio de feedback de concessão de memória em modo de lote que atualizará o tamanho de concessão de memória de um plano armazenado em cache se tiverem ocorrido vazamentos para operadores de modo de lote.
As consultas em modo de lote que solicitam um tamanho excessivo de concessão de memória que resulta em problemas de simultaneidade podem continuar a ter problemas em execuções consecutivas.	As consultas em modo de lote que solicitam um tamanho excessivo de concessão de memória que resulta em problemas de simultaneidade podem ter melhorado a simultaneidade em execuções consecutivas. Isso é ativado por meio de feedback de concessão de memória em modo de lote que atualizará o tamanho da concessão de memória de um plano armazenado em cache se uma quantidade excessiva tiver sido originalmente solicitada.
As consultas de modo de lote que contêm operadores de junção são qualificadas para três algoritmos de junção física, incluindo loop aninhado, junção de hash e junção de mesclagem. Se as estimativas de cardinalidade estiverem incorretas para entradas de junção, um algoritmo de junção inadequado pode ser selecionado. Se isso ocorrer, o desempenho será prejudicado e o algoritmo de junção inadequado permanecerá em uso até que o plano armazenado em cache seja recompilado.	Há um operador de junção adicional chamado junção adaptável. Se as estimativas de cardinalidade estiverem incorretas para a entrada de junção de compilação externa, um algoritmo de junção inadequado pode ser selecionado. Se isso ocorrer e a instrução for elegível para uma junção adaptável, um loop aninhado será usado para entradas de junção menores e uma junção de hash será usada para entradas de junção maiores dinamicamente sem exigir recompilação.
Planos triviais que fazem referência a índices Columnstore não são qualificados para execução em modo de lote.	Um plano trivial que faça referência a índices Columnstore será descartado em favor de um plano qualificado para execução em modo de lote.
O sp_execute_external_script operador UDX só pode ser executado no modo de linha.	O sp_execute_external_script operador UDX é elegível para execução em modo de lote.
As funções com valor de tabela (TVFs) de várias instruções não têm execução intercalada	Execução intercalada para TVFs multi-statement para melhorar a qualidade do plano.

As correções que estavam sob o sinalizador de rastreamento 4199 em versões anteriores do SQL Server anteriores ao SQL Server 2017 agora estão habilitadas por padrão. Com modo de compatibilidade 140. O sinalizador de rastreamento 4199 ainda será aplicável para novas correções do otimizador de consulta lançadas após o SQL Server 2017. Para obter informações sobre o sinalizador de rastreamento 4199, consulte Sinalizador de rastreamento 4199.

Diferenças entre o nível de compatibilidade 120 e o nível 130

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 130.

Definição de nível de compatibilidade igual ou inferior a 120	Definição do nível de compatibilidade de 130
O INSERT em uma instrução INSERT-SELECT é single-threaded.	O INSERT em uma instrução INSERT-SELECT é multi-threaded ou pode ter um plano paralelo.
As consultas em uma tabela com otimização de memória são executadas com thread único.	As consultas em uma tabela com otimização de memória agora podem ter planos paralelos.
Introduzido o estimador de cardinalidade SQL 2014 CardinalityEstimationModelVersion="120"	Melhorias adicionais na estimativa de cardinalidade (CE) com o Modelo de Estimativa de Cardinalidade 130, que é visível a partir de um plano de consulta. CardinalityEstimationModelVersion="130"
O modo de lote versus as alterações do modo de linha com os índices Columnstore: As classificações em uma tabela com o índice Columnstore estão no modo Linha Os agregados da função de janela operam em modo de linha, como LAG ou LEAD Consultas em tabelas Columnstore com várias cláusulas distintas operadas no modo Linha Consultas em execução sob MAXDOP 1 ou com um plano serial executado no modo de linha	O modo de lote versus as alterações do modo de linha com os índices Columnstore: As classificações em uma tabela com um índice Columnstore agora estão no modo de lote Os agregados de janelas agora operam em modo de lote, como LAG ou LEAD As consultas em tabelas Columnstore com várias cláusulas distintas operam no modo Batch Consultas executadas em MAXDOP 1 ou com um plano serial são executadas no Modo de Lote
As estatísticas podem ser atualizadas automaticamente.	A lógica que atualiza automaticamente as estatísticas é mais agressiva em mesas grandes. Na prática, isso deve reduzir os casos em que os clientes viram problemas de desempenho em consultas em que as linhas recém-inseridas são consultadas com frequência, mas em que as estatísticas não foram atualizadas para incluir esses valores.
O rastreamento 2371 está DESATIVADO por padrão no SQL Server 2014 (12.x).	O rastreamento 2371 está ATIVADO por padrão no SQL Server 2016 (13.x). O sinalizador de rastreamento 2371 diz ao atualizador automático de estatísticas para obter uma amostra de um subconjunto menor e mais sábio de linhas, em uma tabela que tem muitas linhas. Uma melhoria é incluir na amostra mais linhas que foram inseridas recentemente. Outra melhoria é permitir que as consultas sejam executadas enquanto o processo de estatísticas de atualização está em execução, em vez de bloquear a consulta.
Para o nível 120, as estatísticas são amostradas por um processo de thread único.	Para o nível 130, as estatísticas são amostradas por um processo multi-threaded (processo paralelo).
253 chaves estrangeiras de entrada é o limite.	Uma determinada tabela pode ser referenciada por até 10.000 chaves estrangeiras de entrada ou referências semelhantes. Para restrições, consulte Criar relações de chave estrangeira.
Os algoritmos de hash MD2, MD4, MD5, SHA e SHA1 preteridos são permitidos.	Apenas SHA2_256 e SHA2_512 algoritmos de hash são permitidos.
	O SQL Server 2016 (13.x) inclui melhorias em alguns tipos de dados, conversões e algumas operações (principalmente incomuns). Para obter detalhes, consulte Aprimoramentos do SQL Server e do Banco de Dados SQL do Azure no tratamento de alguns tipos de dados e operações incomuns.
A STRING_SPLIT função não está disponível.	A STRING_SPLIT função está disponível no nível de compatibilidade 130 ou superior. Se o nível de compatibilidade do banco de dados for inferior a 130, o SQL Server não poderá localizar e executar STRING_SPLIT a função.

As correções que estavam sob o sinalizador de rastreamento 4199 em versões anteriores do SQL Server antes do SQL Server 2016 (13.x) agora estão habilitadas por padrão. Com modo de compatibilidade 130. O sinalizador de rastreamento 4199 ainda será aplicável para novas correções do otimizador de consulta lançadas após o SQL Server 2016 (13.x). Para usar o otimizador de consulta mais antigo no Banco de dados SQL, você deve selecionar o nível de compatibilidade 110. Para obter informações sobre o sinalizador de rastreamento 4199, consulte Sinalizador de rastreamento 4199.

Diferenças entre níveis de compatibilidade mais baixos e nível 120

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 120.

Definição do nível de compatibilidade de 110 ou inferior	Definição do nível de compatibilidade de 120
O otimizador de consulta mais antigo é usado.	O SQL Server 2014 (12.x) inclui melhorias substanciais no componente que cria e otimiza planos de consulta. Esse novo recurso de otimizador de consulta depende do uso do nível de compatibilidade de banco de dados 120. Novos aplicativos de banco de dados devem ser desenvolvidos usando o nível de compatibilidade de banco de dados 120 para aproveitar essas melhorias. Os aplicativos migrados de versões anteriores do SQL Server devem ser cuidadosamente testados para confirmar se o bom desempenho foi mantido ou melhorado. Se o desempenho diminuir, você poderá definir o nível de compatibilidade do banco de dados como 110 ou anterior para usar a metodologia mais antiga do otimizador de consulta. O nível de compatibilidade de banco de dados 120 usa um novo estimador de cardinalidade que é ajustado para armazenamento de dados moderno e cargas de trabalho OLTP. Antes de definir o nível de compatibilidade do banco de dados como 110 devido a problemas de desempenho, consulte as recomendações na seção Planos de Consulta de Novidades no SQL Server 2016.
Em níveis de compatibilidade inferiores a 120, a configuração de idioma é ignorada ao converter um valor de data em um valor de cadeia de caracteres. Esse comportamento é específico apenas para o tipo de data . Veja o exemplo B na seção Exemplos .	A configuração de idioma não é ignorada ao converter um valor de data em um valor de cadeia de caracteres.
As referências recursivas no lado direito de uma EXCEPT cláusula criam um loop infinito. O exemplo C na seção Exemplos demonstra esse comportamento.	As referências recursivas em uma EXCEPT cláusula geram um erro em conformidade com o padrão ANSI SQL.
A expressão de tabela comum recursiva (CTE) permite nomes de coluna duplicados.	O CTE recursivo não permite nomes de colunas duplicados.
Os gatilhos desabilitados são habilitados se os gatilhos forem alterados.	Alterar um gatilho não altera o estado (ativado ou desativado) do gatilho.
A cláusula da tabela OUTPUT INTO ignora e IDENTITY_INSERT SETTING = OFF permite que valores explícitos sejam inseridos.	Não é possível inserir valores explícitos para uma coluna de identidade em uma tabela quando IDENTITY_INSERT está definido como OFF.
Quando a contenção do banco de dados é definida como parcial, validar o $actionOUTPUT campo na cláusula de uma MERGE instrução pode retornar um erro de agrupamento.	O agrupamento dos valores retornados pela $action cláusula de uma MERGE instrução é o agrupamento do banco de dados em vez do agrupamento do servidor e um erro de conflito de agrupamento não é retornado.
Uma SELECT INTO instrução sempre cria uma operação de inserção de thread único.	Uma SELECT INTO instrução pode criar uma operação de inserção paralela. Ao inserir um grande número de linhas, a operação paralela pode melhorar o desempenho.

Diferenças entre níveis de compatibilidade mais baixos e níveis 100 e 110

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 110. Esta secção também se aplica a níveis de compatibilidade superiores a 110.

Definição de nível de compatibilidade igual ou inferior a 100	Definição do nível de compatibilidade de pelo menos 110
Os objetos de banco de dados CLR (Common Language Runtime) são executados com a versão 4 do CLR. No entanto, algumas alterações de comportamento introduzidas na versão 4 do CLR são evitadas. Para obter mais informações, consulte O que há de novo na integração CLR?	Os objetos de banco de dados CLR são executados com a versão 4 do CLR.
As funções XQuery string-length e substring contam cada substituto como dois caracteres.	As funções XQuery string-length e substring contam cada substituto como um caractere.
PIVOT é permitido em uma consulta de expressão de tabela comum (CTE) recursiva. No entanto, a consulta retorna resultados incorretos quando há várias linhas por agrupamento.	PIVOT não é permitido em uma consulta de expressão de tabela comum (CTE) recursiva. Um erro é retornado.
O algoritmo RC4 só é suportado para compatibilidade com versões anteriores. O novo material só pode ser encriptado utilizando RC4 ou RC4_128 quando a base de dados estiver no nível de compatibilidade 90 ou 100. (Não recomendado.) No SQL Server 2012 (11.x), o material criptografado usando RC4 ou RC4_128 pode ser descriptografado em qualquer nível de compatibilidade.	O novo material não pode ser encriptado usando RC4 ou RC4_128. Em vez disso, use um algoritmo mais recente, como um dos algoritmos AES. No SQL Server 2012 (11.x), o material criptografado usando RC4 ou RC4_128 pode ser descriptografado em qualquer nível de compatibilidade.
O estilo padrão para CAST e CONVERT operações nos tipos de dados time e datetime2 é 121, exceto quando qualquer um dos tipos é usado em uma expressão de coluna computada. Para colunas computadas, o estilo padrão é 0. Esse comportamento afeta colunas computadas quando elas são criadas, usadas em consultas que envolvem parametrização automática ou usadas em definições de restrição. O Exemplo D na seção Exemplos mostra a diferença entre os estilos 0 e 121. Não demonstra o comportamento descrito acima. Para obter mais informações sobre estilos de data e hora, consulte CAST e CONVERT.	No nível de compatibilidade 110, o estilo padrão para CAST e CONVERT operações nos tipos de dados time e datetime2 é sempre 121. Se sua consulta depender do comportamento antigo, use um nível de compatibilidade menor que 110 ou especifique explicitamente o estilo 0 na consulta afetada. Atualizar o banco de dados para o nível de compatibilidade 110 não alterará os dados do usuário que foram armazenados no disco. Você deve corrigir manualmente esses dados conforme apropriado. Por exemplo, se você costumava SELECT INTO criar uma tabela a partir de uma fonte que continha uma expressão de coluna computada descrita acima, os dados (usando o estilo 0) seriam armazenados em vez da própria definição de coluna computada. Você precisaria atualizar manualmente esses dados para corresponder ao estilo 121.
O operador + (Addition) pode ser aplicado a um operando do tipo date, time, datetime2 ou datetimeoffset se o outro operando tiver o tipo datetime ou smalldatetime.	Tentar aplicar o operador de adição a um operando do tipo date, time, datetime2 ou datetimeoffset e um operando do tipo datetime ou smalldatetime causará o erro 402.
Todas as colunas em tabelas remotas do tipo smalldatetime referenciadas em um modo de exibição particionado são mapeadas como datetime. As colunas correspondentes em tabelas locais (na mesma posição ordinal na lista de seleção) devem ser do tipo datetime.	Todas as colunas em tabelas remotas do tipo smalldatetime referenciadas em um modo de exibição particionado são mapeadas como smalldatetime. As colunas correspondentes em tabelas locais (na mesma posição ordinal na lista de seleção) devem ser do tipo smalldatetime. Após a atualização para 110, a exibição particionada distribuída falhará devido à incompatibilidade de tipo de dados. Você pode resolver isso alterando o tipo de dados na tabela remota para datetime ou definindo o nível de compatibilidade do banco de dados local como 100 ou inferior.
SOUNDEX function implementa as seguintes regras: 1) H maiúsculo ou W maiúsculo é ignorado ao separar duas consoantes que têm o mesmo número no SOUNDEX código. 2) Se os dois primeiros caracteres de character_expression tiverem o mesmo número no código, ambos os SOUNDEX caracteres são incluídos. Caso contrário, se um conjunto de consoantes lado a lado tiver o mesmo número no SOUNDEX código, todas elas serão excluídas, exceto a primeira.	SOUNDEX function implementa as seguintes regras: 1) Se H SOUNDEX maiúsculo ou W maiúsculo separarem duas consoantes que têm o mesmo número no código, a consoante à direita será ignorada 2) Se um conjunto de consoantes lado a lado tiver o mesmo número no SOUNDEX código, todas elas são excluídas, exceto a primeira. As regras adicionais podem fazer com que os SOUNDEX valores calculados pela função sejam diferentes dos valores computados em níveis de compatibilidade anteriores. Depois de atualizar para o nível de compatibilidade 110, talvez seja necessário reconstruir os índices, heaps ou restrições CHECK que usam a SOUNDEX função. Para obter mais informações, consulte SOUNDEX.
STRING_AGG está disponível sem um <order_clause>arquivo .	STRING_AGGestá disponível com um arquivo .<order_clause> Para obter mais informações, consulte STRING_AGG

Diferenças entre o nível de compatibilidade 90 e o nível 100

Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 100.

Definição do nível de compatibilidade de 90	Definição do nível de compatibilidade de 100	Possibilidade de impacto
A configuração QUOTED_IDENTIFIER é sempre definida como ON para funções com valor de tabela de várias instruções quando são criadas, independentemente da configuração de nível de sessão.	A configuração de sessão IDENTIFICADOR CITADO é honrada quando funções com valor de tabela de várias instruções são criadas.	Médio
Quando você cria ou altera uma função de partição, literais datetime e smalldatetime na função são avaliados assumindo US_English como a configuração de idioma.	A configuração de idioma atual é usada para avaliar literais datetime e smalldatetime na função de partição.	Médio
A FOR BROWSE cláusula é permitida (e ignorada) em INSERT e SELECT INTO declarações.	A FOR BROWSE cláusula não é permitida em INSERT e SELECT INTO declarações.	Médio
Predicados de texto completo são permitidos na OUTPUT cláusula.	Predicados de texto completo não são permitidos OUTPUT na cláusula.	Baixo
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLISTe DROP FULLTEXT STOPLIST não são suportados. A lista de paradas do sistema é automaticamente associada a novos índices de texto completo.	CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLISTe DROP FULLTEXT STOPLIST são suportados.	Baixo
MERGE não é imposta como uma palavra-chave reservada.	MERGE é uma palavra-chave totalmente reservada. A MERGE instrução é suportada em ambos os níveis de compatibilidade 100 e 90.	Baixo
O uso do <dml_table_source> argumento da instrução INSERT gera um erro de sintaxe.	Você pode capturar os resultados de uma cláusula OUTPUT em uma instrução INSERT, UPDATE, DELETE ou MERGE aninhada e inserir esses resultados em uma tabela ou exibição de destino. Isso é feito usando o <dml_table_source> argumento da instrução INSERT.	Baixo
A menos que NOINDEX seja especificado DBCC CHECKDB ou DBCC CHECKTABLE execute verificações de consistência física e lógica em uma única tabela ou exibição indexada e em todos os seus índices não clusterizados e XML. Não há suporte para índices espaciais.	A menos que NOINDEX seja especificado DBCC CHECKDB ou DBCC CHECKTABLE execute verificações de consistência física e lógica em uma única tabela e em todos os seus índices não clusterizados. No entanto, em índices XML, índices espaciais e exibições indexadas, apenas verificações de consistência física são executadas por padrão. Se WITH EXTENDED_LOGICAL_CHECKS for especificado, verificações lógicas serão executadas em exibições indexadas, índices XML e índices espaciais, quando presentes. Por padrão, as verificações de consistência física são executadas antes das verificações de consistência lógica. Se NOINDEX também for especificado, apenas as verificações lógicas serão executadas.	Baixo
Quando uma cláusula OUTPUT é usada com uma instrução DML (linguagem de manipulação de dados) e ocorre um erro em tempo de execução durante a execução da instrução, toda a transação é encerrada e revertida.	Quando uma OUTPUT cláusula é usada com uma instrução DML (linguagem de manipulação de dados) e ocorre um erro em tempo de execução durante a execução da instrução, o comportamento depende da SET XACT_ABORT configuração. Se SET XACT_ABORT estiver OFF, um erro de anulação de instrução gerado pela instrução DML usando a OUTPUT cláusula encerrará a instrução, mas a execução do lote continuará e a transação não será revertida. Se SET XACT_ABORT estiver ON, todos os erros de tempo de execução gerados pela instrução DML usando a cláusula OUTPUT encerrarão o lote e a transação será revertida.	Baixo
CUBE e ROLLUP não são impostos como palavras-chave reservadas.	CUBE e ROLLUP são palavras-chave reservadas dentro da cláusula GROUP BY.	Baixo
A validação estrita é aplicada a elementos do tipo XML anyType .	A validação lax é aplicada a elementos do tipo anyType . Para obter mais informações, consulte Componentes curinga e validação de conteúdo.	Baixo
Os atributos especiais xsi:nil e xsi:type não podem ser consultados ou modificados por instruções de linguagem de manipulação de dados. Isso significa que /e/@xsi:nil falha enquanto /e/@* ignora os atributos xsi:nil e xsi:type . No entanto, /e retorna os atributos xsi:nil e xsi:type para consistência com SELECT xmlCol, mesmo que xsi:nil = "false".	Os atributos especiais xsi:nil e xsi:type são armazenados como atributos regulares e podem ser consultados e modificados. Por exemplo, a execução da consulta SELECT x.query('a/b/@*') retorna todos os atributos, incluindo xsi:nil e xsi:type. Para excluir esses tipos na consulta, substitua @* por @*[namespace-uri(.) != "insert xsi namespace uri" e not (local-name(.) = "type" ou local-name(.) ="nil".	Baixo
Uma função definida pelo usuário que converte um valor de cadeia de caracteres constante XML em um tipo datetime do SQL Server é marcada como determinística.	Uma função definida pelo usuário que converte um valor de cadeia de caracteres constante XML em um tipo datetime do SQL Server é marcada como não determinística.	Baixo
A união XML e os tipos de lista não são totalmente suportados.	Os tipos união e lista são totalmente suportados, incluindo a seguinte funcionalidade: União da lista União sindical Lista de tipos atómicos Lista do sindicato	Baixo
As opções SET necessárias para um método xQuery não são validadas quando o método está contido em uma exibição ou função com valor de tabela embutida.	As opções SET necessárias para um método xQuery são validadas quando o método está contido em uma exibição ou função com valor de tabela embutida. Um erro é gerado se as opções SET do método estão definidas incorretamente.	Baixo
Os valores de atributos XML que contêm caracteres de fim de linha (retorno de carro e alimentação de linha) não são normalizados de acordo com o padrão XML. Ou seja, ambos os caracteres são retornados em vez de um único caractere de alimentação de linha.	Os valores de atributos XML que contêm caracteres de fim de linha (retorno de carro e alimentação de linha) são normalizados de acordo com o padrão XML. Ou seja, todas as quebras de linha em entidades analisadas externas (incluindo a entidade do documento) são normalizadas na entrada traduzindo a sequência de dois caracteres #xD #xA e qualquer #xD que não seja seguida por #xA para um único caractere #xA. Os aplicativos que usam atributos para transportar valores de cadeia de caracteres que contêm caracteres de fim de linha não receberão esses caracteres de volta à medida que forem enviados. Para evitar o processo de normalização, use as entidades de caracteres numéricos XML para codificar todos os caracteres de fim de linha.	Baixo
As propriedades ROWGUIDCOL da coluna e IDENTITY podem ser nomeadas incorretamente como uma restrição. Por exemplo, a instrução CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) é executada, mas o nome da restrição não é preservado e não está acessível ao usuário.	As propriedades ROWGUIDCOL da coluna e IDENTITY não podem ser nomeadas como uma restrição. O erro 156 é retornado.	Baixo
A atualização de colunas usando uma atribuição bidirecional pode UPDATE T1 SET @v = column_name = <expression> produzir resultados inesperados porque o valor ativo da variável pode ser usado em outras cláusulas, como a cláusula e WHERE durante a ON execução da instrução, em vez do valor inicial da instrução. Isso pode fazer com que os significados dos predicados mudem de forma imprevisível por linha. Esse comportamento é aplicável somente quando o nível de compatibilidade é definido como 90.	A atualização de colunas usando uma atribuição bidirecional produz resultados esperados porque somente o valor inicial da instrução da coluna é acessado durante a execução da instrução.	Baixo
A atribuição de variáveis é permitida em uma instrução que contém um operador de nível UNION superior, mas retorna resultados inesperados. Saiba mais no exemplo E.	A atribuição de variáveis não é permitida em uma instrução que contenha um operador UNION de nível superior. O erro 10734 é retornado. Encontre uma sugestão de reescrita no exemplo E.	Baixo
A função ODBC {fn CONVERT()} usa o formato de data padrão do idioma. Para alguns idiomas, o formato padrão é YDM, o que pode resultar em erros de conversão quando CONVERT() é combinado com outras funções, como {fn CURDATE()}, que esperam um formato YMD.	A função {fn CONVERT()} ODBC usa o estilo 121 (um formato YMD independente de idioma) ao converter para os tipos de dados ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME e SQL_TYPE_TIMESTAMP.	Baixo
Intrínsecas de data/hora, como DATEPART não exigem que os valores de entrada de cadeia de caracteres sejam literais de data/hora válidos. Por exemplo, SELECT DATEPART (year, '2007/05-30') compila com êxito.	Intrínsecos de data/hora, como DATEPART exigem que os valores de entrada de cadeia de caracteres sejam literais de data/hora válidos. O erro 241 é retornado quando um literal datetime inválido é usado.	Baixo
Os espaços à direita especificados no primeiro parâmetro de entrada para a função REPLACE são cortados quando o parâmetro é do tipo char. Por exemplo, na instrução SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', o valor 'ABC ' é avaliado incorretamente como 'ABC'.	Os espaços de fuga são sempre preservados. Para aplicativos que dependem do comportamento anterior da função, use a RTRIM função ao especificar o primeiro parâmetro de entrada para a função. Por exemplo, a sintaxe a seguir reproduzirá o comportamento do SQL Server 2005: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.	Baixo

Palavras-chave reservadas

A configuração de compatibilidade também determina as palavras-chave reservadas pelo Mecanismo de Banco de Dados. A tabela a seguir mostra as palavras-chave reservadas que são introduzidas por cada um dos níveis de compatibilidade.

Definição do nível de compatibilidade	Palavras-chave reservadas
130	A determinar.
120	Nenhum.
110	WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE
100	CUBE, MERGE, ROLLUP
90	EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

Num determinado nível de compatibilidade, as palavras-chave reservadas incluem todas as palavras-chave introduzidas nesse nível ou abaixo deste. Assim, por exemplo, para aplicações de nível 110, todas as palavras-chave listadas na tabela anterior são reservadas. Nos níveis de compatibilidade mais baixos, as palavras-chave de nível 100 permanecem nomes de objeto válidos, mas os recursos de idioma de nível 110 correspondentes a essas palavras-chave não estão disponíveis.

Uma vez introduzida, uma palavra-chave permanece reservada. Por exemplo, a palavra-chave reservada PIVOT, que foi introduzida no nível de compatibilidade 90, também é reservada nos níveis 100, 110 e 120.

Se um aplicativo usar um identificador reservado como palavra-chave para seu nível de compatibilidade, o aplicativo falhará. Para contornar isso, coloque o identificador entre colchetes ([]) ou aspas (""); Por exemplo, para atualizar um aplicativo que usa o identificador EXTERNAL para o nível de compatibilidade 90, você pode alterar o identificador para um ou [EXTERNAL]"EXTERNAL" .

Para obter mais informações, consulte Palavras-chave reservadas.

Permissões

Requer permissão ALTER no banco de dados.

Exemplos

Um. Alterar o nível de compatibilidade

O exemplo a seguir altera o nível de compatibilidade do AdventureWorks2022 banco de dados de exemplo para 150, o padrão para o SQL Server 2019 (15.x).

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO

O exemplo a seguir retorna o nível de compatibilidade do banco de dados atual.

SELECT name,
       compatibility_level
FROM sys.databases
WHERE name = db_name();
GO

B. Ignore a instrução SET LANGUAGE, exceto no nível de compatibilidade 120 ou superior

A consulta a seguir ignora a instrução, SET LANGUAGE exceto no nível de compatibilidade 120 ou superior.

SET DATEFORMAT dmy;

DECLARE @t2 AS DATE = '12/5/2011';

SET LANGUAGE dutch;

SELECT CONVERT (VARCHAR (11), @t2, 106);
GO

Resultados quando o nível de compatibilidade é inferior a 120: 12 May 2011

Resultados quando o nível de compatibilidade é definido como 120 ou superior: 12 mei 2011

C. Para a configuração de nível de compatibilidade de 110 ou inferior, as referências recursivas no lado direito de uma cláusula EXCEPT criam um loop infinito

WITH cte AS
    (SELECT * FROM (VALUES (1), (2), (3)) AS v(a)),
    r AS (SELECT a
    FROM cte
UNION ALL
    (SELECT a FROM cte EXCEPT SELECT a FROM r))
SELECT a
FROM r;
GO

D. A diferença entre os estilos 0 e 121

Quando o nível de compatibilidade é inferior a 110, o estilo padrão para CAST operações CONVERT nos tipos de dados time e datetime2 é 121, exceto quando qualquer um dos tipos é usado em uma expressão de coluna computada. Para colunas computadas, o estilo padrão é 0.

Quando o nível de compatibilidade é 110 ou superior, o estilo padrão para CAST e CONVERT operações nos tipos de dados time e datetime2 é sempre 121. Consulte Diferenças entre níveis de compatibilidade mais baixos e níveis 100 e 110 para obter mais informações.

Para obter mais informações sobre estilos de data e hora, consulte CAST e CONVERT.

DROP TABLE IF EXISTS t1;
GO

CREATE TABLE t1
(
    c1 TIME (7),
    c2 DATETIME2
);
GO

INSERT t1 (c1, c2)
VALUES (GETDATE(), GETDATE());
GO

SELECT CONVERT (NVARCHAR (16), c1, 0) AS TimeStyle0,
       CONVERT (NVARCHAR (16), c1, 121) AS TimeStyle121,
       CONVERT (NVARCHAR (32), c2, 0) AS Datetime2Style0,
       CONVERT (NVARCHAR (32), c2, 121) AS Datetime2Style121
FROM t1;
GO

Isso retorna resultados como os seguintes:

TimeStyle0	TimeStyle121	Datetime2Style0	Datetime2Style121
15:15	15:15:35.8100000	7 jun 2011 15:15	2011-06-07 15:15:35.8130000

E. Atribuição variável - operador UNION de nível superior

Na configuração de nível de compatibilidade do banco de dados de 90, a atribuição de variáveis é permitida em uma instrução que contém um operador UNION de nível superior, mas retorna resultados inesperados. Por exemplo, nas instruções a seguir, a variável @v local recebe o valor da coluna BusinessEntityID da união de duas tabelas. Por definição, quando a instrução SELECT retorna mais de um valor, a variável recebe o último valor retornado. Nesse caso, a variável recebe corretamente o último valor, no entanto, o conjunto de resultados da instrução SELECT UNION também é retornado.

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 110;
GO

USE AdventureWorks2022;
GO

DECLARE @v AS INT;

SELECT @v = BusinessEntityID
FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID
FROM HumanResources.EmployeeAddress;

SELECT @v;

Na configuração de nível de compatibilidade do banco de dados de 100 e superior, a atribuição de variáveis não é permitida em uma instrução que contenha um operador UNION de nível superior. O erro 10734 é retornado.

Para resolver o erro, reescreva a consulta conforme mostrado no exemplo a seguir.

DECLARE @v AS INT;

SELECT @v = BusinessEntityID
FROM (SELECT BusinessEntityID
      FROM HumanResources.Employee
      UNION ALL
      SELECT BusinessEntityID
      FROM HumanResources.EmployeeAddress) AS Test;

SELECT @v;

Conteúdo relacionado

• Mantenha a estabilidade de desempenho durante a atualização para o SQL Server mais recente
• Alterar o nível de compatibilidade do banco de dados e usar o Repositório de Consultas
• Certificação de compatibilidade
• BASE DE DADOS ALTER (Transact-SQL)
• Atualizar bancos de dados usando o Assistente de Ajuste de Consulta
• CRIAR BASE DE DADOS
• Exibir ou alterar o nível de compatibilidade de um banco de dados
• Indicações do Query Store