Когда происходит реорганизация, строки меняют места - следовательно, rid'ы меняются - следовательно, индексы не могут не стать инвалидными. Я сомневаюсь, что какая-то другая СУБД справилась бы лучше.

Самый первый вопрос поэтому - действительно ли такая частая реорганизация такой большой таблицы нужна. Я подозреваю, что нет. Быть может, раз в год достаточно. Или даже это слишком часто.

Изменить структуру, чтобы можно было проводить реорганизацию по частям. Провести партишионирование (если доступно).

Существует и "партишионирование для бедных": разбить таблицу на несколько, назначив на них constraint's, по которым строка попадает точно в одну, и объединить со view через union all.

то есть вместо table t создать
create table t1 (... constraint c1 check ...)
create table t2 (... constraint c2 check ...)
....
create table tn (... constraint cN check ...)
create view t as
select * from t1
union all
...
select * from tn.
и при попытке вставки insert into t ... строки
все constraints c1...cn, кроме одной, должны давать false

(Кстати, не все знают, что, в отличие от where, где не выбираются строки, для которых предикат даёт undefined, СУБД позволяет вставить строку, если результат предиката в check оказался undefined).

Добавить много-много ОЗУ, перейти с винчестеров на ССОД.

Сменить софт, найти тот, у которого разработчики более вменяемые.

Chumakov_JAVictor Metelitsa,
http://www.sql.ru/forum/1264275/reorg-table-kak-svesti-k-minimumu-vremya-dlya-provedeniya-reorganizacii-tablic-i-indeksov
Там практически все ответы на Ваши предложения
Чудес же не бывает.

Chumakov_JAMark Barinstein,
Да и пока шла сама реорганизация блокировки были ну очень часто. 2 дня доказывания что только полная реорганизация поможет и итог 11 часов ожидания и все просто стало летать.

Почему "только полная реорганизация поможет" и в чём заключалось доказывание? Не в битых же индексах и не в том, что были тормоза, пока реорганизация шла?