13.1.1 BW - KPIs

В разделе ключевых показателей приводятся наиболее важные метрики и рекомендации по их корректировки/оптимизации.

Логический признак измененных записей

По умолчанию функции планирования IP или BPS не могут распознать изменившиеся записи в рамках сессии. Но случается так, что во многих случая должны обрабатываться только измененные записи, однако часто функциями обрабатывается весь объем данных. Рекомендуется в инфо-куб добавить "индикатор изменений " (новый InfoObject) для отслеживания изменившихся записей в рамках сессии. В результате функции планирования будут обрабатывать только изменившиеся записи, это позволяет существенно снизить объем обрабатываемых записей. SAP Note 1101726 описывает механизм применения данной логики.

Время выполнения функций планирования

Время выполнения функций планирования включает в себя время на выполнение логики функции планирования, время на чтение данных (фильтрацию) и чтение ссылочных данных. Длительное время выполнения функций планирования информирует о необходимости проверки логики и кода который используется для ее реализации. В показателе выводится максимальное время выполнения функции планирования в секундах и число обращений к ссылочным данным.

Режим кеширования запросов планирования

SAP Note 1026944 описывает новый, более производительный режим кеширования: cache mode 5 (BLOB/Cluster Enhanced), который наиболее подходит для работы с буферами планирования т.к. лучше поддерживает обработку результатов запросов состоящего из большого числа записей. По умолчанию Cache mode 5 не активен. Включение поддержки режима 5: RSADMIN параметр RSR_CACHE_ACTIVATE_NEW = X программа SAP_RSADMIN_MAINTAIN, установка режима кеширования для инфопровайдера осуществляется в транзакции RSRT или RSDIPROP.

Использование дельта-кеша

Показывает число запросов планирования для которых не используется "Update Cache Objects in Delta Process" переключатель в свойствах запроса RSRT. Это флаг уменьшает количество данных которые должны быть считаны из базы и увеличивает  производительность за счет использования кеша.

Производительность сервера блокировок

При параллельной работе нескольких пользователей время ожидания для установки блокировок для объектов планирования мжет занимать много времени. SM12 временно сигнализирует о большом числе блокировок. Рекомендуется сокращать число объектов блокирования путем отключения ненужных в транзакции RSPLAN (RSPLSE). Рекомендованный размер сервера блокировок - 200 MB.

Однако, часто возникает ситуация когда объектов блокирования и пользователей так много, что время выполнения операций записи/чтения таблицы блокировок существенно вырастает, что приводит к возникновению сообщения «Переполнение сервера блокировок для инфопровайдера», выходом из такой ситуации может быть полное отключение блокировок для функций планирования в экспертном режиме RSPLAN. В этом случае ключевым элементом для обеспечения целостности данных становятся полномочия на анализ. Дополнительная информация представлена в SAP Note 928044.

13.1.2.1 Largest DSO tables

Большой размер таблиц DSO объектов является индикатором для принятия мер по их оптимизации (например логическому разделению).

Имя DSO	Имя Активной таблицы	# Записей
TOAE15	/BIC/ATOAE1500	49.811.143
TOBL04	/BIC/ATOBL0400	41.656.192

13.1.2.2 Largest InfoCubes

Значение в столбце "Записей" это сумма числа строк в E и F таблицах куба. Если они превысят установленные ограничения, то им будет установлен сначала ЖЕЛТЫЙ, или КРАСНЫЙ уровень опасности. ЖЕЛТЫЙ уровень > 500,000,000 записей, КРАСНЫЙ > 1,000,000,000.

Имя инфо-куба	# Записей
TCAE04	274.104.828
TPSW02BU	209.938.263

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

Большое число запросов и записей в F-таблице фактов увеличивает время выполнения запросов, также увеличивается время на удаление и пересоздание вторичных индексов до и после загрузки данных в куб. Рекомендуется использовать сжатие запросов куба с максимально допустимой глубиной (например по последний закрытый период в ERP).

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

Приближение к критичным показателям является поводом для анализа наполнения кубов и их оптимизации (физическое, логическое партицирование, архивирование в NLS, использование семантически разделенных объектов и т.д.).

 

Также в блоке 13.1.2 приводится информация по:

• 13.1.2.3 Largest Master data tables (SID-tables)
• 13.1.2.4 Largest Master data tables (time independent: X-tables)
• 13.1.2.5 Largest Master data tables (time dependent: Y-tables)
• 13.1.2.6 Largest Hierarchy tables (I-tables)
• 13.1.2.7 Largest Validity tables (L-tables)

13.1.3.2 InfoCube Design of Dimensions

Раздел ошибки дизайна измерений инфо-куба показывает разницу между числом записей в таблицах измерений и таблицей фактов, допустимое отклонение не должно превышать 30%. Если значения инфо-объекта присутствуют в связке почти для всех записей таблицы фактов, то такой инфо-объект должен быть выделен в отдельное измерение позиций.