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

!Z!По-моему вы неправильно подходите к проблеме. Наверное, лучше выяснить почему запрос идет через FFS, а не плодить хинты.
Табличка относительно большая 30Гб, собирать по ней статистику уйдет целый день (может есть какие-то ускоренные способы, не знаю). Индекс тоже довольно большой (по многим полям 7Гб). Ежедневно добавляется неск. тысяч 50 записей.
По-моему уже очень бы надо разбить ее на части, чтобы собирать статистику только по новым данным,
но как именно - очень удобно было бы по годам, но данные добавляются/изменяются во всех годах.
Есть вариант разбить по годам, пофискить и все новые данные лить в аналогичные, но пустые таблицы, а раз в неделю перекладывать в большие(ую) таблицы(у), дабы не сбивать статистику типа, но по специфике данных, не получится тогда в течение недели держать объективную информацию (нормально смердженную) или придется усложнять, утяжелять запросы отчетов.
Теперь еще учтем, что опции патиционирования как таковой нет.
Сейчас получается, что иногда оракл выбирает нормальный план, иногда сваливается в IFFS, если запретить IFFS, то уходит вообще в фулскан, поэтому пришлось явно указать какой индекс использовать. Работает. Но не нравится это.

dbms_statский советникнужно добавлять рассчитанную статистику заранее на основе прогноза
Это как?