Активировал для куба BW-статистику на предмет выявления причин долгого выполнения запроса. Посмотрел ее. Параметр QTIMEOLAPINIT очень высок (20-25 секунд), при этом время на выполнение запроса и его отображение суммарно 2-3 секунды. В документации сказано, что параметр этот охватывает время загрузки и компиляции запроса, повторное выполнение запроса проходит быстро и параметр этот уже где-то 2 секунды (хотя иногда и три раза вподряд выполнишь запрос, а он равен 20 сек). Если все так и должно быть, то все-равно непонятно, почему так долго компилируется запрос?!

а может быть дело не в компиляции запроса? попробуй проанализировать статистику в st03

ST03, насколько я понял, использует статистику из таблицы RSDDSTAT. Я как раз привел значение из этого столбца. К тому же ST03 дает усредненную оценку запроса или куба. Вот содержание этой таблицы для несколькиз запросов

QTIMEOLAPIINIT QTIMEOLAP QTIMEDB QTIMEVARDP
20,238281 0,234375 2,414062 13,609375
19,191407 0,097656 0,601563 11,261719
14,214844 0,093750 0,457031 11,339844
1,195313 0,101563 0,000000 2,007813
1,789063 0,101563 0,000000 1,636719
0,535156 0,101564 0,000000 4,667969
21,609375 0,101563 0,640625 4,753906
0,414062 0,101562 0,000000 2,113281
0,328125 0,109376 0,000000 1,640625
1,082032 0,117188 1,335937 2,105469
23,136719 0,109376 0,343750 2,074219

продолжение

QTIMEUSER QTIMECLIEN TIMECHAVLR TIMEAUTHCH
0,000000 4,058594 0,125000 2,031250
0,000000 4,121093 0,054688 0,035156
0,000000 2,648437 0,046875 0,023438
0,000000 2,683594 0,007812 0,023438
0,000000 2,621094 0,000000 0,023438
0,000000 2,640624 0,003906 0,035156
0,000000 2,367188 0,007812 0,031250
0,000000 2,773439 0,003906 0,027344
0,000000 2,531250 0,007812 0,019531
0,000000 2,664062 0,003906 0,023438
0,000000 2,636719 0,007812 0,156250

Переиндексацию куба давно делал?
Кстати, какой для запроса стоит режим выборки данных - по мере раскрытия иерархий или все данные сразу?

2 bkmz

READMODE = H

Что такое переиндексация куба?

st03 действительно использует данные статистики. однако по поводу усредненных значений - это заблуждение.

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

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

Естественно перед загрузкой в цепочке процессов индексы удаляются, а после воссоздаются.

ST03 - отражает данные по запросу, но не по шагам навигации и использует для этого таблицу RSDDSTAT, в которой информация представлена в более детализированном виде (по каждому шагу навигации). Распечатку данных из нее я уже приводил. Из нее видно,
что поле QTIMEDB не превышает 3 сек. в самом худшем случае.
Согласно документации оно включает интервал времени от момента
обращения сервера приложений к БД и до возврата результата на сервер приложений. Поэтому агрегаты, индексы, ST03 здесь не причем.

Вопрос все еще актуален

)

удачи в поиске решения.

Надеюсь ознакомление с этим материалом немного развеет туман, который здесь напустили
http://www.sapteched.com/pdfs04/SDN301/SDN301.pdf

Не слишком обнадежило...