Добрый день. Имеется система SLES 10, Oracle 10.2.0.2, SAP NW (BI 7.0).
При выборках из кубов наблюдается крайне низкая производительность.
Выборки следующего вида:

SELECT ... FROM "/BIC/EIC_C03" ... JOIN "/BIC/DIC_C032" ... JOIN "/BI0/XMATERIAL" ...

В вопросах буду рассматривать таблицу /BIC/EIC_C03 (21 млн. записей). На ней, исходя из трассировок, затыки и происходят (есть еще несколько таких же, но решив с одной - решится и с другими).
---
Вопрос собственно следующий, как ускорить данные выборки (дополнительно к тем телодвижениям, которые опишу ниже)?
Есть ли возможность обойти JOIN'ы?
Оракловая опция STAR_TRANSFORMATION отключена (согласно ноте САП). При включенной опции, выборки из кубов, нарисованные программерами, валятся в дамп по Оракловым ошибкам.
Статистики собираю по таблицам
---
На данные момент внедряю следующее (пока не сделано):
1. Обновление Оракла до 10.2.0.4 и накат последних патчей.
2. Секционирование таблицы /BIC/EIC_C03.
3. Создание индексов в режиме nologging.
4. Конвертация БД на 32Kb размер блока данных ОРАКЛа (на данный момент - 8Kb).

Каково состояние БД?
Хиты в st04?
Свопы в st02?
Индексы целые?
(горе-консультанты часто в цепочках индексы грохают, но не факт что индексы потом нормально на кубике восстанавливают)

"Есть ли возможность обойти JOIN'ы?" - тр. rsrt и /h...
"выборки из кубов, нарисованные программерами, валятся в дамп по Оракловым ошибкам." - какие именно ошибки?
А чем они рисовали, мышкой в BEx-е или руками свой код писали?

Вот Вы пишите, что отключили стартрансформейшен.
Можно номер ноты в студию?
(Для 9-ки актуальна нота 632556)

САП уже одобрил 10.2.0.4 для 7-ки?
(Надо же как время то бежит...)

"Секционирование таблицы /BIC/EIC_C03" - может Вы имели ввиду партиционирование?
Дык это при проектировании делать надо было.
Или теперь кубик перезаливать придеца, хотя в 7-ке кажеца больше возможностей в этом плане...

"Создание индексов в режиме nologging." - а чем именно Вам поможет то, что индексы не будут логироваться?
(
Сколько годков с ораклой работаю, а не знал, что отключение логирования влияет на скорость выборки...
Это что то новое.
Расскажите подробнее.
)

8192 - стандарт это саповский...
(32к Вам не поможет)

ЗЫ Агрегировать не пробовали?

ЗЫ ЗЫ Вообще причин может быть очень много...
Смотреть однако нужно...
Все смотреть, от настроек БД+BW до времени I/O БД на дисках.

На уровне ОС во время данных выборок наблюдается только высокая загрузка процессоров (по данному направлению сейчас занимаюсь оптимизацией значений параметров ОРАКЛа).
Индексы на уровне ОРАКЛа пересоздавал. На данный момент программеры, которые разработки свои внедряли, отсутствуют, так что вопрос по удалению и созданию индексов (делали втихаря) остается пока открытым и вопросы по этому процессу снимаются.
По поводу JOIN'ов - это понятное дело. Сформулирую вопрос по другому, а нужно л обходить JOIN'ы ?


Изначально мышкой, потом частично перерисовывали руками.


Сходу не скажу, много всего перелопачено. Вспоминается фраза, что оптимизатору 10-ки по барабану, включен он или нет. Хотя возможно это только в некоторых случаях (как-то с битмапными индексами, например). Дополнительный вопрос по стартрансформу: Насколько я понял, имеет смысл его все же включить и разобраться с ОРАКЛовыми ошибками, возникающими при выборках ?


В конце июня - начале июля... Раньше и не планировали...


Проектирование чего имеется ввиду ?
А зачем перезаливать кубик, если можно на уровне СУБД сделать из обычной таблицы секционированную (ну, или, партиционированную, одно и то же) и зажить спокойно ? Или могут быть подводные камни (с SAP BI на самом деле знаком не так давно) ?


Тут имел ввиду, в какой момент происходит создание/удаление индексов. Отключая логирование - уменьшаем время ожидания данного действа, а не скорость выборки. Пока вопрос закрыт. Нужна инфа от создателей кубов.


Уточнил применительно к САПу. Согласен, хотя для хранилищ могли бы уж и расстараться уйти от вездесущей 8.

"Тут фея взмахнула палочкой и у танка отвалилась башня..."

Для 10-ки нота 830576

STANDARD PARAMETER RECOMMENDATIONS FOR ORACLE 10.2.0.2
**************************************************

Parameter Recommendation
------------------------------- ------------------------------------
BACKGROUND_DUMP_DEST <SAPDATA_HOME>/saptrace/background
COMMIT_WRITE Do not set
COMPATIBLE 10.2.0
CONTROL_FILES At least three copies on
different disk areas
CONTROL_FILE_RECORD_KEEP_TIME 30 or higher
CORE_DUMP_DEST <SAPDATA_HOME>/saptrace/background
DB_BLOCK_SIZE 8192
DB_CACHE_SIZE Size depends on the available
memory (Notes 789011, 617416)
DB_FILES Larger than the number of data files
to be expected in the short term
DB_FILE_MULTIBLOCK_READ_COUNT Do not set
DB_NAME <db_name>
DB_WRITER_PROCESSES Only set in case of increased
DBWR load (Notes 79341, 793113)
EVENT
"10027 trace name context forever, level 1" (Note 596420)
"10028 trace name context forever, level 1" (Note 596420)
"10162 trace name context forever, level 1" (Notes 977319,
1040300)
"10183 trace name context forever, level 1" (Note 128648)
"10191 trace name context forever, level 1" (Note 128221)
"10629 trace name context forever, level 32" (Note 869521,
other settings of events 10626 / 10629 also allowed)
"10891 trace name context forever, level 1" (Note 1037651)
"14532 trace name context forever, level 1" (Note 1031682,
>= 10.2.0.2, Fix 5618049 must be implemented)
"38068 trace name context forever, level 100" (Note 176754)
"38087 trace name context forever, level 1" (Note 948197,
>= 10.2.0.2, Fix 5842686 must be implemented)
FILESYSTEMIO_OPTIONS SETALL (Note the restrictions from
Note 999524)
LOG_ARCHIVE_DEST Do not set!
LOG_ARCHIVE_DEST_1
"LOCATION=<SAPDATA_HOME>/oraarch/<sid>arch"
LOG_ARCHIVE_FORMAT %t_%s_%r.dbf
LOG_BUFFER 1048576 (Actual value may
be different, see comment below.)
LOG_CHECKPOINTS_TO_ALERT TRUE
MAX_DUMP_FILE_SIZE 20000
OPEN_CURSORS 800 (up to a maximum of 2000)
OPTIMIZER_FEATURES_ENABLE Do not set
OPTIMIZER_INDEX_CACHING OLTP: 50
OLAP: Do not set.
OPTIMIZER_INDEX_COST_ADJ OLTP: 20
OLAP: Do not set.
OPTIMIZER_MODE Do not set
PARALLEL_EXECUTION_MESSAGE_SIZE 16384
PARALLEL_MAX_SERVERS #DB-CPU-Cores * 10
PARALLEL_THREADS_PER_CPU 1
PGA_AGGREGATE_TARGET OLTP: 20 % of available memory
OLAP: 40 % of available memory
PROCESSES #ABAP work processes * 2 +
#J2EE server processes *
<max-connections> +
PARALLEL_MAX_SERVERS + 40
QUERY_REWRITE_ENABLED FALSE
RECYCLEBIN OFF
REMOTE_OS_AUTHENT TRUE
REPLICATION_DEPENDENCY_TRACKING FALSE (if no replication
is used)
SESSIONS 2 * PROCESSES
SHARED_POOL_SIZE 400 MB or greater, refer to Note 690241
STAR_TRANSFORMATION_ENABLED TRUE
UNDO_MANAGEMENT AUTO (Note 600141)
UNDO_RETENTION set if required (refer to Note 600141)
UNDO_TABLESPACE PSAPUNDO (Note 600141)
USER_DUMP_DEST <SAPDATA_HOME>/saptrace/usertrace
_B_TREE_BITMAP_PLANS FALSE
_BLOOM_FILTER_ENABLED FALSE (see Note 1119194)
_FIX_CONTROL
'4728348:OFF' (10.2.0.2, if fix 5397482 from Note 981875
has not been implemented, refer to Notes 964858 and 997889)
'5705630:ON' (10.2.0.2, if the fix 5705630 from Note 981875
has been implemented)
'6660162:ON' (10.2.0.2, if the fix 6660162 from Note 981875
has been implemented)
'6440977:ON' (10.2.0.2, if the fix 6440977 from Note 981875
has been implemented)
'6626018:ON' (10.2.0.2, if the fix 6626018 from Note 981875
has been implemented)
_INDEX_JOIN_ENABLED FALSE (10.2.0.2, refer to Note
964858)
_IN_MEMORY_UNDO FALSE (up to and including 10.2.0.3, if fixes
5363584 and 4899479 from
Notes 980805 and 1013476
are not implemented)
_OPTIM_PEEK_USER_BINDS FALSE (see Note 755342)
_OPTIMIZER_MJC_ENABLED FALSE (Note 176754 (30))
_SORT_ELIMINATION_COST_RATIO 10 (See Note 176754 (16))
_TABLE_LOOKUP_PREFETCH_SIZE 0 (Note 1109753)

ORACLE 10.1: ADDITIONAL/ALTERNATIVE PARAMETER SETTINGS
*********************************************************

Parameter Recommendation
------------------------------- ------------------------------------
COMPATIBLE 10.1.0
EVENT 10040 (Level 1, Note 899070)
RECYCLEBIN Do not set
_OPTIMIZER_OR_EXPANSION DEPTH (10.1.0.5 or higher, Note 849229)
_PGA_MAX_SIZE Only for BW:
400MB as of PGA_AGGREGATE_TARGET>4G
600MB as of PGA_AGGREGATE_TARGET>8G
800MB as of PGA_AGGREGATE_TARGET>12G
_RECYCLEBIN FALSE

NOTES ON THE RECOMMENDED PARAMETERS
*****************************************

BACKGROUND_DUMP_DEST
Path for alert log and background trace files
COMPATIBLE

Так, шта стартрансформейшен тру и память на этот раз Вам изменила...
И не надо Вам оракловые параметры подбирать - сап за Вас их уже 100 лет тому назад протестировал, опробировал и задокументировал.
(Кстати, сап-поддержка активно общаеЦа с Ораклом. И если настоятельно их попросить, то они в Оракл запрос пошлют. Там все серьезно, не по деЦки...)

ИМХО Еще и с эвентами нужно серьезно разбираЦа... мдя...

По поводу 10.2.0.4 - в матрице сап-продуктов пока что ее не видно...

По поводу индексов - rsa1 -> infoprovider -> биноКл -> имя куба -> manage -> performence -> проверяем состояние индексов кубика.

В базе напрямую (индексы & партиции) - категорически не рекомендую!
Наживете себе проблем на всю оставшуюся, указанную в трудовом договоре и еще после Вас людям куча проблем останеца...

Это на самом деле просто.
В тр. DB02 - рефрешим и смотрим разбитые индексы и объекты сап-словаря...

Кстати, не плохо бы и оракловый словарь проверить и чтобы инвалидов в БД не было...

По поводу джоинов - это от задач зависит.
Часто без них просто не обойтись.

Логирование влияет на скорость создания конечно, но в основном на время DDL....
Отключите - будет Вам тихий уЖос если придеЦа систему восстанавливать.

Вообще говоря, битмапы при заливке должны убиваЦа, а Б-три как жили на фактических табличках, так и пусть себе живут...
Не трогайте их...

ЗЫ ИМХО Ну не в том месте Вы "роете"...
Для начала рекомендую почитать ноты и установить для БД вышеописанные параметры.

Узнаю ноту...
Спасибо за остальную инфу.