Народ, выведите на путь истинный...
Задолбался уже о стенку биться.

Имелся ряд standalone CONTEX Оракл Техт индексов используемых в запросе. Перформанс был ну мягко скажем не очень...
Когда обьединили standalone индексы, относящиеся к одной и той же таблице, получили big releaf по response time, но потеряли транзакционность: не видно изменений, когда значение в одной из колонок обьеденненного индекса апдейтится.
Запрашиваю таблицу DR$<index_name>$I: токен не проиндексирован.

Вот стэйтмент которым генерю индекс:


Я уже и вручную синхронизировал индекс с помощью :
1. exec CTX_DDL.OPTIMIZE_INDEX( idx_name => 'rep_mlt', optlevel => 'FULL');
2. exec CTX_DDL.SYNC_INDEX('rep_mlt', '2M');
Результат все тот же: не индексируется проапдэйченный контент, хоть тресни.
Когда грохаешь индекс и строешь его снова, то все ОК. Но фишка то в том, что он должен бы транзакцинонный, standalone индексы-то работают.

Сам тему создал - сам себе и отвечаю.

На первый взгляд нет ошибок, все сделано правильно.
Но есть один маленький, но очень важный момент, который был очевиден для меня, но не был описан в деталях выше. Так вот, используемая колонка rep_id в создании rep_mlt индекса и являлась предметом всех траблов, потому как эта колонка одна из физически существующих в таблице и задекларированных в multi-column index-е.
Фрагмент из руководства по Оракл Текст:


Одним словом - RTFM.

Ну а если честно, то поддался я влиянию одного ДБА, который курирует наш проект. Когда я задал ему вопрос почему в руководстве написано MUST create a dummy column, он не смог связно ответить, но заверил что dummy column is not a big deal, в его проектах это было стандартом.
Возможно.
Если не нужна транзакционность.