Коллеги.
Идёт обновление цели данных и выбор на правилах данных из основных данных другого инфообъекта по неключевому значению.
Работает не быстро, особенно если помножить на много записей.
Чтобы ускорить, вижу вариант создать индекс на таблицу инфо-объекта по выбираемому полю.

Кроме того. что понадобится ключ на объект - какие проблемы могут возникнуть?
Какие есть альтернативные варианты ускорения выборки?

в порядке убывания важности.

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

2. индекс, но надо делать непосредственно в продуктиве, открывать на изменения систему. потом желательно убедиться (если ускорение незаметно), что он используется (смотрим трассировку и план запроса в st05).

3. буферизация таблиц мастер-данных, не факт, что поможет, тут надо смотреть на статистику.

P.S. есть еще варианты.

важно перед тем как индексировать, посмотреть трассировку в st05 для запроса чтения мастер данных, найти нужный SQL-запрос, важно знать, какую конкретно таблицу читаем (P-,X-,Y-...). после этого надо в st05 зайти в SQL и посмотреть план запроса, если есть "full table scan", то индекс нужен практически 100%. далее читайте НОТЫ =)

Спасибо. Где-то так и думал, что можно всё, только нужно с головой делать.

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

Добавлю свои 5 копеек.

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

REPORT Z_INDEX.

*----------------------------------------------------------------------*
* Selection screen
*----------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME TITLE TEXT-001.
PARAMETERS: P_TABN TYPE TABNAME OBLIGATORY,
P_INDEX TYPE INDEXID OBLIGATORY.

PARAMETERS: P_CRT TYPE C RADIOBUTTON GROUP G1,
P_DEL TYPE C RADIOBUTTON GROUP G1.
SELECTION-SCREEN END OF BLOCK B1.

*----------------------------------------------------------------------*
* Main code
*----------------------------------------------------------------------*
START-OF-SELECTION.

* Create index
CASE 'X'.
WHEN P_CRT.
CALL FUNCTION 'DD_CREATE_INDEX'
EXPORTING
INDEXNAME = P_INDEX
TABNAME = P_TABN
EXCEPTIONS
BASETAB_ERROR = 1
DB_ERROR = 2
DD_ERROR = 3
INDEX_EXISTS = 4
OTHERS = 5.

* Delete index
WHEN P_DEL.
CALL FUNCTION 'DD_DROP_INDEX'
EXPORTING
TABNAME = P_TABN
INDEXNAME = P_INDEX
EXCEPTIONS
INDEX_NOT_DROPPED = 1
PROGRAM_NOT_GENERATED = 2
PROGRAM_NOT_WRITTEN = 3
OTHERS = 4.

ENDCASE.

Спасибо за код. Это хорошо для своих табличек. А каким ФМ можно определить и создать индекс "с нуля"?
На DEV системе идёт постоянная перегенерация объектов и BW таблички пересоздаются, "забывая" о созданных собственных индексах. А потом ищешь причину резкого падения производительности

А чем таблицы признака принципиально отличаются от "своих"?

Видимо этим же.


Тогда этот код тебе и нужен.

Это при учете, селективность (отношение размера выборки к размеру таблиц) низкая.
Например, если идет "full table scan" по полю bool ("" или "Х" - селективность высокая), то от индекса станет только хуже.

Как раз имею ввиду индекс не по первичному ключу, а по произвольным полям. Когда идёт перегенерация инфо-объекта, то может пересоздаваться сама таблица и информации об индексах не остаётся.
Эти ФМ удаляют/восстанавливают индексы из DB, оставляя определение в DD.

Тогда прошу прощения.
1. Можно попробовать банально SQL-оператором индексы создать
2. Отдебажить "инструментальное" создание индексов.

И еще. Поскольку ораклом не занимался, изучил вопрос по селективности можно не переживать оптимизатор работает намано и сам отрубает индексы.

Да как-то в решении, которое будет ещё, возможно, продаваться использовать native SQL стрёмно.

Тут как-раз идея заставить app server взаимодействовать с oracle, чтобы они как бы одинаково думали. Каждый запрос проверяется на использование индексов в ST05.

Должен же быть ФМ создания.... Хотя тут ответ простой - есть место откуда можно потрейсить Вопрос времени, как обычно.

С соблюдением стандарта (SQL92) ничего стремного не вижу. Ей богу в дебаге инструментария где-то натыкался именно на такое решение. Вот только не помню, индексы это были или нет. Правда там были завязки на СУБД.