Поделиться через


Изменения поведения компонентов ядра СУБД в SQL Server 2014

В этом разделе описываются изменения поведения ядра СУБД. Изменения поведения влияют на работу функций или взаимодействие в SQL Server 2014 по сравнению с более ранними версиями SQL Server.

Изменения поведения в SQL Server 2014

В более ранних версиях SQL Server запросы к XML-документу с строками в течение определенной длины (более 4020 символов) могут возвращать неправильные результаты. В SQL Server 2014 такие запросы возвращают правильные результаты.

Изменения поведения в SQL Server 2012

Обнаружение метаданных

Улучшения ядра СУБД, начиная с SQL Server 2012, позволяют SQLDescribeCol получать более точные описания ожидаемых результатов, чем возвращаемые SQLDescribeCol в предыдущих версиях SQL Server. Дополнительные сведения см. в разделе "Обнаружение метаданных".

Параметр SET FMTONLY для определения формата ответа без фактического выполнения запроса заменяется на sp_describe_first_result_set (Transact-SQL), sp_describe_undeclared_parameters (Transact-SQL), sys.dm_exec_describe_first_result_set (Transact-SQL), и sys.dm_exec_describe_first_result_set_for_object (Transact-SQL).

Изменения в поведении при скриптировании задачи агента SQL Server

Начиная с SQL Server 2012, если создать новое задание путем копирования скрипта из существующего задания, новое задание может непреднамеренно повлиять на существующее задание. Чтобы создать новое задание с помощью скрипта из существующего задания, вручную удалите параметр @schedule_uid который обычно является последним параметром раздела, который создает расписание заданий в существующем задании. При этом будет создано новое независимое расписание для нового задания, не влияя на существующие задания.

Константное свёртывание для функций и методов CLR User-Defined

Начиная с SQL Server 2012, следующие пользовательские объекты CLR могут быть свёрнуты:

  • Детерминированные скалярные функции CLR, определяемые пользователем.
  • Детерминированные методы определяемых пользователем типов CLR.

Это улучшение стремится повысить производительность, если эти функции или методы вызываются несколько раз с теми же аргументами. Однако это изменение может привести к непредвиденным результатам, если недетерминированные функции или методы помечены как детерминированные в ошибке. Детерминированность функции или метода CLR указывается значением свойства IsDeterministic для SqlFunctionAttribute или SqlMethodAttribute.

Поведение метода STEnvelope() изменилось с пустыми пространственными типами

Поведение STEnvelope метода с пустыми объектами теперь согласовано с поведением других пространственных методов SQL Server.

В SQL Server 2008 STEnvelope метод вернул следующие результаты при вызове с пустыми объектами:

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  

В SQL Server 2012 STEnvelope метод теперь возвращает следующие результаты при вызове с пустыми объектами:

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  

Чтобы определить, является ли пространственный объект пустым, вызовите метод STIsEmpty (geometry Data Type).

Функция LOG имеет новый необязательный параметр

Теперь функция LOG имеет необязательный базовый параметр. Дополнительные сведения см. в разделе LOG (Transact-SQL).

Вычисление статистики во время операций с секционированными индексами изменилось

В SQL Server 2014 статистика не создается путем сканирования всех строк в таблице при создании или перестроении секционированного индекса. Вместо этого оптимизатор запросов использует для создания статистики алгоритм выборки по умолчанию. После обновления базы данных с секционированных индексов можно заметить разницу в данных гистограммы для этих индексов. Это изменение в поведении может не повлиять на производительность запросов. Для получения статистики по секционированным индексам путем сканирования всех строк таблицы используйте инструкции CREATE STATISTICS или UPDATE STATISTICS с предложением FULLSCAN.

Преобразование типа данных методом XML-значения изменилось

Внутреннее поведение value метода xml типа данных изменилось. Этот метод выполняет XQuery для XML и возвращает скалярное значение указанного типа данных SQL Server. Тип xs должен быть преобразован в тип данных SQL Server. value Ранее метод внутренне преобразовал исходное значение в xs:string, а затем преобразовал xs:string в тип данных SQL Server. В SQL Server 2014 преобразование в xs:string пропускается в следующих случаях:

Исходный тип данных XS Целевой тип данных SQL Server
байт

короткий

инт

целое число

долго

беззнаковый байт

unsignedShort (беззнаковое короткое целое число)

беззнаковое целое число

длинное целое число без знака

положительное целое число

неположительное целое число

отрицательное целое число

неотрицательное целое число
tinyint

smallint

инт

bigint

десятичная система

числовой
десятичная система десятичная система

числовой
плавать настоящий
двойной плавать

Новое поведение повышает производительность при пропуске промежуточного преобразования. Однако при сбое преобразования типов данных отображаются сообщения об ошибках, отличные от тех, которые были вызваны при преобразовании из промежуточного значения xs:string. Например, если метод value не удалось преобразовать int значение 100000 в значение smallint, предыдущее сообщение об ошибке было:

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

В SQL Server 2014 без промежуточного преобразования в xs:string сообщение об ошибке :

Arithmetic overflow error converting expression to data type smallint.

изменение поведения sqlcmd.exe в режиме XML

При выполнении команды SELECT * из T FOR XML возникают изменения в поведении, если вы используете sqlcmd.exe с режимом XML (:XML ON)

Измененное сообщение DBCC CHECKIDENT

В SQL Server 2012 сообщение, возвращаемое командой DBCC CHECKIDENT, изменилось только в том случае, если она используется с RESEED new_reseed_value для изменения текущего значения идентификатора. Новое сообщение — "Проверка информации о личности: текущее значение личности '<текущее значение личности>'". Выполнение инструкции DBCC завершено. Если DBCC напечатал сообщения об ошибках, обратитесь к системному администратору.

В более ранних версиях сообщение "Проверка сведений об удостоверениях: текущее значение удостоверения "<текущее значение> удостоверения", текущее значение столбца "<текущее значение> столбца". Выполнение DBCC завершено. Если сообщения об ошибках DBCC печатаются, обратитесь к системному администратору". Сообщение не изменяется при DBCC CHECKIDENT указании со NORESEEDвторым параметром или без повторного значения. Дополнительные сведения см. в разделе DBCC CHECKIDENT (Transact-SQL).

Изменено поведение функции exist() в типе данных XML

Поведение exist() функции изменилось при сравнении типа XML-данных со значением NULL до 0 (ноль). Рассмотрим следующий пример:

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

В более ранних версиях это сравнение возвращает 1 (true); Теперь это сравнение возвращает значение 0 (ноль, false).

Следующие сравнения не изменились:

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  

См. также

Критические изменения функций ядра СУБД в SQL Server 2014
Нерекомендуемые функции ядра СУБД в SQL Server 2014
Неподдерживаемые функции ядра СУБД в SQL Server 2014
Уровень совместимости инструкции ALTER DATABASE (Transact-SQL)