В службах SQL Server 2008 Analysis Services

Руководство по повышению производительности служб Analysis
Services
Техническая статья по SQL Server
Авторы: Ричард Ткачук и Томас Кейсер
Соавторы и технические редакторы:
T.K. Ананд (Anand)
Мариус Думитру (Marius Dumitru)
Грег Галловей (Greg Galloway)
Сива Харинат (Siva Harinath)
Денни Ли (Denny Lee)
Эдвард Меломед (Edward Melomed)
Акшай Мирчандани (Akshai Mirchandani)
Моша Пасумански (Mosha Pasumansky)
Карл Рабелер (Carl Rabeler)
Элизабет Витт (Elizabeth Vitt)
Седат Йогурткуоглу (Sedat Yogurtcuoglu)
Анн Зорнер (Anne Zorner)
Опубликовано: Октябрь 2008 г.
Область применения: SQL Server 2008
Сводка: В этом техническом документе приводится описание того, как разработчики
приложений могут применять методы повышения производительности обработки запросов в
решениях, использующих службы SQL Server 2008 Analysis Services OLAP.
Авторские права
Сведения, содержащиеся в данном документе, отражают текущую позицию корпорации
Майкрософт по рассматриваемым вопросам на момент публикации документа. Поскольку
корпорации Майкрософт приходится реагировать на изменение рыночных условий, текст
документа не может рассматриваться как обязательство со стороны корпорации
Майкрософт. Корпорация Майкрософт не гарантирует достоверности предоставленной
информации после даты публикации.
Данный технический документ предоставляется исключительно в ознакомительных
целях. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ДАЕТ В НЕМ НИКАКИХ ЯВНЫХ ИЛИ
ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ.
Ответственность за соблюдение всех авторских прав целиком и полностью несет
пользователь. Без ограничения авторских прав ни одна из частей этого документа не
может быть воспроизведена, сохранена или использована в системах поиска либо
передана в любой форме, любыми способами (электронными, механическими, в виде
фотокопии, в виде записи или любыми другими) и в любых целях без письменного
разрешения корпорации Майкрософт.
Корпорация Майкрософт может иметь патенты, патентные заявки, охраняемые товарные
знаки, авторские или другие права на интеллектуальную собственность применительно к
содержимому этого документа. Без письменного разрешения корпорации Майкрософт
данный документ не дает лицензии на эти патенты, товарные знаки, авторские права и
другую интеллектуальную собственность.
© Корпорация Майкрософт (Microsoft Corporation), 2008. Все права защищены.
Microsoft, Excel, SQL Server, Visual Basic, Windows и Windows Server являются товарными
знаками компаний, входящих в корпорацию Майкрософт.
Все прочие товарные знаки являются собственностью их владельцев.
2
Содержание
1
Введение .............................................................................................................................................. 6
2
Основные сведения об архитектуре обработчика запросов........................................................... 6
2.1
Управление сеансом ............................................................................................................... 7
2.2
Архитектура задания ............................................................................................................... 8
2.3
Обработчик запросов .............................................................................................................. 9
2.3.1
Кэш обработчика запросов............................................................................................... 10
2.3.2
Внутренние данные обработчика запросов ................................................................... 12
2.4
3
Повышение производительности запросов ................................................................................... 18
3.1
Выравнивание скоростей запросов ..................................................................................... 19
3.2
Анализ проблем, связанных с производительностью запросов ....................................... 20
3.3
Оптимизация измерений ...................................................................................................... 22
3.3.1
Определение связей атрибутов ....................................................................................... 23
3.3.2
Эффективное использование иерархий .......................................................................... 24
3.4
Максимизация выгоды от использования агрегатов ......................................................... 26
3.4.1
Обнаружение использования агрегатов ......................................................................... 26
3.4.2
Интерпретация агрегатов ................................................................................................. 27
3.4.3
Создание агрегатов ........................................................................................................... 28
3.5
Использование секций для повышения производительности запросов ......................... 31
3.5.1
Введение ............................................................................................................................ 32
3.5.2
Создание срезов секций ................................................................................................... 32
3.5.3
Рекомендации для агрегатов для нескольких секций ................................................... 33
3.5.4
Конструирование секции счетчика уникальных объектов (distinct count) ................... 34
3.5.5
Изменение размера секции ............................................................................................. 34
3.6
Оптимизация многомерных выражений............................................................................. 34
3.6.1
Диагностика проблемы .................................................................................................... 34
3.6.2
Рекомендации по вычислениям ...................................................................................... 35
3.7
Разогрев кэша ........................................................................................................................ 49
3.8
Повышение производительности в многопользовательском режиме ............................ 51
3.8.1
3
Получение данных................................................................................................................. 17
Повышение параллелизма запросов .............................................................................. 51
4
3.8.2
Тип кучи памяти................................................................................................................. 53
3.8.3
Блокировка длительных запросов................................................................................... 53
3.8.4
Балансировка сетевой нагрузки и базы данных, доступные только для чтения ........ 54
Основные сведения об обработке и измерении производительности обработки .................... 55
4.1
Общие сведения о задании обработки ............................................................................... 56
4.2
Обработка по базовому плану ............................................................................................. 56
4.2.1
Трассировка системного монитора ................................................................................. 56
4.2.2
Трассировка профайлера ................................................................................................. 57
4.3
5
Повышение производительности обработки измерений ............................................................. 58
5.1
Основные сведения об архитектуре обработки измерений ............................................. 59
5.2
Команды обработки измерений .......................................................................................... 61
5.3
Блок-схема настройки обработки измерений .................................................................... 63
5.4
Рекомендации по оптимизации производительности обработки измерений ............... 63
5.4.1
Использование представлений SQL для привязки запроса для измерений ............... 64
5.4.2
Оптимизация обработки атрибутов в нескольких источниках данных ........................ 64
5.4.3
Уменьшение служебных данных атрибутов ................................................................... 64
5.4.4
Эффективное использование свойств KeyColumns, ValueColumn и NameColumn....... 65
5.4.5
Удаление индексов битовой карты ................................................................................. 65
5.4.6
Отключение иерархии атрибута и использование свойств элементов ........................ 66
5.5
6
Настройка запроса на обработку реляционного измерения ............................................ 66
Повышение производительности обработки секций .................................................................... 67
6.1
Основные сведения об архитектуре обработки секций .................................................... 67
6.2
Команды обработки секций ................................................................................................. 68
6.3
Блок-схема настройки обработки секций ........................................................................... 69
6.4
Рекомендации по повышению производительности обработки секций ........................ 71
6.4.1
Оптимизация операций вставки, обновления и удаления данных .............................. 71
6.4.2
Выбор эффективных типов данных в таблицах фактов ................................................. 73
6.5
4
Выявление распределения времени обработки ................................................................ 58
Настройка запроса на обработку реляционных секций .................................................... 73
6.5.1
Избавление от соединений .............................................................................................. 74
6.5.2
Настройка реляционного секционирования .................................................................. 74
6.5.3
Настройка реляционного индексирования .................................................................... 75
6.5.4
7
8
5
Использование индекса FILLFACTOR = 100 и сжатия данных ........................................ 77
6.6
Устранение дополнительных временных затрат на блокировку базы данных ............... 78
6.7
Оптимизация пропускной способности сети ...................................................................... 79
6.8
Совершенствование подсистемы ввода-вывода ................................................................ 81
6.9
Увеличение параллелизма добавлением секций .............................................................. 81
6.10
Настройка максимального количества соединений .......................................................... 82
6.11
Настройка свойств ThreadPool и CoordinatorExecutionMode ............................................. 82
6.12
Настройка свойства BufferMemoryLimit .............................................................................. 83
6.13
Настройка свойства Process Index Phase .............................................................................. 84
6.13.1
Избегайте сброса временных данных на диск ............................................................... 84
6.13.2
Устранение узких мест ввода-вывода ............................................................................. 85
6.13.3
Добавление секций для увеличения параллелизма ..................................................... 85
6.13.4
Настройка потоков и AggregationMemorySettings .......................................................... 85
Настройка ресурсов сервера ............................................................................................................ 87
7.1
Использование настройки PreAllocate ................................................................................. 87
7.2
Отключение «Черного ящика» ............................................................................................. 88
7.3
Отслеживание и настройка памяти сервера ....................................................................... 88
Заключение ........................................................................................................................................ 89
1 Введение
Поскольку повышение скорости обработки запросов службами Microsoft® SQL Server® Analysis
Services является слишком обширной темой, в данном техническом документе методы
повышения скорости обработки запросов рассматриваются в трех разделах.
Повышение производительности запросов — производительность запросов влияет на степень
удовлетворения ожиданий конечного пользователя. Поэтому производительность запросов
используется для оценки оперативной аналитической обработки OLAP. Службы Analysis Services
предоставляют ряд механизмов, позволяющих увеличить производительность запросов, включая
статистическую обработку, кэширование и извлечение индексированных данных. Кроме того,
производительность запросов можно улучшить путем оптимизации атрибутов измерений, кубов и
многомерных запросов (MDX).
Повышение производительности обработки — обработка является операцией обновления
данных в базе данных служб Anylisis Services. Чем выше производительность обработки, тем
раньше пользователи получат доступ к обновленным данным. Службы Analysis Services
предоставляют ряд механизмов, с помощью которых можно повлиять на производительность
обработки, включая эффективное построение измерений, эффективную статистическую
обработку, секции и экономичную стратегию обработки (например, добавочное обновление
вместо полного, обновление вместо упреждающего кэширования).
Настройка ресурсов сервера — существует несколько параметров ядра, которые можно настроить
и повлиять тем самым как на производительность запросов, так и на производительность
обработки.
2 Основные сведения об архитектуре обработчика запросов
Для того чтобы построение запросов для конечных пользователей было максимально
эффективным, архитектура построения запросов служб Analysis Services предоставляет несколько
компонентов, работающих совместно для эффективного извлечения и оценки данных. На рис. 1
представлены три основные операции, выполняемые при обращении с запросом: управление
сеансом, выполнение запросов многомерных выражений и извлечение данных; также на рисунке
представлены серверные компоненты, участвующие в каждой из этих операций.
6
Рис. 1 Архитектура обработчика запросов служб Analysis Services
2.1 Управление сеансом
Клиентские приложения взаимодействуют со службами Analysis Services посредством XML для
аналитики (XMLA) по протоколам TCP/IP или HTTP. Службы Analysis Services предоставляют
компонент прослушивания XMLA, который обрабатывает XMLA-взаимодействие между службами
Analysis Services и их клиентами. Диспетчер сеансов служб Analysis Services управляет тем, как
клиенты соединяются с экземпляром служб Analysis Services. Пользователи, прошедшие проверку
подлинности Windows® и имеющие доступ хотя бы к одной базе данных, могут подключиться к
службам Analysis Services. После подключения к службам Analysis Services диспетчер безопасности
определяет права пользователя на основании сочетания ролей служб Analysis Services,
применимых к данному пользователю. В зависимости от архитектуры клиентского приложения и
прав безопасности для соединения клиент создает сеанс при запуске приложения и впоследствии
использует этот сеанс для отправки запросов. Сеанс предоставляет контекст, в котором
7
клиентские запросы исполняются обработчиком запросов. Сеанс существует до тех пор, пока он не
будет закрыт клиентским приложением или сервером.
2.2 Архитектура задания
Службы Analysis Services используют централизованную архитектуру заданий для реализации
запросов и обработки результатов. Задание — это основная единица обработки и выполнения
запроса. Задание может иметь несколько уровней вложенных дочерних заданий, в зависимости
от сложности запроса.
Например, во время операций обработки создается задание для обрабатываемого объекта,
такого как измерение. Задание измерения может затем включать несколько дочерних заданий,
обрабатывающих атрибуты в измерении. При отправке запроса задания используются для
извлечения из секции данных фактов и агрегатов, удовлетворяющих запросу. Например, если
имеется запрос, который получает доступ к нескольким секциям, создается родительское или
координирующее задание для самого запроса вместе с одним или несколькими дочерними
заданиями для каждой секции.
Рис. 2 Архитектура задания
Обычно одновременное выполнение нескольких заданий оказывает положительное влияние на
производительность, если имеются достаточные ресурсы процессора, позволяющие проводить
эффективную обработку одновременных операций, а также достаточное количество памяти и
дискового пространства. Максимальное количество заданий, которые могут выполняться
одновременно для текущей операции (включая обработку и обращение с запросом) определяется
свойством CoordinatorExecutionMode:
8
•
Отрицательное число указывает на максимальное количество параллельных заданий,
которые могут быть запущены на одном процессоре для одной операции.
•
Значение 0 обозначает отсутствие ограничений.
•
Положительное число указывает абсолютное количество параллельных заданий, которые
могут быть запущены на одном сервере.
Значением по умолчанию свойства CoordinatorExecutionMode является -4 и означает, что будут
запущены четыре задания на один процессор. Такое значение достаточно для большинства
серверных сред. Если необходимо поднять уровень параллелизма на сервере, можно увеличить
значение этого свойства как путем увеличения количества заданий на процессор, так и путем
установки для свойства абсолютного значения.
Свойство CoordinatorExecutionMode, отвечающее за общее количество заданий, которые могут
быть выполнены параллельно, не является единственным свойством, влияющим на параллельные
операции. Следует также учитывать влияние других универсальных параметров, например
свойства сервера MaxThreads, определяющего максимальное количество потоков отправки
запросов и обработки, выполняемых параллельно (дополнительные сведения о параметрах
потоков см. в разделе Повышение производительности в многопользовательском режиме). Кроме
того, при помощи команды MaxParallelможно задать максимальное количество заданий
обработки, выполняемых параллельно для конкретной операции обработки. Эти параметры
подробно описаны в следующих разделах.
2.3 Обработчик запросов
Обработчик запросов выполняет запросы многомерных выражений и возвращает набор ячеек или
набор строк. В этом разделе содержатся общие сведения о выполнении запросов обработчиком
запросов. Дополнительные сведения об оптимизации многомерных выражений см. в разделе
Оптимизация многомерных выражений.
Чтобы получить данные, запрошенные в запросе, обработчик запросов строит план выполнения
для получения запрошенных результатов на основе данных куба и вычислений. Существуют два
основных типа планов выполнения запроса; выбор того или другого плана обработчиком может
оказать серьезное влияние на производительность. Дополнительные сведения см. в разделе
Вычисление подпространства.
Для взаимодействия с подсистемой хранилища обработчик запросов использует план
выполнения, чтобы перевести запрос данных в один или несколько запросов к вложенному кубу,
понятных подсистеме хранилища. Вложенный куб — это логическая единица запроса,
кэширования и извлечения данных. Вложенный куб является подмножеством данных куба,
определенных перекрестным соединением одного или нескольких элементов с одного уровня
каждой иерархии атрибута. Один или несколько одноуровневых элементов также называются
одним зерном или единичной гранулярностью. Запрос многомерных выражений может быть
преобразован в несколько запросов к вложенному кубу, в зависимости от гранулярности
атрибутов и сложности вычислений. Например, запрос, включающий все элементы иерархии
атрибута Country (если она не является иерархией типа «родители-потомки»), будет разбит на два
запроса к вложенному кубу: один для всех элементов, второй для стран.
При вычислении ячеек обработчик запросов использует свой кэш для хранения результатов
вычислений. Основным преимуществом кэша является оптимизация вычислений и поддержка
повторного использования результатов вычислений для всех пользователей (имеющих
9
одинаковые роли безопасности). Для оптимизации повторного использования кэша обработчик
запросов выбирает один из трех уровней кэширования, определяющих использование кэша:
универсальный, сеансовый или уровень запроса.
2.3.1 Кэш обработчика запросов
При выполнении запроса многомерных выражений обработчик запросов сохраняет результаты
вычисления в кэше обработчика запросов. Основным преимуществом кэша является оптимизация
вычислений и поддержка повторного использования результатов вычислений для всех
пользователей. Чтобы понять, как обработчик запросов использует кэширование в ходе
выполнения запроса, рассмотрим следующий пример. Имеется вычисляемый элемент,
называемый коэффициентом прибыльности. Когда запрос многомерных выражений запрашивает
коэффициент прибыльности по территории продаж, обработчик запросов кэширует ненулевые
значения коэффициента прибыльности для каждой территории продаж. Для управления
повторным использованием кэшированных результатов для всех пользователей обработчик
запросов создает в кэше различные контексты.



Контекст запроса содержит результаты любых вычислений, созданных с использованием
ключевого слова WITH внутри запроса. Контекст запроса создается по запросу и
завершается после завершения запроса. Поэтому кэш контекста запроса не является
общим для всех запросов сеанса.
Контекст сеанса содержит результаты вычислений, созданные с использованием
инструкции CREATE в рамках данного сеанса. Кэш контекста сеанса повторно используется
запросами в рамках одного сеанса, однако не является общим для нескольких сеансов.
Универсальный контекст содержит результаты вычислений для всех пользователей. Кэш
универсального контекста является общим для всех сеансов, имеющих одинаковые роли
безопасности.
Контексты распределяются по уровням в зависимости от уровня повторного использования. На
верхнем уровне находится контекст запроса, который может быть использован только в пределах
одного запроса. На нижнем уровне находится универсальный контекст, имеющий самые большие
возможности повторного использования для нескольких сеансов и нескольких пользователей.
Рис. 3 Уровни контекста кэша
10
При выполнении каждый запрос многомерных выражений должен ссылаться все три контекста
для определения потенциальных вычислений и условий безопасности, которые могут оказать
влияние на вычисление запроса. Например, чтобы разрешить запрос, содержащий вычисляемый
элемент, обработчик запросов создает контекст запроса для разрешения вычисляемого элемента
запроса, контекст сеанса для проведения вычислений сеанса и универсальный контекст для
выполнения сценария многомерных выражений и получения прав безопасности пользователя,
направившего запрос. Обратите внимание, что контексты создаются только в случае, если они еще
не созданы. После построения контексты используются повторно, если это возможно.
Несмотря на то что один запрос ссылается на все три контекста, он может использовать кэш
только одного контекста. Это означает, что обработчик запросов должен выбрать, какой кэш будет
использован для данного конкретного запроса. Обработчик запросов всегда пытается
использовать более широкий кэш, в зависимости от того, находит или нет обработчик запросов
вычисления в более узком контексте.
Если обработчик запросов находит вычисления, созданные во время отправки запроса, он всегда
использует контекст запроса, даже если запрос также указывает на вычисления из универсального
контекста (существует одно исключение: запросы с вычисляемыми элементами в форме Aggregate
(<set>) используют кэш сеанса). Если вычисления запроса не найдены, а найдены
вычисления сеанса, обработчик запросов использует кэш сеанса. Обработчик запросов выбирает
кэш исходя из наличия в нем вычислений. Такое поведение особенно характерно для
пользователей, применяющих клиентские средства создания запросов многомерных выражений.
Если клиентское средство создает вычисления сеанса или запроса, универсальный кэш не
используется, даже если намеренно не используется вычисления сеанса или запроса.
Существуют другие сценарии вычислений, которые влияют на то, как обработчик запросов
кэширует вычисления. При вызове хранимой процедуры из многомерных выражений ядро всегда
использует кэш запроса. Это происходит потому, что хранимые процедуры являются
недетерминированными, т. е. нет никакой гарантии, какой результат вернет хранимая процедура.
В результате данные не будут кэшированы в универсальном или сеансовом контексте. И
наоборот, вычисления будут сохранены в кэше запроса. Помимо этого, следующие сценарии
определяют, каким образом обработчик запросов кэширует результаты вычислений.
11
•
Использование безопасности уровня ячеек, функций UserName, StrToSet или LookupCube в
сценарии многомерных выражений либо в определении безопасности ячейки или
измерения выключает универсальный кэш, т. е. одно выражение, использующее эти
функции, выключает универсальное кэширование для всего куба.
•
Если активировать визуальные итоги для сеанса путем установки значения 1 для свойства
default MDX Visual Mode в строке соединения со службами Analysis Services, обработчик
запросов использует кэш запроса для всех запросов, созданных во время этого сеанса.
•
Если активировать визуальные итоги для запроса при помощи функции многомерных
выражений VisualTotals, обработчик запросов будет использовать кэш запроса.
•
Запросы, использующие синтаксис подзапроса выборки (SELECT FROM SELECT), или
запросы, основанные на вложенном кубе сеанса (CREATE SUBCUBE), приводят к тому, что
используется кэш запроса или сеанса соответственно.
•
Произвольные формы могут использовать кэш запроса только в случае, если они
используются в подзапросе выборки, в инструкции WHERE или в вычисляемом элементе.
Произвольная форма — это любой набор, который не может быть представлен в виде
перекрестного соединения одноуровневых элементов иерархии атрибута. Например,
{(Food, USA), (Drink, Canada)} является произвольной формой, так же как и
{customer.geography.USA, customer.geography.[British Columbia]}. Обратите внимание, что
произвольная форма на оси запроса не ограничивает использование какого-либо кэша.
Исходя из такого поведения лучше определять вычисления в универсальном диапазоне, если
рабочая нагрузка запроса может использовать данные других пользователей. Примером такого
сценария является структурированная рабочая нагрузка отчетов, когда имеется небольшое
количество ролей безопасности. Напротив, если рабочая нагрузка требует индивидуальных
наборов данных для каждого пользователя, например куб кадровых данных, для которого
требуется большое количество ролей безопасности или используется динамическая безопасность,
возможность повторного использования результатов вычислений уменьшается или сводится к
нулю. В результате преимущества производительности, связанные с повторным использованием
кэша обработчика запросов, становятся не такими заметными.
Частичные выражения (т. е. часть вычисления, которая может быть использована более одного
раза в выражении) и свойства ячеек не кэшируются. Попробуйте создать отдельный вычисляемый
элемент так, чтобы обработчик запросов мог кэшировать результаты при первой оценке и
повторно использовать результаты в последующих запросах. Дополнительные сведения см. в
разделе Кэширование частичных выражений и свойств ячеек).
2.3.2 Внутренние данные обработчика запросов
В службах SQL Server 2008 Analysis Services произошло несколько изменений внутренних данных
обработчика запросов. В этом разделе будут рассмотрены эти изменения и описаны специальные
методы оптимизации.
2.3.2.1 Вычисление подпространства
Смысл вычисления подпространства лучше всего понять при сравнении с оценкой вычисления в
режиме «ячейка за ячейкой». Рассмотрим простое вычисление RollingSum, которое суммирует
продажи для предыдущего и текущего года, и запрос значения RollingSum за 2005 год для всех
товаров.
RollingSum = (Year.PrevMember, Sales) + Sales
SELECT 2005 on columns, Product.Members on rows WHERE RollingSum
12
Оценка такого вычисления в режиме «ячейка за ячейкой» выполняется в соответствии с
диаграммой на рис. 4.
Рис. 4 Оценка в режиме «ячейка за ячейкой»
Каждая из 10 ячеек для [2005, All Products] оценивается по очереди. Для каждой ячейки
потребуется перейти к предыдущему году, получить значение продаж и добавить его к продажам
за текущий год. Такой подход вызывает две серьезные проблемы производительности.
Во-первых, если данные разрежены (т. е. их немного), ячейки вычисляются, даже если они
возвращают нулевое значение. В приведенном выше примере вычисление ячеек для строки
Product 3 и Product 6 — пустая трата времени. Влияние этого может быть серьезным: в кубе с
разреженными значениями количество вычисляемых ячеек может отличаться на несколько
порядков.
Во-вторых, даже если данные имеют хорошую плотность, т. е. каждая ячейка имеет значение и
нет напрасной оценки абсолютно всех ячеек, оценка носит повторяющийся характер. Одна и та же
работа (например, получение элемента за предыдущий год, установка контекста для ячейки за
предыдущий год, проверка рекурсии) выполняется для каждого товара. Было бы гораздо более
эффективно вывести эту работу из внутреннего цикла оценки каждой ячейки.
Теперь рассмотрим этот же пример с применением вычисления подпространства. Во-первых,
можно считать, что работа сводится к продвижению по дереву выполнения, определяя, какое
пространство необходимо заполнить. Необходимо вычислить пространство исходя из запроса.
[Product.*, 2005, RollingSum]
13
(где знак * означает каждый элемент иерархии атрибута). При таком вычислении это означает, что
сначала нужно вычислить пространство
[Product.*, 2004, Sales],
затем пространство
[Product.*, 2005, Sales]
и применить оператор + к этим двум пространствам.
Если продажи вошли в вычисления, будут определены пространства, необходимые для
вычисления продаж, и дерево будет расширено. В этом случае продажи являются базовой мерой,
поэтому необходимо просто получить данные подсистемы хранилища, чтобы заполнить два
пространства в концевых узлах, затем выработать дерево, применив оператор для заполнения
пространства в корневом узле. Таким образом, извлекаются одна строка (Product3, 2004, 3) и две
строки { (Product3, 2005, 20), (Product6, 2005, 5)}, после чего к ним применяется оператор +,
который дает результат, приведенный на рис. 5.
Рис. 5 План выполнения
Оператор + работает с пространствами, а не просто со скалярными значениями. Он отвечает за
объединение двух пространств и создание пространства, содержащего каждый продукт,
присутствующий в одном из двух пространств, после суммирования. Это план выполнения
запроса. Обратите внимание, что обрабатываются только те данные, которые могут повлиять на
результат. Нет данных относительного теоретического пространства, для которого необходимо
выполнить вычисление.
14
План выполнения запроса может содержать узлы как в режиме подпространства, так и в режиме
«ячейка за ячейкой». Некоторые функции не поддерживаются в режиме подпространства, в
результате ядро переключается обратно в режим «ячейка за ячейкой». Однако даже во время
оценки выражения в режиме «ячейка за ячейкой» ядро может вернуться в режим
подпространства.
2.3.2.2 Сравнение ресурсоемких планов запросов с нересурсоемкими
Построение плана запроса может потребовать большого количества ресурсов. Потребление
ресурсов при построении плана выполнения может даже превышать потребление ресурсов при
выполнении запроса. Службы Analysis Services грубо классифицируют планы на ресурсоемкие или
нересурсоемкие. План считается ресурсоемким, если используется режим «ячейка за ячейкой»
либо если для построения плана требуется считывать данные куба. В противном случае план
выполнения считается нересурсоемким.
Данные куба используются в планах запросов в нескольких сценариях. Некоторые планы запросов
приводят к сопоставлению одного элемента с другим из-за использования функций многомерных
выражений, таких как PrevMember и Parent. Эти сопоставления строятся на основе данных куба и
материализуются в ходе построения планов запроса. Функции IIf, CASE и IF могут также привести к
созданию ресурсоемких планов запроса, если для секционирования пространства куба для оценки
одной из ветвей потребуется считывание данных куба. Дополнительные сведения см. в разделе
Функция IIf в службах SQL Server 2008 Analysis Services.
2.3.2.3 Разреженность выражения
Разреженность выражения выражается количеством ячеек с ненулевыми значениями по
сравнению с общим количеством ячеек. Если ненулевых значений относительно немного,
выражение считается разреженным. Если ненулевых значений много, выражение является
плотным. Как будет видно позднее, плотность выражения может оказать влияние на план
запроса.
Как можно определить плотность выражения? Рассмотрим простую невычисляемую меру — она
плотная или разреженная? В OLAP базовые меры фактов являются разреженными. Это означает,
что типичная мера не имеет значений для каждого элемента атрибута. Например, клиент не
покупает большую часть продуктов большее количество дней в большем количестве магазинов.
На самом деле все как раз наоборот. Обычный клиент приобретает небольшой процент всех
продуктов в немногих магазинах всего несколько дней в месяце. Ниже приводится ряд других
простых правил для часто используемых выражений.
Выражение
Обычная мера
Постоянное значение
Скалярное выражение, например счет,
свойства
<exp1>+<exp2>
15
Разреженное/плотное
Разреженное
Плотное (за исключением постоянных
значений NULL, значений true/false)
Плотное
Разреженное, если оба выражения exp1 и
<exp1>-<exp2>
<exp1>*<exp2>
<exp1> / <exp2>
Sum(<set>, <exp>)
Aggregate(<set>, <exp>)
IIf(<cond>, <exp1>, <exp2>)
exp2 являются разреженными; в противном
случае — плотное
Разреженное, если выражение exp1 или
выражение exp2 является разреженным; в
противном случае — плотное
Разреженное, если выражение <exp1>
является разреженным; в противном случае
— плотное
Наследуется от <exp>
Определяется степенью незаполненности
ветви по умолчанию (см. IIf)
2.3.2.4 Значения по умолчанию
Каждое выражение имеет значение по умолчанию, т. е. значение, которое выражение принимает
чаще всего. Обработчик запросов вычисляет значение выражения по умолчанию и повторно
использует его на всем пространстве. Большую часть времени значение равно NULL (пустое в
электронных таблицах Microsof Excel®), поскольку обычно (хотя и не всегда) результатом
выражения с входными значениями NULL является значение NULL. Ядро может вычислить пустой
результат один раз, а затем будет вычислять только значения на гораздо меньшем пространстве с
непустыми значениями.
Другая важная область применения значений по умолчанию — это в условии в функции IIf. Знание
того, какая ветвь оценивается чаще, определяет план выполнения. В следующей таблице
приводятся значения по умолчанию некоторых часто используемых выражений.
Выражение
Обычная мера
IsEmpty(<обычная мера>)
Значение по
умолчанию
NULL
True
<обычная мера A> = <обычная
мера B>
True
<элемент A> IS <элемент B>
False
16
Комментарий
Нет.
Большая часть теоретического
пространства заполнена значениями
NULL. Поэтому функция IsEmpty
возвращает значение True в
большинстве случаев.
Значения для обеих мер обычно равны
NULL, поэтому результат оценки равен
True в большинстве случаев.
Это отличается от сравнения значений
— ядро предполагает, что в
большинстве случаев сравниваются
разные элементы.
2.3.2.5 Переменные атрибуты
Значения ячеек главным образом зависят от координат атрибутов. Однако некоторые вычисления
не зависят от каждого атрибута. Например, выражение
[Customer].[Customer Geography].properties("Postal Code")
зависит только от атрибута Customer в измерении Customer. При оценке этого выражения
относительно подпространства с другими атрибутами любые атрибуты, от которых выражение не
зависит, могут быть удалены после того, как выражение будет разрешено и спроецировано
обратно на исходное подпространство. Атрибуты, от которых выражение зависит, считаются его
переменными атрибутами. Например, рассмотрим следующий запрос:
with member measures.Zip as
[Customer].[Customer Geography].currentmember.properties("Postal Code")
select measures.zip on 0,
[Product].[Category].members on 1
from [Adventure Works]
where [Customer].[Customer Geography].[Customer].&[25818]
Это выражение зависит от атрибута customer и не зависит от атрибута category, поэтому customer
является переменным атрибутом, а category не является. В этом случае выражение оценивается
для customer только один раз, а не столько, сколько имеется категорий товаров.
2.3.2.6 Внутренние данные обработчика запросов. Заключение
Планы запросов, степень незаполненности выражений, значения по умолчанию и переменные
атрибуты являются ключевыми внутренними данными, определяющими поведение обработчика
запросов. В дальнейшем эти элементы будут затронуты при рассмотрении оптимизации
производительности запросов.
2.4 Получение данных
При отправке запроса к кубу обработчик запросов разбивает запрос на запросы к вложенному
кубу подсистемы хранилища. Для каждого запроса к вложенному кубу подсистема хранилища
сначала пытается получить данные из кэша подсистемы хранилища. Если данные в кэше
недоступны, подсистема хранилища попытается получить данные из агрегата. Если агрегатов нет,
подсистема хранилища должна получить данные из данных фактов в секциях группы меры.
Каждая секция разделена на группы по 64К записей, которые называются сегментами.
17
Координирующее задание создается для каждого запроса к вложенному кубу. Создается столько
заданий, сколько имеется секций. (Это также верно, если запрос запрашивает данные,
расположенные в срезе секции. Дополнительные сведения см. в разделе Разделение секции на
срезы.) Каждое из этих заданий:

Выстраивается вслед за другим заданием для следующего сегмента (если текущий сегмент
не является последним).

Использует индексы битовых карт, чтобы определить, есть ли данные в сегменте,
соответствующем запросу вложенного куба.

Просматривает сегмент, если в нем есть данные.
После того как задание каждого сегмента поставлено в очередь, для отдельной секции структура
задания выглядит следующим образом.
Рис. 6. Структура
Структура задания
заданияпросмотра
просмотрасекций
секций
Сразу после того, как задание сегмента поставлено в очередь, оно стартует другие задания
сегментов, поэтому заданий ровно столько, сколько сегментов. Если индексы обнаружат, что в
сегменте нет данных, соответствующих вложенному кубу, задание завершается.
3 Повышение производительности запросов
Чтобы повысить производительность запросов, вначале необходимо понять текущую ситуацию,
проанализировать узкие места и затем применить один из нескольких методов, включая
оптимизацию построения измерений, разработку и построение агрегатов, секционирование и
применение лучших рекомендаций.
Можно много времени потратить впустую. Важно сначала понять природу проблемы, прежде чем
применять специфические методы.
18
3.1 Выравнивание скоростей запросов
Прежде чем приступить к оптимизации, следует определить воспроизводимый базовый план.
Снимите измерения на холодной (т. е. не заполненной значениями) подсистеме хранилища, кэшах
обработчика запросов и на теплом кэше операционной системы. Для этого выполните запрос,
очистите кэши подсистемы хранилища и формул и запустите сценарий путем выполнения запроса,
который ничего не возвращает и не кэширует, как описано ниже.
select {} on 0 from [Adventure Works]
Выполните этот запрос второй раз. При выполнении запроса во второй раз используйте
приложение SQL Server Profiler, чтобы выполнить трассировку с дополнительными включенными
событиями:


Обработка запросов\подробные сведения о запросе к вложенному кубу
Обработка запросов\получение данных из агрегата
Трассировка содержит важные сведения.
Рис. 6 Образец трассировки
Текст для события запроса вложенного куба (Query Subcube Verbose) заслуживает пояснения.
Текст содержит сведения для каждого атрибута в каждом измерении:



19
0 указывает, что атрибут не включен в запрос (выбран элемент All).
* указывает, что каждый элемент атрибута был запрошен.
+ указывает, что были запрошены два или более элемента атрибута.

<целочисленное значение> указывает, что был получен один элемент атрибута. Целое
число представляет собой идентификатор данных элемента (внутренний
идентификатор, созданный ядром).
Сохраните эту трассировку, поскольку она содержит важные сведения о времени и указывает на
события, которые будут описаны далее.
Чтобы очистить кэши хранилища и обработчика запросов, используйте команду ClearCache.
<ClearCache xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>Adventure Works DW</DatabaseID>
</Object>
</ClearCache>
На файловый кэш операционной системы оказывает влияние все, что работает на оборудовании,
— постарайтесь уменьшить или свести к нулю другие процессы. Это может быть особенно трудно
сделать, если куб хранится в сети хранения данных (SAN), используемой другими приложениями.
Среда SQL Server Management Studio показывает время запросов, однако будьте осторожны.
Время — это количество времени, потраченное на получение и отображение набора ячеек. Для
больших результатов время подготовки к просмотру набора ячеек может превосходить время,
потребовавшееся серверу для их формирования. Трассировка приложения SQL Server Profiler
содержит не только сведения о том, на что было потрачено время, но и точную длительность
работы ядра.
3.2 Анализ проблем, связанных с производительностью запросов
Когда производительность оставляет желать лучшего, источник проблемы может находиться в
разных областях. На рис. 8 показано, как можно определить источник проблемы.
20
storage engine
No
Optimize
Dimensions
No
Define
Aggregations
Query
Processor or
Storage
Engine
Dimensions
Optimized?
MDX
Optimized
No
Yes
Yes
Aggregations
Hit?
Yes
Partitions
Optimized
query processor
Yes
Optimize MDX
Fragmented
Query Space
Yes
No
Warm Cache
Memory Bound
No
No
Optimize
Partitions
CPU Bound
No
Yes
Preallocate or add
memory
Yes
Add CPU or Read
only database
I/O Bound
Yes
No
Improve I/O or
scale out (multiuser only)
Increase Query
Parallelism
Рис. 7 Блок-схема настройки производительности запросов
Первый шаг — определить, порождается проблема обработчиком запросов или подсистемой
хранилища. Чтобы определить количество времени, в течение которого подсистема
просматривает данные, используйте приложение SQL Server Profiler для создания трассировки.
Ограничьте события некэшируемыми извлечениями данных из подсистемы хранилища, выбрав
только подробные сведения о вложенном кубе запроса и отфильтровав их по событию
subclass=22. Результат будет схож с представленным на рис. 9.
21
Рис. 8 Определение времени, затраченного на просмотр секций
Если основная часть времени затрачена в подсистеме хранилища вместе с событиями вложенного
куба запроса, то проблема, скорее всего, связана с подсистемой хранилища. Попробуйте
оптимизировать измерение, агрегаты или использовать секции для улучшения
производительности запросов. Если основная часть времени затрачена не в подсистеме
хранилища, а в обработчике запросов, сфокусируйте внимание на оптимизации многомерных
выражений.
Проблема может быть связана как с формулой, так и с подсистемой хранилища.
Фрагментированное пространство запросов можно проанализировать при помощи профайлера,
если создается много событий вложенного куба запроса. Каждый запрос может длиться недолго,
но вместе они могут занять длительное время. Если проблема в этом, попробуйте «разогреть»
кэш, чтобы уменьшить количество операций ввода-вывода, порождающих проблему.
Некоторые проблемы, связанные с производительностью работы в многопользовательском
режиме, могут быть разрешены путем работы с запросами одного пользователя, но определенно
не все. Некоторые параметры конфигурации, характерные для многопользовательских сред,
описываются в разделе Повышение производительности работы в многопользовательском
режиме.
Если куб оптимизирован, можно попробовать оптимизировать использование ресурсов памяти и
ЦП. Способы повышения количества потоков для однопользовательского и
многопользовательского сценариев описываются в разделе Повышение уровня параллелизма
запросов. Эти же методы можно использовать для резервирования памяти и улучшения
производительности запросов и обработки; их подробное описание приводится в разделе
Использование PreAllocate.
Производительность можно также повысить путем увеличения ресурсов ЦП, памяти или
подсистемы ввода-вывода. Такие рекомендации не входят в область рассмотрения настоящего
руководства. Существуют другие способы, доступные для кластеров или баз данных, доступных
только для чтения. Эти методы кратко описываются в следующих разделах, чтобы пользователь
мог понять, может ли это быть причиной возникшей проблемы.
Наблюдение за использованием памяти рассматривается в отдельном разделе Наблюдение и
настройка использования памяти сервера.
3.3 Оптимизация измерений
Правильная конструкция измерения — это один из наиболее важных факторов высокой
производительности решения для служб Analysis Services. Один из первых шагов по улучшению
производительности куба заключается в изучении измерений и связей атрибутов. Ниже
22
приводятся два самых важных способа оптимизации структуры измерения для повышения
производительности запросов:

Определение связей атрибутов.

Эффективное использование пользовательских иерархий.
3.3.1 Определение связей атрибутов
Связи атрибутов определяют функциональные зависимости между атрибутами. Другими словами,
если А имеет связанный атрибут В, в записи А  B, существует один элемент в В для каждого
элемента в А и много элементов в А для данного элемента в В. Более конкретно, если связь
атрибутов City  State и если текущий город — Сиэтл, ясно, что штатом должен быть Вашингтон.
Часто существуют связи между атрибутами, которые могут или не могут быть объявлены в
исходной таблице измерения, используемой подсистемой служб Analysis Services для
оптимизации производительности. По умолчанию все атрибуты связаны с ключом, а схема связей
атрибутов представляет «куст», в котором все связи исходят от ключевого атрибута и
заканчиваются у каждого другого атрибута.
Рис. 9 Кустообразные связи атрибутов
Производительность можно оптимизировать путем определения связей, поддерживаемых
данными. В этом случае имя модели определяет линию товаров и подкатегорию, а подкатегория
определяет категорию (другими словами, одна подкатегория не может находиться более чем в
одной категории). После определения связей в редакторе связей атрибутов получается
следующее.
23
Рис. 10 Переопределенные связи атрибутов
Связи атрибутов помогают повысить производительность следующими двумя способами.

Выстраиваются индексы, поэтому перекрестным произведениям не нужно проходить
через ключевой атрибут.

Агрегаты, построенные на атрибутах, могут быть использованы повторно для связанных
атрибутов.
Обратите внимание на перекрестные произведения подкатегории и категории на двух рисунках,
приведенных выше. На первом рисунке, где связи атрибутов не определены явным образом,
подсистема должна сначала определить, какие товары находятся в каждой подкатегории, а затем
определить, к каким категориям относятся эти товары. Для больших измерений это может занять
очень много времени. Если связь атрибутов определена, подсистема служб Analysis Services знает
заранее, к какой категории принадлежит каждая подкатегория благодаря индексам, построенным
во время обработки.
При определении связи атрибутов тип связи может быть гибким или жестким. Гибкая связь
атрибутов — это такая связь, при которой элементы могут перемещаться при обновлении
измерения, а жесткая связь атрибутов гарантирует фиксированное положение элемента.
Например, связь между месяцем и годом является фиксированной, потому что отдельно взятый
месяц не может изменить свой год при обновлении измерения. Однако связь между клиентом и
городом может быть гибкой, поскольку клиент может переехать. (Стоит заметить, что
определение агрегата в качестве гибкого или жесткого не оказывает влияния на
производительность запросов.)
3.3.2 Эффективное использование иерархий
Атрибуты, отображаемые только в иерархиях атрибутов, не включаются автоматически в агрегаты
мастером статистических схем. Запросы, использующие такие атрибуты, возвращают суммарные
данные по первичному ключу. Без использования агрегатов производительность запросов с
такими иерархиями атрибутов может быть низкой.
24
Чтобы повысить производительность, можно назначить атрибут в качестве кандидата для
агрегата, используя свойство Использование агрегата. Дополнительные сведения об этом способе
см. в разделе Определение кандидатов для агрегата. Однако, прежде чем изменять свойство
Использование агрегата, стоит попробовать использовать пользовательские иерархии.
Службы Analysis Services позволяют строить два типа пользовательских иерархий: естественные и
искусственные иерархии, каждая из которых имеет разные характеристики производительности и
структуру.
В естественной иерархии все атрибуты, участвующие в качестве уровней в иерархии, имеют
прямые или косвенные связи атрибутов сверху донизу иерархии.
В искусственной иерархии имеется по крайней мере два последовательных уровня, не имеющие
связей атрибутов. Обычно такие иерархии используются для создания углубленной детализации
открытых атрибутов, которые не следуют естественной иерархии. Например, пользователи могут
просмотреть иерархию пола и образования.
Рис. 11 Естественные и искусственные иерархии
С точки зрения производительности поведение естественных иерархий отличается от
искусственных иерархий. В естественных иерархиях дерево иерархии материализуется на диске в
хранилище иерархии. Помимо этого, атрибуты, участвующие в естественных иерархиях,
автоматически считаются кандидатами для создания агрегатов.
Искусственные иерархии не материализуются на диске, а атрибуты, участвующие в искусственных
иерархиях, не считаются автоматически кандидатами для создания агрегатов. Скорее всего, они
просто предоставляют пользователям удобные пути для углубленной детализации для открытых
атрибутов, которые не имеют естественных связей. Путем сбора таких атрибутов в иерархии
можно использовать разные навигационные функции многомерных выражений для быстрого
проведения вычислений, например доля в процентах от родительского объекта.
Чтобы воспользоваться естественными иерархиями, определите каскадные связи атрибутов для
всех атрибутов, участвующих в иерархии.
25
3.4 Максимизация выгоды от использования агрегатов
Агрегат — это заранее вычисленная сводка данных, которую службы Analysis Services используют
для повышения производительности запросов.
Конструирование агрегатов — это процесс выбора наиболее эффективных агрегатов для рабочей
нагрузки, связанной с запросами. Во время разработки агрегатов следует учитывать преимущества
для запросов, обеспечиваемые агрегатами, по сравнению с временем, требуемым для их
создания и обновления. Добавление ненужных статистических схем может ухудшить
производительность, поскольку нечастые вызовы перемещают агрегат в файловый кэш за счет
вымещения какого-либо другого элемента.
В то время как агрегаты физически разрабатываются на одну секцию группы мер, методы
оптимизации для максимального увеличения статистических схем применяются независимо от
того, используется одна или несколько секций. В этом разделе агрегаты рассматриваются в
фундаментальном контексте куба с одной группой мер и одной секцией, если не предполагается
иное. Дополнительные сведения о том, как повысить производительность запросов при помощи
нескольких секций, см. в разделе Использование секций для повышения производительности
запросов.
3.4.1 Обнаружение использования агрегатов
Используйте приложение SQL Server Profiler, чтобы просмотреть, как и когда агрегаты были
использованы для удовлетворения запросов. В приложении SQL Server Profiler существует
несколько событий, описывающих ход выполнения запроса. Событие, которое относится к
попаданиям агрегатов, — это событие Получение данных из агрегата.
Рис. 12 Сценарий 1. Трассировка приложения SQL Server Profiler для куба с
использованием агрегата
На рис. 13 показана трассировка приложения SQL Server Profiler разрешения запроса для куба с
агрегатами. В трассировке приложения SQL Server Profiler отображаются операции, которые
выполняет подсистема хранилища для получения результирующего набора.
Подсистема хранилища получает данные из агрегата C 0000, 0001, 0000, как
показывает событие Получение данных из агрегата. Помимо имени агрегата, агрегат
C, на рис. 13 также показан вектор, 000, 0001, 0000, который описывает содержимое
26
агрегата. Дополнительные сведения о том, что фактически этот вектор означает,
приводятся в следующем разделе Интерпретация агрегатов.
Данные агрегатов загружаются в кэш группы мер подсистемы хранилища, откуда
обработчик запросов их получает и возвращает результирующий набор клиенту.
На рис. 14 показана трассировка приложения SQL Server Profiler для того же самого запроса и куба,
однако на этот раз куб не имеет агрегатов, удовлетворяющих запросу.
Рис. 14. Сценарий 2. Трассировка приложения SQL Server Profiler для куба без использования
агрегата
После отправки запроса вместо того, чтобы получить данные из агрегата, подсистема хранилища
обращается к подробным данным в секции. С этого момента процесс повторяется. Данные
загружаются в кэш группы мер подсистемы хранилища.
3.4.2 Интерпретация агрегатов
Когда службы Analysis Services создают агрегат, каждое измерение получает имя вектора, который
определяет, указывает ли атрибут на атрибут или на уровень All. Уровень атрибута представлен
значением 1, а уровень All — значением 0. Рассмотрим следующие примеры векторов агрегатов
для измерения товара.



Агрегат по атрибуту ProductKey= [Product Key]:1 [Color]:0 [Subcategory]:0 [Category]:0 или
1000
Агрегат по атрибуту Category = [Product Key]:0 [Color]:0 [Subcategory]:0 [Category]:1 или
0001
Агрегат по ProductKey.All и Color.All и Subcategory.All и Category.All = [Product Key]:0
[Color]:0 [Subcategory]:0 [Category]:0 или 0000
Чтобы идентифицировать каждый агрегат, службы Analysis Services объединяют векторы
измерений в один длинный векторный путь, также называемый вложенный куб, при этом каждый
вектор измерения отделяется запятой.
Порядок измерений в векторе определяется порядком измерений в кубе. Чтобы определить
порядок измерений в кубе, используйте один из следующих способов. Если куб открыт в среде
SQL Server Business Intelligence Development Studio, порядок измерений в кубе можно просмотреть
на вкладке Структура куба. Порядок измерений в кубе отображается в области «Измерения».
Также порядок измерений можно просмотреть в виде списка в XMLA-определении куба.
27
Порядок атрибутов в векторе для каждого измерения определяется порядком атрибутов в
измерении. Порядок атрибутов в каждом измерении можно определить путем просмотра XMLфайла измерения.
Например, следующее определение вложенного куба (0000, 0001, 0001) описывает агрегат для
следующего:

Product — All, All, All, All

Customer — All, All, All, State/Province

Order Date — All, All, All, Year
Понимание того, как читать эти векторы, полезно при просмотре попаданий агрегатов в
приложении SQL Server Profiler. В приложении SQL Server Profiler посмотреть, как вектор
сопоставляется с определенными атрибутами измерения, можно путем включения события
Подробные сведения о запросе вложенного куба.
3.4.3 Создание агрегатов
Чтобы позволить службам Analysis Services успешно применять алгоритм конструирования
агрегатов, можно применить следующие методы оптимизации, чтобы повысить качество
конструкции агрегата. (В следующих разделах эти методы рассматриваются более подробно.)
Определение кандидатов для создания агрегата — когда в службах Analysis Services
разрабатываются агрегаты, алгоритм конструирования агрегатов не включает автоматически
каждый атрибут в агрегат. Поэтому при разработке куба следует проверить атрибуты, которые
включаются в агрегат, и решить, стоит ли добавлять дополнительные кандидаты для создания
агрегата.
Указание статистики о данных куба — чтобы сделать интеллектуальную оценку ресурсных затрат
на агрегаты, алгоритм схемы анализирует статистику куба для каждого кандидата в агрегаты.
Примеры этих метаданных включают счетчики элементов и таблиц фактов. Обновление
метаданных может повысить эффективность статистической схемы.
Оптимизация на основе использования — чтобы сконцентрировать агрегаты на определенном
шаблоне использования, выполните запросы и запустите мастер оптимизации с учетом
использования.
3.4.3.1 Определение кандидатов для создания агрегата
Когда в службах Analysis Services разрабатываются агрегаты, алгоритм конструирования агрегатов
не включает автоматически каждый атрибут в агрегат. Чтобы систематизировать этот процесс,
службы Analysis Services используют свойство Использование агрегатов для определения того,
какие атрибуты следует включить. Для каждой группы мер следует проверить атрибуты, которые
автоматически включаются в агрегат, и решить, стоит ли добавлять дополнительные кандидаты
для создания агрегата.
Правила использования агрегата
28
Кандидат для создания агрегата — это атрибут, который службы Analysis Services включают в
потенциальный агрегат. Чтобы определить, является ли какой-либо атрибут кандидатом для
создания агрегата, подсистема хранилища использует значение свойства Использование агрегата.
Свойству Использование агрегата назначается атрибут куба, поэтому оно применимо глобально
ко всем группам мер и секциям в кубе. Для каждого атрибута в кубе свойство Использование
агрегата может принимать одно из четырех значений: Полное, Отсутствует, Неограниченно и По
умолчанию.
Полное— каждый агрегат для куба должен включать этот атрибут или связанный атрибут,
находящийся ниже в цепочке атрибутов. Например, имеется измерение товаров со следующей
цепочкой связанных атрибутов: товар, подкатегория товара и категория товара. Если задать
свойству Использование агрегата для категории товара значение Полное, службы Analysis Services
могут создать агрегат, который будет включать подкатегорию товара в противовес категории
товара, если подкатегория товара связана с категорией и может быть использована для получения
итоговых значений категории.
Отсутствует— агрегат для куба не может включать этот атрибут.
Неограниченно— конструктор агрегатов не получает каких-либо ограничений, однако атрибут
должен быть оценен, чтобы можно было определить, является ли он ценным кандидатом для
создания агрегата.
По умолчанию — конструктор применяет правило по умолчанию на основе типа атрибута и
измерения. Это значение по умолчанию для свойства Использование агрегата.
Правило по умолчанию очень консервативно в отношении того, какие атрибуты включаются в
агрегат. Правило по умолчанию подразделяется на четыре ограничения.
Ограничение по умолчанию 1— неограниченно — для атрибута гранулярности группы мер
измерения значением по умолчанию является Неограниченно. Атрибут гранулярности совпадает с
ключевым атрибутом измерения, если группа мер объединяется с измерением при помощи
атрибута первичного ключа.
Ограничение по умолчанию 2 — отсутствует для специальных типов измерений — для всех
атрибутов (за исключением All) в измерениях «многие ко многим», нематериализованных
ссылочных измерений и измерений интеллектуального анализа данных, значением по умолчанию
является Отсутствует.
Ограничение по умолчанию 3 — неограниченно для естественных иерархий — естественная
иерархия — это пользовательская иерархия, в которой все атрибуты, участвующие в иерархии,
содержат связи атрибутов с атрибутом, который является исходным для следующего уровня. Для
таких атрибутов значением по умолчанию является Неограниченно, за исключением атрибутов,
не подлежащих агрегированию, для которых установлено значение Полное (даже если они не
присутствуют в пользовательской иерархии).
29
Ограничение по умолчанию 4 — отсутствует для всех остальных атрибутов. Для всех остальных
атрибутов измерений значением по умолчанию является Отсутствует.
3.4.3.2 Оказание влияния на кандидатов для включения в агрегат
В силу природы свойства Использование агрегата руководствуйтесь следующими
соображениями.
Атрибуты, представленные только как иерархии атрибутов — если конкретный атрибут
представлен только как иерархия атрибутов, например «цвет», может потребоваться изменить
для него значение свойства Использование агрегата следующим образом.
Во-первых, замените для свойства Использование агрегата значение По умолчанию на значение
Неограниченно, если атрибут является часто используемым либо если есть особые соображения
по улучшению производительности сведения или углубленной детализации. Например, если
имеются суммарные оценочные листы с отчетами, может потребоваться, чтобы пользователи
получили сразу быстрый отклик на первый запрос, прежде чем они будут углубляться в детали.
Задание для свойстваИспользование агрегата определенной иерархии атрибутов значения
Неограниченно уместно в некоторых случаях, однако не стоит задавать всем иерархиям атрибутов
значение Неограниченно. Увеличение числа включаемых атрибутов обостряет проблему
пространства, которую должен учитывать алгоритм атрибута. Мастеру может понадобиться по
крайней мере час, чтобы завершить конструирование, и значительно больше времени, чтобы
обработать результаты. Задавайте для этого свойства значение Неограниченно только для часто
используемых иерархий атрибутов. По общему правилу следует задавать от пяти до десяти
атрибутов со значением Неограниченно на одно измерение.
Затем замените для свойства Использование агрегата значениеПо умолчанию на значение
Полное в том невероятном случае, если он используется практически в каждом запросе, который
необходимо оптимизировать. Это очень редкий случай, и такое изменение следует выполнять
только для тех атрибутов, которые имеют относительно небольшое количество элементов.
Редко используемые атрибуты — для атрибутов, участвующих в естественных иерархиях, может
потребоваться изменить для свойства Использование агрегата значение По умолчанию на
значение Отсутствует, если пользователи используют их лишь изредка. Такой подход позволяет
уменьшить пространство агрегата и получить от пяти до десяти атрибутов со значением
Неограниченно на одно измерение. Например, можно использовать определенные атрибуты,
которые применяются только некоторыми продвинутыми пользователями, намеренно идущими
на снижение производительности. В этом случае пользователь фактически вынуждает алгоритм
конструирования агрегатов тратить время только на построение агрегатов, которые обеспечивают
наибольшую эффективность большинству пользователей.
Алгоритм конструирования агрегатов оценивает затраты ресурсов/преимущества каждого
агрегата на основе счетчиков элементов и записей в таблице фактов. Обновление метаданных
может повысить эффективность статистической схемы. Счетчик записей в таблице фактов можно
30
определить в свойстве EstimatedRows для каждой группы мер, а счетчик элементов атрибута — в
свойстве EstimatedCount каждого атрибута.
3.4.3.3 Оптимизация на основе использования
Мастер оптимизации с учетом использования просматривает запросы в журнале запросов
(который должен быть подготовлен заранее) и разрабатывает агрегаты, которые охватывают 100
самых медленных запросов. Используйте мастер оптимизации с учетом использования и
получайте 100%-ный выигрыш в производительности, так как мастер позволяет разрабатывать
агрегаты, которые избегают попадания напрямую в секцию.
После окончания конструирования агрегатов их можно добавить в существующую схему или
полностью заменить схему. Будьте осторожны при добавлении агрегатов в существующую схему:
две схемы могут содержать агрегаты, которые служат практически одинаковым целям, а при
объединении будут мешать друг другу. Просмотрите новые агрегаты, сравните их со старыми и
убедитесь, что нет практически одинаковых агрегатов. В среде SQL Server Management Studio или
Business Intelligence Development Studio статистическую схему можно скопировать в другие
секции.
Статистические схемы повышают требовательность метаданных к ресурсам. Старайтесь
уменьшить количество статистических схем на одну групп мер.
3.4.3.4 Агрегаты и иерархии типа «родители-потомки»
В иерархиях типа «родители-потомки» агрегаты создаются только для ключевого атрибута и
атрибута верхнего уровня (например, атрибута All), если он не отключен. Воздержитесь от
использования иерархий типа «родители-потомки», содержащих большое количество элементов.
(Какое количество считается большим? Точного числа нет, потому что производительность
запроса на промежуточных уровнях иерархии типа «родители-потомки» уменьшается линейно
вместе с количеством элементов.) Помимо этого, ограничьте количество иерархий типа
«родители-потомки» в кубе.
В проекте, где участвует крупная иерархия типа «родители-потомки», стоит изменить исходную
схему, чтобы частично или полностью реорганизовать иерархию в обычную, с фиксированным
числом уровней. После реорганизации данных в пользовательскую иерархию можно
использовать свойство Скрыть элемент, если для каждого уровня, чтобы скрыть лишние или
отсутствующие элементы.
3.5 Использование секций для повышения производительности запросов
Секции разделяют данные групп мер на физические единицы. Эффективное использование
секций помогает повысить производительность запросов, улучшить производительность
обработки и облегчить управление данными. В этом разделе рассматривается использование
секций для улучшения производительности запросов. До окончания разработки стратегии
секционирования следует уравновесить преимущества и затраты ресурсов между
производительностью запросов и производительностью обработки.
31
3.5.1 Введение
Можно использовать несколько секций, чтобы разбить группу мер на отдельные физические
компоненты. Преимуществами секционирования для повышения производительности запросов
являются следующие.

Создание срезов секций: секции, не содержащие данных во вложенном кубе, не получают
запросов. Таким образом экономятся ресурсы, необходимые для считывания индекса (или
сканирование таблицы в режиме ROLAP, когда нет индексов MOLAP).

Статистическая схема: каждая секция может иметь собственную или общую
статистическую схему. Таким образом, секции, обращение к которым идет чаще или
разнообразнее, могут иметь собственные схемы.
Рис. 15. Интеллектуальная отправка запросов по секциям
На рис. 15 показана трассировка профайлера для запроса, запрашивающего объем продаж
торговых посредников по типу компании из куба Adventure Works. Группа мер «Товарооборот
посредников» из куба Adventure Works содержит четыре секции: по одной на каждый год.
Поскольку запрос выполняется за 2003 год, подсистема хранилища может обращаться прямо к
секции продаж посредников за 2003 год и не обрабатывать другие секции.
3.5.2 Создание срезов секций
Секции привязаны к исходной таблице, представлению или исходному запросу. Для секций
MOLAP во время обработки службы Analysis Services внутренне определяют диапазон данных,
которые содержатся в каждой секции путем использования минимального и максимального
значений данных каждого атрибута для вычисления диапазона данных, которые содержатся в
секции. Затем диапазон данных для каждого атрибута объединяется для создания определения
среза секции. Зная это, подсистема хранилища может решить, какие секции необходимо
просматривать при запросе, и выбирает только те секции, которые имеют отношение к запросу.
Для секций ROLAP и секций упреждающего кэширования определить срез в свойствах секции
необходимо вручную.
32
Минимальный и максимальный идентификаторы данных могут указывать на отдельный элемент
или диапазон. Например, секционирование по годам дает одинаковые значения минимального и
максимального идентификаторов данных среза для атрибута «год», и запрос отправляется
определенному моменту во времени, т. е. только в секцию нужного года.
Важно помнить, что срез секции поддерживается в качестве диапазона идентификаторов данных,
которым нельзя явно управлять. Идентификаторы данных получаются во время обработки
измерения по мере нахождения новых элементов. Если они выходят за пределы таблицы
измерения, то внутренняя последовательность идентификаторов данных может отличаться от
ключей атрибутов. Это может привести к излишним операциям считывания секций. Поэтому
самостоятельное определение среза для секций MOLAP может быть эффективнее. Например, если
выполняется секционирование по годам так, что некоторые секции содержат диапазоны лет,
определение среза явным образом помогает избежать проблему перекрытия данных.
При использовании нескольких секций для одной группы мер убедитесь, что выполняется
обновление статистических данных для каждой секции. Более конкретно, важно убедиться, что
данные секции и счетчики элементов точно отражают конкретные данные этой секции, а не
данные по всей группе мер.
Обратите внимание, что срез не определяется, а индексы не выстраиваются для разделов,
содержащих количество строк меньше, чем IndexBuildThreshold (значение по умолчанию равно
4 096).
3.5.3 Рекомендации для агрегатов для нескольких секций
При определении секций помните, что они не должны содержать однообразные наборы данных
или статистические схемы. Например, для определенной группы мер можно задать 3 годовые
секции, 11 месячных секций, 3 недельные и от 1 до 7 дневных секций. Смысл использования
разнородных секций с разными уровнями детализации заключается в том, что так удобнее
управлять загрузкой новых данных без использования ненужных секций (более подробно об этом
в следующем разделе) и благодаря этому можно разрабатывать агрегаты для групп секций,
имеющих общий уровень сведений.
Для каждой секции можно использовать отдельную статистическую схему. Такая гибкость
позволяет определить наборы данных, которые требуют более сложных статистических схем.
Рассмотрим следующий пример. В кубе с несколькими секциями для месяцев новые данные
могут поступить в одну секцию, соответствующую последнему месяцу. Обычно это именно та
секция, к которой поступает наибольшее число запросов. Общая стратегия агрегатов в этом случае
заключается в выполнении оптимизации на основе использования наиболее свежей секции,
оставляя без изменений более старые и редко запрашиваемые секции.
Самая новая статистическая схема может быть скопирована в базовую секцию. Эта базовая секция
не содержит данных, она служит только для того, чтобы хранить текущую статистическую схему.
Когда приходит время добавить новую секцию (например, в начале нового месяца), базовая
33
секция может быть клонирована в новую. После определения среза на новой секции она готова
принимать данные в качестве текущей секции. После изначального полного процесса текущая
секция может дополнительно обновляться до конца периода.
3.5.4 Конструирование секции счетчика уникальных объектов (distinct count)
Секции уникальных объектов являются особенными. Когда секции уникальных объектов получают
запрос, задания каждого сегмента секции должны координировать свою работу, чтобы избежать
подсчета одних и тех же элементов. Например, если при подсчете разных клиентов один и тот же
идентификатор потребителя находится в нескольких секциях, задания секций должны распознать
совпадение, чтобы не учитывать одного потребителя более одного раза.
Если каждая секция содержит неперекрывающийся диапазон значений, такой координации
заданий можно избежать, а производительность запросов может улучшиться от 20 до 300
процентов!
Дополнительные сведения об оптимизации подсчета числа уникальных объектов см. в
техническом документе «Подсчет числа уникальных объектов в службах Analysis Services»,
доступном по следующей ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=65df6ebf-9d1c-405f-84b108f492af52dd&displaylang=ru
3.5.5 Изменение размера секции
Для групп мер, содержащих не только уникальные значения, тестирование с секциями,
имеющими размер от 200 МБ до 3 ГБ, показало, что сам по себе размер секции не оказывает
существенного влияния на скорость запросов. Стратегия секционирования должна учитывать
следующие факторы:

Повышение скорости обработки и гибкость

Повышение управляемости доставки новых данных

Повышение производительности запросов за счет устранения секций

Поддержка разных статистических схем
3.6 Оптимизация многомерных выражений
Отладка производительности вычислений в кубе может быть сложной, если вычислений много.
Первым делом стоит попробовать сузить область появления проблемы, а затем применить
рекомендации к многомерным выражениям.
3.6.1 Диагностика проблемы
Диагностика проблемы может быть быстрой, если простой запрос приводит к определенному
вычислению (в этом случае переходите к следующему разделу), однако, если есть несколько
цепочек выражений или сложный запрос, для нахождения проблемы может потребоваться время.
34
Попробуйте уменьшить запрос до простейшего выражения так, чтобы этот запрос по-прежнему
вызывал проблему. При использовании клиентских приложений сам запрос может быть
проблемой, если ему требуются большие объемы данных и выполняется излишняя детализация (в
обход агрегатов) либо если запрос содержит вычисления в обход универсального кэша и кэша
сеанса обработчика запросов.
Если подтвердится, что проблема находится в кубе, удалите или закомментируйте все вычисления
из куба. Это включает следующее:

Нестандартные формулы элементов

Унарные операторы

Сценарии многомерных выражений (за исключением инструкции вычисления, которую не
следует изменять)
Повторите запрос. Возможно, его потребуется изменить, чтобы учесть отсутствие некоторых
элементов. Выполняйте вычисления до тех пор, пока проблема снова не проявит себя.
3.6.2 Рекомендации по вычислениям
В этом разделе приводится ряд рекомендаций, которые следует применять для повышения
производительности запросов из куба.
3.6.2.1 Сравнение режима «ячейка за ячейкой» с режимом подпространства
Практически всегда производительность, получаемая в режиме подпространства, выше
производительности, получаемой в режиме «ячейка за ячейкой». Дополнительные сведения,
включая список функций, поддерживаемых в режиме подпространства, см. в разделе
«Повышение производительности многомерных выражений в службах SQL Server 2008 Analysis
Services» электронной документации по SQL Server, доступной по следующей ссылке:
http://msdn.microsoft.com/ru-ru/library/bb934106(SQL.100).aspx
В следующей таблице приводятся наиболее частые причины отказа от режима подпространства.
Характеристика или
функция
Задание псевдонимов
Комментарий
Замените выражением набора, а не псевдонимом. Например,
следующий запрос выполняется в режиме подпространства:
with
member measures.SubspaceMode as
sum(
[Product].[Category].[Category].members,
[Measures].[Internet Sales Amount]
)
select
{measures.SubspaceMode,[Measures].[Internet Sales
Amount]} on 0 ,
35
[Customer].[Customer Geography].[Country].members on 1
from [Adventure Works]
сell properties value
однако почти такой же запрос, в котором набор заменен псевдонимом,
выполняется в режиме «ячейка за ячейкой».
with
set y as [Product].[Category].[Category].members
member measures.Naive as
sum(
y,
[Measures].[Internet Sales Amount]
)
select
{measures.Naive,[Measures].[Internet Sales Amount]} on 0
,
[Customer].[Customer Geography].[Country].members on 1
from [Adventure Works]
cell properties value
Позднее связывание в
функциях
LinkMember, StrToSet,
StrToMember,
StrToValue
Функции позднего связывания — это функции, которые зависят от
контекста запросов и не могут быть оценены статически. Например,
следующий код является статически связанным:
with member measures.x as
(strtomember("[Customer].[Customer
Geography].[Country].&[Australia]"),[Measures].[Internet
Sales Amount])
select measures.x on 0,
[Customer].[Customer Geography].[Country].members on 1
from [Adventure Works]
cell properties value
Запрос имеет позднее связывание, если его аргумент может быть
вычислен только в контексте:
with member measures.x as
(strtomember([Customer].[Customer
Geography].currentmember.uniquename),[Measures].[Internet
Sales Amount])
select measures.x on 0,
[Customer].[Customer Geography].[Country].members on 1
from [Adventure Works]
cell properties value
Определяемые
пользователем
хранимые процедуры
LookupCube
36
Широко распространенные функции Microsoft Visual Basic® для
приложений (VBA) и Excel внутренне поддерживаются в многомерных
выражениях. Определяемые пользователем хранимые процедуры
вычисляются в режиме «ячейка за ячейкой».
Связанные группы мер часто представляют собой лучшую альтернативу.
3.6.2.2 Функция IIf в службах SQL Server 2008 Analysis Services
Функция многомерных выражений IIf — это часто используемое выражение, которое может быть
ресурсозатратным для вычисления. Подсистема оптимизирует производительность на основе
нескольких простых критериев. Функция IIf принимает три аргумента:
iif(<условие>, <ветвь then>, <ветвь else>)
Если результат вычисления равен true, используется значение из ветви then, в противном случае
значение из ветви else.
Обратите внимание на ключевое слово «used»: одна или обе ветви могут быть вычислены, даже
если их значения не используются. Подсистеме может быть проще вычислить выражение
относительно всего пространства и использовать его при необходимости — это называется
активный план, — чем разрезать пространство на потенциально огромное количество
фрагментов и вычислять только там, где это необходимо, — строгий план.
Примечание. Одной из наиболее распространенных ошибок в сценариях на основе многомерных
выражений является использование функции IIf, когда условие зависит от координат ячейки, а не
от значения. Если условие зависит от координат ячейки, используйте области и назначения. После
этого условие не вычисляется относительно пространства и подсистема не оценивает одну или
две ветви относительно всего пространства. Возможно, в некоторых случаях использование
назначений приводит к громоздкому повторению назначений, однако всегда стоит сначала
сравнить оба подхода.
Первое, на что следует обратить внимание, — это является план запроса ресурсозатратным или не
является. Большинство планов запросов с условием IIf не являются ресурсозатратными, однако
сложные вложенные условия с большим количеством функций IIf могут привести к
последовательному просмотру ячейки за ячейкой.
Следующее, на что обращает внимание подсистема, — это какое значение условие принимает
наиболее часто. Это зависит от значения условия по умолчанию. Если значение условия по
умолчанию равно true, ветвь then является ветвью по умолчанию, т. е. ветвью, которая
оценивается для большей части подпространства. Знание нескольких простых правил о том, как
оценивается условие, позволит определить ветвь по умолчанию.
37

В разреженных выражениях большинство ячеек пустые. Значением функции IsEmpty по
умолчанию в разреженном выражении является true.

Операция сравнения с нулем разреженного выражения возвращает значение true.

Значением по умолчанию оператора IS является false.

Если условие не может быть оценено в режиме подпространства, ветвь по умолчанию
отсутствует.
Например, функция IIf очень часто используется для проверки, является ли знаменатель
ненулевым значением.
iif([Measures].[Internet Sales Amount]=0, NULL, [Measures].[Internet Order
Quantity]/[Measures].[Internet Sales Amount])
Вычисление объема продаж через Интернет (Internet Sales Amount) не производится, поэтому
выражение является разреженным. Таким образом, значением условия по умолчанию является
true, а ветвь по умолчанию — это ветвь then с нулевым выражением.
В следующей таблице показано, как оценивается каждая ветвь функции IIf.
План запроса для ветви
Ветвь
является
ветвью по
умолчанию
Степень
незаполненности
выражений
ветви
Ресурсозатратное
Не
Не применяется
применяется
Строгий
Нересурсозатратное
True
Не применяется
Активный
Нересурсозатратное
False
Плотное
Строгий
Нересурсозатратное
False
Разреженное
Активный
Вычисление
В службах SQL Server 2008 Analysis Services поведение по умолчанию можно заменить
подсказками в запросах.
iif(
[<условие>
, <ветвь then> [подсказка [активный | строгий]]
, <ветвь else> [hint [Eager | Strict]]
)
Когда нужно переопределить поведение по умолчанию? Ниже приводятся наиболее часто
возникающие случаи, когда может потребоваться изменить поведение по умолчанию.
 Подсистема определяет, является ли план запроса для условия ресурсозатратным, и
вычисляет каждую ветвь в строгом режиме.
 Условие вычисляется в режиме «ячейка за ячейкой», а каждая ветвь вычисляется в
активном режиме.
 Выражение ветви является плотным, однако его несложно вычислить.
38
Например, обратите внимание на следующее простое выражение, которое принимает обратное
значение меры.
with member
measures.x as
iif(
[Measures].[Internet Sales Amount]=0
, NULL
, (1/[Measures].[Internet Sales Amount]) )
select {[Measures].x} on 0,
[Customer].[Customer Geography].[Country].members *
[Product].[Product Categories].[Category].members on 1
from [Adventure Works]
cell properties value
План запроса не является ресурсозатратным, ветвь else не является ветвью по умолчанию, а
выражение плотное, поэтому оно вычисляется в строгом режиме. Это заставляет подсистему
материализовать пространство, относительно которого выполняется вычисление. Это можно
просмотреть в приложении SQL Server Profiler, выбрав события подробного отображения
сведений запросов к вложенному кубу, как показано на рис. 16.
39
Рис. 16. Трассировка запроса IIf по умолчанию
Обратите внимание, что определение вложенного куба для измерения Product и Customer
(измерения 7 и 8 соответственно) имеет знак + в атрибутах Country и Category. Это означает, что
включено более одного, но не все элементы. Обработчик запросов определил, какие кортежи
удовлетворяют условию, разделил пространство и вычисляет долю относительно этого
пространства.
Чтобы план запроса не секционировал пространство, запрос следует изменить следующим
образом (выделено жирным шрифтом).
with member
measures.x as
iif(
[Measures].[Internet Sales Amount]=0
, NULL
, (1/[Measures].[Internet Sales Amount]) hint eager)
select {[Measures].x} on 0,
[Customer].[Customer Geography].[Country].members *
[Product].[Product Categories].[Category].members on 1
from [Adventure Works]
cell properties value
40
Рис. 17. Трассировка IIf с подсказками в запросе многомерных выражений
Теперь одинаковые атрибуты отмечены звездочкой *, что значит, что выражение вычисляется
относительно всего пространства, а не относительно секционированного пространства.
3.6.2.3 Свойства кэширования частичных выражений и ячеек
Частичные выражения (т. е. те, которые являются частью вычисляемого элемента или назначения)
не кэшируются. Поэтому, если ресурсозатратное второстепенное выражение используется более
одного раза, попробуйте создать отдельный вычисляемый элемент, который обработчик запросов
смог бы кэшировать и использовать повторно. Рассмотрим следующий пример.
this = iif(<ресурсозатратное выражение>= 0, 1/<сложное выражение>, NULL);
Повторяемые частичные выражения могут быть удалены и заменены скрытым вычисляемым
элементом, как показано ниже.
create member currentcube.measures.MyPartialExpression as <ресурсозатратное
выражение> , visible=0;
this = iif(measures.MyPartialExpression >= 0, 1/ measures.MyPartialExpression, NULL);
Кэшируется только свойство ячейки значения. Если имеются сложные свойства ячейки, которые
поддерживают такие элементы, как подсветка появляющихся исключений, попробуйте создать
отдельную вычисляемую меру. Например, вместо
41
create member currentcube.measures.[Value] as <exp> , backgroundColor=<сложное
выражение>;
выполните следующее:
create member currentcube.measures.MyCellPrope as <сложное выражение> , visible=0;
create member currentcube.measures.[Value] as <exp> , backgroundColor=<сложное
выражение>;
3.6.2.4 Избегайте имитации компонентов ядра с помощью выражений
Некоторые встроенные компоненты можно имитировать при помощи многомерных выражений.

Унарные операторы

Вычисляемые столбцы в представлении источника данных (DSV)

Выражения мер

Полуаддитивные меры
Эти компоненты можно воспроизвести в сценариях MDX (на самом деле иногда это обязательно,
поскольку некоторые из них поддерживаются только в Enterprise SKU), однако это часто оказывает
негативное влияние на производительность.
Например, распределительные унарные операторы (т. е. операторы, порядок элементов которых
не имеет значения, например +, - и ~) обычно работают вдвое быстрее, чем имитация их
возможностей с помощью присваиваний.
Существуют редкие исключения. Например, можно попробовать повысить производительность
нераспределительных унарных операторов (использующих операторы *, / или числовые
значения) при помощи многомерных выражений. Кроме того, пользователь может знать
некоторые особые характеристики своих данных, которые позволят ему повысить
производительность.
3.6.2.5 Удаление переменных атрибутов из выражений набора
Выражения набора не поддерживают переменные атрибуты. Это оказывает влияние на все
функции, включая Filter, Aggregate, Avg и др. Этой проблемы можно избежать, явным образом
назначив неизменяемые атрибуты каждому элементу.
42
Например, в этом вычислении подсчитывается среднее значение продаж, включающее только
продажи свыше 100 долларов.
with member measures.AvgSales as
avg(
filter(
descendants([Customer].[Customer Geography].[All Customers],,leaves)
, [Measures].[Internet Sales Amount]>100
)
,[Measures].[Internet Sales Amount]
)
select measures.AvgSales on 0,
[Customer].[Customer Geography].[City].members on 1
from [Adventure Works]
Это занимает 2,29 секунды на переносном компьютере, т. е. достаточно много времени. Но
среднее значение продаж для всех потребителей во всех городах не зависит от текущего города
(это всего лишь еще один способ сказать, что этот город не является переменным атрибутом).
Можно явным образом удалить город как переменный атрибут, заменив его элементом all, как
показано ниже.
with member measures.AvgSales as
avg(
filter(
descendants([Customer].[Customer Geography].[All Customers],,leaves)
, [Measures].[Internet Sales Amount]>100
)
,[Measures].[Internet Sales Amount]
)
43
member measures.AvgSalesWithOverWrite as (measures.AvgSales, root([Customer]))
select measures.AvgSalesWithOverWrite on 0,
[Customer].[Customer Geography].[City].members on 1
from [Adventure Works]
Это занимает менее одной секунды, что значительно быстрее.
3.6.2.6 Избегайте присваивать непустые значения непустым ячейкам
Модуль служб Analysis Services очень эффективно удаляет пустые строки. Добавление вычислений
с непустыми значениями, заменяющими значения NULL, не позволяет службам Analysis Services
удалять эти строки. Например, следующий запрос заменяет значения NULL знаком дефиса,
поэтому ключевое слово non empty не удаляет их.
with member measures.x as
iif( not isempty([Measures].[Internet Sales Amount]),[Measures].[Internet Sales
Amount],"-")
select descendants([Date].[Calendar].[Calendar Year].&[2004] ) on 0,
non empty [Customer].[Customer Geography].[Customer].members on 1
from [Adventure Works]
where measures.x
Свойство non empty взаимодействует со значениями ячеек, а не с форматированными
значениями. В редких случаях можно использовать строку форматирования для замены значений
NULL таким же символом, одновременно удаляя пустые строки и столбцы примерно в половине
случаев.
with member measures.x as
[Measures].[Internet Sales Amount], FORMAT_STRING = "#.00;(#.00);#.00;-"
select descendants([Date].[Calendar].[Calendar Year].&[2004] ) on 0,
non empty [Customer].[Customer Geography].[Customer].members on 1
from [Adventure Works]
44
where measures.x
Причина, по которой этот метод используется только в редких случаях, заключается в том, что
запрос не является эквивалентным, второй запрос удаляет полностью пустые строки. Что еще
более важно, ни Excel, ни службы Reporting Services не поддерживают четвертый аргумент в
format_string. Дополнительные сведения об использовании свойства вычисления format_string см.
в разделе «Содержание FORMAT_STRING (MDX)» электронной документации по SQL Server,
доступном по следующей ссылке:
http://msdn.microsoft.com/ru-ru/library/ms146084.aspx
3.6.2.7 Снижение затрат ресурсов для вычисления форматированных
значений
В некоторых случаях затраты ресурсов на определение строки форматирования для выражения
превышают затраты ресурсов на получение самого значения. Чтобы определить, относится ли это
к медленному запросу, сравните его время выполнения с использованием свойства ячейки
форматированного значения и без его использования, как показано в примере ниже.
select [Measures].[Internet Average Sales Amount] on 0 from [Adventure Works] cell
properties value
Если результат заметно быстрее без форматирования, примените форматирование напрямую к
сценарию, как показано ниже.
scope([Measures].[Internet Average Sales Amount]);
FORMAT_STRING(this) = "currency";
end scope;
И выполните запрос (с применением форматирования), чтобы определить выигрыш в
производительности.
3.6.2.8 Рекомендации относительно разреженных и плотных выражений c
использованием «expr1 * expr2»
При написании выражений, использующих результаты двух других выражений, поставьте более
разреженное выражение слева.
45
Обратите внимание на следующие два запроса, которые включают конвертацию валюты и
применение обменного курса к измерению даты в кубе Adventure Works. Единственное отличие
заключается в изменении порядка выражений в результирующем вычислении ячейки. Результаты
совпадают, однако использование сначала более разреженных продаж через Интернет приводит
к экономии примерно в 10 %. (Это немного в данном случае, но может быть значительно больше в
других случаях. Экономия зависит от относительной степень незаполненности двух выражений,
поэтому выигрыш в производительности колеблется.)
Сначала разреженное выражение
with cell CALCULATION x for '({[Measures].[Internet Sales Amount]},leaves([Date]))'
as
[Measures].[Internet Sales Amount] *
([Measures].[Average Rate],[Destination Currency].[Destination Currency].&[EURO])
select
non empty [Date].[Calendar].members on 0,
non empty [Product].[Product Categories].members on 1
from [Adventure Works]
where ([Measures].[Internet Sales Amount], [Customer].[Customer Geography].[StateProvince].&[BC]&[CA])
Сначала плотное выражение
with cell CALCULATION x for '({[Measures].[Internet Sales Amount]},leaves([Date]))'
as
([Measures].[Average Rate],[Destination Currency].[Destination Currency].&[EURO])*
[Measures].[Internet Sales Amount]
select
non empty [Date].[Calendar].members on 0,
non empty [Product].[Product Categories].members on 1
from [Adventure Works]
46
where ([Measures].[Internet Sales Amount], [Customer].[Customer Geography].[StateProvince].&[BC]&[CA])
3.6.2.9 Сравнение объектов и значений
Для определения того, является ли текущий элемент или кортеж указанным объектом,
используйте функцию IS. Например, следующий запрос не только показывает низкую
производительность, он еще и составлен неверно. В примере навязывается излишнее вычисление
ячеек и сравнение значений вместо элементов.
[Customer].[Customer Geography].[Country].&[Australia] = [Customer].[Customer
Geography].currentmember
К тому же не выполняйте дополнительные шаги при определении, является ли аргумент
CurrentMember отдельным элементом, с помощью функций Intersect и Counting.
intersect({[Customer].[Customer Geography].[Country].&[Australia]},
[Customer].[Customer Geography].currentmember).count > 0
Выполните следующее:
[Customer].[Customer Geography].[Country].&[Australia] is [Customer].[Customer
Geography].currentmember
3.6.2.10
Оценка принадлежности к набору
Определить, находится ли элемент или кортеж в наборе, проще всего с помощью функции
Intersect. Функция Rank выполняет дополнительную операцию и определяет, где конкретно в
наборе находится объект. Если в этом нет нужды, не используйте эту функцию. Например, вместо
этого
rank( [Customer].[Customer Geography].[Country].&[Australia],
<выражение набора> )>0
47
Выполните следующее:
intersect({[Customer].[Customer Geography].[Country].&[Australia]}, <set>
).count > 0
3.6.2.11
Попробуйте перенести вычисления в реляционный модуль
Иногда для повышения производительности вычисления можно переносить в реляционный
модуль и обрабатывать как простые статистические выражения. В данном случае единого
решения не существует, но при возникновении проблем с производительностью необходимо
учитывать возможности решения вычисления в базе данных-источнике или представлении
источника данных с предварительным заполнением, а не вычисления во время выполнения
запроса.
Например, вместо написания выражений типа Sum(Customer.City.Members,
cint(Customer.City.Currentmember.properties(“Population”))) попробуйте определить отдельную
группу мер для таблицы City с суммарной мерой в столбце Population.
В качестве второго варианта можно вычислить произведение доходов на количество проданных
товаров в концевых узлах и провести статистическую обработку с вычислениями. Вычисление
этого результата в базе данных-источнике или в представлении источника данных повысит
производительность.
3.6.2.12
NON_EMPTY_BEHAVIOR
В некоторых ситуациях вычисление результата выражения требует больших затрат ресурсов, даже
если мы заранее знаем на основании значения какого-либо кортежа индикатора, что он будет
равен NULL. Свойство NONEMPTY_BEHAVIOR иногда помогает в такого рода вычислениях. Если
данное свойство равно NULL, то выражение гарантированно равно NULL (в большинстве случаев) и
наоборот.
Данное свойство часто обеспечивало существенное повышение производительности в прошлых
версиях. В SQL Server 2008 это свойство нередко пропускается (поскольку во многих случаях
обработчик автоматически обрабатывает непустые ячейки) и иногда может привести к снижению
производительности. Исключите его из сценария многомерных выражений и добавьте его вновь
после того, как тестирование производительности покажет улучшение.
Свойство используется для назначений следующим образом.
this = <e1>;
Non_Empty_Behavior(this) = <e2>;
48
Для вычисляемых элементов в сценарии многомерных выражений это свойство используется
следующим образом.
create member currentcube.measures.x as <e1>, non_empty_behavior = <e2>
В службах SQL Server 2005 Analysis Services использовались сложные правила определения
свойства, условий его использования или пропуска обработчиком и способа его использования
обработчиком. В службах SQL Server 2008 Analysis Services поведение данного свойства
изменилось:



Оно остается гарантией того, что если NON_EMPTY_BEHAVIOR равно NULL, то и выражение
равно NULL. (Если это не так, могут возвращаться неверные результаты запроса.)
Однако обратное не всегда верно, т. е. выражение NON_EMPTY_BEHAVIOR может
возвращать отличное от NULL значение при значении исходного выражения NULL.
Обработчик в большинстве случаев не учитывает данное свойство и самостоятельно
выводит установленное поведение выражения.
Если свойство определено и применено обработчиком, то оно семантически эквивалентно
(однако не эквивалентно по производительности) следующему выражению.
this = <e1> * iif(isempty(<e2>), NULL, 1)
Свойство NON_EMPTY_BEHAVIOR используется, если <e2> равно sparse и <e1> равно dense или
<e1> вычисляется в упрощенном режиме ячейка за ячейкой. Если эти условия не выполняются и
оба, <e1> и <e2>, являются разреженными (т. е. <e2> является более разреженным, чем <e1>),
повышения производительности можно добиться следующим принудительным поведением.
this = iif(isempty(<e2>), NULL, <e1>);
Свойство NON_EMPTY_BEHAVIOR можно выразить в виде простого кортежного выражения,
включая простые функции навигации по элементам, такие как .prevmember или .parent, или
перечислимый набор. Перечислимый набор эквивалентен NON_EMPTY_BEHAVIOR для
результирующей суммы.
3.7 Разогрев кэша
При выполнении запроса память используется прежде всего для хранения кэшированных
результатов в кэшах подсистемы хранилища и обработчика запросов. Для совершенствования
преимуществ кэширования можно уменьшить время отклика на запрос посредством
предварительной загрузки данных в один или оба кэша. Это можно делать либо посредством
предварительного выполнения одного или более запросов, либо посредством использования
инструкции CREATE CACHE. Этот процесс называется разогревом кэша.
49
Оба механизма аналогичны друг другу, хотя у инструкции CREATE CACHE есть преимущество — она
не возвращает значения ячеек и в целом выполняется быстрее, поскольку не задействован
обработчик запросов.
Определение данных, которые необходимо кэшировать, может представлять сложность. Один из
подходов — запуск трассировки при выполнении запроса и изучение событий вложенных кубов.
Обнаружение большого числа запросов вложенных кубов к одинаковому уровню детализации
может означать, что обработчик запросов выполняет множество запросов для немного
различающихся данных, что приводит к тому, что подсистема хранилища осуществляет массу
мелких, но трудоемких запросов ввода-вывода там, где было бы эффективнее получить данные
массивом, а затем возвратить результаты из кэша.
Для предварительного выполнения запросов можно создать приложение, выполняющее набор
обобщенных запросов, для имитации активности типичного пользователя с целью исследования
процесса заполнения кэша. Например, если вы определили, что пользователи выполняют запрос
по месяцу и по продукту, то можно создать набор запросов, запрашивающих данные по продукту
и месяцу. Если запустить такой запрос при запуске службы Analysis Services или обработке группы
мер или одной из ее секций, то этот набор запросов предварительно загрузит кэш результатов
запроса теми данными, которые понадобятся для выполнения таких запросов еще до того, как
пользователи сформируют эти типы запросов. Эта методика существенно сокращает время ответа
службы Analysis Services на запросы пользователя, которые ожидались таким набором запросов.
Для определения набора обобщенных запросов можно использовать журнал запросов службы
Analysis Services, чтобы установить атрибуты измерения, обычно запрашиваемые в
пользовательских запросах. Можно использовать приложение типа макроса Microsoft Excel или
файл сценария для разогрева кэша после выполнения операции, сбрасывающей на диск кэш
результатов запроса. Например, это приложение может выполняться автоматически по окончании
этапа обработки кубов.
При проверке эффективности различных запросов, разогревающих кэш, необходимо очищать кэш
результатов запроса между проверками, чтобы обеспечить достоверность проверки.
Следует отметить, что кэшированные результаты могут вытесняться другими результатами
запроса. Может потребоваться обновление результатов кэша согласно определенному
расписанию. Кроме того, необходимо ограничить разогрев кэша объемом данных, который
помещается в память, оставляя достаточно пространства для кэширования других запросов.
Агрессивный просмотр данных
Возможно, при вычислении выражения запрашивается большее количество данных, чем
необходимо для определения результата.
Если есть подозрение, что извлекается больше данных, чем необходимо, можно использовать
приложение SQL Server Profiler для диагностики того, как запрос просматривает события
вложенного куба и секции. При просмотрах вложенного куба проверьте подробное событие
50
вложенного куба и проверьте, не извлекается ли из подсистемы хранилища больше элементов,
чем необходимо. Для малых кубов это вряд ли составит проблему. Для более крупных кубов с
несколькими секциями это может существенно снижать производительность запросов. На
следующем рисунке показано, как одно событие вложенного куба запроса приводит к просмотру
секции.
Рис. 18. Агрессивный просмотр секции
Существует два потенциальных решения. Если выражение для вычисления содержит
произвольную форму (определяется в разделе, посвященном кэшу обработчика запросов), то
обработчик запросов не в состоянии определить, что данные ограничены одной секцией, и
запрашивает данные из всех секций. Попробуйте избегать произвольных форм.
В других случаях обработчик запросов попросту чрезвычайно активно запрашивает данные. Для
малых кубов это не имеет особого значения, а для более крупных кубов это грозит
неприятностями. При обнаружении такого поведения обратитесь в службу поддержки
пользователей корпорации Майкрософт.
3.8 Повышение производительности в многопользовательском режиме
Во многих случаях причины низкой производительности многопользовательской режима могут
крыться в низкой производительности однопользовательского режима. Но это не всегда так. В
некоторых случаях службы Analysis Services не используют все ресурсы компьютера при
увеличении количества пользователей. Существует несколько способов повышения
производительности.
3.8.1 Повышение параллелизма запросов
Для управления клиентскими подключениями при выполнении запроса службы Analysis Services
используют поток прослушивания для передачи запросов и создания новых серверных
соединений (при необходимости). Для удовлетворения требований запросов поток
прослушивания управляет рабочими потоками в пуле потоков запросов и в пуле потоков
обработки, назначает рабочие потоки определенным запросам, запускает новые рабочие потоки в
случае недостаточного количества активных рабочих потоков в данном пуле и завершает рабочие
процессы при необходимости.
Для удовлетворения требований запросов пулы потоков используются следующим образом.

51
Рабочие потоки из пула запросов проверяют кэш данных и вычислений соответственно для
любых данных и/или вычислений, имеющих отношение к запросу клиента.

При необходимости рабочие потоки из пула обработки выделяются для получения данных
с диска.

После получения данных рабочие потоки из пула запросов сохраняют результаты в кэше
запросов для выполнения будущих запросов.

Рабочие потоки из пула запросов выполняют необходимые вычисления и используют кэш
вычислений для хранения результатов вычисления.
Чем больше потоков доступно для удовлетворения запросов, тем больше запросов можно
выполнять в параллельном режиме. Это особенно важно в сценариях, где многочисленные
пользователя формируют запросы.
Threadpool\Query\MaxThreads определяет максимальное количество рабочих потоков,
поддерживаемых в пуле потоков запроса. По умолчанию для данного свойства устанавливается
значение, равное 10 или удвоенному числу ядер (в этом заключается отличие от SQL Server 2005,
поэтому необходимо проверять данное значение для обновленных экземпляров). Увеличение
Threadpool\Query\MaxThreads не приведет к существенному увеличению производительности
запроса. Однако большее значение этого свойства позволяет увеличить число одновременно
обслуживаемых запросов.
Поскольку выполнение запросов также включает получение данных из секций, необходимо
учитывать максимальное количество доступных потоков в пуле обработки, которое указывается в
свойстве Threadpool\Process\MaxThreads . В SQL Server 2005 это свойство по умолчанию равно 64.
Это значение изменено в SQL Server 2008 на 64- или 10-кратное количество ядер, в зависимости от
того, какая величина больше (и является рекомендуемым в настоящий момент значением). При
рассмотрении сценариев изменения свойства Threadpool\Process\MaxThreads помните, что
изменение данной настройки влияет на пул потоков обработки как для запросов, так и для
обработки. Дополнительные сведения о том, как это свойство влияет на операции обработки, см.
в разделе Настройка потоков.
Поскольку изменение свойств Threadpool\Process\MaxThreads и Threadpool\Query\MaxThreads
может повысить параллелизм обработки запросов, необходимо также учитывать дополнительный
эффект параметра CoordinatorExecutionMode. Рассмотрим следующий пример. Если используется
сервер с 4 процессорами и принимается значение по умолчанию параметра
CoordinatorExecutionMode, равное -4, то для всех операций сервера одновременно может
выполняться 16 заданий. Поэтому, если параллельно выполняются 10 запросов, которым в сумме
необходимо 20 заданий, одновременно можно запустить только 16 заданий (предполагается, что
в это время не выполняются операции обработки). Если достигается пороговое количество
заданий, последующие задания ожидают в очереди до момента, когда станет возможным создать
новое задание. Таким образом, если узким местом операции является количество заданий,
увеличение числа потоков необязательно приведет к повышению общей производительности.
52
На практике балансировка заданий и потоков может оказаться непростой задачей. Для
повышения параллелизма важно найти наиболее критичное с точки зрения параллелизма узкое
место, например количество одновременно выполняемых заданий, или число параллельных
потоков, или оба эти параметра. Для их определения необходимо наблюдать за следующими
счетчиками производительности:



Threads\Query pool job queue length — число заданий в очереди пула потоков запросов.
Значение, отличное от NULL, означает, что число запросов превысило число доступных
потоков запроса. В этом случае можно увеличить число потоков запроса. Однако, если
уровень загрузки ЦП уже слишком высок, увеличение числа потоков будет способствовать
добавлению переключений контекста и падению производительности.
Threads\Query pool busy threads — число занятых потоков в пуле потоков запросов.
Threads\Query pool busy threads — число бездействующих потоков в пуле потоков
запросов.
Дополнительные сведения см. по адресу
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/ssasqptb.mspx.
3.8.2 Тип кучи памяти
Пропускную способность многопользовательской работы можно увеличить использованием кучи
Windows вместо кучи служб Analysis Services. Такое увеличение пропускной способности может
привести к небольшому, но измеримому увеличению стоимости для однопользовательских
запросов, однако пропускная способность многопользовательской работы увеличивается почти на
100 % (т. е. за тот же промежуток времени обрабатывается вдвое больше запросов).
Существенные выигрыш в пропускной способности для многопользовательской работы обычно
перевешивает затраты на производительность однопользовательской работы. Для использования
диспетчера кучи NTLFH вместо диспетчера кучи OLAP необходимо изменить следующие
параметры.
Настройка
Значение по умолчанию.
MemoryHeapType
HeapTypeForObjects
1
1
Многопользовательская
работа
2
0
3.8.3 Блокировка длительных запросов
В многопользовательских сценариях долго выполняющиеся запросы могут ограничивать
выполнение других запросов (даже более быстро выполняющихся запросов), задействуя все
доступные потоки, а также могут блокировать выполнение других запросов до тех пор, пока не
будет завершено выполнение долго выполняющегося запроса. Можно снижать активность
использования запросов каждым заданием координатора, изменяя порядок каждого из заданий
сегмента в очереди. Как описано в разделе Получение данных, каждое задание сегмента
незамедлительно ставится в очередь до того, как предыдущее задание сегмента начнет просмотр
53
данных. Это поведение можно изменить для сериализации заданий сегмента, используя
следующие настройки .
Настройка
Значение по умолчанию
CoordinatorQueryBalancingFactor
-1
CoordinatorQueryBoostPriorityLevel 3
Многопользовательские
неблокирующие настройки
1
0
Необходимо быть внимательным, ведь, хотя эти настройки снижают или отключают блокировку
выполнения более быстро выполняющихся запросов длительными запросами, они снижают
общую пропускную способность. Если после изменения этих настроек выполнение запросов
продолжает блокироваться, свяжитесь со службой поддержки пользователей Майкрософт.
3.8.4 Балансировка сетевой нагрузки и базы данных, доступные только для
чтения
Хотя фундаментальные изменения структуры выходят за рамки данного документа, они могут
использоваться для решения проблем с запросами и вкратце описаны в данном разделе.
3.8.4.1 Балансировка сетевой нагрузки
Если узким местом производительности является использование процессора в отдельной системе
из-за рабочей нагрузки со стороны запросов от нескольких пользователей, можно повысить
производительность выполнения запросов с помощью кластера из серверов служб Analysis
Services, который будет обслуживать запросы. Нагрузку по обработке запросов можно
равномерно распределить между двумя серверами служб Analysis Services или между большим
числом серверов, что позволит одновременно поддерживать большее число пользователей (такая
структура называется фермой серверов). Кластеры с распределением нагрузки обычно
масштабируются линейно. Кластерные решения поставляются как корпорацией Майкрософт, так и
сторонними поставщиками. Решением корпорации Майкрософт по равномерному
распределению нагрузки является балансировка сетевой нагрузки (NLB), являющаяся функцией
операционной системы Windows Server®. С помощью NLB можно создать кластер NLB серверов
служб Analysis Services, работающих в многосерверном режиме. При работе кластера NLB
серверов служб Analysis Services в многосерверном режиме входящие запросы равномерно
распределяются по нагрузке между серверами служб Analysis Services. При использовании
кластера балансировки нагрузки нужно иметь в виду, что кэши данных на каждом из серверов в
кластере балансировки нагрузки будут различны. Это может привести к разному времени ответа
на запросы от одного и того же клиента.
Кластер балансировки нагрузки может также использоваться для обеспечения доступности в
случае, если один сервер служб Analysis Services выйдет из строя. Дополнительным средством
повышения производительности при использовании кластера балансировки нагрузки является
распределение задач обработки между серверами в автономном режиме. После обработки
новых данных на сервере в автономном режиме можно обновить серверы служб Analysis Services
54
в кластере балансировки нагрузки посредством синхронизации базы данных служб Analysis
Services.
Если пользователи направляют много запросов, требующих просмотра данных фактов, кластер
балансировки нагрузки может оказаться хорошим решением. Например, запросы, требующие
просмотра большого количества данных фактов, содержат расширенные запросы (такие как
наибольшие значения или медианы), а также случайные запросы к очень сложным кубам, где
вероятность попадания в агрегаты очень мала.
Тем не менее кластер балансировки нагрузки обычно не требуется для повышения
производительности служб Analysis Services, если для выполнения большинства запросов
используются агрегаты. Другими словами, необходимо сначала сконцентрировать внимание на
качественном проектировании агрегатов и секционировании. Кроме того, кластер балансировки
нагрузки не решает проблему низкой производительности, если узким местом является обработка
или если вы пытаетесь совершенствовать выполнение отдельного запроса от одного
пользователя. Обратите внимание, что одним из ограничений для использования кластера
балансировки нагрузки является невозможность использования обратной записи, поскольку нет
одиночного сервера для обратной записи данных.
3.8.4.2 Базы данных только для чтения
В новой версии SQL Server 2008 база данных может быть помечена как база данных только для
чтения и может использоваться несколькими экземплярами службы Analysis Services, то есть
несколько экземпляров службы Analysis Services могут совместно использовать один каталог
данных (обычно находящийся в сети SAN). Этот параметр необходимо учитывать в случае, когда
многопользовательская рабочая нагрузка на подсистему хранилища невелика, но значительна на
обработчик запросов. Несмотря на то что службы Analysis Services поддерживают несколько
экземпляров, указывающих на одну и ту же папку данных, управление пользовательскими
сеансами во всех экземплярах осуществляется приложением.
4 Основные сведения об обработке и измерении
производительности обработки
В следующих разделах содержатся рекомендации по настройке обработки кубов. Обработка —
это операция по загрузке данных из одного или более источников данных в один или несколько
объектов службы Analysis Services. Хотя о системах OLAP обычно судят не по скорости обработки
данных, производительность обработки влияет на то, насколько быстро данные становятся
доступными новым запросам. Хотя у каждого приложения свои требования к обновлению данных,
от обновления раз в месяц до обновлений почти в реальном времени, чем выше
производительность обработки, тем скорее пользователи смогут запрашивать обновленные
данные.
Службы Analysis Services имеют несколько команд обработки, позволяющих тонко управлять
загрузкой данных и частотой обновления кубов.
55
4.1 Общие сведения о задании обработки
Для управления операциями обработки службы Analysis Services используют централизованно
управляемые задания. Задание обработки — это универсальная единица работы, созданная
запросом на обработку.
С точки зрения архитектуры задание может быть разбито на родительские задания и дочерние
задания. Определенный объект может иметь несколько уровней вложенных заданий в
зависимости от того, где расположен объект в иерархии базы данных OLAP. Количество и тип
родительских и дочерних заданий зависит от 1) обрабатываемого объекта, такого как измерение,
куб, группа мер или секция, а также от 2) запрашиваемой операции обработки, например
ProcessFull, ProcessUpdate или ProcessIndexes.
Например, при выполнении операции ProcessFull для группы мер родительское задание создается
для группы мер с дочерними заданиями, создаваемыми для каждой секции. Для каждой секции
порождается серия дочерних заданий для выполнения операции ProcessFull на данных фактов и
агрегатах. Кроме того, службы Analysis Services реализуют зависимости между заданиями.
Например, задания кубов зависят от заданий измерения.
Наиболее важные возможности настройки производительности включают задания обработки для
основных объектов обработки: измерений и секций. Каждому из этих заданий посвящен
отдельный раздел данного руководства.
Дополнительные сведения по обработке см. в технической статье Архитектура обработчика
службы Analysis Services 2005.
4.2 Обработка по базовому плану
Чтобы количественно измерить эффект от настройки и выявления проблем, необходимо сначала
создать базовый план. Базовый план позволяет анализировать корневые причины проблем и
проводить целенаправленную оптимизацию.
В этом разделе описывается процесс настройки базового плана.
4.2.1 Трассировка системного монитора
Счетчики производительности Windows абсолютно необходимы для настройки
производительности служб Analysis Services. Воспользуйтесь средством системный монитор для
настройки трассировки с участием этих счетчиков:



56
MSOLAP: обработка
o Считано строк/сек
MSOLAP: статистическая обработка
o Записей байтов во временный файл/сек
o Создано строк/сек
o Текущие секции
MSOLAP: потоки





o Бездействующих потоков в пуле обработки
o Длина очереди заданий пула обработки
o Занятых потоков в пуле обработки
MSSQL: диспетчер памяти
o Общая память сервера
o Память целевого сервера
Обработать
o Байтов виртуальной памяти — msmdsrv.exe
o Рабочее множество — msmdsrv.exe
o Байтов исключительного пользования — msmdsrv.exe
o % процессорного времени — msmdsrv.exe и sqlservr.exe
Логический диск:
o Среднее время обмена с диском (сек) — все экземпляры
Процессор:
o % процессорного времени — всего
Система:
o Переключение контекста / сек
Настраивает трассировку для сохранения данных в файл. Для настройки обработки достаточно
измерения каждые 15 секунд.
В процессе настройки обработки необходимо измерять эти счетчики после каждого
произведенного изменения, чтобы проверить, насколько успешно вы двигаетесь к достижению
цели повышения производительности. Кроме того, следует учитывать общее время обработки.
Использование и интерпретация отдельных счетчиков описывается ниже в следующих разделах.
4.2.2 Трассировка профайлера
Для оптимизации SQL-запросов, формирующих часть процесса обработки, необходимо также
выполнять трассировку реляционной базы данных. Если реляционной базой данных является SQL
Server, воспользуйтесь для этого приложением SQL Server Profiler. Если вы не используете SQL
Server, обратитесь к поставщику своей базы данных за дополнительными сведениями по
настройке базы данных. В следующем примере предполагается, что в качестве реляционной
основы для служб Analysis Services используется SQL Server.
В трассировке приложения SQL Server Profiler необходимо также отслеживать следующие
события:


Performance/Showplan XML Statistics Profile
TSQL/SQL:BatchCompleted
Включите следующие столбцы событий:


57
TextData
Reads



DatabaseName
SPID
Duration
Можно воспользоваться шаблоном Настройка и добавить столбец Reads и Showplan XML Statistics
Profiles. Аналогично трассировке системного монитора настройте трассировку для сохранения
данных в файле для последующего анализа.
Настройте трассировку приложения SQL Server Profiler для сохранения данных журнала в таблице
вместо файла. Это облегчает согласование трассировок позднее.
Данные о производительности, собранные этими трассировками, будут использоваться в
следующем разделе, чтобы помочь настроить обработку.
4.3 Выявление распределения времени обработки
Для целенаправленной настройки обработки необходимо сначала определить, на что тратится
время: на обработку секций или на обработку измерений. Поскольку измерения обрабатываются
до обработки секций, можно легко измерить, сколько времени тратится на измерения.
При обработке секций необходимо различать ProcessData и ProcessIndex , ведь методы их
настройки существенно отличаются. Если следовать нашим рекомендациям и выполнять
ProcessData, а затем ProcessIndex вместо ProcessFull, можно легко определить время,
потраченное на каждый этап.
При использовании ProcessFull вместо разделения на ProcessData и ProcessIndex получить
представление о том, когда заканчивается каждый из этапов, можно путем отслеживания
следующих счетчиков системного монитора.


При ProcessData показание счетчика MSOLAP:обработка — считано строк/сек больше
нуля.
При ProcessIndex показание счетчика MSOLAP:статистическая обработка — создано
строк/сек больше нуля.
ProcessData можно далее разбить на время, потраченное процессом SQL Server, и время,
потраченное процессом служб Analysis Services. Можно использовать счетчики Обработка,
собранные для того, чтобы определить, на что затрачивается больше времени ЦП.
5 Повышение производительности обработки измерений
Цель повышения производительности обработки измерений — эффективное обновление данных
измерения, которое не снижает производительности выполнения запросов зависимых секций. В
этом разделе описываются следующие методы достижения данной цели:


58
Оптимизация запросов источника SQL.
Уменьшение служебных данных атрибутов.
В данном разделе также содержатся сведения об архитектуре обработки измерений.
5.1 Основные сведения об архитектуре обработки измерений
При обработке измерений MOLAP задания используются для извлечения, индексирования и
сохранения данных в хранилищах измерений.
Для создания таких хранилищ измерений подсистема хранилища использует ряд заданий,
представленных на рис. 19.
Рис. 19. Задания обработки измерений
Построение хранилищ атрибутов
Для каждого атрибута измерения создается экземпляр задания для извлечения и сохранения
элементов атрибута в хранилище атрибутов. Хранилище атрибутов состоит из хранилища ключей,
хранилища имен и хранилища связей.
Поскольку хранилища связей содержат сведения о зависимых атрибутах, требуется упорядочение
заданий обработки. Для обеспечения правильного потока операций подсистема хранилища
анализирует зависимости между атрибутами, а затем создает дерево выполнения с правильным
упорядочением. Дерево выполнения затем используется для определения лучшего
распараллеливания обработки измерений.
Рис. 20 отображает пример дерева выполнения для измерения времени. Сплошные стрелки
представляют связи атрибутов в измерении. Штриховые стрелки представляют неявные связи
каждого атрибута с атрибутом «Все».
59
Примечание. Измерение настроено с использованием каскадных связей атрибутов, которые
рекомендуются для всех конструкций измерения.
Рис. 20 Пример дерева выполнения
В этом примере атрибут «Все» обрабатывается первым, поскольку задано, что у него нет связей с
другими атрибутами. За ним следуют атрибуты «Финансовый год» и «Календарный год», которые
могут обрабатываться параллельно. Другие атрибуты обрабатываются в соответствии с
зависимостями в дереве выполнения, причем атрибут первичного ключа всегда обрабатывается
последним, поскольку он всегда имеет хотя бы одну связь атрибутов, за исключением тех случаев,
когда он является единственным атрибутом в измерении.
Время, затраченное на обработку атрибута, обычно зависит от следующих факторов: 1) количества
элементов и 2) числа связей атрибутов. Несмотря на то что вы не можете управлять количеством
элементов данного атрибута, можно повысить производительность обработки, используя
каскадные связи атрибутов. Это особенно важно для ключевого атрибута, поскольку он имеет
наибольшее количество элементов, а все остальные задания (иерархия, декодирование, индекс
битовой карты) ожидают завершения этого задания. Связи атрибутов снижают потребность в
памяти при обработке. При обработке атрибута все зависимые атрибуты должны храниться в
памяти. При отсутствии связей атрибутов все атрибуты должны храниться в памяти во время
обработки ключевого атрибута. Это может привести к нехватке памяти.
Дополнительные сведения о важности использования каскадных связей атрибутов см. в разделе
Определение связей атрибутов.
Создание хранилищ декодирования
60
Хранилища декодирования широко используются подсистемой хранилища. При запросе они
используются для извлечения данных из измерения. При обработке они используются для
создания битовых индексов для измерения.
Создание хранилищ иерархии
Хранилище иерархии представляет собой сохраненное представление структуры дерева. Для
каждой естественной иерархии в измерении создается задание, создающее хранилища иерархии.
Создание индексов битовой карты
Для эффективного поиска данных атрибута в хранилище связей при выполнении запроса
подсистема хранилища во время обработки создает индексы битовой карты. Для атрибутов с
большим количеством элементов обработка битовых индексов может занять некоторое время. В
большинстве сценариев битовые индексы предоставляют существенные преимущества при
выполнении запросов, однако при наличии атрибутов большой мощности (кардинальности) это
преимущество при выполнении запроса, предоставляемое битовыми индексами, может не
превысить расходы на обработку создания битовых индексов.
5.2 Команды обработки измерений
Для обработки для измерения, необходимо выполнить команды обработки измерения. Каждая
команда обработки создает одно или несколько заданий для выполнения необходимых
операций.
С точки зрения производительности наиболее важными являются следующие команды обработки
измерений:





ProcessFull
ProcessData
ProcessIndexes
ProcessUpdate
ProcessAdd
Команда ProcessFull удаляет все содержимое хранилища измерения и перестраивает его. В
фоновом режиме ProcessFull выполняет все задания обработки измерений, а также выполняет
неявную операцию ProcessClear для всех зависимых секций. Это означает, что всякий раз при
выполнении c измерением операции ProcessFull необходимо выполнять операцию ProcessFull для
зависимых секций, чтобы перевести куб в режим «в сети».
ProcessData удаляет все содержимое хранилища измерений и перестраивает только хранилища
атрибутов и иерархии, а также очищает секции. ProcessData является первым компонентом,
выполняемым операцией ProcessFull.
61
Операция ProcessIndexes требует, чтобы измерение уже имело построенные хранилища
атрибутов и иерархий, она оставляет данные в этих хранилищах, а затем перестраивает битовые
индексы. ProcessIndexes является вторым компонентом операции ProcessFull.
В отличие от операции ProcessFull операция ProcessUpdate не удаляет содержимое хранилища
измерений. Вместо этого она аккуратно выполняет обновления, чтобы сохранить зависимые
секции. В частности, ProcessUpdate отправляет SQL-запросы для чтения всей таблицы измерения,
а затем вносит изменения в хранилища измерений. ProcessUpdate способна обрабатывать
вставку, обновление и удаление в зависимости от типа связи атрибутов (жесткой или гибкой) в
измерении. Следует отметить, что ProcessUpdate удаляет недопустимые агрегаты и индексы,
поэтому вам надо перестроить агрегаты для поддержания производительности выполнения
запросов. Тем не менее гибкие агрегаты удаляются только при обнаружении изменений.
ProcessAdd оптимизирует операцию ProcessUpdate в сценариях, требующих только вставки новых
элементов. ProcessAdd не удаляет и не обновляет существующие элементы. ProcessAdd
увеличивает производительность, поскольку позволяет использовать другую исходную таблицу
или именованный запрос в представлении источника данных, ограничивающие строки исходной
таблицы измерения только новыми строками. Это устраняет необходимость чтения всех исходных
данных. Кроме того, ProcessAdd также сохраняет все индексы и агрегаты (гибкие и жесткие).
Примечание. ProcessAdd доступна только в качестве команды XMLA.
62
5.3 Блок-схема настройки обработки измерений
Relational or Analysis
Services problem?
AS
No
Apply dimension design
best practise
lower query
speed ok?
Use
<PreAllocate>
Relational
Analyse
Attribute
Usage
Index tuning advisor
not used for
slice and dice?
Replace attribute
hierarchy with member
properties
Remove bitmaps
Yes
Memory can
be reserved
for Analysis
Services?
No
Dim
fast enough
Yes
Done
Дополнительные сведения по статистике ожидания SQL Server и методам ее трассировки см. в
разделе sys.dm_os_wait_stats в электронной документации по SQL Server.
5.4 Рекомендации по оптимизации производительности обработки
измерений
Существуют общие проверенные рекомендации по проектированию, которые легко реализовать и
которые обеспечивают быстрое повышение производительности измерения. Необходимо
стремиться придерживаться данных рекомендаций при конструировании измерений.
В службах SQL Server 2008 Analysis Services предупреждения объектов АМО предоставляются
средой Business Intelligence Development Studio и помогают проверенными рекомендациями.
63
5.4.1 Использование представлений SQL для привязки запроса для
измерений
Поскольку привязки запросов для измерений в службах SQL Server 2008 Analysis Services не
существует, ее можно реализовать, используя представление (вместо таблиц) в качестве базового
источника данных измерений. Таким образом, можно использовать подсказки, индексированные
представления или другие методы настройки реляционных баз данных для оптимизации
инструкции SQL, получающей доступ к таблицам измерений через представление.
В большинстве случаев желательно создать собственную унифицированную многомерную модель
(UDM) поверх представлений базы данных. Можно не только применять реляционную настройку,
но и использовать подсказку NOLOCK в определении представления. Эта подсказка исключает
накладные расходы на управление блокировками в базе данных, что может еще больше поднять
производительность.
Представления облегчают отладку. Можно выполнять SQL-запросы непосредственно к
представлениям для сравнения реляционных данных с кубом. Таким образом, представления
предоставляют удобный способ инкапсулировать бизнес-логику, которая обычно реализуется в
качестве привязки запроса в унифицированной модели измерений (UDM). В то время как
синтаксис UDM схож с синтаксисом представления SQL, нельзя выполнять инструкции SQL к
унифицированной многомерной модели (UDM).
5.4.2 Оптимизация обработки атрибутов в нескольких источниках данных
Если измерение поступает из нескольких источников данных, использование каскадных связей
атрибутов позволяет системе сегментировать атрибуты во время обработки по источникам
данных. Если ключ, имя и связи атрибутов поступают из одного и того же источника данных,
система способна оптимизировать SQL-запрос для этого атрибута, отправляя запрос только одной
базе данных. В отсутствии каскадных связей атрибутов функция OPENROWSET SQL Server,
обеспечивающая доступ к данным из нескольких источников, используется для слияния потоков
данных. В такой ситуации обработка ключевого атрибута выполняется чрезвычайно медленно,
поскольку он должен получить доступ к нескольким производным таблицам OPENROWSET.
Если имеется такая возможность, попробуйте выполнить ETL для передачи всех данных,
требующихся для измерения, в одну базу данных SQL Server. Это позволит использовать
реляционный модуль для настройки запроса.
5.4.3 Уменьшение служебных данных атрибутов
Каждый атрибут, включаемый в измерение, влияет на размер куба, размер измерения,
статистическую схему и производительность обработки. При определении атрибута, который не
будет использоваться конечными пользователями, полностью удалите атрибут из измерения.
После удаления излишних атрибутов можно использовать ряд методов для оптимизации
обработки оставшихся атрибутов.
64
5.4.4 Эффективное использование свойств KeyColumns, ValueColumn и
NameColumn
При добавлении нового атрибута в измерение определение атрибута выполняется с
использованием трех свойств. Свойство KeyColumns определяет одно или несколько полей
источника, которые однозначно определяют каждый экземпляр атрибута.
Свойство NameColumn определяет поле источника, которое отображается для конечных
пользователей. Если вы не определили значение свойства NameColumn, оно автоматически
устанавливается равным значению свойства KeyColumns.
ValueColumn позволяет получить дополнительные сведения об атрибуте, обычно используемые
для вычислений. В отличие от свойств элементов данное свойство атрибута строго типизировано,
что позволяет обеспечить повышенную производительность при использовании в вычислениях.
Доступ к содержимому данного свойства можно получить посредством функции MemberValue
многомерного выражения.
Использование ValueColumn и NameColumn устраняет необходимость лишних атрибутов. Это
позволяет сократить общее количество атрибутов в структуре, повышая ее эффективность.
Службы Analysis Services обеспечивают возможность получать свойства KeyColumns, ValueColumn
и NameColumn из разных исходных столбцов. Это полезно при наличии отдельной сущности,
например продукта, определенного двумя разными атрибутами: суррогатным ключом и
описательным названием продукта. Если пользователи захотят сделать срезы данных по
продуктам, они могут обнаружить, что суррогатный ключ не информативен для бизнеса, и вместо
него будут использовать название продукта.
Рекомендуется назначить числовое поле источника свойству KeyColumns, а не строковое свойство.
Это не только сократит время обработки, но и уменьшит размер измерения. Это особенно важно
для атрибутов, имеющих большое число элементов, например больше миллиона элементов.
5.4.5 Удаление индексов битовой карты
При обработке атрибута первичного ключа для каждого связанного атрибута создаются индексы
битовой карты. Создание индексов битовой карты для первичного ключа может занять некоторое
время, если он содержит один или несколько связанных атрибутов большой мощности. В момент
выполнения запроса индексы битовой карты для данных атрибутов никак не влияют на ускорение
получения данных, поскольку подсистеме хранилища все равно придется фильтровать огромное
количество различных значений. Это может отрицательно повлиять на время ответа на запрос.
Например, первичный ключ измерения заказчиков однозначно определяет каждого заказчика по
номеру учетной записи, тем не менее пользователи также хотят получать продольные и
поперечные срезы данных по номеру социального страхования заказчика. Номер учетной записи
каждого заказчика имеет связь «один к одному» с номером социального страхования заказчика.
Чтобы не тратить время на создание ненужных индексов битовой карты для атрибута номера
65
социального страхования, можно отключить его индексы битовой карты, установив для свойства
AttributeHierarchyOptimizedState значение Not optimized.
5.4.6 Отключение иерархии атрибута и использование свойств элементов
В качестве альтернативы иерархиям атрибутов свойства элементов предоставляют другой
механизм вывода сведений об измерении. Для заданного атрибута свойства элемента
автоматически создаются для каждой связи атрибутов. Для атрибута первичного ключа это
означает, что любой атрибут, который непосредственно связан с первичным ключом, доступен в
качестве свойства элемента атрибута первичного ключа.
Если необходимо получить доступ к атрибуту как к свойству элемента, после проверки
правильности связи можно отключить иерархию атрибутов, установив для свойства
AttributeHierarchyEnabled значение False. С точки зрения обработки отключение иерархии
атрибута может способствовать повышению производительности и уменьшению размеров куба,
так как атрибут более не индексируется и не агрегируется. Это особенно полезно для атрибутов
большой мощности, связанных «один к одному» с первичным ключом. Атрибуты большой
мощности, такие как телефонные номера и адреса, обычно не требуют анализа продольных и
поперечных срезов. Отключив иерархии для этих атрибутов и осуществляя доступ к ним через
свойства элементов, можно сократить время обработки и уменьшить размеры куба.
При принятии решения об отключении иерархии атрибутов необходимо учитывать влияние
использования свойств элементов на выполнение запросов и обработку. Свойства элементов
нельзя поместить на ось запросов в среде Business Intelligence Design Studio так, как это делается с
иерархиями атрибутов и иерархиями пользователей. Для запроса свойства элемента необходимо
запросить свойства атрибута, содержащего свойство элемента.
Например, если вам необходим номер рабочего телефона заказчика, необходимо запросить
свойства заказчика, а затем запросить свойство номера телефона. Для упрощения этого процесса
большинство используемых клиентских средств отображают свойства элементов в
пользовательских интерфейсах.
В общем, запрос свойств элементов может выполняться медленнее, чем запрос иерархий
атрибута, поскольку свойства элементов не индексируются и не участвуют в агрегатах.
Фактическое влияние на производительность выполнения запроса зависит от того, как
используется атрибут.
Например, если пользователям необходимо получать продольные и поперечные срезы данных по
номеру и по описанию учетной записи, то с позиции запроса лучше сохранить иерархии атрибута
и удалить индексы битовой карты, когда важна производительность обработки.
5.5 Настройка запроса на обработку реляционного измерения
В отличие от секций фактов, которые отправляют только один запрос на сервер, операции
обработки измерений отправляют несколько запросов. В сравнении с фактами измерения обычно
бывают маленькими, но сложными таблицами с небольшим количеством изменений. Таблицы с
66
такими характеристиками часто могут сильно индексироваться с небольшими дополнительными
временными затратами производительности системы на вставку/обновление. Этим можно с
успехом воспользоваться при обработке и не заботиться об использовании реляционных
индексов.
Самым простым способом настройки реляционных запросов, используемым для обработки
измерений, является применение помощника по настройке ядра СУБД в трассировке профайлера
обработки измерения. Для небольших таблиц измерений можно выйти из положения
посредством добавления всех предложенных индексов. В более крупных таблицах назначьте
индексы долго выполняющимся запросам.
6 Повышение производительности обработки секций
Целью повышения производительности обработки секций является эффективное обновление
данных фактов и агрегатов, удовлетворяющее общим требованиям к обновлению данных. В этом
разделе рассматриваются следующие методы достижения данной цели: оптимизация запросов
источника SQL, использование нескольких секций, настройка ввода/вывода, повышение скорости
работы сети и настройка потоков и параллелизма.
6.1 Основные сведения об архитектуре обработки секций
При обработке секций исходные данные извлекаются и сохраняются на диске при помощи ряда
заданий, представленных на рис. 21.
Рис. 21. Задания обработки секций
Обработка данных фактов
Данные фактов обрабатываются с использованием трех параллельных потоков, выполняющих
следующие задания:



67
Отправка инструкций SQL для извлечения данных из источников данных.
Просмотр ключей измерения в хранилищах измерений и заполнение буфера обработки.
При заполнении буфера обработки перезапись его на диск.
Создание агрегатов и индексов битовой карты
Агрегаты создаются в памяти во время обработки. Хотя слишком малое число агрегатов может не
оказывать заметного влияния на производительность выполнения запросов, чрезмерное число
агрегатов может увеличить время обработки, ненамного улучшая производительность
выполнения запросов.
Если агрегаты не помещаются в памяти, фрагменты записываются во временные файлы и
сливаются по окончании процесса. На этом этапе также создаются индексы битовой карты и
посегментно записываются на диск.
6.2 Команды обработки секций
Когда необходимо выполнить операцию обработки секции, выдаются команды обработки секций.
Каждая команда обработки создает одно или несколько заданий для выполнения необходимых
операций.
Для обработки секций доступны следующие команды:






ProcessFull
ProcessData
ProcessIndexes
ProcessAdd
ProcessClear
ProcessClearIndex
Команда ProcessFull удаляет содержимое хранилища секции и перестраивает его. В фоновом
режиме команда ProcessFull выполняет заданияProcessData и ProcessIndexes.
Команда ProcessData удаляет содержимое хранилища объекта и перестраивает только данные
фактов.
Команда ProcessIndexes требует, чтобы в секции уже имелись данные. Команда ProcessIndexes не
трогает данные, созданные во время выполнения команды ProcessData, и на их основе создает
новые агрегаты и битовые индексы.
Команда ProcessAdd создает внутреннюю временную секцию, обрабатывает ее с использованием
целевых данных фактов, а затем производит ее слияние с существующей секцией. Обратите
внимание, что ProcessAdd является именем команды XMLA. В средах Business Intelligence
Development Studio и SQL Server Management Studio она отображается как ProcessIncremental.
Команда ProcessClear удаляет все данные из секции. Обратите внимание, что ProcessClear — это
имя команды XMLA. В средах Business Intelligence Development Studio и SQL Server Management
Studio она отображается как UnProcess.
68
Команда ProcessClearIndex удаляет все индексы и агрегаты из секции. Состояние секций после
этой команды такое же, как после выполнения команды ProcessClear с последующим
выполнением ProcessData. Обратите внимание, что ProcessClearIndex — это имя команды XMLA.
Эта команда недоступна в средах Business Intelligence Development Studio и SQL Server
Management Studio.
6.3 Блок-схема настройки обработки секций
На следующей блок-схеме представлен процесс настройки команды ProcessData.
69
Waiting for
PAGEIO_X
in SQL Server?
Source query fully
optimized?
Yes
How many
partitions does the
process query
touch?
No
>1
Repartition
cube or
relational
No
Add cluster
index to
support quey
Yes
Denormalize
and use star
schema
Yes
=1
No
Optimize data types
Use lock
elimination
No
Waiting for
LCK_X in SQL?
Yes
Query supported by
index?
Model
Apply Data
Compression
No
Yes
Yes
Using SQL
2008?
Waiting for
ASYNC_NETWORK_IO
in SQL Server?
Joins in
query?
No
Yes
Still waiting for
PAGEIO_X?
Enough
NIC Capacity
NIC
< # Cores in
Analysis
Services Adjust network packet
size
Still waits for
ASYNC_NETWORK_IO
?
NIC Near
capacity
Optimize
network
infrastructure
Tune I/O system or
upgrade hardware
NIC interrupt affinty
configured?
Yes
Afinitze network and
distribute load
No
Yes
CPU load on
Analysis Services?
=100
<100
CPU load on SQL
Server
Adjust
threadpool
=100
Idle threads
< #Cores
>0
Max connections in
data source
= # Cores
< # Cores in
Analysis Services
Для команды ProcessIndexes применяется следующая блок-схема.
70
= # Cores in
Analysis
Services
Done
<100
=0
Repartition
cube
Increase max connection
to #cores in Analysis
Services
Try shared memory
connections if available
# Concurrent
processing
partitions
>0
Add memory
or
move tempdir
to faster drives
I/O bottleneck
Yes
Add more I/O
capacity
% Processor Time
<100%
No more
threads
Adjust ThreadPool
settings
<
requested
Adjust AggMemMin
Temp vytes
written
=0
=100%
Yes
<100%
Idle threads
Max speed achieved
# Processing
partitions
= requested
Possible to request
more partitions?
No
Possible
Design for more
partitions?
Not viable
Adjust
CoordinatorBuildMaxThreads
6.4 Рекомендации по повышению производительности обработки секций
При создании таблиц фактов воспользуйтесь рекомендациями следующих технических статей:


10 рекомендаций по созданию крупномасштабного реляционного хранилища данных
Рекомендации по обработке службами Analysis Services
6.4.1 Оптимизация операций вставки, обновления и удаления данных
Этот раздел содержит рекомендации по эффективному обновлению секций данных, а также
обработке вставок, обновлений и удалений.
71
Вставки
Если имеется доступный для просмотра обработанный куб и необходимо добавить новые данные
в имеющуюся секцию группы мер, можно воспользоваться одним из следующих методов:


ProcessFull — выполните операцию ProcessFull для имеющейся секции. В ходе выполнения
операции ProcessFull куб остается доступным для просмотра имеющихся данных, в то же
время создается отдельный набор файлов, содержащих новые данные. По окончании
обработки новые данные секции будут доступны для просмотра. Обратите внимание, что
ProcessFull необязательна с технической точки зрения, если выполнялись только вставки.
Для оптимизации обработки операций вставки можно воспользоваться командой
ProcessAdd.
ProcessAdd — используйте эту операцию для присоединения данных к существующим
файлам секции. При частом выполнении команды ProcessAdd рекомендуется
периодически выполнять операцию ProcessFull для перестроения и повторного сжатия
файлов данных секции. Команда ProcessAdd создает внутреннюю временную секцию и
выполняет ее слияние. Со временем это приводит к фрагментации данных и возникает
необходимость периодического выполнения операции ProcessFull.
Если группа мер содержит несколько секций, как описано в предыдущем разделе, то эффективнее
всего будет создать новую секцию, которая будет содержать новые данные, а затем выполнить
операцию ProcessFull. Данный метод позволяет добавлять новые данные, не оказывая влияния на
имеющиеся секции. По окончании обработки новой секции она станет доступной для запросов.
Обновления
При необходимости обновления данных можно выполнить операцию ProcessFull. Она полезна,
если можно назначить для обновлений специальную секцию, чтобы впоследствии обрабатывать
только одну секцию. Вместо непосредственного обновления данных фактов рекомендуется
использовать механизм ведения журнала для реализации изменений данных. При таком
сценарии обновление превратится во вставку, исправляющую имеющиеся данные. При таком
подходе можно просто продолжить добавление новых данных в секцию при помощи операции
ProcessAdd. При использовании метода ведения журнала также создается контрольный след
изменений, произведенных в таблице фактов.
Удаления
При операции удаления несколько секций предоставляют замечательную возможность выгрузки
устаревших данных. Рассмотрим следующий пример. В группе мер имеются данные за
13 месяцев, секции по 1 месяцу. Необходимо выгрузить самый давний месяц из куба. Для этого
можно просто удалить секцию, не затрагивая другие секции.
Если имеются старые элементы измерения, которые появились только в истекшем месяце, их
можно удалить при помощи операции ProcessUpdate с измерением (только если оно содержит
гибкие связи). Чтобы удалить элементы из ключевого атрибута/атрибута гранулярности
измерения, необходимо установить для свойства UnknownMember измерения значение Hidden.
72
Это необходимо потому, что сервер не знает, была ли назначена запись факта удаленному
элементу. При соответствующей настройке этого свойства элемент будет скрыт в момент запроса.
Другим вариантом действия является удаление данных из базовой таблицы и выполнение
операции ProcessFull . Однако на его выполнение требуется больше времени, чем на выполнение
ProcessUpdate.
По мере роста измерения, возможно, придется выполнить операцию ProcessFull с измерением
для окончательного удаления удаленных ключей. Но при этом все связанные секции необходимо
повторно обработать. Для этого может потребоваться окно для большого пакета, что приемлемо
не для всех сценариев.
6.4.2 Выбор эффективных типов данных в таблицах фактов
При обработке данные необходимо переместить из SQL Server в службы Analysis Services. Чем
шире строки, тем большая пропускная способность необходима для их перемещения.
Использование некоторых типов данных в силу их конструкции занимает меньше времени, чем
других. Для максимальной производительности попытайтесь использовать только такие типы
данных в таблицах фактов.
Тип столбца факта
Суррогатные ключи
Дата в ключе
Целочисленные меры
Числовые меры
Столбцы подсчета различных объектов
Самые быстрые типы данных SQL Server
tinyint, smallint, int, bigint
int в формате ггггММдд
tinyint, smallint, int, bigint
smallmoney, money, real, float
(Обратите внимание, что обработка типов
decimal и vardecimal требует больше
вычислительной мощности ЦП, чем обработка
типов money и float)
tinyint, smallint, int, bigint
(Если столбец подсчета относится к типу char,
попробуйте хэшировать его или заменить на
суррогатный ключ)
6.5 Настройка запроса на обработку реляционных секций
На этапе ProcessData строки считываются из реляционного источника в службы Analysis Services.
На этом этапе службы Analysis Services могут потреблять строки с очень высокой скоростью. Чтобы
достичь этой высокой скорости необходимо настроить соответствующую пропускную способность
реляционной базы данных.
В следующем подразделе предполагается, что в качестве реляционного источника используется
SQL Server. Некоторые из рекомендаций могут также применяться при использовании другого
73
реляционного источника — обратитесь за помощью по особенностям платформы к специалисту
по базам данных.
Службы Analysis Services используют сведения секции при формировании запроса. Если
связывание запроса в UDM не выполнялось, то выдача инструкции SELECT реляционному
источнику не представляет труда. Она включает в себя:


SELECT для столбцов, необходимых для обработки. Это столбцы измерений и меры.
Кроме того, условие WHERE, если вы используете секции. Управлять условием WHERE
можно посредством изменения связывания запроса секции.
6.5.1 Избавление от соединений
При использовании представления базы данных или именованного запроса UDM в качестве
основы для секций, необходимо избегать соединений в данном запросе. Этого можно добиться
посредством денормализации присоединенных к таблице фактов столбцов. Если вы используете
структуру схемы типа «звезда», то эта операция вам уже знакома.
Дополнительные сведения о реляционных схемах типа «звезда», а также о проектировании и
денормализации для получения оптимальной производительности, см. в:

Ralph Kimball, The Data Warehouse Toolkit
6.5.2 Настройка реляционного секционирования
При использовании реляционного секционирования необходимо убедиться, что каждая секция
куба контактирует по меньшей мере с одной реляционной секцией. Чтобы это проверить,
воспользуйтесь событием XML Showplan в трассировке приложения SQL Server Profiler.
Если вы отбросили все соединения, план вашего запроса должен выглядеть примерно так, как
показано на рис. 22.
Рис. 22. Оптимальный запрос на обработку секций
Нажмите кнопку просмотра таблицы (это может быть и просмотр диапазона или поиск индекса в
вашем случае) и вызовите область свойств.
74
Рис. 23. Обращение к слишком большому количеству секций
Получен доступ к секции 4 и секции 5. Значение Actual Partition Count должно равняться 1. Если
это условие не соблюдается (см. выше), необходимо переделать секционирование данных
реляционного источника с тем, чтобы каждая секция куба контактировала не более чем с одной
реляционной секцией.
6.5.2.1 Особый случай: число различных объектов (distinct count)
Группы мер числа различных объектов имеют особые требования для секционирования. Обычно в
качестве столбца секционирования используется время или другое измерение. Тем не менее при
секционировании группы мер числа различных объектов, секционирование необходимо
проводить по значению столбца меры числа различных объектов.
Сгруппируйте столбец меры числа различных объектов на отдельные неперекрывающиеся
интервалы. Каждый из интервалов должен содержать приблизительно одно и то же количество
строк из источника данных. Эти интервалы затем образуют источник секций службы Analysis
Services.
Поскольку параллелизм этапа обработки данных ограничен количеством имеющихся секций,
необходимо разбить меру числа различных объектов на столько неперекрывающихся интервалов
одинакового размера, сколько ядер ЦП имеет компьютер со службами Analysis Services.
Начиная с версии службы Analysis Services 2005 и далее, можно использовать нецелочисленные
столбцы для групп мер числа различных объектов. Однако из соображений производительности
этого необходимо избегать. Представленный ниже технический документ описывает процесс
использования хэш-функций для преобразования нецелочисленных столбцов в целочисленные
для числа различных элементов. Он также содержит примеры стратегии секционирования при
помощи неперекрывающихся интервалов.

Оптимизация подсчета различных объектов службы Analysis Services
6.5.3 Настройка реляционного индексирования
Хотя обычно каждая секция куба должна контактировать не более чем с одной реляционной
секцией, обратное неверно. Вполне возможно иметь более одной секции куба, обращающейся к
одной и той же реляционной секции. Например, реляционный источник, секционированный по
году, с кубом, секционированным по месяцу, может обеспечить оптимальную
производительность обработки.
75
При отсутствии связи «один к одному» между реляционными секциями и секциями куба обычно
желательно, чтобы индекс поддерживал запрос, обрабатывающий факты. Для этих целей лучшим
выбором будет кластеризованный индекс; если стратегия загрузки поддерживает такой индекс, то
именно его и нужно выбрать.
Если обрабатывающий запрос поддерживается индексом, то план должен выглядеть следующим
образом.
Рис. 24. Правильная поддержка обработки индексом
Дополнительные сведения по оптимизации запросов см. в разделе:


10 распространенных проблем с производительностью SQL Server 2005 для приложений
хранилищ данных и отчетности
И. Бен-ган, Любор Коллар. Внутри Microsoft SQL Server 2005: запросы на T-SQL. (Itzik BenGan, Lubor Kollar, Inside Microsoft SQL Server 2005: T-SQL Querying)
6.5.3.1 Особый случай: число различных объектов
Подобно секционированию, подсчет различных объектов снова является особым случаем для
индексирования.
В запросах на обработку числа различных объектов есть предложение ORDER BY, которое
добавляется к ним службами Analysis Services. Например, если ввести подсчет различных объектов
в столбце CustomerPONumber в таблице FactInternetSales, то можно получить такой запрос при
обработке:
SELECT … FROM FactInternetSales
ORDER BY [CustomerPONumber]
Если секция содержит большое количество строк, то упорядочение данных может занять много
времени. Без поддерживающих индексов план запроса выглядит следующим образом.
76
Рис. 25. Реляционная сортировка, порожденная подсчетом различных
объектов
Заметили, как много времени занимает операция сортировки? Создав кластеризованный индекс,
отсортированный по столбцу с числом различных объектов (в данном случае CustomerPONumber),
можно избежать этой операции и получить следующий план запроса.
Рис. 26. Запрос числа различных объектов, поддерживаемый правильным
индексом
Безусловно, этот индекс необходимо обслуживать. Но если он имеется, то способствует
увеличению скорости обрабатывающих запросов.
6.5.4 Использование индекса FILLFACTOR = 100 и сжатия данных
Если в индексе происходит разбиение страниц, то страницы индекса могут быть заполнены не на
100 %. В результате SQL Server будет считывать больше страниц базы данных, чем это необходимо
при просмотре индекса.
Обнаружить неполные страницы индекса можно посредством запроса SQL Server DMV
sys.dm_db_index_physical_stats. Если столбец avg_page_space_used_in_percent значительно ниже
100 %, то имеет смысл выполнить перестроение индекса с параметром FILLFACTOR 100. Такое
перестроение индекса не всегда возможно, но этот прием позволит снизить затраты на вводвывод. Для устаревших данных желательно выполнить перестроение индексов в таблице, прежде
чем пометить данные как предназначенные только для чтения.
SQL Server 2008 имеет возможность сжатия типа ROW или PAGE, позволяющего дополнительно
сократить количество операций ввода-вывода, необходимых для обслуживания запроса на
обработку фактов реляционной базой данных. Сжатие требует дополнительных временных затрат
ЦП, но снижение числа операций ввода-вывода стоит того.
77
6.6 Устранение дополнительных временных затрат на блокировку базы
данных
Когда SQL Server просматривает индекс или таблицу, в ходе считывания строк необходимы
блокировки страниц. Это позволяет сделать таблицу доступной для многих пользователей
одновременно. Однако при рабочих нагрузках хранилища данных эти блокировки страниц не
всегда являются оптимальной стратегией, особенно в случае, когда большие запросы на
получение данных (типа обработки фактов) получают доступ к данным.
Измеряя счетчик системного монитора MSSQL:блокировки — запросов на блокировку / с и
выполняя поиск событий LCK в sys.dm_os_wait_stats, можно оценить, сколько дополнительных
временных затрат уходит на управление блокировками во время обработки.
Для устранения дополнительных временных затрат на блокировку существуют три варианта
действий.



Вариант 1. Установка реляционной базы данных в режим только для чтения до начала
обработки.
Вариант 2. Создание индексов фактов посредством ALLOW_PAGE_LOCKS = OFF и
ALLOW_ROW_LOCKS = OFF.
Вариант 3. Выполнение обработки при помощи представления с указанием WITH (NOLOCK)
или WITH (TABLOCK)подсказки в запросе.
Вариант 1 подходит не для всех сценариев, поскольку установка базы данных в режим только для
чтения требует монопольного доступа к базе данных. Тем не менее это быстрый и простой способ
окончательно удалить любые имеющиеся ожидающие блокировки элементы.
Вариант 2 является хорошей стратегией для хранилищ данных. Поскольку блокировки чтения SQL
Server (блокировки S) совместимы с другими блокировками S, два модуля чтения могут получать
доступ к одной и той же таблице дважды, не требуя тонкой гранулярности блокировок страниц и
строк. Если операции вставки выполняются только в пакетном режиме, целесообразно
использовать только блокировки таблиц. Чтобы отключить блокировку строк/страниц в таблице и
индексе, перестройте ВСЕ следующим образом.
ALTER INDEX ALL ON FactInternetSales REBUILD
WITH (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = OFF)
Вариант 3 является очень полезным методом. Обработка посредством представления
обеспечивает дополнительный уровень абстракции поверх базы данных — отличная стратегия
конструирования. В определении представления можно добавить подсказку NOLOCK или
TABLOCK, чтобы исключить дополнительные временные затраты на блокировку базы данных во
время обработки. Данный подход имеет то преимущество, что устранение блокировок не зависит
от того, как создаются и управляются индексы.
CREATE VIEW vFactInternetSales
78
AS
SELECT [ProductKey], [OrderDateKey], [DueDateKey]
,[ShipDateKey], [CustomerKey], [PromotionKey]
,[CurrencyKey], [SalesTerritoryKey], [SalesOrderNumber]
,[SalesOrderLineNumber], [RevisionNumber], [OrderQuantity]
,[UnitPrice], [ExtendedAmount], [UnitPriceDiscountPct]
,[DiscountAmount], [ProductStandardCost], [TotalProductCost]
,[SalesAmount], [TaxAmt], [Freight]
,[CarrierTrackingNumber] ,[CustomerPONumber]
FROM [dbo].[FactInternetSales] WITH (NOLOCK)
При использовании подсказки NOLOCK остерегайтесь «грязного» считывания, которое может
произойти. Дополнительные сведения о режимах блокировки см. в разделе SET TRANSACTION
ISOLATION LEVEL в электронной документации по SQL Server.
6.7 Оптимизация пропускной способности сети
При выполнении ProcessData строки должны передаваться между SQL Server и службами Analysis
Services. Если две эти службы установлены на разных компьютерах, возникает трафик в сети
TCP/IP. Убедитесь, что все сетевые компоненты настроены для поддержки необходимой
пропускной способности. Если пропускная способность Ethernet постоянно близка к 80 % от
максимальной мощности, то добавление сети дополнительной емкости обычно ускоряет
выполнение операции ProcessData. Кроме того, если сеть становится узким местом, вы увидите
ожидание операций ASYNC_NETWORK_IO в SQL Server.
Наряду с созданием высокоскоростной сети, существует несколько дополнительных
конфигураций, которые можно изменять для ускорения сетевого трафика.
Увеличение размера сетевого пакета для SQL Server в свойствах источника данных позволит
минимизировать протокольные служебные данные, необходимые для создания большого
количества мелких пакетов. Значение по умолчанию для SQL Server 2008 равно 4096. При загрузке
хранилища данных размер пакета в 32 КБ (в SQL Server это означает присвоение значения 32767)
может ускорить обработку. Вместо изменения значения в SQL Server переопределите его в
источнике данных.
79
Рис. 13 Настройка размера сетевого пакета
Необходимо учитывать значительные дополнительные временные затраты на передачу данных
по сети TCP/IP. Напоминаем, что, если службы Analysis Services установлены на том же
компьютере, что и SQL Server, они способны использовать соединения посредством общей
памяти. Соединения через общую память имеют минимальные дополнительные временные
затраты при обмене данными между SQL Server и службами Analysis Services. В зависимости от
рабочей нагрузки обработки можно ускорить обработку, объединив SQL Server и службы Analysis
Services на одном компьютере.
Можно проверить, использует ли соединение общую память, выполнив следующую инструкцию
SELECT.
SELECT session_id, net_transport, net_packet_size
FROM sys.dm_exec_connections
Свойство net_transport для SPID служб Analysis Services должно отображать: Общая память.
Дополнительные сведения о соединениях через общую память см. в разделах:

80
Создание допустимой строки соединения с использованием протокола общей памяти
6.8 Совершенствование подсистемы ввода-вывода
Когда полностью настроена система реляционного источника и устранены узкие места сети,
пришло время заняться подсистемой ввода-вывода.
С точки зрения SQL Server можно измерить задержку ввода-вывода по sys.dm_os_wait_stats. Если
вы постоянно видите большое время ожидания для PAGELATCH_IO, можно воспользоваться более
быстрой подсистемой ввода-вывода для SQL Server.
Если вы поместили файлы службы Analysis Services на диск с отдельной буквой или точку
подключения (рекомендуется), можно использовать счетчик логический диск системного
монитора для измерения времени ожидания ввода-вывода. Если время ожидания постоянно
превышает 0,015 секунды, можно также использовать более быструю подсистему ввода-вывода
на дисках служб Analysis Services.
Методы настройки подсистем ввода-вывода не входят в содержание данного документа.
Дополнительные сведения см. в следующих технических статьях и документах:



10 рекомендаций по хранению
Основы ввода-вывода в SQL Server 2000
Рекомендации по предварительному развертыванию ввода-вывода
6.9 Увеличение параллелизма добавлением секций
На данном этапе настройки вас ограничивает только имеющаяся производительность ЦП и
способность устанавливать приложения с высокой степенью параллелизма. Пришло время
взглянуть на счетчик Процессор: итого трассировки базового плана. Если этот счетчик не равен
100 %, значит вы не используете свой ЦП на полную мощность. По мере выполнения настройки
продолжайте сравнивать с базовыми показателями, чтобы измерять улучшения, и обращайте
особое внимание на появляющиеся узкие места при принудительной отправке все большего
количества данных через систему.
Использование нескольких секций может повысить производительность обработки. Секции
позволяют параллельно работать с несколькими более мелкими частями таблицы фактов.
Поскольку одно соединение с SQL Server способно передавать ограниченное количество строк в
секунду, добавление дополнительных секций, а значит и соединений, может увеличить
пропускную способность. Количество секций, которые могут обрабатываться параллельно,
зависит от мощности ЦП и архитектуры компьютера. Практическое правило — продолжайте
увеличивать параллелизм до тех пор, пока показания счетчика MSOLAP:обработка — считано
строк/сек не перестанут расти. Можно измерить количество обрабатываемых параллельных
секций при помощи счетчика системного монитора MSOLAP: статистическая обработка —
текущие секции.
Способность параллельной обработки нескольких секций полезна в разных сценариях, однако
существует несколько рекомендаций, которых необходимо придерживаться. Помните, что при
обработке группы мер, не содержащей обработанных секций, службы Analysis Services должны
81
инициализировать структуру куба для данной группы мер. Для этого требуется монопольная
блокировка, предотвращающая параллельную обработку секций. Эту блокировку необходимо
удалить до начала полной параллельной обработки в системе. Для удаления блокировки
инициализации убедитесь в наличии хотя бы одной обработанной секции на каждую группу мер
до начала параллельной операции. При отсутствии обработанной секции можно выполнить
команду ProcessStructure в кубе для создания его исходной структуры, а затем перейти к
параллельной обработке секций групп мер. Вы не столкнетесь с данным ограничением, если
будете обрабатывать секции в одном и том же сеансе клиента с использованием XMLA элемента
MaxParallel для управления уровнем параллелизма.
6.10 Настройка максимального количества соединений
При увеличении параллелизма обработки выше уровня в 10 параллельных секций придется
настроить максимальное количество соединений с базой данных, которые службы Analysis
Services оставляют открытыми. Это количество можно изменить в свойствах источника данных.
Рис. 28. Добавление дополнительных соединений с базами данных
Установите данное значение по меньшей мере равным количеству секций, которые будут
обрабатываться параллельно.
6.11 Настройка свойств ThreadPool и CoordinatorExecutionMode
Эти серверные свойства увеличивают количество потоков, которые могут быть использованы для
поддержки операций параллельной обработки.
Показатель ThreadPool\Process\MaxThreads определяет максимальное число доступных потоков в
службах Analysis Services в процессе обработки. В больших компьютерах с несколькими ЦП
значение по умолчанию для данной настройки может оказаться слишком низким для
82
использования полной мощности ЦП. Тем не менее при увеличении значения данного счетчика
помните, что увеличение параллелизма обработки также оказывает влияние на запросы,
выполняемые системой. Чем больше мощности процессора и потоков выделяется для обработки,
тем меньше ресурсов ЦП используется для выполнения запросов. Разумеется, при обработке
кубов в пакетном режиме такая проблема не возникнет.
Для оптимизации данных настроек для этапа команды ProcessData проверьте счетчик системного
монитора для объекта MSOLAP: потоки, используя представленную ниже таблицу в качестве
руководства.
Ситуация
Длина очереди заданий пула обработки > 0 и
Бездействующих потоков в пуле обработки = 0
для более продолжительного времени во время
обработки.
Оба показателя Длина очереди заданий пула
обработки > 0 и Бездействующих потоков в пуле
обработки > 0 в одно и то же время обработки.
Действие
Увеличьте параметр
Threadpool\Process\MaxThreads и повторите
проверку.
Уменьшите параметр
CoordinatorExecutionMode и повторите
проверку.
Можно использовать счетчик Процессор — % процессорного времени — итого в качестве
примерного показателя того, на сколько нужно изменить данные настройки. Цель — максимально
приблизиться к значению 100 % загрузки ЦП. Например, если загрузка ЦП равна 50 %, можно
удвоить значение Threadpool\Process\MaxThreads, чтобы посмотреть, удвоится ли при этом
использование ЦП.
Дополнительные сведения о настройке пулов потоков см. в следующем техническом документе:

Свойства сервера служб SQL Server 2005 Analysis Services (SSAS)
6.12 Настройка свойства BufferMemoryLimit
OLAP\Process\BufferMemoryLimit определяет размер буферов для данных фактов, используемых
при обработке секций. Хотя значение по умолчанию OLAP\Process\BufferMemoryLimit достаточно
для большинства развертываний, может потребоваться изменить это свойство по следующему
сценарию.
Если гранулярность для группы мер соответствует большей степени обобщения, чем для таблицы
фактов реляционного источника данных, подумайте об увеличении размеров буферов, чтобы
облегчить группирование данных. Например, если исходные данные разбиты по дням, а группа
мер разбита по месяцам, службам Analysis Services необходимо сгруппировать ежедневные
данные по месяцам до записи на диск. Такое группирование осуществляется в одном буфере и
сбрасывается на диск по окончании процесса. Увеличивая размер буфера, вы сокращаете
количество раз выгрузки данных из буфера на диск. Поскольку это позволяет достичь более
высокого коэффициента сжатия, размер данных фактов на диске сокращается, что ведет к
повышению производительности. Однако нужно иметь в виду, что при высоких значениях
83
BufferMemoryLimit используется больший объем памяти. Если объем памяти недостаточен,
параллелизм снижается.
6.13 Настройка свойства Process Index Phase
На этапе выполнения команды ProcessIndexes в кубе создаются агрегаты. На этом этапе в
реляционном механизме не выполняется дополнительных действий и, если службы Analysis
Services и SQL Server совместно используют одно и то же поле, можно выделить все ядра ЦП
службам Analysis Services.
Ключевым показателем, оптимизируемым при операции ProcessIndexes, является счетчик
производительности MSOLAP:статистическая обработка — создано строк/сек. При увеличении
значения счетчика время выполнения команды ProcessIndexes сокращается. Этот счетчик можно
использовать при настройке скорости.
6.13.1
Избегайте сброса временных данных на диск
В процессе обработки буфер агрегатов определяет объем памяти, доступный для создания
агрегатов для данной секции. Если объем буфера агрегатов слишком мал, службы Analysis Services
дополняют его временными файлами. Временные файлы создаются в папке TempDir, когда
память заполнена и данные сортируются и записываются на диск. Когда все необходимые файлы
созданы, они сливаются в окончательное назначение. Использование временных файлов может
привести к некоторому падению производительности во время обработки. Для наблюдения за
временными файлами, используемыми в процессе обработки, просмотрите
счетчикMSOLAP:обработка агрегатов\записано байтов во временные файлы за сек.
Кроме того, при параллельной обработке нескольких секций или обработке целого куба в одной
транзакции необходимо убедиться, что общий объем необходимой памяти не превышает
значение настройки Memory\TotalMemoryLimit. Если службы Analysis Services достигают значения
Memory\TotalMemoryLimit во время обработки, то они не позволяют буферу агрегатов
увеличиваться в объеме, что приводит к использованию временных файлов при обработке
агрегата. Более того, при нехватке виртуального адресного пространства для этих одновременных
операций, возможно появление ошибок, вызванных недостатком памяти. При недостаточном
объеме физической памяти происходит разбиение памяти на страницы. Если при параллельной
обработке ресурсы ограниченны, попробуйте сократить количество параллельных операций.
При конфигурации по умолчанию службы Analysis Services выдают исключение «Нехватка памяти»
при попытке запроса слишком большого объема памяти в процессе обработки. Данную ошибку
можно отключить, установив для свойства MemoryLimitErrorEnabled значение false в свойствах
сервера. Однако это может привести к выгрузке на диск и замедлению выполнения операции
обработки.
Если выгрузка данных на диск неизбежна, убедитесь, что папка TempDir и файл подкачки
являются быстрой системой ввода-вывода.
84
6.13.2
Устранение узких мест ввода-вывода
При выполнении операции ProcessIndexes работа с диском обычно менее интенсивная, чем при
выполнении ProcessData. При наличии достаточных ресурсов ввода-вывода, позволяющих
избежать узких мест при операции ProcessData, скорее всего, скорость процессов ввода-вывода
будет достаточной для выполнения ProcessIndexes. Тем не менее необходимо продолжать
наблюдение за операциями ввода-вывода, используя рекомендации документа
Совершенствование подсистемы ввода-вывода.
6.13.3
Добавление секций для увеличения параллелизма
Подобно операции ProcessData, параллельная обработка большего числа секций может ускорить
выполнение ProcessIndexes. Используется та же стратегия настройки: продолжайте увеличивать
число секций до тех пор, пока скорость обработки не перестанет расти.
6.13.4
Настройка потоков и AggregationMemorySettings
При выполнении операции ProcessIndexes службы Analysis Services просматривают и объединяют
секции, созданные при выполнении ProcessData. Существует два способа параллельного
выполнения данной операции:


Использование нескольких потоков для параллельного просмотра и объединения
сегментов одной секции.
Одновременный просмотр и объединение нескольких секций с использованием меньшего
количества потоков.
Оба метода могут использоваться одновременно в большей или меньшей степени. Используя
свойства сервера, можно управлять процессом выполнения. Кроме того, обе настройки
ограничены настройками потоков на сервере, как описано в разделе Настройка свойств
ThreadPool и CoordinatorExecutionMode.
При добавлении дополнительных секций с целью увеличения параллелизма, возможно, придется
изменить настройки AggregationMemory. Если конструкция не позволяет добавлять
дополнительные секции, можно изменить свойство CoordinatorBuildMaxThreads для
дополнительного увеличения параллелизма.
Когда при измерении загрузки ЦП счетчиком Процессор — % процессорного времени — итого
получен результат меньше 100 % и предполагается, что узких мест нет, появляется возможность
еще больше увеличить скорость выполнения команды ProcessIndex, используя методики из этого
раздела.
6.13.4.1
Настройка потоков
Как и для операции ProcessData, для достижения оптимальной производительности может
потребоваться настройка пула потоков. Воспользуйтесь рекомендациями раздела Настройка
свойств ThreadPool и CoordinatorExecutionMode.
85
6.13.4.2
Настройка свойства AggregationMemoryMin
Среди свойств сервера имеются следующие настройки:


OLAP\Process\AggregationMemoryLimitMin
OLAP\Process\AggregationMemoryLimitMax
Эти настройки, выраженные в процентах от объема памяти службы Analysis Services, определяют
память, выделенную для создания агрегатов в каждой секции. Когда службы Analysis Services
начинают обработку секций, параллелизм регулируется на основании настройки
AggregationMemoryMin. Например, если запустить пять параллельных заданий обработки секций
с настройкой AggregationMemoryMin = 10, то для обработки будет выделен предполагаемый
объем памяти в 50 %. Если объем памяти недостаточен, то задания обработки новых секций будут
блокироваться до тех пор, пока не появится достаточно памяти. Если обрабатывается несколько
секций параллельно, то уменьшение значения AggregationMemoryLimitMin может увеличить
скорость выполнения операции ProcessIndexes. Ограничивая минимальный объем памяти,
выделяемый для одной секции, на этапе обработки индекса можно добиться более высокой
степени параллелизма.
Подобно другим счетчикам службы Analysis Services, значение данной настройки, превышающее
100, интерпретируется как фиксированный объем памяти в килобайтах. Использование
абсолютного значения в килобайтах в компьютерах с большими объемами памяти может
обеспечить более совершенное управление памятью, чем использование процентного значения.
6.13.4.3
Настройка свойства CoordinatorBuildMaxThreads
При просмотре одной секции количество потоков, используемых для просмотра содержимого,
ограничено настройкой CoordinatorBuildMaxThreads. Эта настройка определяет максимальное
количество потоков, выделенное для задания обработки одной секции. Она подобна настройке
CoordinatorExecutionMode (см. раздел Архитектура задания). Если эта настройка имеет
отрицательное значение, то ее абсолютное значение умножается на количество ядер в
компьютере для определения максимального количества потоков, которые могут выполняться.
Если настройка имеет положительное значение, то оно равно абсолютному количеству потоков,
которые могут выполняться. Следует помнить, что в процессе обработки вы все равно ограничены
количеством потоков в пуле потоков процесса, а значит, увеличение данного числа может также
увеличить обработку пула потоков.
86
Partition
Process Job
Thread n
Thread 1
Thread 0
n = CoordinatorBuilMaxThread
Segments
Segments
Segments
Рис. 29. Свойство CoordinatorBuildMaxThreads
Если вам не удается достичь высокой степени параллелизма при помощи секций, можно
изменить значение свойства CoordinatorBuildMaxThreads. Увеличение значения позволит
использовать большее количество потоков для одной секции.
Следует заметить, что в некоторых случаях необходимо также изменить настройку
AggregationMemoryMin, чтобы получить оптимальные результаты .
7 Настройка ресурсов сервера
В процессе настройки приложения возникают ситуации, когда просто необходимо добавить
дополнительное оборудование или выполнить настройку самого сервера. В этом разделе
описаны серверные настройки, которые можно использовать для повышения
производительности.
7.1 Использование настройки PreAllocate
Настройка PreAllocate, которую можно найти в msmdsrv.ini, может использоваться для
резервирования физической памяти для службы Analysis Services. В установках, где службы
Analysis Services установлены параллельно с другими службами на одном компьютере, настройка
PreAllocate может обеспечить более стабильную конфигурацию памяти.
Необходимо заметить, что если учетная запись служб, используемая для работы службы Analysis
Services, также имеет право доступа Блокировка страниц в памяти, то PreAllocate приведет
службу Analysis Services к использованию памяти больших страниц. Параметр Блокировка страниц
в памяти настраивается с использованием gpedit.msc. Помните, что память больших страниц не
87
может быть выгружена в файл подкачки. Несмотря на то что это может способствовать
повышению производительности, огромное число выделенных больших страниц может привести
к тому, что система станет недоступной.
Если вы используете PreAllocate с большими страницами, необходимо оставлять примерно 20 %
общей системной памяти для работы системы.
Важно! PreAllocate оказывает огромное влияние на работу операционной системы Windows
Server® 2003. С внедрением Windows Server 2008 управление памятью значительно
усовершенствовано. Данная настройка тестировалась в Windows 2008 Server, но не
продемонстрировала существенных преимуществ использования PreAllocate на данной
платформе. Учитывая недостатки настройки PreAllocate, можно заключить, что она является
фактически бесполезной в Windows Server 2008.
Дополнительные сведения о влиянии настройки PreAllocate см. в следующей технической статье:

Сравнение работы служб Microsoft SQL Server 2008 Analysis Services в Windows Server 2008
и Windows Server 2003 и предварительное выделение памяти: извлеченные уроки
7.2 Отключение «Черного ящика»
«Черный ящик» обеспечивает механизм записи работы сервера службы Analysis Services в
краткосрочный журнал. «Черный ящик» предоставляет массу возможностей при устранении
определенных неполадок, связанных с запросами и обработкой, однако он оказывает
дополнительную нагрузку на подсистему ввода-вывода. Если вы находитесь в рабочей среде и
вам не требуются функции «Черного ящика», можете отключить ведение журнала, тем самым
сократив дополнительные временные затраты подсистемы ввода-вывода. Работа «Черного
ящика» управляется свойством сервера Log\Flight Recorder\Enabled. По умолчанию это свойство
имеет значение true.
7.3 Отслеживание и настройка памяти сервера
Обычно чем больше памяти вы имеете, тем лучше. Если файлы данных могут располагаться в кэше
операционной системы, производительность подсистемы хранилища неприхотлива. Если
обработчик формул способен кэшировать результаты, то значения ячеек используются повторно
вместо пересчета. Производительность также увеличивается, если избегать сброса результатов на
диск в процессе обработки. Однако нужно иметь в виду, что службы Analysis Services не
использует память расширений AWE в 32-разрядных системах. Если куб требует наличия большого
объема памяти, рекомендуется использовать 64-разрядное оборудование.
Основными настройками памяти являются Memory\TotalMemoryLimit и
Memory\LowMemoryLimit, которые выражаются в проценте доступной памяти. Можно
отслеживать память из диспетчера задач или посредством следующих счетчиков
производительности:

88
MSAS2008:Память\использование памяти, КБ


MSAS2008:Память\нижний предел памяти, КБ
MSAS2008:Память\верхний предел памяти, КБ
Если не используется настройка PreAllocate, службы Analysis Services отказываются от памяти при
отсутствии загрузки, в то время как другие приложения (например, ядро SQL Server) могут
использовать освободившуюся память и не отказываться от нее. Таким образом, важно правильно
настроить не только службы Analysis Services, но и другие приложения на компьютере.
Прежде чем принять решение о потребности в дополнительной памяти, выполните шаги,
описанные в разделах, посвященных запросам и обработке, чтобы оптимизировать
производительность куба.
8 Заключение
Данный документ предоставляет средства диагностики и рассматривает проблемы
производительности обработки и запросов службы SQL Server 2008 Analysis Services.
Дополнительные сведения см. в следующих разделах:
http://sqlcat.com/: группа поддержки пользователей SQL
http://www.microsoft.com/sqlserver/: веб-узел SQL Server
http://technet.microsoft.com/ru-ru/sqlserver/: технический центр SQL Server
http://msdn.microsoft.com/ru-ru/sqlserver/: центр разработки SQL Server
При наличии вопросов или замечаний обращайтесь к авторам статьи. Связаться с Richard
Tkachuk можно по адресу richtk@Microsoft.com или с Thomas Kejser по адресу
tjkejser@Microsoft.com.
Помог ли вам этот документ? Оставьте свой отзыв. Оцените этот документ по шкале от 1
(плохо) до 5 (отлично). Почему он заслужил такую оценку? Пример:

Относить ли хорошую оценку на счет удачных примеров, информативных снимков
экрана, ясного изложения, чего-либо еще?

Относить ли плохую оценку на счет неудачных примеров, неразборчивых снимков
экрана, невнятного изложения?
Ваш отзыв поможет нам повысить качество нашей документации.
Отправить отзыв.
89