RE: high latch free

Hi Ujang

The latch free is taking less than 10% of the response time. So, if you have a problem is not the latch... The main problem I see is that you have no partition key in the WHERE clause. Therefore no partition pruning is used and PARTITION RANGE ALL is causing too much logical I/O for nothing.

Few more comments...

> I guess because of that index, so we could have problem with
> latch free event, or any other clues?

It would be interesting to know why...
Which is the latch you are waiting for?

> how if I create index I_EVENT_IPT_CALL__TRANSID index for 2
> column ( trans_id and OBJ_ID0)

Mhmm... It would be much better to know the query... Anyway the execution plan, except for the missing partition pruning, looks good. The only thing it could be better is to avoid accessing EVENT_SESSION_IPT_CALL_T. Of course that is only possible if you are accessing trans_id and obj_id0 only.

> or should I increase parallel* parameter ?

Once more, why? IMHO if you are really suffering from contention increasing the parallelization can only lead to more contention.

HTH
Chris

--
http://www.freelists.org/webpage/oracle-l