block contention

If the high concurrency of insert,  and if we insert into the same block,  the block will became a hot block, the wait event maybe latch: CBC, data buffer busy. this usually is the case when the index is date related and sequence related.  

and for some power seller, (all the inserted rows with the same USER_ID), the event may be TX-Transaction (index contention) besides hot block events when the index block spilt .

first we need to make sure whether it caused by index block.

For buffer busy wait,  
SELECT row_wait_obj#
  FROM V$SESSION
WHERE EVENT = 'buffer busy waits';

SELECT owner, object_name, subobject_name, object_type
  FROM DBA_OBJECTS
WHERE data_object_id = &row_wait_obj;

For latch: CBC
SELECT OBJ data_object_id, FILE#, DBABLK,CLASS, STATE, TCH
  FROM X$BH
WHERE HLADDR = 'address of latch'
  ORDER BY TCH;

SELECT OBJECT_NAME, SUBOBJECT_NAME
  FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = &obj;


date index is used for index range scan, we can't hash them,  we need to check whether the index is a must.  
select distinct hash_value from v$sql_plan where object_name='&index_name';

Usually this kind of index is for DW query.  we can test the sql without the index to see if the index is a must, if not, we can drop the index.

user_id index usually for KV query,  we can hash them but this doesn't work for power seller(with the same user_id). but sometimes, when we run the sql like:
select * from t where user_id=? and col=?.  we created the multi-columns index like (user_id, col) for it, we can reverse the order by (col, user_id), this will easy ease some loads for insert. The index efficiency for select will be decrease a bit, but it deserves the try.

Also , some high concurrency will cause buffer busy wait on segment header when allocate the new space, it is better to use ASSM or increase freelist number or freelist groups.

Please correct me if I am wrong somewhere.