Автор: Карл Рэбелер (Carl Rabeler)
Редакторы: Марк Соуза (Mark Souza), Прем Мехра (Prem Mehra), Линдсей Аллен (Lindsey Allen), Майк Уинер (Mike Weiner), Джеймс Подгорски (James Podgorski), Дональд Фармер (Donald Farmer), Роберт Брюкнер (Robert Bruckner), Санджай Мишра (Sanjay Mishra), Джеймс Подгорски (James Podgorski), Лукаш Павловски (Lukasz Pawlowski), Джефф Бернхардт (Jeff Bernhardt), Николас Дрицас (Nicholas Dritsas)
Microsoft SQL Server 2008 имеет новые функции, которые отсутствуют в предыдущих версиях, в новой версии также появились многочисленные усовершенствования в производительности и удобстве использования, которые специально предназначены для решений бизнес-аналитики. Эти функции используются для повышения скорости работы, увеличения производительности труда разработчиков и повышения удобства работы конечных пользователей. Цель этой статьи заключается в перечислении и кратком описанием основных причин, по которым SQL Server 2008 следует использовать для новых решений бизнес-аналитики, а также причин обновления существующих решений бизнес-аналитики до SQL Server 2008. Вначале будут описаны усовершенствования производительности, для которых не требуются изменения существующих решений бизнес-аналитики, а затем мы перейдем к технологии.
Важно. Сведения об обновлении существующих решений
бизнес-аналитики до SQL Server 2008 см. в документе Технический справочник. Обновление
SQL Server 2008.
1.
Усовершенствования
масштабируемости и управления ресурсами в службах Reporting Services
Механизм отчетности служб SQL Server 2005 Reporting Services имеет
ограниченные возможности по управлению ресурсами. В результате этого при
обработке больших отчетов, а также при значительной нагрузке от большого числа
одновременно работающих пользователей может возникнуть нехватка памяти. Кроме
того, на подготовку к просмотру длинных отчетов у служб SQL Server 2005 Reporting Services может уходить
много времени, поскольку перед тем, как пользователь увидит первую страницу,
должны быть обработаны все страницы.
В службах SQL Server 2008 Reporting Services компонент Report Engine был переработан с
тем, чтобы службы Reporting Services могли управлять ресурсами (потоки, память и состояние),
чтобы обеспечить наличие достаточного объема памяти для выполнения очень
больших отчетов и обработки значительной нагрузки от большого числа
одновременно работающих пользователей (за счет разбиения на страницы и
высвобождения памяти в случае ее нехватки). Для
достижения этого используются следующие средства:
·
Встраивание в
компонент Report Engine возможностей HTTP и удаление зависимости служб Reporting Services от служб IIS. В результате этого
настраивать службы Reporting Services стало намного проще, поскольку они изолированы от
других веб-приложений.
·
Вычисление
элементов отчета по запросу.
·
Подготовка к
просмотру только тех страниц, которые запросил пользователь (если только в
отчете нет ссылки на все страницы), что уменьшает время ответа для первой
страницы.
При работе со службами SQL Server 2008 Reporting Services в нашей
лаборатории было отмечено, что в сравнении со службами SQL Server 2005 Reporting Services службы SQL Server 2008 Reporting Services обслуживали в 3–4 раза больше пользователей и их
запросов на таком же аппаратном обеспечении без ошибок HTTP 503 «Служба недоступна» независимо от типа модуля
подготовки отчетов. В отличие от служб SQL Server 2008 Reporting Services, по мере роста числа пользователей и их запросов
независимо от типа модуля подготовки отчетов службы SQL Server 2005 Reporting Services выдавали огромное количество ошибок HTTP 503 «Служба
недоступна».
Наши тесты ясно показали,
что новая архитектура управления ресурсами сервера отчетов позволяет службам SQL Server 2008 Reporting Services выполнять
масштабирование, особенно на новых компьютерах с четырьмя четырехъядерными
процессорами. При тестировании рабочей нагрузки службы SQL Server 2008 Reporting Services постоянно оказывались лучше SQL Server 2005 при
использовании модулей подготовки PDF и XLS на платформе с четырьмя четырехъядерными
процессорами (16 ядер) как по времени ответа, так и по общей пропускной
способности. По результатам этих испытаний для служб SQL Server 2008 Reporting Services мы рекомендуем увеличить объем аппаратных
ресурсов до четырех четырехъядерных процессоров для обеспечения
производительности и распределить нагрузку на два узла для обеспечения высокого
уровня доступности. В дальнейшем по мере возникновения потребности в большей вычислительной
мощности подключайте дополнительные серверы с четырьмя четырехъядерными
процессорами. При использовании служб SQL Server 2005 Reporting Services из-за нехватки ресурсов рекомендуется выполнять
масштабное развертывание выше четырех процессоров. Тесты четко свидетельствуют,
что службы SQL Server
2008 Reporting Services используют аппаратные ресурсы более эффективно, чем службы SQL Server 2005 Reporting Services, особенно при
использовании новых серверов с четырьмя четырехъядерными процессорами.
Дополнительные сведения см. в статье Сравнение масштабируемости служб Reporting Services 2008 и Reporting Services 2005: полученные уроки.
2.
Вычисление в
подпространстве в службах Analysis Services
Обработчик формул служб SQL Server Analysis Services для получения
запрошенных данных разрабатывает план выполнения запроса. Каждый узел плана
выполнения запроса использует один из двух типов режимов оценки: режим
вычисления в подпространстве или режим оценки «ячейка за ячейкой». При
использовании режима вычисления в подпространстве обработчик формул служб Analysis Services использует только
ячейки с данными, которые оказывают влияние на результат. При использовании же
режима «ячейка за ячейкой» обработчик формул служб Analysis Services использует все ячейки, которые теоретически могли
бы оказать влияние на результат, без учета того, содержат ли они данные или нет.
Получение данных в разреженном кубе, который является стандартной структурой, с
помощью режима оценки «ячейка за ячейкой» является неэффективным для запросов,
требующих значительных вычислений, поскольку обрабатывается много пустых ячеек
(которые не влияют на результат).
До выхода пакета обновления
2 (SP2) в SQL Server 2005 планы
выполнения запросов, выработанные обработчиком формул служб Analysis Services, главным образом
состояли из узлов, которые использовали режим оценки «ячейка за ячейкой». В пакете
обновления 2 (SP2) SQL Server
2005 режим вычисления в подпространстве поддерживается небольшим количеством
функций многомерного выражения. В службах SQL Server 2008 Analysis Services подавляющее большинство функций многомерного
выражения используют режим вычисления в подпространстве. При работе с нашими
клиентами в отношении служб SQL Server 2008 Analysis Services мы наблюдаем значительный рост производительности
при работе со следующими объектами:
·
Разреженные кубы
·
Кубы со сложными вычислениями
Этот рост
производительности при использовании служб SQL Server 2008 Analysis Services достигается без внесения изменений в решение
бизнес-аналитики. Кроме того, также можно добиться дальнейшего роста
производительности кубов со сложными вычислениями путем дополнительной
настройки вычислений многомерных выражений в кубах. Дополнительные сведения см.
в статьях Повышение производительности многомерных выражений
в службах SQL Server 2008 Analysis Services и Руководство по повышению
производительности служб SQL Server 2005 Analysis Services.
3.
Параллелизм
конвейеров в службах Integration Services
В службах SQL Server 2005 Integration Services каждому дереву
выполнения в задаче DataFlow в пакете обычно назначается один рабочий поток.
Кроме того, при определенных условиях каждое дерево выполнения фактически
использует один и тот же поток одновременно с другими деревьями выполнения. Такой подход имеет следующие преимущества:
·
Планирование
потоков производится до выполнения пакета, во время выполнения на планирование
время не тратится.
·
Данные буфера
остаются в кэше, поскольку поток использует полный буфер на всем дереве
выполнения.
Тем не менее у такого
подхода есть и недостатки, которые часто перевешивают упомянутые достоинства,
особенно при работе с длинными деревьями выполнения или деревьями выполнения с
большим количеством ветвей.
·
Планирование
потоков не всегда является оптимальным, поскольку относительный объем работы
для каждого дерева выполнения до его выполнения неизвестен.
·
Если число
деревьев выполнения меньше, чем количество ядер процессоров в компьютере с
несколькими процессорами, то используются не все ядра. Недостаточное
задействование всех ядер особенно заметно, если дерево выполнения состоит из
нескольких синхронных компонентов, поскольку в этом случае все синхронные компоненты
используют один поток и может оказаться, что они привязаны к одному ядру
процессора. Такая же проблема возникает при разбиении данных на несколько путей
с помощью многоадресной доставки, поскольку многоадресная доставка является
синхронным компонентом. В результате, хотя визуально представляется, что пакет
распараллелен, пути выполняются последовательно, поскольку выходные пути
принадлежат одному дереву выполнения, которому выделяется только один поток.
Примечание. При вставке в
поток данных асинхронного преобразования для увеличения параллелизма путем
создания второго дерева выполнения (трюк для повышения производительности на
высокопроизводительных многопроцессорных компьютерах) возникает потеря
производительности, так как все данные должны копироваться для нового дерева
выполнения.
В службах SQL Server 2008 Integration Services параллелизм
конвейеров усовершенствован путем внедрения улучшений в архитектуру подсистемы
обработки потока данных. Теперь рабочие потоки динамически назначаются отдельным
компонентам из общего пула потоков. В результате этого в многоядерных
компьютерах подсистема обработки потока данных автоматически задействует все
ядра, при этом прибегать к каким-либо трюкам не требуется. За счет улучшения
параллелизма конвейеров в службах SQL Server 2008 Integration Services с помощью пула потоков повышается скорость
выполнения пакета, при этом имеющиеся ресурсы лучше используются при условии
отсутствия нехватки других ресурсов (например, ввода/вывода или памяти). В
сотрудничестве с клиентами, использующими службы SQL Server 2008 Integration Services, мы выяснили, что при обработке пакетов с
длинными цепями синхронных преобразований, а также большинства пакетов,
выполняющихся на многопроцессорных компьютерах, производительность значительно
возросла.
Примечание. Дополнительные сведения о службах SQL Server 2008 Integration
Services от группы разработчиков SQL Server Integration Services см. в
коллективном блоге SSIS Team Blog. Дополнительные сведения о производительности см. в
статьях Мировой рекорд ETL и 10 основных рекомендаций по службам SQL Server Integration Services.
4.
Усовершенствования
масштабируемости и готовности в службах Analysis Services
В SQL Server
2005 резервные копии больших баз данных Analysis Services обладают ограниченной масштабируемостью, а службы
Analysis Services поддерживают только одно расположение для всех баз данных Analysis Services в экземпляре
служб Analysis Services, хотя группы мер для секций в базе данных можно распределять по нескольким
дискам для распределения ввода/вывода. Более того, для повышения
масштабируемости и готовности, после обработки одной базы данных для экземпляра
служб Analysis Services на сервере обработки обработанную базу данных нельзя отсоединить, а затем
присоединить ее к серверу запросов. Кроме того, в службах SQL Server 2005 Analysis Services изначально
отсутствует поддержка присоединения доступной только для чтения копии базы
данных Analysis Services к нескольким серверам для повышения
масштабируемости и готовности. Такая возможность поддерживается только за счет
использования технологий моментальных снимков SAN (см. статью Масштабное развертывание запросов в
службах Analysis Services с помощью моментальных снимков SAN).
В службах SQL Server 2008 Analysis Services эти проблемы решены за счет следующих
усовершенствований масштабируемости и готовности.
·
Можно
создавать резервную копию базы данных служб Analysis Services любого размера. Производительность резервных
копий баз данных служб Analysis Services масштабируется линейно, она сравнима с резервными
копиями на уровне файлов.
·
В экземпляре
служб Analysis Service
каждую базу данных можно развернуть в собственном месте хранения, что позволяет
размещать каждую базу данных Analysis Service из экземпляра на отдельном диске.
·
Можно
отсоединять всю базу данных из экземпляра служб Analysis Service, копировать или перемещать ее в новое
расположение, а затем присоединять ее к другому экземпляру Analysis Service. Эта функция
повышает масштабируемость и производительность, позволяя обрабатывать новые
данные для базы данных служб Analysis Service на сервере обработки, при этом пользователи будут
запрашивать текущую версию базы данных служб Analysis Service, расположенную на сервере запросов. После
завершения обработки обработанную базу данных можно отсоединить от сервера
обработки и присоединить ее к серверу запросов. Более того, при использовании
двух экземпляров служб Analysis Services на сервере запросов и подсистемы балансировки
загрузки для распределения запросов соответствующему экземпляру можно
направлять новые соединения пользователей к вновь присоединенной базе данных,
не влияя на готовность, поскольку подключенные в данный момент пользователи
могут завершить свои выполняющиеся в данный момент запросы к ранее
присоединенной базе данных. Эта функция также позволяет отсоединять базу данных
от экземпляра служб Analysis Services в целях архивирования или резервного копирования.
·
Для повышения
масштабируемости и готовности базу данных служб Analysis Services можно присоединить в режиме доступа только для
чтения к нескольким экземплярам служб Analysis Services. Доступная только для чтения база данных может
храниться в сети хранения данных (SAN) и монтироваться на нескольких экземплярах, либо
она может совместно использоваться посредством общей папки файловой системы и
монтироваться на нескольких экземплярах.
Примечание. При работе с
большими базами данных, в которых секции истории не изменяются, для
клонирования отсоединенной базы данных потребуется использовать функции
высокоскоростного копирования SAN либо Robocopy. Дополнительные сведения об использовании Robocopy см. в статье Образец сценария Robocopy для пользовательской синхронизации баз
данных служб Analysis Services.
Следующая схема
иллюстрирует использование этих новых функций, когда один сервер обработки
присоединен к базе данных в режиме чтения и записи, а четыре сервера запросов
присоединены к одной базе данных, доступной только для чтения. Подсистема балансировки загрузки распределяет запросы среди четырех
серверов запросов.
5.
Оптимизированные
возможности конструирования в службах Analysis Services
Решения служб SQL Server Analysis Services
конструируются в среде Business Intelligence Development Studio. В SQL Server 2005 при разработке решения служб Analysis Services в среде Business Intelligence Development Studio очень легко создать
решение, которое не соответствует рекомендациям по достижению наилучшей
производительности, в результате чего могут возникнуть проблемы с
производительностью. Например, отсутствие нужных связей атрибутов будет
значительной недоработкой и может ухудшить производительность. Однако среда SQL Server 2005 Business Intelligence Development Studio не уведомляет об
этом разработчика, который не создал такие связи. Кроме того, во время работы
со службами SQL Server 2005 Analysis Services для достижения оптимальной производительности
статистические выражения часто приходится конструировать вручную.
В службах SQL Server 2008 Analysis Services в среду
разработки Business Intelligence Development Studio для обеспечения соблюдения рекомендаций и помощи
разработчикам в создании высокопроизводительных решений были внесены следующие
изменения.
·
В объектную
модель AMO
добавлены уведомления о рекомендациях, называемые предупреждениями AMO. Эти сообщения с
предупреждениями формируются в среде Business Intelligence Development Studio, чтобы уведомить разработчиков, когда их
конструкции не соответствуют какой-либо из более чем 40 рекомендаций. Эти
предупреждения интегрированы в проверки конструктора, проводимые в реальном времени,
они используют синие волнистые линии. Ненавязчиво (на них можно не обращать
внимания) они позволяют разработчикам видеть потенциальные проблемы конструкций
задолго до их развертывания. С помощью этой новой функции можно также
анализировать соответствие существующих кубов служб SQL Server 2005 Analysis Services рекомендациям по разработке. Для этого нужно либо
открыть базу данных Analysis Services в среде Business Intelligence Development Studio версии SQL Server 2008, либо запустить последнюю версию анализатора
соответствия рекомендациям для SQL Server 2005 (в котором также имеются эти предупреждения AMO). Доступ к этим
предупреждениям AMO можно получить из PowerShell или пользовательского клиентского приложения.
·
Был добавлен
новый конструктор связей атрибутов для просмотра и редактирования связей
атрибутов. Конструктор имеет встроенные проверки,
помогающие создавать оптимальные конструкции измерений.
·
Редактор
измерений был усовершенствован путем использования одного мастера измерения,
улучшения обнаружения и классификации атрибутов измерений и свойств элементов,
а также добавления автоматического обнаружения отношений «родители-потомки».
·
В среду Business Intelligence Development Studio был добавлен новый
конструктор агрегатов с новым алгоритмом создания новых агрегатов. Конструктор
агрегатов оптимизирован для работы со статистическими выражениями, основанными
на использовании. Теперь легко анализировать существующие статистические
выражения, дополнять эти выражения, удалять или заменять их. Для помощи в
объединении существующих и новых статистических схем предоставляется
интеллектуальная поддержка. Дополнительные сведения о новом конструкторе
агрегатов и его использовании со статистическими выражениями, основанными на
использовании, см. в статье Новые возможности оптимизации на основе
использования в службах SQL Server 2008 Analysis Services.
6.
Новые и улучшенные
возможности разработки и визуализации в службах Reporting Services
В службах SQL Server 2005 Reporting Services можно создавать
мощные и функциональные диаграммы и графики, позволяющие детализировать
углублением или переходить по ссылкам в другие отчеты и на веб-сайты. Кроме
того, эти отчеты и графики можно интегрировать на панели мониторинга. Однако
добиться быстрой и четкой работы этих отчетов и графиков бывает сложно, на это
требуется много времени.
Службы SQL Server
2008 Reporting Services предлагают множество улучшений для разработки, которые повышают
продуктивность работы разработчика. Кроме того, теперь в службы включены
полнофункциональные версии диаграммы Dundas и элементов управления в виде датчиков, что
позволяет создавать красивые диаграммы и датчики.
Улучшения для разработки
Кроме того, в службах SQL Server 2008 Reporting Services появилось множество других улучшений для
разработки. Далее перечислены некоторые из них.
·
Новый формат
представления данных — Tablix. Теперь с помощью Tablix можно создавать отчеты с любой структурой,
используя в них все лучшее, что есть в таблицах и матрицах.
·
Улучшенные
возможности форматирования. Теперь можно создавать текстовые поля со смешанными
стилями, абзацами и гиперссылками, а с помощью расширений можно реализовывать
форматирование в строке.
·
Улучшенные
возможности конструирования. Конструктор отчетов в Microsoft Visual Studio переработан для упрощения работы конструкторов.
·
Среда
разработки «Построитель отчетов 2.0». Эта изолированная среда разработки имеет
наглядный и знакомый вид Microsoft Office.
Улучшения диаграмм
Улучшения диаграмм включают разрывы шкалы, заметки, палитры
пользовательских цветов, слияние диаграмм и использование нескольких осей. Далее перечислены новые типы диаграмм:
·
Ступенчатый график
·
Область сплайн
·
Круговая диаграмма
·
Полярная диаграмма
·
Лепестковая диаграмма
·
Диаграмма Ганта
·
Линия/столбец диапазона
·
Воронкообразная диаграмма
·
Пирамидальная диаграмма
·
Гистограмма
·
Блок
Датчики
Ниже перечислены новые типы датчиков:
·
Круглый
·
Линейный
·
Угловой
·
Термометр
·
Числовые индикаторы
·
Индикаторы состояния
Дополнительные сведения см. в статьях Службы Reporting Services и Новые возможности (службы Reporting Services).
7. Сжатие данных в реляционном модуле
Подсистема дискового
ввода/вывода является одним из наиболее часто встречающихся узких мест многих
реляционных хранилищ данных. Для сокращения времени чтения/записи часто
добавляются новые диски. Это может быть затратно, особенно для высокопроизводительных
систем хранения. В то же время потребность в пространстве для хранения
продолжает расти в силу быстрого увеличения объема данных. Одновременно растут
и затраты на обслуживание баз данных (резервное копирование, восстановление,
перенос и так далее).
В SQL Server 2008 для решения некоторых из этих проблем используется сжатие данных. С
помощью механизма сжатия данных можно выборочно сжимать любую таблицу, секцию
таблицы или индекс, при этом будет высвобождаться место на диске, требоваться
меньше памяти и ресурсов ввода/вывода. Работая с клиентами, мы отмечаем, что во
многих средах возможность сжатия данных позволила сэкономить 50–80 % места на диске. Эта экономия
места на диске сразу же преобразуется в меньший объем памяти, который требуется
для высокоскоростного дискового хранилища. В реляционных хранилищах данных, где
узким местом является подсистема ввода/вывода и мощности процессора
задействуются не полностью, можно также ожидать роста общей производительности.
SQL Server
поддерживает два типа сжатия данных: сжатие
строк, когда сжимаются
отдельные столбцы таблицы, и сжатие
страниц, когда с помощью
сжатия строк, префиксов и словарного сжатия сжимаются страницы данных. Результаты сжатия в значительной степени зависят от типов
данных и сведений, которые содержатся в базе данных. Но в общем использование
сжатия строк ведет к меньшей загрузке процессора, хотя при этом высвобождается
меньше пространства. С другой стороны, сжатие страниц ведет к большей загрузке
процессора, но его результатом является больший объем высвобожденного
пространства. Сжатие страниц является надмножеством сжатия строк в том смысле,
что к объекту или секции объекта, сжимаемой с помощью сжатия страниц, также
применено сжатие строк. Сжатые страницы остаются сжатыми в памяти до тех пор,
пока к строкам или столбцам не производится обращение.
И сжатие строк, и сжатие страниц
можно применить к таблице или индексу, находящимся в оперативном режиме, не
влияя на готовность приложения к работе. Однако на такое сжатие может уйти
больше времени. Секции секционированной таблицы в оперативном режиме сжимать
нельзя. При проведении испытаний было установлено, что использование гибридного
подхода, когда сжимались только несколько самых больших таблиц, обеспечило
наилучшую общую производительность. Этот подход позволил высвободить
значительное место на диске, при этом было оказано минимальное влияние на производительность.
Поскольку в процессе сжатия требуется дополнительное место на диске, было
установлено, что лучше всего начинать сжатие с объектов меньшего размера из
тех, которые требуется сжать. За счет этого во время сжатия используется
наименьший объем места на диске, при этом в процессе сжатия можно избежать
нехватки дискового пространства.
Чтобы определить, какой размер
будет у объекта после его сжатия, используйте системную хранимую процедуру sp_estimate_data_compression_savings . Сжатие баз данных поддерживается только в выпусках SQL Server 2008 Enterprise и Developer. Оно полностью управляется на уровне базы данных и не требует каких-либо
изменений в приложениях.
8.
Регулятор ресурсов в
реляционном модуле
Раньше для SQL Server было сложно поддерживать
устойчивый уровень обслуживания, предотвращая бесконтрольные запросы и
обеспечивая выделение ресурсов для важнейших рабочих загрузок. Отсутствовала
возможность гарантировать выделение определенного объема ресурсов набору
запросов, отсутствовало управление приоритетами доступа к реляционному модулю SQL Server. У всех запросов были равные права
на доступ ко всем доступным ресурсам реляционного модуля.
Пример.
·
Одному большому запросу к
хранилищу данных может быть предоставлено до 25 % памяти рабочей области. При трех
одновременных больших запросах этого типа все следующие большие запросы будут
заблокированы.
·
Некоторые рабочие нагрузки
выигрывают от уменьшения параллелизма. Во время обработки секций службы SQL Server Analysis Services могут выдавать большое количество
параллельных запросов. Для обеспечения наилучшей производительности
рекомендуется так настроить задания на обработку в службах Analysis Services, чтобы они выдавали по одному
запросу на ядро компьютера с реляционным хранилищем данных. Однако, если
реляционный механизм распараллеливает каждый из таких обрабатывающих запросов,
потоки могут начать пробуксовывать. Одним из решений является выполнение
каждого обрабатывающего запроса с использованием параметра MAXDOP=1. Но до выхода SQL Server 2008 это был серверный параметр,
который применялся ко всем запросам, поскольку добавить подсказку MAXDOP в обрабатывающие запросы служб Analysis Services было нельзя. Использование
параметра MAXDOP=1 для всех запросов оказывало
отрицательное влияние на запросы, которые значительно выигрывали от
распараллеливания, из-за чего приходилось выбирать, запросы какого типа
оптимизировать.
В SQL Server 2008 для решения этих проблем
используется регулятор ресурсов, который позволяет пользователям разграничивать
рабочие нагрузки, выделяя ресурсы по мере надобности, управляя параллелизмом
для определенных рабочих нагрузок (например, по имени пользователя или
компьютера) и значительно увеличивая параллельность для запросов, требующих
значительных объемов ресурсов. Ограничения регулятора ресурсов можно легко
перенастроить в режиме реального времени, при этом воздействие на выполняемые в
данный момент рабочие нагрузки остается минимальным. Распределение рабочей
нагрузки пулу ресурсов можно настраивать на уровне соединения, а сам этот
процесс является полностью прозрачным
для приложений. Эта новая функция особенно полезна в системах с большим объемом
памяти и несколькими ядрами.
На приведенной ниже диаграмме показан процесс распределения ресурсов. В
этом сценарии настроены три пула рабочих нагрузок (рабочая нагрузка Admin, рабочая нагрузка OLTP и рабочая нагрузка Report), а пулу рабочей нагрузки OLTP присвоен высокий приоритет.
Параллельно настроены два пула ресурсов (пул Admin и пул Application), имеющие определенные
ограничения по памяти и процессору (ЦП), как показано на диаграмме. Наконец,
рабочая нагрузка Admin распределяется пулу Admin, а рабочие нагрузки OLTP и Report распределяются пулу Application.
Ниже приведены некоторые особенности, которые следует учитывать при использовании
регулятора ресурсов.
·
Поскольку регулятор ресурсов в качестве
идентификатора пула ресурсов использует учетные данные для входа, имя узла или
имя приложения, приложения ISV, которые используют одно имя входа для подключения нескольких пользователей
приложения к SQL Server, без переработки приложения не смогут использовать регулятор ресурсов.
После переработки приложение должно будет использовать один из идентификаторов
ресурсов из дифференцированных рабочих нагрузок приложения.
·
В текущей версии не поддерживается
группирование объектов на уровне базы данных, при которой доступ к ресурсам
регулируется на основе объектов базы данных, к которым осуществляется доступ.
·
Регулятор ресурсов позволяет
управлять ресурсами только в одном экземпляре SQL Server. Для управления несколькими
экземплярами можно использовать Системный диспетчер ресурсов Windows.
·
Настраивать можно только использование
ресурсов процессора и памяти. Управление
ресурсами ввода-вывода не реализовано.
·
В текущей версии динамическое
переключение рабочих нагрузок между пулами ресурсов после соединения
невозможно.
·
Регулятор ресурсов поддерживается
только в выпусках SQL Server 2008 Enterprise и Developer и может использоваться только для
компонента SQL Server Database Engine. Использованием ресурсов службами
SQL Server Analysis Services, службами SQL Server Integration Services и службами SQL Server Reporting Services нельзя управлять с помощью
регулятора ресурсов. Для управления этими службами SQL Server можно использовать Системный диспетчер ресурсов Windows.
9. Минимально протоколируемые операции в реляционном
модуле
Хотя операции массовой загрузки имеют значительные
преимущества по производительности относительно построковых операций,
протоколирование этих операций массовой загрузки (обычно вставки) при загрузке
больших объемов данных часто является причиной возникновения узких мест при
вводе/выводе на диск. В отличие от полностью протоколируемых операций, которые
используют журнал транзакций для отслеживания всех измененных строк, операции с
минимальным протоколированием отслеживают только выделение экстентов и страниц,
а также изменение метаданных. Поскольку в журнал транзакций заносится намного
меньше данных, операции с минимальным протоколированием часто выполняются
быстрее, чем полностью протоколируемые операции, если протоколирование является
узким местом. Более того, так как в журнал транзакций заносится меньше записей,
формируется файл журнала намного меньшего размера, требующий меньше ресурсов
ввода/вывода. Операции с минимальным протоколированием возможны, только если
база данных находится в режиме восстановления с неполным протоколированием или
в режиме простого восстановления. Дополнительные сведения см. в разделе Операции,
для которых возможно минимальное протоколирование. Следует
отметить, что выполнение массовой операции в базе данных с неполным
протоколированием влияет на стратегию резервного копирования для этой базы
данных. Кроме того, откат операции с минимальным протоколированием
протоколируется полностью, в результате чего на откат операции с минимальным
протоколированием может уйти значительно больше времени, чем на саму операцию.
Дополнительные сведения о последствиях см. в документе Резервное
копирование при модели восстановления с неполным протоколированием.
В SQL Server 2008 в качестве нового
способа выполнения операций вставки с минимальным протоколированием появилась
инструкция INSERT…SELECT,
позволяющая инструкциям INSERT на
основе Transact-SQL в
определенных условиях иметь минимальное протоколирование.
·
Кучи —
инструкция INSERT, которая берет строки из
операции SELECT и вставляет их в кучу,
минимально протоколируется, если в целевой таблице используется подсказка WITH (TABLOCK).
·
Кластеризованный
индекс — протоколируется ли минимально операция вставки INSERT… SELECT в
кластеризованные индексы, зависит от состояния флага трассировки 610. Не каждая
строка, вставляемая в кластеризованный индекс с флагом трассировки 610,
протоколируется минимально. Если в результате операции массовой загрузки в
экстенте выделяется новая страница, то все строки, последовательно заполняющие
эту новую страницу, протоколируются минимально. Строки, вставляемые на
страницы, которые были выделены до операции массовой загрузки, протоколируются
полностью, как и строки, которые перемещаются в результате разбиения страниц во
время загрузки. Это означает, что для некоторых таблиц некоторые вставки все
равно будут полностью протоколироваться. Если в результате установки флага
трассировки 610 возникает минимальное протоколирование, то в целом
производительность должна улучшиться. Но, как обычно при работе с флагами
трассировки, следует протестировать среду и рабочую нагрузку. Рассмотрим два следующих примера.
Пример 1. Имеется таблица, кластеризованная по ключу, которая содержит четные целые значения ключей 0–16. Таблица имеет четыре конечные страницы, страницы не заполнены до конца, на каждой странице можно разместить еще по две строки. Выполняется массовая загрузка восьми новых строк с нечетными значениями ключей 1–15. Новые строки умещаются на существующие страницы. На приведенном ниже рисунке показан вид этой таблицы до и после операции загрузки.
Рисунок 1. Полностью протоколируемая вставка с флагом
трассировки 610
В этом примере новые страницы не выделяются, а
флаг трассировки 610 не обеспечит никакого минимального протоколирования.
Пример 2. Рассмотрим альтернативный вариант: теперь изначально таблица имеет две страницы, обе они полны и содержат значения ключей 0–7. Выполняется массовая загрузка строк со значениями ключей 8–16.
Рисунок 2. Минимально протоколируемая вставка с флагом
трассировки 610
В этом примере страницы со значениями ключей 8–15
(выделены светло-синим цветом) будут минимально протоколироваться с флагом
трассировки 610.
Дополнительные сведения об использовании этой
новой функции для улучшения производительности при загрузке данных см. в
документе Руководство
по повышению производительности при загрузке данных.
10.
Другие полезные функции
В SQL Server 2008 появились следующие
дополнительные функции, которые улучшают производительность решений
бизнес-аналитики.
Улучшения запросов типа «звезда»
Большинство
запросов к хранилищу данных сконструированы по схеме «звезда» и способны
обрабатывать сотни миллионов строк за один запрос. По умолчанию оптимизатор
запросов сравнивает запросы со схемами «звезда» и создает для них эффективные
планы запроса. Одним из методов создания эффективного плана запроса является
применение битовой фильтрации. Фильтр по битовым картам использует компактное
представление набора значений из таблицы, находящейся в одной части дерева
операторов, для фильтрации строк из другой таблицы, находящейся в другой части
дерева. В сущности, фильтр выполняет сокращение полусоединением, то есть
обрабатываются только те строки второй таблицы, которые удовлетворяют условию
объединения с первой таблицей. В SQL Server 2008 битовые фильтрации
можно ввести в план запроса после оптимизации, как в SQL Server 2005, или динамически с
помощью оптимизатора запросов во время создания плана запроса. Если фильтр
создается динамически, его называют оптимизированным фильтром по битовым
картам. Оптимизированная битовая фильтрация может значительно повысить
производительность запросов к хранилищу данных, использующих схему «звезда»,
удаляя не соответствующие условию строки на раннем этапе плана запроса. Без
оптимизированной битовой фильтрации в некоторой части дерева операторов
обрабатываются все строки в таблице фактов перед тем, как операция объединения
с таблицей измерения удалит не соответствующие условию строки. Если применяется
оптимизированная битовая фильтрация, не соответствующие условию строки в
таблице фактов удаляются немедленно. Оптимизированная фильтрация по битовым
картам доступна только в следующих выпусках SQL Server: Enterprise, Developer и Evaluation.
Дополнительные сведения см. в документе Оптимизация
производительности запросов к хранилищу данных с помощью битовой фильтрации.
Параллелизм для секционированных таблиц
SQL Server 2008 повышает производительность
обработки запросов к секционированным таблицам для многих параллельных планов,
изменяет способ представления параллельных и последовательных планов и улучшает
информацию о секционировании, содержащуюся в планах времени компиляции и в
планах времени выполнения. SQL Server 2005 использует стратегию
выполнения параллельного запроса, когда один поток выделяется на одну секцию,
тогда как SQL Server 2008 может выделять по несколько потоков на одну
секцию. Это улучшение особенно важно для сред хранилищ данных. Таблицы фактов
часто подвергаются секционированию, поскольку они обычно содержат несколько
столбцов с очень большим количеством записей. Дополнительные сведения см. в
документе Улучшенные
возможности обработки запросов для секционированных таблиц и индексов.
Инструкция MERGE
В SQL Server 2008 несколько операций
языка обработки данных DML можно
выполнить, используя одну инструкцию MERGE. Например,
может потребоваться синхронизировать две таблицы путем вставки, обновления или
удаления строк в одной таблице на основании отличий, найденных в другой
таблице. Как правило, это производится путем выполнения хранимой процедуры или
пакета, содержащего отдельные инструкции INSERT, UPDATE и DELETE. Однако
это означает, что данные и в исходных и в целевых таблицах вычисляются и
обрабатываются несколько раз — по крайней мере один раз для каждой инструкции.
При помощи инструкции MERGE можно
заменять отдельные инструкции DML одной
инструкцией. Это может улучшить производительность запросов, так как операции
выполняются внутри одной инструкции. Соответственно, количество обработок
данных в исходных и целевых таблицах снижается. Однако увеличение
производительности зависит от наличия правильных индексов, соединений и других
факторов. Дополнительные сведения см. в разделе Оптимизация
производительности инструкции MERGE.
Отслеживание измененных данных
В SQL Server 2008 эта
новая функция обеспечивает простой способ отслеживания изменений данных,
которые находятся в таблицах базы данных, чтобы эти изменения можно было
перенести во вторую систему, например хранилище данных. Система отслеживания
измененных данных регистрирует действия по вставке, обновлению и удалению,
применяемые к таблицам SQL Server, сохраняя подробности
операций изменения в легко обрабатываемом реляционном формате. Таблицы
изменений, используемые системой отслеживания измененных данных, содержат
столбцы, отражающие структуру столбцов отслеживаемой исходной таблицы, а также
метаданные, необходимые для понимания того, какие изменения произошли. Система
отслеживания измененных данных доступна только в следующих выпусках SQL Server: Enterprise, Developer и Evaluation. Дополнительные сведения см. в статье Настройка
производительности системы отслеживания изменения данных в SQL Server 2008.
ExecutionLog2
В SQL Server 2008
база данных служб Reporting Services хранит дополнительные
сведения, которые позволяют анализировать данные журнала выполнения отчетов для
поиска ответов на следующие вопросы о производительности.
·
Какие отчеты следует кэшировать?
·
Сколько
отчетов было возвращено из кэша по сравнению с выполнением в реальном времени и
созданием моментального снимка выполнения?
·
Какой отчет
использовался чаще всего в течение указанного периода времени?
·
Какие отчеты
имеют самую низкую производительность?
·
Какие отчеты выполнялись
службами SQL Server 2008 Reporting Services, а какие — службами SQL Server 2005
Reporting Services?
·
Для каких
отчетов отмечалась нехватка памяти?
Эти
подробные сведения отображаются в представлении ExecutionLog2. Дополнительные
сведения см. в статье Представление
ExecutionLog2 — анализ и оптимизация
отчетов.
Заключение
В Microsoft SQL Server 2008 появились новые функции, которые отсутствуют в предыдущих версиях, а
также многочисленные усовершенствования производительности и удобства
использования, которые специально предназначены для решений бизнес-аналитики.
Полный список функций с подробным описанием см. в электронной документации по SQL Server и на веб-сайте SQL Server.
Комментариев нет:
Отправить комментарий