Библиотека Интернет Индустрии I2R.ru

При выборе индексов для Хранилища данных, следует помнить, что если вы используете базы данных Хранилища для создания OLAP-кубов, то выбранные вами индексы влияют на время обработки самих кубов. Вообще, решите, не добавить ли индексы для каждой таблицы фактов или измерений и описать связи между этими таблицами. Кроме того, подумайте о создании сводных индексов по всем внешним ключам в таблице фактов и индексов для каждого внешнего ключа в таблицах измерений.

Для достижения максимальной производительности следует правильно выбрать режим хранения - MOLAP, HOLAP, или ROLAP. Как правило, производительность при использовании MOLAP или HOLAP примерно одинакова, а применение ROLAP в любом случае ее понизит. Возможно, следует провести тест, чтобы определить, какой из режимов хранения данных (MOLAP или HOLAP) позволит добиться большей производительность.

С одной стороны, MOLAP требует больших объемов дискового пространства, чем HOLAP и ROLAP, которые примерно равны по этому показателю, хотя для HOLAP, скорее всего, необходимо меньше всего памяти.

Выбирая уровень агрегирования для кубов, лучше не выходить за рамки интервала от 25% до 60%. Как правило, при значениях, близких к 60%, повысится скорость обработки запросов, кроме того, создаваемые кубы не будут настолько большими, что для их построения потребуется слишком много времени и места на диске. Уровни агрегирования выше 60%, как правило, требуют огромных объемов дискового пространства и в большинстве случаев не приводят к существенному увеличению скорости обработки запросов.

Для достижения наивысшей производительности SQL-сервер с Хранилищем или витриной данных и OLAP-сервер должны быть на разных машинах.

Если ваши OLAP-кубы особенно велики или часто используются, возможно, стоит разместить их на отдельных специализированных серверах, чтобы распределить загрузку. Если же часто используется только один куб, создайте его копии на нескольких серверах, а затем распределите рабочую нагрузку по всем этим серверам.

Запланируйте обновление информации в кубах в периоды наименьшей загрузки сервера, чтобы не затруднять работу пользователей.

Объем памяти, используемый OLAP-сервером, можно установить, вызвав пункт меню "Properties" и выбрав вкладку "Environment". Параметр "Minimum allocated memory" по умолчанию равен половине объема вашей оперативной памяти (RAM). Стандартное значение параметра "Memory conservation threshold" равно общему объему RAM на сервере.

Если ваш сервер используется для обработки одного из нескольких кубов - что настоятельно рекомендуется - возможно, следует установить значение "Minimum allocated memory", равное примерно 90% памяти вашего сервера. В этом случае исчезнет необходимость в определении пространства, доступного для работы OLAP-сервера.

Количество обрабатываемых OLAP Service нитей можно установить, вызвав пункт меню "Properties" и выбрав вкладку "Environment". Параметр "Maximum number of threads" по умолчанию равен удвоенному количеству процессоров на вашем сервере (то есть, если у вас четыре процессора, то это значение будет равно восьми). Максимальное значение этого параметра равно 1000.

Следует выяснить, насколько загружены ваши процессоры, определив значения System Object: % Total Processor Time и System Object: Processor Queue Length. Если эти значения свидетельствуют о том, что процессоры не перезагружены, возможно, следует увеличить количество нитей. Чем больше их число, тем выше потенциальная производительность сервера.

Если вы решили произвести подобное изменение, используйте Performance Monitor до и после каждого шага, чтобы выяснить, не вызвали ли вы нехватки ресурсов. Продолжайте увеличивать количество нитей до тех пор, пока производительность не перестанет расти, при условии, что мощности процессоров достаточно.

Если на сервере имеется большое количество RAM, возможно, вам захочется увеличить "Read-ahead buffer size", который можно установить, вызвав пункт меню "Properties" и выбрав вкладку "Processing". Значение, установленное по умолчанию, равно 4 Мб. Этот параметр используется для хранения информации, которая в будущем может понадобиться OLAP-серверу. Чем больше размер этого буфера, тем больше вероятность того, что содержащиеся в нем данные действительно понадобятся.

Как и во всех других случаях при изменении конфигурации сервера, проводите тест, чтобы выявить изменения производительности. Возможно, целесообразно постепенно увеличивать значение этого параметра на 2 Мб до тех пор, пока производительность не перестанет расти или начнет падать.

При разработке OLAP-кубов не включайте в них меры или измерения, которые не будут использоваться. Для этого необходимо проводить качественные анализ и проектирование систем. Неиспользуемая информация увеличит размер куба и снизит производительность.

При использовании мастера "Storage Design Wizard" необязательно придерживаться приведенных рекомендаций. Вы можете экспериментировать с различными компромиссными вариантами, повышая производительность или снижая объем используемого дискового пространства. Если у вас много места на диске и время обновления данных в кубе не принципиально, возможно, следует повысить количество агрегатов данных, содержащихся в кубе.

Создавая OLAP-куб, используйте мастер "Usage Analysis Wizard", чтобы проанализировать обрабатываемые запросы, а также мастер "Usage-Based Optimization Wizard", чтобы повысить производительность.

Если у вас корпоративная версия SQL-сервера (Enterprise version), возможно, следует поделить OLAP-кубы на партиции для повышения производительности. Партиция представляет собой отдельно управляемый элемент хранения. Каждая партиция может иметь свой собственный режим хранения данных и уровень агрегирования. Использование партиций имеет ряд преимуществ:

• Вы можете разместить партиции куба на разных дисках (или матрицах дисковых накопителей) с целью лучшего распределения рабочей нагрузки между несколькими устройствами ввода/вывода.
• Вы можете поделить кубы на партиции, чтобы структурировать данные по интенсивности использования. Допустим, у вас имеется информация за пять лет, причем 80% запросов связаны с данными за последний год, и лишь 20% - с более ранними. В этом случае целесообразно поместить данные за последний год в одну партицию, остальные - в другую. Тогда вы можете выбрать разные уровни агрегирования для каждой партиции, что положительно скажется как на размере куба, так и на его производительности.
• Партиция - это единица разбиения для обработки нити при загрузке куба. Это означает, что на серверах с несколькими центральными процессорами добавление партиций ускоряет загрузку куба.

OLAP и Analysis Services предлагают мастер "Usage-Based Optimization Wizard", который использует так называемый лог запросов (Query Log). Query Log предназначен для оптимизации агрегации куба, основываясь на фактическом использовании данных пользователями. По умолчанию в логе регистрируется 1 из 10 запросов. Мастер использует запросы, записанные в логе, для выработки рекомендаций, направленных на оптимизацию агрегатов кубов.

Существует два варианта, посредством которых Query Log может повлиять на производительность серверов OLAP и Analysis Services. Во-первых, одного из 10 запросов может не хватить, чтобы оптимизировать все запросы к кубу. Значение же 1 из 2 или 1 из 5, возможно, окажется более подходящим.

Вы можете менять это значение в интервале от 1 из 1 до 1 из 10.000. Для этого выполните следующие инструкции:

1. Находясь в Analysis Manager (или OLAP Manager), щелкните правой кнопкой мыши на соответствующем сервере и выберите "Properties", а затем "Logging Tab".
2. Используя опцию "Write to long once per __ queries", вы можете указать необходимое значение (1-10,000).

Конечно, частая регистрация запросов может негативно сказаться на производительности сервера. Поэтому следует ограничить размер сохраняемой в Query Log информации. Вы можете сохранять результаты за несколько часов, несколько дней или даже несколько недель, пока не почувствуете, что зарегистрировали необходимое количество запросов и Wizard имеет достаточно информации для выработки рекомендаций. Но как только этот тест завершен, не забудьте отключить Query Log (это можно сделать в диалоговом окне, которое было описано выше).

Как вы могли догадаться, причина второго варианта влияния Query Log на производительность заключается в том, что для поддержки лога он использует ресурсы процессора и устройств ввода/вывода. Если обрабатываются несколько запросов, использование лога не окажет значительного воздействия на производительность. Но если постоянно выполняется много запросов, возможно, следует отключать эту опцию и использовать ее только тогда, когда необходимо собрать данные для оптимизации, осуществляемой мастером "Usage-Based Optimization Wizard".

Очень часто время обработки куба может быть существенно снижено за счет использования опции "Optimize Schema" в меню Tools. Когда эта опция включена, автоматически отслеживаются и удаляются ненужные связи между таблицами фактов и измерений. Уменьшив количество ненужных связей, можно значительно снизить время обработки куба.

Для того чтобы данная опция работала эффективно, необходимо выполнить следующие условия:

• Таблица измерений должна быть совместно используемой. Кроме того, она должна быть обработана как минимум один раз к моменту запуска "Optimize Schema".
• Столбец числовых ключей для низшего уровня в таблицы измерений должен также содержать ключи, которые относятся к таблице фактов и таблице измерений, причем должен быть единственный ключ, устанавливающий отношение между таблицей фактов и таблицей измерений.
• Ключи в столбце числовых ключей для низшего уровня таблицы измерений должны также быть уникальными.
• В кубе должен быть представлен низший уровень таблицы измерений. Хотя этот уровень может быть невиден (спрятан), он не должен быть отключен.