Уважаемые форумчане, подскажите, существует ли какая-нибудь "легальная" возможность создания индекса на PSA-таблице?! Если создать индекс в системе разработки, то перенести его не получится, т.к. сама таблица принадлежит пакету $tmp. Положить таблицу в не-$tmp-пакет, как я понимаю, тоже не получится, так как при переносе в тестовую систему PSA-таблица генерируется с другим именем. Создать напрямую в тестовой системе индекс на PSA-таблице нельзя, так как запрещены изменения (да и сама идея создавать индексы отдельно, а не в запросе на перенос - не радует). Создавать индексы непосредственно в БД - тоже кривое решение.

Вместе с тем, встречаются ноты, которые косвенно указывают на то, что индексы каким-то образом возможно создавать, например:
1042182 - Secondary index is inconsistent for PSA tables
В ней есть фразы


Попытался добиться появления индекса на PSA-таблице в разработке, но так в итоге ничего и не получилось

PS: Интересует именно индекс на "классической" PSA-таблице источника данных

Так вроде Вы уже процитировали подсказку: в источнике данных на стороне BI (закладка "Поля") есть колонка галок "Ключевое поле". Вопрос только в том, как его заполнить.

Попробуйте ключевое поле задать в структуре ИД в исходной системе, семантический индекс создавать на самой таблице PSA в BW. Договоритесь с базисом или если есть права сами, откройте систему продуктива на изменяемую сгенерите индекс и закрывайте.

Поле-то есть, да только в источнике данных на стороне BI (источник данных RSDS) оно "засерено". Да и вообще, если взять стандартный источник, например, 0FI_AR_4, то у него отмечены ключевые поля

BUKRS
FISCPER
BELNR
BUZEI
UPOSZ

но на PSA нет никаких вторичных индексов, да и первичный они не входят

Еще вот такая нота есть 1701750 - DataSource: Secondary index on PSA, но в ней опять-таки указана фраза



Так что непонятки остаются

Что такое Семантический индекс создавать на самой таблице PSA в BW?!

Возможность о создании индекса в тестовой и продуктивной системе отклонена изначально! Скорее на БД создадут, но это все коряво

Да, поле "серое", и не открывается при очистке PSA - я об этом упоминал.
0FI_AR_4 - он как раз по умолчанию не RSDS, а ISFS. На нем индекса действительно не наблюдается. А вот, например, у 0FI_AR_30 (R3TR RSDS) - он есть (нота для 7-ки, и указано, что индекс предназначается для использования трансформацией).
С переносом между системами проблем быть не должно, флажки зайдут из ERP при репликации для каждой системы, попадут, похоже, в RSDSSEGFD-KEYFIELD, и при активации источника в BI индекс благополучно будет создан.

Приветствую!

Как вариант, можно попробовать создать индекс абапом (sql'ем), определяя имя psa-таблицы с помощью соответствующего функционального модуля.

Нота 1677278, программа ROSOA_CHANGE_KEY. Правда таким образом получится создать только один вторичный индекс. Ну хоть что-то!

Acknowledgements: Online, Mergens и service.sap.com!

Исходная задача неизвестна, но можно вспомнить еще такую экзотику как BI-источник на PSA таблице (нота 894771). Может получиться второй индекс.

Ну от того, что на PSA таблице создали generic-источник данных, вторичных индексов у нее не прибавится

Да, но появится вторая PSA таблица с идентичным содержимым (кроме служебных REQUEST, DATAPAKID, PARTNO, RECORD), для которой можно будет задать свой индекс KEY. И это, например, стало бы выходом для 0FI_AR_4, если не мигрировать.

Вторичный индекс на PSA нужен, чтобы ускорить выборочное чтение из нее (в ней под 100 млн. записей) Переливать все данные из этой PSA в другую PSA с помощью generic-экстракции только ради того, чтобы из нее потом прочитать по другому индексу - это великое извращение!

PS: Дальнейшее обсуждение не имеет смысла, так как для текущих задач одного вторичного индекса хватило. Так что тема решена