Есть большой куб с 10 признаками и 20 показателями с кучей атрибутов, c объемом ~80млн строк. Ежедневная загрузка новых данных ~120т строк. Данные нагружены за 2 года. БД Оракл 10, памяти 8Гб, Винд, рейд на дисковом массиве, процы Ксеон. Куб сжат. Таблица F пустая. Каждый признак находиться в отдельном измерении, измерения небольшие относительно основного куба.

Есть отчет на этом кубе, время работы отчета неприлично долго. Во время работы в Оракле висит событие "последовательное чтение". Создаем агрегаты, лучше, но все равно долго. Удалили агрегаты. Акселератор пока не будем смотреть.
Смотрим Таблицу Е партицированна по месяцу. Изменяем Таблицу Е, удаляем лишние месяца, оставляя пока толька нужные нам месяца, сразу выделяем нужный размер партиции. Смотрим, лучше, но не достаточно. Ставим количество паралелльных количество потоков 8 (сервер должен правильно настроен!!!). Время работы доходит до 1-1,5 мин если делать за весь период, железо тянет. Нас устраивает, но можно еще. Идеи еще есть, выложу позже. Вот как-то так можно добиться проиводительность.

ВНИМАНИЕ. Если вы будете планировать подобные действия со своей базой, убедитесь что есть бекапы и вы сможете с них восстановиться. И учесть возможность железа, настройки БД.

И остался один вопрос. Почему пользователь оставляет два показателя в отчете. В БД идет расчет по все показателям.

1. Если план выполнения запроса показывает full scan, то этому может быть несколько причин:

- отсутствуют или невалидны индексы (что маловероятно, особенно на E-таблице)
- неактуальна/не собрана/собирается недостаточно часто статистика на уровне Oracle
- читается слишком много данных (оптимизатор Oracle принимает решение читать full scan-ом всю таблицу, а не индексы, несмотря на актуальную статистику; раз у вас таблица партицирована по календарному месяцу, и он используется в качестве ограничения в фильтре, то наиболее вероятен вариант full scan партиции/партиций)
- выводится слишком много данных (то есть большая часть времени уходит на формирование самого отчета, а не на извлечение из DB - это конечно не причина full scan-а, но тоже может существенно влиять на общее время отклика с момента ввода параметров до получения результата)
- запрос в BEX построен неоптимально

Большую часть вопросов можно проверить при отладке запроса в RSRT

2. Ну значит пользователю нужны только эти два показателя. Что уж тут поделать! Либо эти два показателя вычисляются на основе других, либо пользователь хочет видеть только эти два показателя в начальном ракурсе, но иметь возможность, при желании, отобразить и остальные в процессе навигации (если это было предусмотрено в настройках запроса)

Индексы, статистика - это первое что было проверено. Вычисляемых покателей нет(пока).
В измерениях данных немного, в отчет тоже выводиться данных немного, в основном они все агрегируются. Да и на самом отчете стоит ограничение 1 млн. яйчеек. Поэтому и идет full scan, вопрос только был какой индексный или табличный full scan. Выяснили, что табличный, вот и выставили распараллеливание.
Планируем в дальшейшем переместить в отдельное ТП с большим размером блока, индексы подтюнить. Пока смотрим и собираем информацию об долгоиграющих отчетах.
Можно по подробнее как "запрос в BEX построен неоптимально", может мы что-то пропустили.
Увидели еще интересную вещь, если пользователь оставляет в отчете несколько нужных показателей (не вычисляемых) без признаков, всегда идет расчет всех показателей, и помимо этого ВСЕГДА считается count() и идет группировка по sid_ounit. А все это дополнительная и не нужная нагрузка.

1. Сколько записей в % отношении (или абсолютном) извлекается по отношению к общему количеству записей в кубе?
2. Сколько записей в % отношении (или абсолютном) выводится в отчете по отношению к извлекаемому количеству?
Рассчитав эти показатели можно понять целесообразность создания агрегатов и понять причину full scan. А оперировать терминами "немного" и "в основном они агрегируются" - это разговор ни о чем.

Это что еще за ограничение такое?!

Не видя структуру запроса давать какие-то советы почти бессмысленно. Самое простое - может у вас там в ограничениях много исключений (что приводит к OR-инструкциям на уровне БД и отключению индексов), а может у вас ограничения стоят в основном на показателях, а не в фильтре, при этом сам запрос может разделяться на подзапросы (это зависит от ограниченных показателей, имеет смысл запустить ST05 трассировку и оценить планы и время выполнения запросов, сравнить с планами и временем, которые RSRT выдает, кэш при этом лучше отключать или сбрасывать). А может у вас там виртуальные признаки и показатели используются. А еще может в свойствах запроса стоять извлечение всех данных фильтра, а не только тех, которые нужны для навигации и отображения данных. Короче, это просто практика, тут самим надо ковыряться, понимая почему данные извлекаются именно так, а не иначе

Попробуйте NODIM() использовать, как вариант.

Note 1127156

В каком курсе или best practics можно подробно почитать про RSRT.

Вряд ли можно считать сообщение "Result set is too large; data retrieval restricted by configuration" решением проблемы выполнения тяжелых отчетов

Основное - в BW360 и TBW42_1.

Нет, но в ноте описано как установить "maximum number of cells for the result set". У нас стоит 1млн в BEX Web.

Спасибо =))

ассистент, вы для начала уберите все расчетные показатели из отчета, все виртуальные показатели отключите.
лучше скопировать отчет конечно, чтобы продуктив не ломать. кроме того, раз уж вы партицируете по месяцам, то переменная должна быть в глобальном фильтре по месяцу или user-exit или обязательная для ввода.

и еще, что у вас там, есть аналитик, который в состоянии проанализировать отчет из миллиона ячеек??? давайте его нам, есть работа)