Разбухание индексного файла при наличии BITMAP-индекса в 9-ке

Oracle 9.2.0.1
Есть схема в БД, в нее доливается (типа репликации) очень много данных, по объему сравнимо с уже присутствующими в схеме. Если BITMAP-индексов нет, все ок, если есть на немаленькую таблицу, то индексный файл пухнет как на дрожжах, затем следующий и т.д. до полного исчерпания места, после чего
ORA-01654: невозможно увеличить индекс XXX.I_ZAYAVKA_TYPE до 16384 в разделе INDX
Файлы индексов авторасширяемые. Но предел и для них есть.
В алерт-логе на сервере других ошибок нет.

Как обойти трабл? Или это лечится патчами?

P.S. эти BITMAP-индексы нужны, они дают заметный прирост производительности. До них были обычные индексы, так сервер их даже в план запроса не включал...

Это нормальное поведение BITMAP index'ов
Есть 3 варианта в каждом есть свои минусы .

1. после каждого предложения insert в таблицу на которую имеются BITMAP делать commit
2. Удалять индексы перед заливкой, данных и пересоздавать после.
3. Либо же делать REBUILD в какие то периоды времени.

Regards.

нормальное поведение?!

Это хзч, а не поведение...
За обходы спасибо, но ни один меня не радует, ибо плюс у них только один - не плющит BITMAP'ы, а все остальное - только минусы. В системе 24*7 как-то не сильно поиграешься с удалением индексов или пересозданием. А построчный коммит - это вообще ересь при репликации.

Извините за резкость, конечно. Это не в вашу сторону, а в оракл.

Привет

FreeLancer

Это хзч, а не поведение...

А чего ты хотел? Использовать фичу, заточенную под специфическое использование, по другому назначению? На Ferrary руду из котлована вывозить, типа. А для это БелАЗы и прочая ерунда используется.

Это ни на кого не наезд ;-)

Всего

Почитайте, что из себя представляют BITMAP индексы и поймете, что то повышение производительности, которое вы отметили "покупается" как раз тем что индексы при активных изменениях в таблице будут распухать.
Поэтому эти индексы и используется чаще всего в хранилищах данных, где изменения происходят достаточно редко (по сравнению с OLTP системами)
Если для вас такое поведение индексов неприемлимо - можете их не использовать. Выбор за вами.
И Oracle тут непричем.

Any chance you can rewrite code доливки to use bulk dml? That would be best workaround. Bitmap index dml is specially optimized for bulk dml.

SY.

Index maintenance is deferred until the end of each DML operation. For example, if you insert 1000 rows, the inserted rows are placed into a sort buffer and then the updates of all 1000 index entries are batched. (This is why SORT_AREA_SIZE must be set properly for good performance with inserts and updates on bitmap indexes.) Thus, each bitmap segment is updated only once per DML operation, even if more than one row in that segment changes.

SY.

SY

Good point. Thanks

2 FreeLancer
Главное чтобы DML на эту таблицу не было в момент (DELETE, REBUILD)
REBUILD, DELET и CREATE кстати должны проходить достаточно быстро(быстрее чем если бы был B*Tree)
к сожалению пока еще нет online REBUILD для BITMAP

commit можно делать после каждой транзакции.

2 SY
Хороший способ, спасибо
я так понимаю внедряя BULK на BITMAP надо иметь еще подходящий sort_area_size ?

Oracle newbie

я так понимаю внедряя BULK на BITMAP надо иметь еще подходящий sort_area_size ?

Absolutely.

SY.