Alterações no comportamento de recursos do Mecanismo de Banco de Dados no SQL Server 2014

Este tópico descreve as alterações de comportamento no Mecanismo de Banco de Dados. As alterações de comportamento afetam como os recursos funcionam ou interagem no SQL Server 2014 em comparação com as versões anteriores do SQL Server.

Alterações de comportamento no SQL Server 2014

Em versões anteriores do SQL Server, consultas em um documento XML que contém cadeias de caracteres com um determinado comprimento (mais de 4020 caracteres) podem retornar resultados incorretos. No SQL Server 2014, essas consultas retornam os resultados corretos.

Alterações de comportamento no SQL Server 2012

Descoberta de metadados

Os aprimoramentos no Mecanismo de Banco de Dados a partir do SQL Server 2012 permitem que SQLDescribeCol obtenha descrições mais precisas dos resultados esperados do que as retornadas por SQLDescribeCol em versões anteriores do SQL Server. Para obter mais informações, veja Descoberta de metadados.

A opção SET FMTONLY para determinar o formato de uma resposta sem realmente executar a consulta é substituída por sp_describe_first_result_set (Transact-SQL),sp_describe_undeclared_parameters (Transact-SQL),sys.dm_exec_describe_first_result_set (Transact-SQL) e sys.dm_exec_describe_first_result_set_for_object (Transact-SQL).

Alterações de comportamento ao gerar scripts de uma tarefa do SQL Server Agent

A partir do SQL Server 2012, se você criar um novo trabalho copiando o script de um trabalho existente, o novo trabalho poderá afetar inadvertidamente o trabalho existente. Para criar um novo trabalho usando o script de um trabalho existente, exclua manualmente o parâmetro @schedule_uid que geralmente é o último parâmetro da seção que cria o agendamento de trabalho no trabalho existente. Isso criará uma nova agenda independente para o novo trabalho sem afetar os trabalhos existentes.

Dobra constante para funções e métodos de CLR definidos pelo usuário

A partir do SQL Server 2012, os seguintes objetos CLR definidos pelo usuário agora são dobráveis:

• Funções definidas pelo usuário de CLR com valor escalar determinista.
• Métodos deterministas de tipos de CLR definidos pelo usuário.

Esta melhoria busca aprimorar o desempenho quando estas funções ou métodos são chamados mais de uma vez com os mesmos argumentos. Porém, esta alteração pode causar resultados inesperados quando funções ou métodos não deterministas são marcados como deterministas em erro. O determinismo de uma função ou um método CLR é indicado pelo valor da propriedade IsDeterministic de SqlFunctionAttribute ou SqlMethodAttribute.

O comportamento do método STEnvelope() mudou com tipos espaciais vazios

O comportamento do STEnvelope método com objetos vazios agora é consistente com o comportamento de outros métodos espaciais SQL Server.

Em SQL Server 2008, o STEnvelope método retornou os seguintes resultados quando chamado com objetos vazios:

SELECT geometry::Parse('POINT EMPTY').STEnvelope().ToString()  
-- returns POINT EMPTY  
SELECT geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()  
-- returns LINESTRING EMPTY  
SELECT geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()  
-- returns POLYGON EMPTY  

No SQL Server 2012, o STEnvelope método agora retorna os seguintes resultados quando chamado com objetos vazios:

SELECT geometry::Parse('POINT EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  
SELECT geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  
SELECT geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  

Para determinar se um objeto espacial está vazio, chame o método STIsEmpty (tipo de dados geometry).

A função LOG tem novo parâmetro opcional

A LOG função agora tem um parâmetro base opcional. Para obter mais informações, consulte LOG (Transact-SQL).

A computação de estatísticas durante operações de índice particionado mudou

No SQL Server 2014, as estatísticas não são criadas verificando todas as linhas na tabela quando um índice particionado é criado ou recriado. Em vez disso, o otimizador de consulta usa o algoritmo de amostragem padrão para gerar estatísticas. Depois de atualizar um banco de dados com índices particionados, você pode notar uma diferença nos dados de histograma destes índices. Esta alteração no comportamento pode não afetar o desempenho de consulta. Para obter as estatísticas dos índices particionados ao examinar todas as linhas da tabela, use CREATE STATISTICS ou UPDATE STATISTICS com a cláusula FULLSCAN.

A conversão de tipo de dados pelo método de valor XML mudou

O comportamento interno do método value do tipo de dados xml mudou. Esse método executa um XQuery no XML e retorna um valor escalar do tipo de dados SQL Server especificado. O tipo xs deve ser convertido no tipo de dados SQL Server. Anteriormente, o value método converteu internamente o valor de origem em um xs:string e converteu o xs:string no tipo de dados SQL Server. No SQL Server 2014, a conversão em xs:string é ignorada nos seguintes casos:

Tipo de dados de origem XS	Tipo de dados de destino do SQL Server
byte short INT Número inteiro long unsignedByte unsignedShort unsignedInt unsignedLong positiveInteger nonPositiveInteger negativeInteger nonNegativeInteger	TINYINT SMALLINT INT BIGINT decimal numeric
decimal	decimal numeric
FLOAT	real
double	FLOAT

O novo comportamento melhora o desempenho quando a conversão intermediária pode ser ignorada. Porém, quando as conversões de tipo de dados falharem, você verá mensagens de erro diferentes daquelas geradas na conversão do valor xs:string intermediário. Por exemplo, se o método de valor não convertesse o valor int 100000 em smallint, a mensagem de erro anterior seria:

The conversion of the nvarchar value '100000' overflowed an INT2 column. Use a larger integer column.

No SQL Server 2014, sem a conversão intermediária em xs:string, a mensagem de erro é:

Arithmetic overflow error converting expression to data type smallint.

Alteração de comportamento de sqlcmd.exe no modo XML

Haverá alterações de comportamento se você usar sqlcmd.exe com o modo XML (comando:XML ON) ao executar um SELECT * de T FOR XML ....

Mensagem DBCC CHECKIDENT revisada

No SQL Server 2012, a mensagem retornada pelo comando DBCC CHECKIDENT foi alterada somente quando é usada com RESEED new_reseed_value para alterar o valor de identidade atual. A nova mensagem é "Verificando informações de identidade: valor de identidade atual '<valor> de identidade atual'". A execução do DBCC foi concluída. Se o DBCC imprimiu mensagens de erro, entre em contato com o administrador do sistema".

Em versões anteriores, a mensagem é "Verificando informações de identidade: valor de identidade atual '<valor> de identidade atual', valor da coluna atual '<valor> da coluna atual'. Execução de DBCC concluída. Se o DBCC imprimiu mensagens de erro, contate o administrador do sistema." A mensagem não é alterada quando DBCC CHECKIDENT é especificada com NORESEED, sem um segundo parâmetro ou sem um valor de nova linha. Para obter mais informações, confira DBCC CHECKIDENT (Transact-SQL).

O comportamento da função exist() no tipo de dados XML mudou

O comportamento da exist() função foi alterado ao comparar um tipo de dados XML com um valor nulo para 0 (zero). Considere o seguinte exemplo:

DECLARE @test XML;  
SET @test = null;  
SELECT COUNT(1) WHERE @test.exist('/dogs') = 0;  

Nas versões anteriores, esta comparação retorna 1 (true); agora, esta comparação retorna 0 (zero, false).

As comparações a seguir não mudaram:

DECLARE @test XML;  
SET @test = null;  
SELECT COUNT(1) WHERE @test.exist('/dogs') = 1; -- 0 expected, 0 returned  
SELECT COUNT(1) WHERE @test.exist('/dogs') IS NULL; -- 1 expected, 1 returned  

Consulte Também

Alterações recentes em recursos do Mecanismo de Banco de Dados no SQL Server 2014
Recursos do Mecanismo de Banco de Dados preteridos no SQL Server 2014
Funcionalidade do Mecanismo de Banco de Dados descontinuada no SQL Server 2014
Nível de compatibilidade de ALTER DATABASE (Transact-SQL)