Nível de compatibilidade de ALTER DATABASE (Transact-SQL)
Define certos comportamentos de banco de dados como sendo compatíveis com a versão especificada do SQL Server.Para outras opções ALTER DATABASE, consulte ALTER DATABASE (Transact-SQL).
Convenções de sintaxe Transact-SQL
Aplica-se a: SQL Server (SQL Server 2008 até a versão atual), Banco de dados SQL do Azure. |
Sintaxe
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 90 | 100 | 110 | 120 }
Argumentos
database_name
É o nome do banco de dados a ser modificado.COMPATIBILITY_LEVEL {80 | 90 | 100 | 110 | 120 }
É a versão do SQL Server com a qual o banco de dados será compatível.O valor deve ser um dos seguintes:Valor
Descrição
Aplica-se a
80
SQL Server 2000
SQL Server 2008 a SQL Server 2008 R2
90
SQL Server 2005
SQL Server 2008 a SQL Server 2012
100
SQL Server 2008 e SQL Server 2008 R2
SQL Server 2008 a SQL Server 2014
110
SQL Server 2012
SQL Server 2012 a SQL Server 2014
120
SQL Server 2014
SQL Server 2014 a SQL Server 2014
Comentários
Para todas as instalações do SQL Server 2014, o nível de compatibilidade padrão é 120.Bancos de dados criados no SQL Server 2014 são definidos para esse nível, a não ser que o banco de dados modelo tenha um nível de compatibilidade inferior.Quando um banco de dados for atualizado para o SQL Server 2014 a partir de qualquer versão anterior do SQL Server, o banco de dados manterá seu nível de compatibilidade se ele for pelo menos 100.Atualizar um banco de dados com um nível de compatibilidade de 90 definirá o banco de dados com o nível de compatibilidade 100.Isso se aplica aos bancos de dados do sistema e de usuário.Use ALTER DATABASE para alterar o nível de compatibilidade do banco de dados.Para exibir o nível de compatibilidade atual de um banco de dados, consulte a coluna compatibility_level na exibição do catálogo sys.databases.
Usando o nível de compatibilidade para compatibilidade com versões anteriores
O nível de compatibilidade afeta os comportamentos apenas do banco de dados especificado e não do servidor inteiro.O nível de compatibilidade oferece apenas compatibilidade parcial com versões anteriores do SQL Server.Use o nível de compatibilidade como um auxílio de migração provisório ao trabalhar com diferenças de versões nos comportamentos que são controlados pela definição de nível de compatibilidade relevante.Se os aplicativos existentes do SQL Server forem afetados pelas diferenças de comportamento no SQL Server 2014, converta o aplicativo para trabalhar adequadamente.Em seguida, use ALTER DATABASE para alterar o nível de compatibilidade para 120.A nova definição de compatibilidade para um banco de dados entrará em vigor quando o banco de dados passar a ser o atual (como banco de dados padrão no logon ou ao ser especificado em uma instrução USE).
Práticas recomendadas
Alterar o nível de compatibilidade enquanto os usuários estão conectados ao banco de dados pode gerar conjuntos de resultados incorretos para consultas ativas.Por exemplo, se o nível de compatibilidade for alterado enquanto um plano de consulta estiver sendo compilado, o plano compilado poderá basear-se nos níveis de compatibilidade antigos e novos, gerando um plano incorreto e, provavelmente, resultados imprecisos.Além disso, o problema pode ser maior se o plano for colocado no cache de planos e reutilizado em consultas subsequentes.Para evitar resultados de consulta imprecisos, recomendamos o seguinte procedimento ao alterar o nível de compatibilidade de um banco de dados:
Defina o banco de dados para o modo de acesso de usuário único, usando ALTER DATABASE SET SINGLE_USER.
Altere o nível de compatibilidade do banco de dados.
Coloque o banco de dados no modo de acesso multiusuário usando ALTER DATABASE SET MULTI_USER.
Para obter mais informações sobre como definir o modo de acesso de um banco de dados, consulte ALTER DATABASE (Transact-SQL).
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.
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 de nível de compatibilidade 110 ou inferior |
Configuração de nível de compatibilidade 120 |
---|---|
O otimizador de consulta mais antigo é usado. |
O SQL Server 2014 inclui melhorias significativas no componente criado por ele e planos de consulta otimizados.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, consulte as recomendações na seção Planos de Consulta do tópico SQL Server 2014Novidades (Mecanismo de Banco de Dados). |
Em níveis de compatibilidade abaixo de 120, a configuração de idioma é ignorada ao converter um valor de date para um valor de cadeia de caracteres.Observe que esse comportamento é específico apenas para o tipo date.Por exemplo, a consulta a seguir ignora a instrução SET LANGUAGE exceto no nível de compatibilidade 120.
|
A configuração de idioma não é ignorada durante a conversão de um valor date em um valor string. |
As referências recursivas no lado direito de uma cláusula EXCEPT criam um loop infinito.O exemplo a seguir demonstra esse comportamento.
|
As referências recursivas em uma cláusula EXCEPT gerencia um erro em conformidade com o padrão ANSI SQL. |
Uma CTE 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 IDENTITY_INSERT SETTING = OFF e permite que os valores explícitos sejam inseridos. |
Você não pode inserir valores explícitos de uma coluna de identidade em uma tabela quando IDENTITY_INSERT for definido como OFF. |
Quando a contenção do banco de dados for definida como parcial, a validação do campo $action na cláusula OUTPUT de uma instrução MERGE poderá retornar um erro de agrupamento. |
O agrupamento dos valores retornados pela cláusula $action de uma instrução MERGE é o agrupamento de banco de dados, e não o agrupamento do servidor, e um erro de conflito de agrupamento não será 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 número grande de linhas, a operação paralela pode melhorar o desempenho. |
Diferenças entre níveis de compatibilidade inferiores e os níveis 110 e 120
Esta seção descreve os novos comportamentos apresentados com o nível de compatibilidade 110.Esta seção também se aplica ao nível 120.
Configuração de nível de compatibilidade 100 ou inferior |
Configuração de 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 substituto como dois caracteres. |
As funções XQuery string-length e substring contam cada substituto como um caractere. |
PIVOT é permitido em uma consulta CTE (common table expression, 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 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, o material criptografado por meio do algoritmo RC4 ou RC4_128 pode ser descriptografado em qualquer nível de compatibilidade. |
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, 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 a seguir 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 (Transact-SQL).
|
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. |
Qualquer coluna nas 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. |
Qualquer coluna nas 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.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 para 100 ou menos. |
A função SOUNDEX implementa as seguintes regras:
|
A função SOUNDEX implementa as seguintes regras:
As regras adicionais podem fazer com que os valores computados pela função SOUNDEX sejam diferentes dos valores computados sob os níveis de compatibilidade anteriores.Após a atualização para o nível de compatibilidade 110, talvez seja necessário recriar os índices, os heaps ou as restrições CHECK que usam a função SOUNDEX.Para obter mais informações, consulte SOUNDEX (Transact-SQL). |
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 de nível de compatibilidade 90 |
Configuração de nível de compatibilidade 100 |
Possibilidade de impacto |
---|---|---|
A configuração QUOTED_IDENTIFER sempre é definida como ON para funções com valor de tabela de várias instruções ao serem criadas, sem considerar a configuração do 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édia |
Ao criar ou alterar uma função de partição, datetime e literais de smalldatetime na função são avaliados assumindo 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édia |
A cláusula FOR BROWSE é permitida (e ignorada) nas instruções INSERT e SELECT INTO. |
A cláusula FOR BROWSE não é permitida em instruções INSERT SELECT INTO. |
Média |
Predicados de texto completo são permitidos na cláusula OUTPUT. |
Predicados de texto completo não são permitidos na cláusula OUTPUT. |
Baixa |
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST não recebem suporte.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 recebem suporte. |
Baixa |
MERGE não é imposto como uma palavra-chave reservada. |
MERGE é uma palavra-chave completamente reservada.A instrução MERGE é suportadas nos níveis de compatibilidade 100 e 90. |
Baixa |
O uso do argumento <dml_table_source> da instrução INSERT aumenta 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 usando o argumento <dml_table_source> da instrução INSERT. |
Baixa |
A menos que NOINDEX esteja 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 índices não clusterizados e XML.Não há suporte para índices espaciais. |
A menos que NOINDEX esteja 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 í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 estiver especificado, verificações lógicas serão executadas em exibições indexadas, em índices XML e em í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. |
Baixa |
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 que causa um erro de tempo de execução durante sua execução, o comportamento depende da configuração em SET XACT_ABORT.Se SET XACT_ABORT estiver OFF, um erro de cancelamento de instrução gerado pela instrução DML usando a cláusula OUTPUT encerrará a instrução, mas a execução do lote continuará e a transação não será revertida.Se SET XACT_ABORT estiver como 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. |
Baixa |
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. |
Baixa |
A validação restrita é aplicada a elementos do tipo anyType de XML. |
A validação incerta é aplicada a elementos do tipo anyType de XML.Para obter mais informações, consulte Componentes curinga e validação de conteúdo. |
Baixa |
Não é possível consultar ou modificar os atributos especiais xsi:nil e xsi:type através de instruções de linguagem de manipulação de dados. Isto significa que /e/@xsi:nil falhará enquanto /e/@* ignorará os atributos xsi:nil e xsi:type.Entretanto, /e retorna os atributos xsi:nil e xsi:type para verificar 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, executar a consulta SELECT x.query('a/b/@*') retorna todos os atributos, inclusive 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" or local-name(.) ="nil". |
Baixa |
Uma função definida pelo usuário que converte um valor constante da cadeia de caracteres XML para um tipo de datetime do SQL Server é marcada como determinista. |
Uma função definida pelo usuário que converte um valor constante de cadeia de caracteres XML em um tipo datetime do SQL Server é marcado como não determinista. |
Baixa |
Os tipos de listas e união de XML não são totalmente suportados. |
Os tipos de lista e união são totalmente suportados, inclusive as seguintes funcionalidades:
|
Baixa |
As opções SET requeridas para um método xQuery não são validadas quando o método é 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. |
Baixa |
Os valores do atributo XML que contém caracteres de final de 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. |
Baixa |
As propriedades das colunas ROWGUIDCOL e IDENTITY podem ser nomeadas incorretamente como restrições.Por exemplo, a instrução CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) executa, mas o nome da restrição não é preservado e não fica acessível ao usuário. |
As propriedades das colunas ROWGUIDCOL e IDENTITY não podem ser nomeadas como uma restrição.O erro 156 é retornado. |
Baixa |
A atualização de colunas usando atribuição bidirecional, tal qual 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 de instruções, em vez do valor de início 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. |
Baixa |
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.
|
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. Para resolver o erro, reescreva a consulta como demonstrado no exemplo a seguir.
|
Baixa |
A função ODBC {fn CONVERT()} usa o formato de data padrão do idioma.Em algumas linguagens, o formato padrão é YDM, 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. |
Baixa |
A função ODBC {fn CURDATE()} retorna somente a data no formato ‘AAAA-MM-DD’. |
A função ODBC {fn CURDATE()} retorna a data e a hora, como, por exemplo, AAAA-MM-DD hh:mm:ss. |
Baixa |
Datetime intrínseco, como DATEPART, não exige que os valores de entrada de cadeia de caracteres sejam literais válidas de datetime.Por exemplo, SELECT DATEPART (ano, ‘2007/05-30') compila com sucesso. |
Datetime intrínseco, como DATEPART, exige que os valores de entrada de cadeia de caracteres sejam literais válidas de datetime.Erro 241 é retornado quando um datetime literal inválido é usado. |
Baixa |
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 de nível de compatibilidade |
Palavras-chave reservadas |
---|---|
120 |
Nenhuma. |
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, inclua o identificador entre colchetes ([]) ou aspas (""); por exemplo, para atualizar um aplicativo que usa o identificador EXTERNAL com o nível de compatibilidade 90, você pode alterar o identificador para [EXTERNAL] ou "EXTERNAL".
Para obter mais informações, consulte Palavras-chave reservadas (Transact-SQL).
Permissões
Requer a permissão ALTER no banco de dados.
Exemplos
A.Alterando o nível de compatibilidade
O exemplo a seguir altera o nível de compatibilidade do banco de dados AdventureWorks2012 para 110,SQL Server 2012.
ALTER DATABASE AdventureWorks2012
SET COMPATIBILITY_LEVEL = 110;
GO
Consulte também
ALTER DATABASE (Transact-SQL)
Palavras-chave reservadas (Transact-SQL)
CREATE DATABASE (SQL Server Transact-SQL)
DATABASEPROPERTYEX (Transact-SQL)
sys.databases (Transact-SQL)
sys.database_files (Transact-SQL)