Can someone explain why an insert cause multiple logical index reads?
Our application does bulk inserts and insert of each rows caused about 20-30 index reads, if the reads are physical we have a slow insert. The table has 4 indexes , 3 unique and 1 non-unique ( no clustered indexes). We are having random insert spike because of index reads.

so on an avg bulk insert of 200 rows causes about 4000 index reads, each index is isolated to its own tablespace (table partitioning) each index gets about 1000 reads.

Do you think that referential constraints might be somehow involved?

Obviously it has to insert the data into the index, and it has to traverse the b-tree to find the correct page to update, so this could account for several reads each time. If there is no room on the correct index page for the new data, then a page-split of the index page is necessary, which can be costly and require additional index reads.

There is no referential constraints on this table.

Marcus,
How can i monitor for page-splits?
Here is from db2pd:
IIDEmpPgDel BndrySplts PsEmPg Scans KeyUpdates NonBndSpts PgAllocs PseuDels DelClean IntNodSpl
4 79 0 82 588287 550865 32767 33367 550865 123563 723
3 21 0 24 300991 550209 28283 29485 550209 474021 1245
2 147 3915 151 12 550209 25537 29569 550209 56946 342
1 20 0 23 100 550209 28095 29275 550209 436091 1222

RootSplits=0
InclUpdats=0
Merges=0
What can we do to iptimize this?

In that case it could make sense to postpone the index updates to after the bulk of inserts. This is what the LOAD utility does (as opposed to the SQL INSERT).
Maybe that's an option?
(If on LUW, also have a look at the INDEXING MODE option of LOAD.)

load is not an option for us, the table is updated/read constantly...