Thought you might be interested in the observation what I made after changing the sequence cache, Here it is….

I changed the cache for the few sequences, last night snap shot shows me the library cache lock waits went down to 695 (from previous nights 1816) and wait time has gone down to 2023 (from previous nights 5307). But my program tokk the same time to complete (Not so lucky last night).

once again Thanks for your time . I am working in oracle (or any data base) for last 1 and 1/2 years so not quite knowledgeable , please bear with me if I throw any stupid questions .

with best
CT

Precede the code with <code>, follow it with </code>, and replace all spaces with &nbsp;.

Thank you very much for detailed clarification.
version is 10.2.0.1.0

I didn’t think that the percentage should be 100 %. Thought it is a ratio of all the wait events, looking at the other reports five events are adding up to (100+ or – 3 ) %.

yes we are running with sga_target parameter.

I was going down the report to find what is adding up to hard parses ,
I found this statement
and an update seq stmt

update seq$ 
set increment$=:2, 
    minvalue=:3,
    maxvalue=:4,
    cycle#=:5,
    order$=:6,
   cache=:7,
   highwater=:8,
   audit$=:9,
   flags=:10 
where obj#=:1

is parsed for 223,294 and executed for same number oftimes.

Looking in to the other batch pgms running at the same time I found sequence cache are set for 20 where as we generate 35,000 unique numbers. I am not sure whether this is causing the latch problem……..I need to change the cache and see how they are performing.

I have tuned my batch program with the help of 10046 level 8.
.

I did not understand what do you mean by this

“After all, the batch job might have voluntarily lost its time by yielding the CPU in the resource manager”

is there any where I can read more about this stuff.

Thanks again for your time.

CT

p.s How did you formatted my report.I couldn’t get it right.

It seems unlikely, though not impossible, that a small number of “hard parses” would cause the time loss. However, it is a possible that a single operation hitting a silly bug could jam your batch job for ages. (Are you, for example, running with automatic SGA management – there might be a previously unrecorded bug in the code that caused a single parse call to hang for ages).

Bottom line, though, it is not possible to draw any conclusions about your batch job from this summary. After all, the batch job might have voluntarily lost its time by yielding the CPU in the resource manager code path; it might have had to wait for 22 of the ‘lost’ minutes because of TM lock waits; it might have had to compete more for latches, and therefore used more CPU

Since you have a batch job to watch, a low-impact strategy would be to add selects from v$mystat and v$sesstat (for the current SID) to capture the work done and time lost by the session. Otherwise you just need to trace the batch job (10046 level 8 ) to see exactly where the time was spent.

I was studying a system of 4 cpu in 10 g r2. We took a snap shot for one hour period during which our batch programs run. Found Following

EVENT                        WAITS   Time(s)   AvgWait(ms)  %TotalCallTime
----------------------- ---------- ---------   -----------   -------------
resmgr:become active           274    15,162        55,334            26.5
library cache lock           2,360     6,893         2,921            12.0
CPU time                               6,869                          12.0
db file sequential read    851,324     4,386             5             7.7
enq: TM - contention           460     1,340         2,914             2.3


If I see the report , Library cache lock is second(114 minutes). I was using one of your stats pack analysis link from your jl comp page . Looking deep into the report I found we are having a hard parse of 1.69/ second.

I am wondering does this hard parse alone is constituting for the library_cache_lock or some other factor can also constitute. If so, what should I be looking for………your guidence in this regard would be really helpful.

I took the snap shot for this hour , because one of my batch program when I run in development it runs for 35 minutes and when I run during the above hour in production it is taking more than an hour ( to be exact 1 hour 20 minutes).

Thank you very much for sharing your wisdom.

with best
CT

For example, you may have 128,000 cache buffers chains (linked lists) which make it possible for your session to find a particular block very quickly if it is in memory – compute the id of the chain it’s on and the linked list is very short. At the same time, there may only be 16 LRU chains (linked lists) running through your whole buffer and (virtually) every buffer is on one of those chains.

So when you kick a block out of memory, you go to the end of an LRU chain to disconnect the buffer from it – but you then have to work out which cache buffers chain it’s on and remove it from that chain as well.