Slow system problems

Question

hello,
I am currently trying to optimize a data warehouse. its data updation procedure is too slows. I have gathered some wait statistics here they are
latch: shared pool 51660257 3.57
direct path read 42034287 2.9
jobq slave wait 30777938 2.12
latch: session allocation 17211160 1.19
PX Deq: Msg Fragment 16296709 1.12
JOX Jit Process Sleep 14199622 .98
PX Deq: Slave Session Stats 9812554 .68
latch: cache buffers chains 8740357 .6
latch free 6843574 .47
wait list latch free 3103540 .21
PX Deq Credit: send blkd 2546416 .18
PX Deq: Table Q Normal 1066046 .07
PX Deq: Join ACK 877460 .06
cursor: pin S wait on X 815031 .06
shared pool latch during the discussion was the most big problem the architecture described. my point was since it was warehouse database and we are using literal so it should be normal.. what is the opinion of member of this forum.
direct path read/writes are next. we need to distribute the disk I/O system
latch: session allocation why its here. I dont know why we have it.
also is cursor: pin S wait on X is enough to worry about ?
kindly give you expert opinion
regards
Nick

Answer 1

Contentions for the shared pool and library cache latches are mainly due to intense hard parsing. A hard parse applies to new cursors and cursors that are aged out and must be re-executed. Excessive hard parsing is common among applications that primarily use SQL statements with literal values.
Discover the magnitude of hard parsing in your database using the following query. The number of soft parses can be determined by subtracting the hard parse from the total parse.
select a.*, sysdate-b.startup_time days_old from v$sysstat a, v$instance b where a.name like ’parse%’;
Discover the current sessions that perform a lot of hard parses:
select a.sid, c.username, b.name, a.value, round((sysdate - c.logon_time)*24) hours_connectedfrom v$sesstat a, v$statname b, v$session cwhere c.sid = a.sidand a.statistic# = b.statistic#and a.value > 0and b.name = ’parse count (hard)’order by a.value;
You should see significant reduction in the contention for the shared pool and library cache latches when you convert literal SQL statements to use bind variables. The conversion is best done in the application. The workaround is to set the initialization parameter CURSOR_SHARING to FORCE. This allows statements that differ in literal values but are otherwise identical to share a cursor and therefore reduce latch contention, memory usage, and hard parse.
WHATS UR CURSOR_SHARING set to ??
Edited by: S2K on Apr 22, 2009 11:51 AM