Pozaluista na gora:

-- tip tablespace LMT/DMT
-- esli LMT to UNIFORM SIZE ili ustanovky AUTOALLOCATE
-- esli DMT storage parameters -->
dlia index i dlia tablespase

Я попрововал смоделировать ситуацию с bitmat индексами при массовой загрузке. Ниже результаты:

drop table ord_table;
create table ord_table (a varchar2(100), n number);
create bitmap index ord_b_index on ord_table(a);

insert into ord_table
select * from (
select object_type, object_id
from all_objects
union all
select object_type, object_id
..............
select object_type, object_id
from all_objects
union all
select object_type, object_id
from all_objects
)
order by 1
;

36612 rows created.

drop table ord_table;
create table ord_table (a varchar2(100), n number);
create bitmap index ord_b_index on ord_table(a);

insert into ord_table
select * from (
select object_type, object_id
from all_objects
union all
select object_type, object_id
from all_objects
....
union all
select object_type, object_id
from all_objects
)
order by dbms_random.value
;
36612 rows created.

Созданы две одинаковые таблицы с одинаковыми записями и одинаковыми индексами.
Отличаются только в ORDER BY .. - в одном случае загрузка упорядоченная по индексу в другом случайная.

Далее:

analyze table ord_table compute statistics;
analyze table not_ord_table compute statistics;

select
LEAF_BLOCKS, DISTINCT_KEYS, AVG_DATA_BLOCKS_PER_KEY, AVG_LEAF_BLOCKS_PER_KEY,
CLUSTERING_FACTOR, NUM_ROWS
from all_indexes where owner = 'TRAIN' and table_name = 'ORD_TABLE'
and index_name = 'ORD_B_INDEX';

LEAF_BLOCKS DISTINCT_KEYS AVG_DATA_BLOCKS_PER_KEY AVG_LEAF_BLOCKS_PER_KEY CLUSTERING_FACTOR
----------- ------------- ----------------------- ----------------------- -----------------
NUM_ROWS
----------
2 14 1 1 14
14

select BLOCK_ID, BLOCKS from dba_extents
where
owner = 'TRAIN' and segment_name = 'ORD_B_INDEX';

SQL>
BLOCK_ID BLOCKS
---------- ----------
6506 8

select
LEAF_BLOCKS, DISTINCT_KEYS, AVG_DATA_BLOCKS_PER_KEY, AVG_LEAF_BLOCKS_PER_KEY,
CLUSTERING_FACTOR, NUM_ROWS
from all_indexes where owner = 'TRAIN' and table_name = 'NOT_ORD_TABLE'
and index_name = 'NOT_ORD_B_INDEX';

SQL>
LEAF_BLOCKS DISTINCT_KEYS AVG_DATA_BLOCKS_PER_KEY AVG_LEAF_BLOCKS_PER_KEY CLUSTERING_FACTOR
----------- ------------- ----------------------- ----------------------- -----------------
NUM_ROWS
----------
9 14 1 1 23
23

select BLOCK_ID, BLOCKS from dba_extents
where
owner = 'TRAIN' and segment_name = 'NOT_ORD_B_INDEX';
SQL>
BLOCK_ID BLOCKS
---------- ----------
6514 8
6530 8

Посмотрим во внутрь физических блоков для этих индексов:
(полностью дамп не приводится ввиду его объема)

alter system dump datafile 13 block min 6506 block max 6507;
alter system dump datafile 13 block min 6514 block max 6515;

Для ORDER индекса ---
....
row#0[3953] dba: 54532461=0x340196d
col 0; len 1; (1): 54
col 1; TERM
----- end of branch block dump -----

Для NOT_ORDER индекса ---
....

kdxbrbksz 3960
row#0[3944] dba: 54532469=0x3401975
col 0; len 5; (5): 49 4e 44 45 58
col 1; len 4; (4): 03 40 17 a0
col 2; TERM
row#1[3937] dba: 54532470=0x3401976
col 0; len 1; (1): 50
col 1; TERM
row#2[3929] dba: 54532471=0x3401977
col 0; len 2; (2): 50 52
col 1; TERM
row#3[3911] dba: 54532472=0x3401978
col 0; len 7; (7): 53 59 4e 4f 4e 59 4d
col 1; len 4; (4): 03 40 17 94
col 2; TERM
row#4[3904] dba: 54532473=0x3401979
col 0; len 1; (1): 54
col 1; TERM
row#5[3889] dba: 54532482=0x3401982
col 0; len 5; (5): 54 41 42 4c 45
col 1; len 3; (3): 03 40 18
col 2; TERM
row#6[3881] dba: 54532483=0x3401983
col 0; len 2; (2): 54 59
col 1; TERM
row#7[3866] dba: 54532484=0x3401984
col 0; len 4; (4): 56 49 45 57
col 1; len 4; (4): 03 40 17 93
col 2; TERM
----- end of branch block dump -----

Выводы:
при массовой загрузке в случае неупорядоченного потока значений индекса (ЕСЛИ ЭТОТ ИНДЕКС СОЗДАН ДО ЗАГРУЗКИ)
oracle заполняет физические блоки индексов КАК ЕСТЬ В ПОРЯДКЕ ПОСТУПЛЕНИЯ ЗАПИСЕЙ
(по другому не может !!!)
в результате --
а) возникают длинные цепочки блоков с одним начальным блоком и и множеством блоков в цепочке.
б) вполне возможно что плотность заполнения блока в такой ситуации значительно ниже
( для 36000 записей была в два раза ниже)

далее можно развить и проанализировать как связаны цепочки
в разных блоках и помечает ли Oracle незаконченные цепочки как "удаленные" но в лом.

Совершенно ясно одно !!!
в случае полного заполнения физического блока новая запись для значения индесного клуча будет
записана ВЫШЕ HWM и это приведет к огромному количеству мало заполненных блоков.

Да кстати есть одна полусумашедшая мысль:
проборал ли ты увеличить количество FREELISTS поскольку
если FREELISTS = 1 и загрузка идет из одной сессии то
он УЖЕ занят и Oracle ОБЯЗАН использовать HWM в случае заполнения блока до 100-FREE.