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

  • Статья

Изменения в работе функций компонента Database Engine в SQL Server 2008

В этом разделе описаны изменения в компоненте Database Engine. Эти изменения затрагивают работу и взаимодействие функций в SQL Server 2008 по сравнению с более ранними версиями SQL Server.

Агент SQL Server

Изменение в создании сценариев задач агента SQL Server.

В SQL Server 2008 задание, созданное путем копирования сценария из другого задания, могло непреднамеренно повлиять на существующее задание. Чтобы создать новое задание с использованием сценария из другого задания, вручную удалите параметр @schedule\_uid, который обычно является последним параметром в разделе создания расписания для существующего задания. При этом для нового задания будет создано новое отдельное расписание, таким образом влияние на старое задание будет исключено.

Параметры access check cache

В SQL Server 2005 внутреннюю структуру access check result cache можно настраивать только с помощью флагов трассировки. В SQL Server 2008 для изменения этой структуры можно использовать параметры access check cache. Дополнительные сведения см. в разделе Параметры access check cache.

Полнотекстовый поиск

В SQL Server 2008 появилась новая архитектура полнотекстового поиска. Теперь средство полнотекстового поиска полностью интегрировано в компонент SQL Server Database Engine, а не реализовано в виде отдельной службы. Интеграция расширяет возможности управления полнотекстовым поиском, а также повышает масштабируемость, производительность и безопасность по сравнению с предыдущими версиями SQL Server. Дополнительные сведения об основных отличиях в полнотекстовом поиске между SQL Server 2005 и SQL Server 2008, а также рекомендации, относящиеся к новому интегрированному средству полнотекстового поиска, см. в технической статье Полнотекстовый поиск SQL Server 2008: возможности и улучшения на веб-узле MSDN (на английском языке).

Связанные серверы

В SQL Server 2008 изменена семантика транзакций инструкций INSERT...EXECUTE, выполняемых на связанном сервере с замыканием на себя. В SQL Server 2005 этот сценарий не поддерживается и приводит к ошибкам. В SQL Server 2008 инструкция INSERT...EXECUTE может применяться к связанному серверу с замыканием на себя, когда для соединения не включен режим MARS. Если режим MARS не включен для соединения, то поведение такое же, как в SQL Server 2005.

Параллелизм

Обработка и параллелизм запросов к секционированным таблицам

Улучшения структуры секционированных таблиц в SQL Server 2008 позволяют оптимизировать параллелизм обработки запросов к секционированным таблицам по сравнению с SQL Server 2005. В качестве побочного эффекта этих изменений структуры теперь можно выравнивать только двусторонние соединения. Планы запросов для двусторонних выровненных соединений в SQL Server 2008 выглядят так же, как и в SQL Server 2005, и обладают производительностью, сравнимой с SQL Server 2005. Если в соединение включаются дополнительные таблицы с выровненным секционированием, будет выбран другой план, например двустороннее выровненное соединение, за которым следует хэш-соединение с третьей таблицей. Выровненные соединения трех и более таблиц применяются редко, и выровненные соединения не получают преимуществ от улучшений параллелизма в SQL Server 2008. Однако если имеется запрос, для которого SQL Server 2005 выполняет выровненное соединение трех и более таблиц, то возможно, что такой запрос будет выполняться медленнее в SQL Server 2008, если объем памяти мал по сравнению с размером таблиц. В такой ситуации для повышения производительности можно увеличить объем доступной памяти и переписать запрос так, чтобы перед объединением результатов отдельные секции соединялись раздельно. Дополнительные сведения о выровненных соединениях см. в разделе Улучшенные возможности обработки запросов для секционированных таблиц и индексов.

Соединение типа «звезда» и параллелизм

В SQL Server добавлены средства оптимизации для обрабатывающих запросов с соединениями типа «звезда», которые используют хэш-соединения и фильтры по битовым картам. Если запрос обрабатывает данные большого объема, полученные в результате соединения таблиц фактов с таблицами измерений в схеме типа «звезда», то план запроса, в котором применяется новая оптимизация, может выполняться намного быстрее. 

Поэтому для существующих запросов можно подобрать новый план, если они относятся к типу «звезда». Оптимизатор запросов выбирает этот план, если по выполненным оценкам ожидается увеличение производительности. Однако если статистика в оценке затрат оказывается неточной, то оптимизатор запросов может выбрать оптимизацию соединений типа «звезда», хотя другой план будет выполняться быстрее.

Если параметр конфигурации max degree of parallelism или параметр индекса MAXDOP имеет значение 1, то оптимизатор запросов не будет использовать оптимизацию соединений типа «звезда» и преимущества новой оптимизации окажутся недоступными. Если система выполнения запросов отправляет запрос, оптимизированный с параллельным планом только для одного потока, то из плана соединения типа «звезда» с несколькими фильтрами по битовым картам могут быть удалены некоторые фильтры по битовым картам. Такое изменение может замедлить выполнение сильнее, чем можно ожидать в случае перехода с 2 потоков на 1.

Оптимизация соединений типа «звезда» доступна только в выпусках SQL Server Enterprise Edition, Developer Edition и Evaluation Edition. Дополнительные сведения о фильтрации по битовым картам см. в разделе Оптимизация производительности запросов к хранилищу данных с помощью фильтрации по битовым картам. Дополнительные сведения об интерпретации планов запросов, содержащих фильтры по битовым картам, см. в разделе Обработка планов выполнения, содержащих фильтры по битовым картам. Дополнительные сведения об оптимизации соединений типа «звезда» см. в статье журнала TechNet Производительность запросов к хранилищу данных.

Параллелизм небольшого числа внешних строк

В SQL Server 2008 упрощается параллелизм соединений вложенного цикла, если на внешней стороне соединения находится небольшое число строк. В SQL Server 2005, если доступно несколько потоков, на каждый поток приходилось по одной странице строк с внешней стороны соединения. Если число строк невелико, то они с большой вероятностью располагаются на одной странице. В таких случаях применяется только один поток и теряются возможные преимущества параллелизма. В SQL Server 2008 для таких случаев предусмотрен оператор обмена, который выделяет по одной строке на поток, чтобы использовать все доступные ЦП. Повышение степени параллелизма приводит к временному увеличению загрузки ЦП по сравнению с SQL Server 2005, однако запросы будут выполняться быстрее. Новый режим работы включается, только если число внешних строк невелико, а оцениваемая стоимость запроса достаточно велика, чтобы повышение степени параллелизма стало ощутимым. Если оцениваемая стоимость запроса мала или оценка количества элементов для внешней стороны превышает 1000, то SQL Server будет выделять по одной странице на поток, как и в SQL Server 2005. Дополнительные сведения об операторах обмена и параллельной обработке запросов см. в разделе Параллельная обработка запросов.

Запросы к секционированным таблицам, в которых используются подсказки USE PLAN

В SQL Server 2008 изменился способ обработки запросов к страницам секционированных таблиц и индексов. Запросы к секционированным объектам, в которых используется подсказка USE PLAN, могут содержать недопустимый план. После выполнения обновления до SQL Server 2008 рекомендуется выполнить следующие процедуры.

Если подсказка USE PLAN указана непосредственно в запросе, сделайте следующее.

  1. Удалите подсказку USE PLAN из запроса.

  2. Проверьте работу запроса.

  3. Если оптимизатор не выбрал подходящий план, настройте запрос и затем укажите подсказку USE PLAN с нужным планом запроса.

Если подсказка USE PLAN указана непосредственно в структуре плана, сделайте следующее.

  1. Проверьте правильность структуры плана с помощью функции sys.fn_validate_plan_guide. Кроме того, проверить недопустимые планы можно в приложении Приложение SQL Server Profiler по событию Plan Guide Unsuccessful.

  2. Если структура плана неверна, удалите ее. Если оптимизатор не выбрал подходящий план, настройте запрос и затем укажите подсказку USE PLAN с нужным планом запроса.

Дополнительные сведения об обработке запросов для секционированных объектов см. в разделе Улучшенные возможности обработки запросов для секционированных таблиц и индексов.

Структуры планов

Если в SQL Server 2008 невозможно обработать структуру плана, то запрос компилируется с помощью другого плана и ошибки не возникает. В SQL Server 2005 возникает ошибка, и запрос не выполняется.

Структуры планов, созданные в SQL Server 2005, могут не работать после обновления до SQL Server 2008. Недопустимые структуры планов не приводят к нарушению работы приложения, однако и использовать их невозможно. Рекомендуется переоценить и протестировать определения структур планов при обновлении приложения для работы с новой версией SQL Server. Требования к настройке производительности и поведение сопоставления структур планов могут меняться. После обновления базы данных до версии SQL Server 2008 рекомендуется, чтобы проверить существующие структуры планов, с помощью функции sys.fn_validate_plan_guide выполнить следующие задачи. Кроме того, отслеживать недопустимые структуры планов можно при помощи события Plan Guide Unsuccessful в приложении SQL Server Profiler.

Архитектура обработчика запросов

В SQL Server 2008 изменился способ обработки запросов к страницам секционированных таблиц и индексов. В запросах к секционированным объектам, в которых используется подсказка USE PLAN для плана, созданного SQL Server 2005, может содержаться недопустимый план. Дополнительные сведения см. в разделе Вопросы обновления компонента Database Engine. Дополнительные сведения об обработке запроса для секционированных объектов см. в разделе Улучшенные возможности обработки запросов для секционированных таблиц и индексов.

Функция REPLACE

В SQL Server 2005 выполняется усечение конечных пробелов в первом входном параметре функции REPLACE, если параметр имеет тип char. Например, в инструкции SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>' значение 'ABC ' ошибочно приводится к виду 'ABC'.

В SQL Server 2008 конечные пробелы всегда сохраняются. В приложениях, работа которых основана на прежних правилах для этой функции, при указании ее входных параметров следует применять функцию RTRIM. Например, следующая конструкция воспроизводит усечение, работавшее в SQL Server 2005: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.

Системные базы данных

База данных resource

В SQL Server 2005 файлы данных и журналов для базы данных Resource зависят от размещения файла данных базы данных master. Поэтому перемещение базы данных master также требует перемещения базы данных Resource в то же место. В SQL Server 2008 такая зависимость отсутствует. Файлы базы данных master могут быть перемещены без перемещения базы данных Resource.

В SQL Server 2008 база данных Resource по умолчанию находится в папке <диск>:\Program Files\Microsoft SQL Server\MSSQL10.<имя_экземпляра>\Binn\. База данных Resource не может быть перемещена.

База данных tempdb

В более ранних версиях SQL Server параметру базы данных PAGE_VERIFY присваивается значение NONE применительно к базе данных tempdb, которая не может быть изменена. В SQL Server 2008 значением по умолчанию для базы данных tempdb является CHECKSUM для новых установок SQL Server. После обновления установки SQL Server значением по умолчанию остается NONE. Этот параметр можно изменять. Для работы с базой данных tempdb рекомендуется использовать CHECKSUM.

Использование INSERT…SELECT для массовой загрузки данных с минимальным ведением журнала

В более ранних версиях SQL Server массовая загрузка строк в целевую таблицу с помощью инструкции INSERT INTO <target_table> SELECT <columns> FROM <source_table> всегда полностью заносилась в журнал. В SQL Server 2008 эта операция может быть выполнена с минимальным ведением журнала, если целевая таблица является кучей, для модели восстановления базы данных настроено простое или неполное протоколирование и в целевой таблице задана подсказка TABLOCK. Минимальное протоколирование может улучшить производительность инструкции и снизить вероятность того, что во время операции будет заполнен весь журнал транзакций. Дополнительные сведения см. в разделе Инструкция INSERT (Transact-SQL).

XML

Обновление типизированного XML с SQL Server 2005 до SQL Server 2008

В SQL Server 2008 входит несколько расширений поддержки схем XML, в том числе поддержка проверки lax, улучшенная обработка данных объектов xs:date, xs:time и xs:dateTime, а также добавлена поддержка типов list и union. В большинстве случаев эти изменения не влияют на вопросы обновления. Однако если используется коллекция схем XML в SQL Server 2005, которая допускает значения типов xs:date, xs:time и xs:dateTime (или любых подтипов), то при обновлении базы данных SQL Server 2005 до SQL Server 2008 выполняются следующие этапы обновления.

  1. Со всеми столбцами xml, типизированными коллекцией схем XML, которая содержит элементы или атрибуты, типизированные xs:anyType, xs:anySimpleType, xs:date или любыми их подтипами, xs:time или любыми его подтипами либо xs:dateTime или любыми его подтипами, а также типами union или list, содержащими любые из этих типов, выполняются следующие действия.

    1. Отключаются все XML-индексы столбца.

    2. Все значения SQL Server 2005 сохраняют представление в часовом поясе П, поскольку для них выполняется нормализация относительно часового пояса П.

    3. Все значения xs:date или xs:dateTime, предшествующие дате «1 января 1 года», приведут к ошибке во время выполнения при перестроении индекса или применении инструкции XQuery либо XML-DML к данным типа xml, содержащим такие значения.

  2. Все отрицательные значения года в аспектах xs:date или xs:dateTime либо значения по умолчанию в коллекции схем XML автоматически обновляются до наименьшего значения, допустимого базовыми типами xs:date или xs:dateTime. Например, 0001-01-01T00:00:00.0000000Z для типа xs:dateTime.

Обратите внимание, что при помощи простой инструкции SQL SELECT можно получить весь тип данных xml, даже если в нем содержатся отрицательные значения года. Отрицательные значения года рекомендуется заменить значением года в новом поддерживаемом диапазоне; кроме того, можно изменить тип элемента или атрибута на xs:string. Дополнительные сведения см. в разделе Сравнение типизированного и нетипизированного XML.

Нестрогая проверка и элементы xs:anyType

В SQL Server 2005 не поддерживается проверка lax и к элементам типа anyType применяется строгая проверка. В SQL Server 2008 содержимое элементов типа anyType проверяется с применением проверки lax. Дополнительные сведения см. в разделе Компоненты-шаблоны и проверка достоверности содержимого.

Журнал изменений

Обновленное содержимое

Добавлены разделы «Параметры access check cache», «Полнотекстовый поиск», «Параллелизм» и «XML».

Добавлен раздел «Использование INSERT… SELECT для массовой загрузки данных с минимальным протоколированием».

Добавлен раздел «Изменение в создании сценариев задач агента SQL Server».