Nível de compatibilidade de ALTER DATABASE (Transact-SQL)
Aplica-se a: 
SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure
Define Transact-SQL e os comportamentos de processamento de consulta para que sejam compatíveis com a versão especificada do mecanismo SQL. Para obter outras opções de ALTER DATABASE, confira ALTER DATABASE.
Para obter mais informações sobre as convenções de sintaxe, confira Convenções de sintaxe Transact-SQL.
Sintaxe
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }
Argumentos
database_name
O nome do banco de dados a ser modificado.
COMPATIBILITY_LEVEL { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }
A versão do SQL Server com a qual o banco de dados será compatível. Os seguintes valores de nível de compatibilidade podem ser configurados (nem todas as versões dão suporte a todos os níveis de compatibilidade listados acima):
| Produto | Versão do Mecanismo de Banco de Dados | Designação de nível de compatibilidade padrão | Valores do nível de compatibilidade com suporte |
|---|---|---|---|
| Banco de Dados SQL do Azure | 16 | 160 | 160, 150, 140, 130, 120, 110, 100 |
| Instância Gerenciada do Azure SQL | 16 | 150 | 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 | 120 | 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 o SQL Server e o Banco de Dados SQL do Azure não são comparáveis entre si, mas números de build internos para esses produtos separados. O mecanismo de banco de dados para o Banco de Dados SQL do Azure se baseia na mesma base de código do mecanismo de banco de dados do SQL Server. O mais importante é que o mecanismo de banco de dados do Banco de Dados SQL do Azure sempre tem os bits mais recentes do mecanismo de banco de dados SQL. A versão 12 do Banco 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 o fluxo de trabalho recomendado para atualizar o nível de compatibilidade, confira Manter a estabilidade do desempenho durante a atualização para SQL Server mais recentes. Além disso, para uma experiência assistida com a atualização do nível de compatibilidade do banco de dados, confira Atualizando bancos de dados usando o Assistente de Ajuste de Consulta.
Comentários
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 como esse nível, a não ser que o banco de dados do model tenha um nível de compatibilidade inferior. Para bancos de dados anexados ou restaurados de qualquer versão anterior de SQL Server, o banco de dados manterá seu nível de compatibilidade existente se tiver o mínimo de permissão para essa instância do SQL Server. Mover um banco de dados com um nível de compatibilidade mais baixo do que o nível 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 de usuário.
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,msdbe Resource são definidos para o nível de compatibilidade padrão para determinada versão do Mecanismo de Banco de Dados. - O banco de dados do sistema
mastermantém o nível de compatibilidade anterior à atualização. Isso não afetará o comportamento do banco de dados do usuário.
No caso dos bancos de dados preexistentes em execução em níveis de compatibilidade mais baixos, contanto que o aplicativo não precise usar aprimoramentos que estão disponíveis apenas em um nível de compatibilidade do banco de dados mais alto, é uma abordagem válida manter o nível de compatibilidade do banco de dados anterior. Para um novo trabalho de desenvolvimento ou quando um aplicativo existente exigir o uso de novos recursos, como Processamento Inteligente de Consulta e alguns novos Transact-SQL, planeje atualizar o nível de compatibilidade do banco de dados para o mais recente disponível. Para saber mais, confira Níveis de compatibilidade e atualizações de Mecanismo de Banco de Dados.
Observação
Caso não haja dependências e objetos de usuário, geralmente é seguro atualizar para o nível de compatibilidade padrão. Para obter mais informações, confira Recomendações – banco de dados mestre.
Use ALTER DATABASE para alterar o nível de compatibilidade do banco de dados. A nova configuração do nível de compatibilidade de um banco de dados tem efeito quando um comando USE <database> é emitido ou um novo logon é processado com esse banco de dados como o contexto do banco de dados padrão.
Para exibir o nível de compatibilidade atual de um banco de dados, consulte a coluna compatibility_level na exibição de catálogo sys.databases.
Um banco de dados de distribuição criado em uma versão anterior do SQL Server e atualizado para o SQL Server 2016 (13.x) RTM ou o Service Pack 1 tem um nível de compatibilidade 90, para o qual não há suporte em outros bancos de dados. Isso não tem um efeito na funcionalidade de 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 que ele corresponda ao banco de dados master.
Para usar o nível de compatibilidade do banco de dados 120 ou superior para seu banco de dados geral, mas optar pelo modelo de estimativa de cardinalidade do SQL Server 2012 (11.x), que mapeia para o nível de compatibilidade do banco de dados 110, confira ALTER DATABASE SCOPED CONFIGURATION e, em especial, a palavra-chave LEGACY_CARDINALITY_ESTIMATION = ON.
Observações para o SQL do Azure
O nível de compatibilidade padrão é SQL Server 2022 (160) para bancos de dados recém-criados no Banco de Dados SQL do Azure.
O nível de compatibilidade padrão é SQL Server 2019 (150) para bancos de dados recém-criados na Instância Gerenciada de SQL do Azure.
A Microsoft não atualiza automaticamente o nível de compatibilidade do banco de dados para bancos de dados existentes. É responsabilidade dos clientes fazer isso a seu critério.
A Microsoft recomenda que os clientes planejem atualizar para o último nível de compatibilidade, para utilizar as últimas melhorias de otimização de consulta. 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 o nível de compatibilidade 130 no Banco de Dados SQL do Azure. Este artigo se refere ao nível de compatibilidade 130 e ao SQL Server, mas a mesma metodologia se aplica a atualizações para o nível 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 compatíveis com o Banco de Dados SQL do Azure.
Encontre o nível de compatibilidade atual
Para determinar o nível de compatibilidade atual, consulte a coluna compatibility_level 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 de banco de dados, permitindo que o Mecanismo de Banco de Dados do SQL Server seja atualizado, mantendo o mesmo status funcional de aplicativos de conexão e o mesmo nível de compatibilidade do banco de dados antes da atualização. Isso significa que é possível atualizar de uma versão mais antiga de 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 de SQL do Azure) sem alterações do aplicativo (exceto a conectividade do banco de dados). Para saber mais, confira Certificação de Compatibilidade.
Desde que o aplicativo não precise usar os aprimoramentos que estão disponíveis somente em um nível de compatibilidade do banco de dados mais alto, esta é uma abordagem válida para atualizar o Mecanismo de Banco de Dados do SQL Server e manter o nível de compatibilidade do banco de dados anterior. Para saber mais sobre como usar o nível de compatibilidade para compatibilidade com versões anteriores, confira 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 recompilados automaticamente conforme necessário.
Usar o nível de compatibilidade para compatibilidade com versões anteriores
A configuração do nível de compatibilidade do banco de dados oferece compatibilidade com versões anteriores do SQL Server com relação ao Transact-SQL e comportamentos de otimização de consulta apenas para o banco de dados especificado, não para todo o servidor.
Começando com o modo de compatibilidade 130, qualquer plano de consulta novo que afete correções e recursos foi adicionado intencionalmente apenas ao novo nível de compatibilidade. Isso foi feito para minimizar o risco durante as atualizações que surge da degradação do desempenho devido a alterações no plano de consulta potencialmente introduzidas pelos novos comportamentos de otimização de consulta.
Da perspectiva do aplicativo, use o nível de compatibilidade mais baixo como um caminho de migração mais seguro para trabalhar com diferenças de versões nos comportamentos controlados pela configuração de nível de compatibilidade relevante. A meta ainda deve ser atualizar para o último nível de compatibilidade em algum ponto no tempo, para herdar alguns dos novos recursos, como o Processamento de Consulta Inteligente, mas fazer isso de maneira controlada.
Para obter mais informações, incluindo o fluxo de trabalho recomendado para atualizar o nível de compatibilidade do banco de dados, confira Melhores práticas para atualizar o nível de compatibilidade do banco de dados.
A funcionalidade descontinuada introduzida em uma determinada versão do SQL Servernão é protegida pelo nível de compatibilidade. Refere-se à funcionalidade removida do Mecanismo de Banco de Dados do SQL Server. Por exemplo, a dica
FASTFIRSTROWfoi descontinuada no SQL Server 2012 (11.x) e substituída pela dicaOPTION (FAST n ). A definição do nível de compatibilidade do banco de dados como 110 não restaurará a dica descontinuada. Para obter mais informações sobre recursos preteridos, confira Funcionalidade do mecanismo de banco de dados descontinuada no SQL Server.As alterações significativas introduzidas em uma determinada versão do SQL Server podem não ser protegidas pelo nível de compatibilidade. Refere-se às alterações de comportamento entre versões do Mecanismo de Banco de Dados do SQL Server. Geralmente, o comportamento do Transact-SQL é protegido pelo nível de compatibilidade. No entanto, os objetos do sistema alterados ou removidos não são protegidos pelo nível de compatibilidade.
Um exemplo de uma alteração significativa 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 uma precisão aprimorada, levando em conta 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 recentes não protegidas pelo nível de compatibilidade são:
- Alterações de nomes de coluna em objetos do sistema. No SQL Server 2012 (11.x), a coluna
single_pages_kbemsys.dm_os_sys_infofoi renomeada comopages_kb. Seja qual for o nível de compatibilidade, a consultaSELECT single_pages_kb FROM sys.dm_os_sys_infogerará o erro 207 (Nome de coluna inválido). - Objetos do sistema removidos. No SQL Server 2012 (11.x), o
sp_dboptionfoi removido. Independentemente do nível de compatibilidade, a instruçãoEXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE';produzirá o erro 2812 (Couldn't find stored procedure 'sp_dboption').
Para saber mais sobre alterações da falha, confira Alterações da falha em recursos do Mecanismo de Banco de Dados no SQL Server 2019, Alterações da falha em recursos do Mecanismo de Banco de Dados no SQL Server 2017, Alterações da falha em recursos do Mecanismo de Banco de Dados no SQL Server 2016 e Alterações da falha em recursos do Mecanismo de Banco de Dados no SQL Server 2014.
- Alterações de nomes de coluna em objetos do sistema. No SQL Server 2012 (11.x), a coluna
Diferenças entre 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 visto nesta tabela. Para novos trabalhos de desenvolvimento, sempre planeje a certificação de aplicativos no nível de compatibilidade do banco de dados mais recente.
A nova sintaxe de Transact-SQL não é restringida pelo nível de compatibilidade do banco de dados, exceto quando ela pode interromper 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 retêm o nível de compatibilidade existente (se ele for igual ou superior ao nível de compatibilidade mínimo permitido). Isso foi discutido na seção Usando o nível de compatibilidade para compatibilidade com versões anteriores deste artigo.
Começando no nível de compatibilidade do banco de dados 130, todas as novas correções e recursos que afetam os planos de consulta foram adicionados somente 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 que surge da degradação do desempenho devido a alterações no plano de consulta potencialmente introduzidas pelos novos comportamentos de otimização de consulta.
As alterações fundamentais que afetam o plano adicionadas somente ao nível de compatibilidade padrão de uma nova versão do Mecanismo de Banco de Dados são:
As correções do Otimizador de Consulta lançadas para versões anteriores do SQL Server no sinalizador de rastreamento 4199 são habilitadas automaticamente 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 os respectivos níveis de compatibilidade 100 a 120) foram habilitadas automaticamente para bancos de dados que usam o nível de compatibilidade padrão do SQL Server 2016 (13.x) (130). Somente correções do Otimizador de Consulta pós-RTM precisam ser habilitadas explicitamente.
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 de banco de dados, com a opção
QUERY_OPTIMIZER_HOTFIXESem ALTER DATABASE SCOPEed CONFIGURATION (Transact-SQL). - No nível da consulta, com a dica de consulta
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'modificando a consulta. - No nível da consulta, com o
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'sem alterações de código, usando o recurso de Dica do Repositório de Consultas (versão prévia).
Posteriormente, quando SQL Server 2017 (14.x) foi lançado, todas as correções do Otimizador de Consulta lançadas após o RTM SQL Server 2016 (13.x) foram habilitadas automaticamente para bancos de dados usando o nível de compatibilidade do SQL Server 2017 (14.x) padrão (140). Esse é um comportamento cumulativo que inclui todas as correções de versões anteriores também. Novamente, somente correções do Otimizador de Consulta pós-RTM precisam ser habilitadas explicitamente.
A tabela a seguir resume esse comportamento:
Versão do DE (Mecanismo de Banco de Dados) Nível de compatibilidade do banco de dados TF 4199 Alterações do QO em relação a todos os níveis de compatibilidade do banco de dados anteriores Alterações do QO para a versão do DE atual pós-RTM 13 (SQL Server 2016 (13.x)) 100 a 120
130Desativado
Por
Desativado
PorDesabilitado
habilitado
Enabled
habilitadoDesabilitado
habilitado
Desabilitado
habilitado14 (SQL Server 2017 (14.x)) 100 a 120
130
140Desativado
Por
Desativado
Por
Desativado
PorDesabilitado
habilitado
Enabled
habilitado
Enabled
habilitadoDesabilitado
habilitado
Desabilitado
habilitado
Desabilitado
habilitado15 (SQL Server 2019 (15.x)) e 12 (Banco de Dados SQL do Azure) 100 a 120
130 a 140
150Desativado
Por
Desativado
Por
Desativado
PorDesabilitado
habilitado
Enabled
habilitado
Enabled
habilitadoDesabilitado
habilitado
Desabilitado
habilitado
Desabilitado
habilitado16 (SQL Server 2022 (16.x)) and 12 (Banco de Dados SQL do Azure) 100 a 120
130 a 150
160Desativado
Por
Desativado
Por
Desativado
PorDesabilitado
habilitado
Enabled
habilitado
Enabled
habilitadoDesabilitado
habilitado
Desabilitado
habilitado
Desabilitado
habilitadoAs correções do Otimizador de Consulta que tratam de resultados errados ou de 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.
As alterações no Avaliador de Cardinalidade lançadas em SQL Server e Banco de Dados SQL do Azure foram habilitadas apenas 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 SQL Server 2016 (13.x) foi lançado, as alterações no processo de estimativa de cardinalidade ficaram disponíveis somente para bancos de dados que usam nível de compatibilidade padrão SQL Server 2016 (13.x) (130). Os níveis de compatibilidade anteriores mantiveram o comportamento de estimativa de cardinalidade que estava disponível antes de SQL Server 2016 (13.x).
Posteriormente, quando SQL Server 2017 (14.x) foi lançado, alterações mais recentes no processo de estimativa de cardinalidade ficaram disponíveis somente para bancos de dados que usam nível de compatibilidade padrão SQL Server 2017 (14.x) (140). O nível de compatibilidade do banco de dados 130 manteve o comportamento de estimativa de cardinalidade de 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 Novas alterações na versão do CE 13 (SQL Server 2016 (13.x)) < 130
130Desabilitado
habilitado14 (SQL Server 2017 (14.x))1 < 140
140Desabilitado
habilitado15 (SQL Server 2019 (15.x))1 < 150
150Desabilitado
habilitado16 (SQL Server 2022 (16.x))1 < 160
160Desabilitado
habilitado1 Aplicável também a Banco de Dados SQL do Azure.
Outras diferenças entre níveis de compatibilidade específicos estão disponíveis nas próximas seções deste artigo.
Diferenças entre os níveis de compatibilidade 150 e 160
Esta seção descreve os novos comportamentos apresentados com o nível de compatibilidade 160.
| Configuração do nível de compatibilidade 150 ou inferior | Configuração do nível de compatibilidade 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 um 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 de plano confidencial de parâmetro é habilitada por padrão no nível de compatibilidade 160. Para obter mais informações, confira Otimização de PSP. |
| A estimativa de cardinalidade usa apenas um conjunto padrão de suposições de modelo sobre os padrões de uso e distribuição de dados subjacentes 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, com o uso de dicas de consulta. Nenhum ajuste interno poderá ser feito nesse modelo padrão depois que um plano de consulta for gerado. | A estimativa de cardinalidade começa com o conjunto padrão de suposições de modelo sobre os padrões de uso e distribuição de dados subjacentes, mas após algumas execuções para uma determinada consulta, o Mecanismo de Banco de Dados aprende quais diferentes conjuntos de suposições 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. Os comentários de CE são habilitados por padrão no nível de compatibilidade 160. Para obter mais informações, confira Comentários de 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 DOP (grau de paralelismo) aprimora o desempenho da consulta ao identificar ineficiências de paralelismo para consultas repetidas, com base no tempo decorrido e nas esperas. Se o uso de paralelismo for considerado ineficiente, os comentários do DOP reduzirão o DOP na próxima execução da consulta, de qualquer que seja o DOP configurado, e verificarão se isso ajudou. Os comentários do DOP não estão habilitados por padrão. Para habilitar os Comentários do DOP, habilite a configuração no escopo do banco de dados DOP_FEEDBACK em um banco de dados. Para obter mais informações, consulte Comentários do DOP. |
Diferenças entre os níveis de compatibilidade 140 e 150
Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 150.
| Configuração do nível de compatibilidade 140 ou inferior | Configuração do nível de compatibilidade 150 |
|---|---|
| O data warehouse relacional e as cargas de trabalho analíticas podem não ser capazes de usar índices columnstore devido à sobrecarga de 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 de lote. | O modo de execução de lote já está disponível para cargas de trabalho analíticas sem a necessidade de índices columnstore. Para saber mais, confira modo de lote em rowstore. |
| As consultas de modo de linha que solicitam tamanhos de concessão de memória insuficientes que resultam em despejos no 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 despejos no disco podem ter melhorado o desempenho em execuções consecutivas. Para obter mais informações, confira comentários de concessão de memória do 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, confira comentários de concessão de memória do modo de linha. |
| Consultas que fazem referência a UDFs escalares do T-SQL usarão a invocação iterativa, que não apresenta o cálculo de custos e força a execução serial. | Os UDFs escalares do T-SQL são transformados em expressões relacionais equivalentes que são "embutidas" na consulta que faz a chamada, geralmente resultando em ganhos significativos de desempenho. Para saber mais, confira Inlining de UDF escalar do T-SQL. |
| As variáveis de tabela usam um palpite fixo para a estimativa de cardinalidade. Se o número real de linhas for muito superior ao valor do palpite, o desempenho das operações de downstream poderá ser afetado. | Os novos planos usarão a cardinalidade real da variável de tabela encontrada na primeira compilação em vez de uma estimativa fixa. Para saber mais, confira compilação adiada de variável da tabela. |
Confira mais informações sobre os recursos de processamento de consulta habilitados no nível 150 de compatibilidade do banco de dados em Novidades no SQL Server 2019 e em Processamento inteligente de consultas em bancos de dados SQL.
Diferenças entre os níveis de compatibilidade 130 e 140
Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 140.
| Configuração do nível de compatibilidade 130 ou inferior | Configuração do nível de compatibilidade 140 |
|---|---|
| As estimativas de cardinalidade para instruções que referenciam funções com valor de tabela de várias instruções usam uma estimativa de linha fixa. | As estimativas de cardinalidade para instruções qualificadas que referenciam 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. |
| As consultas em modo de lote que solicitam tamanhos de concessão de memória insuficientes que resultam em despejos no 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 despejos no disco podem ter melhorado o desempenho em execuções consecutivas. Isso é habilitado por meio de comentários de concessão de memória do modo de lote que atualizarão o tamanho da concessão de memória de um plano armazenado em cache se ocorreram despejos 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 é habilitado por meio de comentários de concessão de memória do modo de lote que atualizarão o tamanho de concessão de memória de um plano armazenado em cache se uma quantidade excessiva foi 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 hash e junção de mesclagem. Se as estimativas de cardinalidade estiverem incorretas para entradas de junção, um algoritmo de junção inadequado poderá ser selecionado. Se isso ocorrer, o desempenho será afetado 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 poderá ser selecionado. Se isso ocorrer e a instrução for qualificada para uma junção adaptável, um loop aninhado será usado para entradas de junção menores e uma junção hash será usada para entradas de junção maiores dinamicamente sem a necessidade de recompilação. |
| Planos triviais que referenciam índices Columnstore não são qualificados para a execução em modo de lote. | Um plano trivial que referencia índices Columnstore será descartado em favor de um plano que é qualificado para a execução em modo de lote. |
O operador sp_execute_external_script UDX apenas pode ser executado no modo de linha. |
O operador sp_execute_external_script UDX é qualificado para a execução em modo de lote. |
| As TVFs (funções com valor de tabela) de várias instruções não têm execução intercalada | Execução intercalada de TVFs de várias instruções 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 o modo de compatibilidade 140. O sinalizador de rastreamento 4199 ainda será aplicável a novas correções do otimizador de consulta que são liberadas após o SQL Server 2017. Para obter informações sobre o Sinalizador de Rastreamento 4199, consulte Sinalizador de rastreamento 4199.
Diferenças entre os níveis de compatibilidade 120 e 130
Esta seção descreve os novos comportamentos introduzidos com o nível de compatibilidade 130.
| Configuração do nível de compatibilidade 120 ou inferior | Configuração do nível de compatibilidade 130 |
|---|---|
| O INSERT em uma instrução INSERT-SELECT é single-thread. | O INSERT em uma instrução INSERT-SELECT tem vários threads ou pode ter um plano paralelo. |
| As consultas em uma tabela com otimização de memória são executadas no modo single-thread. | As consultas em uma tabela com otimização de memória agora podem ter planos paralelos. |
| Introdução do avaliador de Cardinalidade do SQL 2014 CardinalityEstimationModelVersion="120" | Outras melhorias de CE (estimativa de cardinalidade) com o Modelo de Estimativa de Cardinalidade 130 que está visível em um Plano de consulta. CardinalityEstimationModelVersion="130" |
Alterações do modo de lote versus modo de linha com índices columnstore:
|
Alterações do modo de lote versus modo de linha com índices columnstore:
|
| As estatísticas podem ser atualizadas automaticamente. | A lógica que atualiza automaticamente as estatísticas é mais agressiva em tabelas grandes. Na prática, isso deve reduzir casos em que os clientes observaram problemas de desempenho em consultas nas quais as linhas recém-inseridas são consultadas com frequência, mas nas quais as estatísticas não haviam sido atualizadas para incluir esses valores. |
| O rastreamento 2371 é OFF por padrão no SQL Server 2014 (12.x). | O Rastreamento 2371 é ON por padrão no SQL Server 2016 (13.x). O sinalizador de rastreamento 2371 instrui o atualizador automático de estatísticas a coletar uma amostra de um subconjunto menor, porém, mais inteligente, de linhas em uma tabela que tem um grande número de linhas. Uma melhoria é incluir na amostra mais linhas que foram inseridas recentemente. Outra melhoria é permitir que as consultas sejam executadas enquanto o processo de atualização de estatísticas está em execução, em vez de bloquear a consulta. |
| Para o nível 120, são coletadas amostras das estatísticas por um processo single-thread. | Para o nível 130, são coletadas amostras das estatísticas por um processo multi-thread. |
| 253 chaves estrangeiras de entrada é o limite. | Uma tabela especificada pode ser referenciada por até 10.000 chaves estrangeiras de entrada ou referências semelhantes. Para restrições, consulte Create Foreign Key Relationships. |
| Os algoritmos de hash MD2, MD4, MD5, SHA e SHA1 preteridos são permitidos. | Apenas os algoritmos de hash SHA2_256 e SHA2_512 são permitidos. |
| O SQL Server 2016 (13.x) inclui melhorias em algumas conversões de tipos de dados e outras operações (normalmente incomuns). Para obter detalhes, consulte Melhorias do SQL Server 2016 no tratamento de alguns tipos de dados e operações incomuns. | |
A função STRING_SPLIT não está disponível. |
A função STRING_SPLIT está disponível no nível de compatibilidade 130 ou superior. Se o nível de compatibilidade do seu banco de dados for inferior a 130, o SQL Server não poderá localizar nem executar a função STRING_SPLIT. |
As correções que estavam sob o sinalizador de rastreamento 4199 em versões anteriores do SQL Server anteriores ao SQL Server 2016 (13.x) agora estão habilitadas por padrão. Com o modo de compatibilidade 130. O sinalizador de rastreamento 4199 ainda será aplicável para novas correções do otimizador de consulta que são liberadas após SQL Server 2016 (13.x). Para usar o otimizador de consulta mais antigo no Banco de Dados SQL, é necessário 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 Inferiores e o Nível 120
Esta seção descreve os novos comportamentos apresentados com o nível de compatibilidade 120.
| Configuração do nível de compatibilidade 110 ou inferior | Configuração do nível de compatibilidade 120 |
|---|---|
| O otimizador de consulta mais antigo é usado. | O SQL Server 2014 (12.x) inclui melhorias significativas no componente que cria e otimiza planos de consulta. Esse novo recurso do 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 tirar proveito dessas melhorias. Os aplicativos migrados de versões anteriores do SQL Server devem ser cuidadosamente testados para confirmar que o bom desempenho será mantido ou melhorado. Se o desempenho diminuir, você poderá definir o nível de compatibilidade de banco de dados como 110 ou menos, a fim de usar a metodologia de otimizador de consulta mais antiga. A compatibilidade do banco de dados nível 120 usa um novo avaliador de cardinalidade que é ajustado para moderno data warehouse e cargas de trabalho OLTP. Antes de definir o nível de compatibilidade do banco de dados como 110 devido a problemas de desempenho, confira as recomendações na seção Planos de Consulta do artigo Novidades do Mecanismo de Banco de Dados do SQL Server 2014 (12.x). |
| Em níveis de compatibilidade abaixo de 120, a configuração de idioma é ignorada durante a conversão de um valor de date em um valor de cadeia de caracteres. Esse comportamento é específico apenas ao tipo date. Consulte o exemplo B na seção Exemplos . | A configuração de linguagem não é ignorada durante a conversão de um valor de date em um valor de cadeia de caracteres. |
As referências recursivas no lado direito de uma cláusula EXCEPT criam um loop infinito. O exemplo C na seção Exemplos demonstra esse comportamento. |
Referências recursivas em uma EXCEPT cláusula geram um erro em conformidade com o padrão ANSI SQL. |
| A CTE (expressão de tabela comum) recursiva permite nomes de coluna duplicados. | Uma CTE recursiva não permite nomes de coluna duplicados. |
| Os gatilhos desabilitados serão habilitados se os gatilhos forem alterados. | A alteração de um gatilho não altera o estado (habilitado ou desabilitado) do gatilho. |
A cláusula de tabela OUTPUT INTO ignora o IDENTITY_INSERT SETTING = OFF e permite a inserção de valores explícitos. |
Não é possível inserir valores explícitos para uma coluna de identidade em uma tabela quando IDENTITY_INSERT é definido como OFF. |
Quando a contenção do banco de dados é definida como parcial, a validação do campo $action na cláusula OUTPUT de uma instrução MERGE pode retornar um erro de ordenação. |
A ordenação dos valores retornados pela cláusula $action de uma instrução MERGE é a ordenação de banco de dados, em vez da ordenação do servidor, e um erro de conflito de ordenação não é retornado. |
Uma instrução SELECT INTO sempre criará uma operação de inserção de thread único. |
Uma instrução SELECT INTO 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 Inferiores e os Níveis 100 e 110
Esta seção descreve os novos comportamentos apresentados com o nível de compatibilidade 110. Esta seção também se aplica aos níveis de compatibilidade acima de 110.
| Configuração do nível de compatibilidade 100 ou inferior | Configuração do nível de compatibilidade 110, no mínimo |
|---|---|
| São executados objetos de banco de dados de CLR (Common Language Runtime) com a versão 4 do CLR. Porém, são evitadas algumas alterações de comportamento apresentadas na versão 4 do CLR. Para obter mais informações, consulte Novidades da integração CLR. | São executados objetos de banco de dados de CLR com a versão 4 do CLR. |
| As funções XQuery string-length e substring contam cada par alternativo como dois caracteres. | As funções XQuery string-length e substring contam cada par alternativo como um caractere. |
PIVOT é permitido em uma consulta CTE (expressão de tabela comum) recursiva. No entanto, a consulta retorna resultados incorretos quando há várias linhas por agrupamento. |
PIVOT não é permitido em uma consulta CTE (expressão de tabela comum) recursiva. Um erro é retornado. |
| O algoritmo RC4 tem suporte somente para compatibilidade com versões anteriores. O novo material só pode ser criptografado por meio do algoritmo RC4 ou RC4_128 quando o banco de dados está no nível de compatibilidade 90 ou 100. (Não recomendável.) No SQL Server 2012 (11.x), o material criptografado por meio do algoritmo RC4 ou RC4_128 pode ser descriptografado em qualquer nível de compatibilidade. | O novo material não pode ser criptografado com RC4 ou RC4_128. Use um algoritmo mais recente; por exemplo, um dos algoritmos AES. No SQL Server 2012 (11.x), o material criptografado por meio do algoritmo RC4 ou RC4_128 pode ser descriptografado em qualquer nível de compatibilidade. |
O estilo padrão de operações CAST e CONVERT nos tipos de dados time e datetime2 é 121, exceto quando um dos tipos é usado em uma expressão de coluna computada. Para colunas computadas, o estilo padrão é 0. Esse comportamento afeta as colunas computadas quando são criadas, usadas em consultas que envolvam 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 das operações CAST e CONVERT nos tipos de dados time e datetime2 é sempre 121. Se a sua consulta depender do comportamento antigo, use um nível de compatibilidade inferior a 110 ou especifique explicitamente o estilo 0 na consulta afetada.A atualização do banco de dados para o nível de compatibilidade 110 não alterará os dados de usuário que foram armazenados em disco. Você deve corrigir esses dados manualmente conforme apropriado. Por exemplo, se você usou SELECT INTO para criar uma tabela com base em uma fonte que continha uma expressão de coluna computada descrita acima, os dados (usando o estilo 0) serão armazenados, em vez da própria definição de coluna computada. Você precisará atualizar manualmente esses dados para que coincidam com o estilo 121. |
| O operador + (Adição) pode ser aplicado a um operando do tipo date, time, datetime2 ou datetimeoffset se o outro operando tiver o tipo datetime ou smalldatetime. | A tentativa de 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. |
| As colunas em tabelas remotas do tipo smalldatetime referenciadas em uma exibição particionada 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. | As colunas em tabelas remotas do tipo smalldatetime referenciadas em uma exibição particionada 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. Depois de atualizar para 110, a exibição particionada distribuída falhará devido à incompatibilidade de tipo de dados. Resolva 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. |
A função SOUNDEX implementa as seguintes regras:1) Um H ou W maiúsculo é ignorado durante a separação de duas consoantes que têm o mesmo número no código SOUNDEX.2) Se os primeiros dois caracteres de character_expression tiverem o mesmo número no código SOUNDEX, ambos os caracteres serão incluídos. Caso contrário, se um conjunto de consoantes lado a lado tiver o mesmo número no código SOUNDEX, todas as consoantes serão excluídas, exceto a primeira. |
A função SOUNDEX implementa as seguintes regras:1) Se um H ou W maiúsculo separar duas consoantes que têm o mesmo número no código SOUNDEX, a consoante à direita será ignorada2) Se um conjunto de consoantes lado a lado tiver o mesmo número no código SOUNDEX, todas as consoantes serão excluídas, exceto a primeira.As regras adicionais podem fazer com que os valores calculados pela SOUNDEX função sejam diferentes dos valores calculados em níveis de compatibilidade anteriores. Após a atualização para o nível de compatibilidade 110, talvez seja necessário recompilar 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>. |
STRING_AGG está disponível com um <order_clause> opcional. Para saber mais, confira STRING_AGG |
Diferenças entre os níveis de compatibilidade 90 e 100
Esta seção descreve os novos comportamentos apresentados com o nível de compatibilidade 100.
| Configuração do nível de compatibilidade 90 | Configuração do nível de compatibilidade 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 elas são criadas, independentemente da configuração de nível de sessão. | A configuração de sessão QUOTED IDENTIFIER é atendida quando funções com valor de tabela de várias instruções são criadas. | Médio |
| Ao criar ou alterar uma função de partição, os literais datetime e smalldatetime na função são avaliados, considerando US_English como a configuração de idioma. | A configuração atual de idioma é usada para avaliar datetime e literais de smalldatetime na função de partição. | Médio |
A cláusula FOR BROWSE é permitida (e ignorada) em instruções INSERT e SELECT INTO. |
A cláusula FOR BROWSE não é permitida em instruções INSERT e SELECT INTO. |
Médio |
Predicados de texto completo são permitidos na cláusula OUTPUT. |
Predicados de texto completo não são permitidos na cláusula OUTPUT. |
Baixo |
Não há suporte para CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST. A lista de palavras irrelevantes do sistema é associada automaticamente a novos índices de texto completo. |
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST são compatíveis. |
Baixo |
MERGE não é imposto como uma palavra-chave reservada. |
MERGE é uma palavra-chave completamente reservada. A instrução MERGE é compatível com os níveis de compatibilidade 100 e 90. |
Baixo |
O uso do argumento <dml_table_source> da instrução INSERT gera um erro de sintaxe. |
Além disso, 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. Isto é feito com o argumento <dml_table_source> da instrução INSERT. |
Baixo |
A menos que NOINDEX seja especificado, DBCC CHECKDB ou DBCC CHECKTABLE executará 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 executará verificações de consistência física e lógica em uma única tabela e em todos os seus índices não clusterizados. Entretanto, em índices XML, índices espaciais e exibições indexadas, por padrão são executadas somente as verificações de consistência física.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 estiver especificado, apenas as verificações lógicas serão executadas. |
Baixo |
| Quando uma cláusula OUTPUT é usada com uma instrução DML que causa um erro de tempo de execução durante sua execução, a transação inteira é encerrada e revertida. | 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 sua execução, o comportamento depende da configuração de SET XACT_ABORT. Se SET XACT_ABORT for OFF, um erro de anulação de instrução gerado pela instrução DML que usa a cláusula OUTPUT terminará a instrução, mas a execução do lote continuará e a transação não será revertida. Se SET XACT_ABORT for ON, todos os erros em tempo de execução gerados pela instrução DML que usam a cláusula OUTPUT terminarã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 restrita é aplicada a elementos do tipo anyType XML. | A validação incerta é aplicada a elementos do tipo anyType. Para obter mais informações, consulte Componentes curinga e validação de conteúdo. | Baixo |
| Não é possível consultar ou modificar os atributos especiais xsi:nil e xsi:type 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 manter a consistência com SELECT xmlCol, mesmo se xsi:nil = "false". |
Os atributos especiais xsi:nil e xsi:type são armazenados como atributos normais 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 estes tipos da consulta, substitua @* por @*[namespace-uri(.) != "insert xsi namespace uri" e não (local-name(.) = "type" nem 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 |
| Os tipos de listas e a união XML não têm suporte completo. | Os tipos de lista e união são totalmente suportados, inclusive as seguintes funcionalidades: União de lista União de união Lista de tipos atômicos Lista de união |
Baixo |
| As opções SET requeridas 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 requeridas para um método xQuery são validadas quando o método é contido em uma exibição ou função com valor de tabela embutida. Um erro ocorrerá se as opções SET do método forem definidas incorretamente. | Baixo |
| Os valores do atributo XML que contêm caracteres de fim da linha (retorno de carro e alimentação de linha) não são normalizados de acordo com o padrão XML. Isto é, ambos os caracteres são retornados, em vez de um único caractere de alimentação de linha. | Os valores do atributo XML que contém caracteres de final de linha (retorno de carro e alimentação de linha) são normalizados de acordo com o padrão XML. Isto é, todas as quebras de linha em entidades externas de análise (incluindo a entidade do documento) são normalizadas na entrada pela tradução da sequência de dois caracteres #xD #xA e de qualquer #xD que não seja seguido por #xA em um único caractere #xA. Aplicativos que usam atributos para transportar valores da cadeia de caracteres que contêm caracteres de final de linha não receberão de volta estes caracteres, já que eles foram submetidos. Para evitar o processo de normalização, use as entidades de caractere numérico XML para codificar todos os caracteres de final de linha. |
Baixo |
As propriedades ROWGUIDCOL e IDENTITY da coluna 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 fica acessível ao usuário. |
As propriedades ROWGUIDCOL e IDENTITY da coluna não podem ser nomeadas como uma restrição. O erro 156 é retornado. |
Baixo |
A atualização de colunas usando atribuição bidirecional, como UPDATE T1 SET @v = column_name = <expression>, pode produzir resultados inesperados porque o valor de tempo de vida da variável pode ser usado em outras cláusulas, como nas cláusulas WHERE e ON, durante a execução da instrução, em vez do valor inicial da instrução. Isto pode causar a alteração imprevisível dos significados dos predicados em uma base por linha.Este comportamento só é aplicável quando o nível de compatibilidade é definido em 90. |
A atualização de colunas usando uma atribuição bidirecional gera resultados esperados porque só o valor inicial da instrução é acessado durante a execução da instrução. | Baixo |
A atribuição de variável é 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 da variável não é permitida em uma instrução que contenha um operador UNION de nível superior. O erro 10734 é retornado. Localize uma regravação sugerida no exemplo E. | Baixo |
A função ODBC {fn CONVERT()} usa o formato de data padrão do idioma. Em 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 espera um formato YMD. |
A função ODBC {fn CONVERT()} usa o estilo 121 (um formato YMD independente de linguagem) ao converter os tipos de dados ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME e SQL_TYPE_TIMESTAMP. |
Baixo |
Intrínsecos de data e hora, como DATEPART não exigem que os valores de entrada de cadeia de caracteres sejam literais de data e hora válidos. Por exemplo, SELECT DATEPART (year, '2007/05-30') é compilado com êxito. |
Partes intrínsecas de datetime, como DATEPART, exigem que os valores de entrada de cadeia de caracteres sejam literais de datetime válidos. Erro 241 é retornado quando um datetime literal 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 à direita 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 que são reservadas pelo Mecanismo de Banco de Dados. A tabela a seguir mostra as palavras-chave reservadas que são introduzidas em cada nível de compatibilidade.
| Configuração do nível de compatibilidade | Palavras-chave reservadas |
|---|---|
130 |
A ser determinado. |
120 |
Nenhum. |
110 |
WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE |
100 |
CUBE, MERGE, ROLLUP |
90 |
EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE |
Em um determinado nível de compatibilidade, as palavras-chave reservadas incluem todas as palavras-chave introduzidas naquele nível ou abaixo dele. Por exemplo, para aplicativos no nível 110, todas as palavras-chave listadas na tabela anterior são reservadas. Nos níveis de compatibilidade inferiores, 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 incorporada no nível de compatibilidade 90, também é reservada nos níveis 100, 110 e 120.
Se um aplicativo usar um identificador que é reservado como uma palavra-chave no seu nível de compatibilidade, o aplicativo falhará. Para solucionar esse problema, 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 [EXTERNAL] ou "EXTERNAL".
Para obter mais informações, consulte Palavras-chave reservadas.
Permissões
Requer a permissão ALTER no banco de dados.
Exemplos
a. 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 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. Ignorar 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 date = '12/5/2011' ;
SET LANGUAGE dutch;
SELECT CONVERT(varchar(11), @t2, 106);
GO
Resultados quando o nível de compatibilidade é menor que 120: 12 May 2011
Resultados quando o nível de compatibilidade é definido como 120 ou superior: 12 mei 2011
C. Para a configuração do nível de compatibilidade 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)) 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 for inferior a 110, o estilo padrão de operações CAST e CONVERT nos tipos de dados time e datetime2 será 121, exceto quando um dos tipos for usado em uma expressão de coluna calculada. Para colunas computadas, o estilo padrão é 0.
Quando o nível de compatibilidade for 110 ou superior, o estilo padrão das operações CAST e CONVERT nos tipos de dados time e datetime2 sempre será 121. Confira Diferenças entre níveis de compatibilidade inferiores e níveis 100 e 110 para saber mais.
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 |
|---|---|---|---|
| 15h15 | 15:15:35.8100000 | 7 Jun 2011 15:15 | 2011-06-07 15:15h35.8130000 |
E. Atribuição de variável – operador UNION de nível superior
Na configuração do nível de compatibilidade do banco de dados de 90, a atribuição de variável é 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, o valor da coluna @v da união de duas tabelas é atribuído ao BusinessEntityID da variável local. Por definição, quando a instrução SELECT retorna mais de um valor, a variável é atribuída ao último valor retornado. Neste caso, a variável é atribuída corretamente ao último valor, porém, 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 int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;
Na configuração do nível de compatibilidade do banco de dados de 100 e superior, a atribuição de variável não será 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 como demonstrado no exemplo a seguir.
DECLARE @v int;
SELECT @v = BusinessEntityID FROM
(SELECT BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;
Conteúdo relacionado
- Manter a estabilidade do desempenho durante a atualização para o SQL Server mais recente
- Altere o nível de compatibilidade do banco de dados e use o Repositório de Consultas
- Certificação de compatibilidade
- ALTER DATABASE (Transact-SQL)
- Atualizar bancos de dados usando o assistente de ajuste de consulta
- CREATE DATABASE
- Exibir ou alterar o nível de compatibilidade de um banco de dados
- Dicas do Repositório de Consultas