RE: high latch free
- From: "Christian Antognini" <Christian.Antognini@xxxxxxxxxxxx>
- To: <ujang.jaenudin@xxxxxxxxx>
- Date: Tue, 1 May 2007 19:54:54 +0200
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
