Возникла задача - мониторить факт изменений определённой очень ограниченной группы полей за фиксированный период. Скорость обращения к CDPOS не то чтобы очень.
Можно ли из числа полей, входящих в первичный ключ кластера построить альтернативный unique-индекс, чтобы select шёл через index range scan по нему (например поднять CDPOS-CHANGENR в левую часть индекса)? Или для кластерных таблиц так впринципе делать нельзя (rdbms oracle)?

Нет такой таблички в базе , это кластерная табличка.

ну кластер-то (CDCLS помоему) есть. И кокпит explain показывает к нему планы также как и для плоских таблиц.

Вопрос собственно - допустимо ли на уровне rdbms создавать к нему индексы (альтернативные первичные ключи), минуя инструментарий SE11?

Конкретно к этой табличке не знаю , нет времени посмотреть для чего она там кластерная. А так обычно и создают индекс в оракле на прямую , потом через se11 активируете(как бы создадите) и будет вам такой индекс какой вы хотите. Se11 не умеет онлайн создавать индексы ( не умел , может в 7.31 и научился , не проверял еще ) так что создание в БД на прямую это обычное и единственное нормальное решение без проблем для продуктива. (потом запрос просто принесет данные об индексе из разработки)

мы вобщето со времён 4.6 индексы создаём ТОЛЬКО в SE11 (хоть онлайн, хоть через фоновое задание). Просто для кластерных в SE11 соответствующая кнопка "Индексы" заблокирована впринципе. И соответственно возникли сомнения - если в обход SE11 напрямую в RDBMS команду create index отправить, не покривеет ли чего.
Хз вдруг там индексы в БД какойто служебной "структурой" обвязывается при создании через SE11.

Попробую промоделировать.

Ну посмотрел я что за CDCLS , к чему вы там будете индекс прилеплять ? Думаю что это не возможно , может кто поправит если не прав.

А "онлайн" вы не правильно поняли.
Когда вы создаете индекс через se11 ну и потом несете его запросом , то в оракле индекс создается без опции Online (доступна если не ошибаюсь с 10 оракла уже).
Если вы индекс такой начнете запиливать на большую таблицу в которую еще и пишут что нибудь , то будет вам счастье в виде Exclusive Lock wait + само создание индекса будет в один поток (оч долго) ,
при создании на прямую в оракле можно использовать параллельное создание (потом только обязон отключить это дело) что ускорит процесс многократно. У нас оч большие базы , других вариантов и нет.

ИМХО - создавать можно, оптимизатору БД пофиг на то, знает R/3 про этот индекс или нет

ArmAnn я слышал краем уха что когда из open sql в native sql селект переколбашивается, то отрабатывает некий оптимизатор запроса, но вроде он на AS в форме какого-то процесса (или части процесса). Это тот самый? Тогда вопрос - не повлияет ли отсутствие индекса, на то что он не отработает? Или имеется ввиду оптимизатор со стороны БД?

Ну вы попробуйте на этой табличке создайте , если найдете на чем создавать, вопрос не про в принципе , а конкретно про кластер CDCLS.
P.S. to Pavel Berezin , вот можете почитать отличное разъяснение от Mark Mergaerts (работает в SAP) почему эта затея не прокатит :
http://scn.sap.com/thread/421646

Имеется ввиду оптимизатор на стороне БД. Тот оптимизатор на стороне AS, про который вы пишете - это вероятно Database Interface, оптимизация там другого рода - это чтение из буфера вместо БД, выдача уже обработанных данных кластерной таблицы (например если вы считали BSEG - то пойдет запрос в БД к таблице RFBLG, а потом считали BSET - то второго запроса в БД не будет, вам DBI сразу выдаст данные)

Там немного не о том - Марк отвечает что нельзя создать вторичный индекс на поля BSEG (так как таблица 'виртуальная'), но Павел то хочет создать индекс на реальное поле реальной таблицы. Так как таблица кластерная - САП такое не позволяет, но не вижу причин почему нельзя создать индекс на уровне БД

А вы просто не внимательно прочитали , почитайте еще раз про то что содержится в RFBLG (аналог CDCLS) в данном случае.
Создать то можете , но какой в этом смысл ?

спасибо за совет, но я знаю что содержится в RFBLG
Смысл такой:
Есть в программе запрос к CDPOS (не спрашивайте меня почему без OBJECTCLAS и OBJECTID, это в условии задачи)

На уровне БД увидим такой запрос:

При выполнении этого запроса получим фактически полный перебор по первичному индексу (так как OBJECTCLAS и OBJECTID не известны).
Если сделаем отдельный индекс на поле CHANGENR таблицы CDCLS - то в таком случае все поля индекса будут известны, а значит выборка будет гораздо более эффективной.

P.S. Однако это все теоретические изыскания. Самый надежный способ - сделать индекс и проверить

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

нету увы других.

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

Я же просто хочу "вывернуть наизнанку" те поля, что входят в первичный ключ кластера (в частности, сместить CHANGENR левее OBJECTID, чтобы запрос "дай мне все изменения материалов за диапазон дат" шёл с меньшим IOCost - в точности как ArmAnn сказазал)