RE: v$session_longops

RE: v$session_longops

 

  


Hi Larry,

I'm on course (pl/sql programming), hence the delay in
replying. Database app lists all Telkom Transmission equipment in SA,
10.20 was limited in Kernel to 4010 file-sz and was exceeding, so
oracle was terminating when it could no open a file handler. So, we
went to MTS which took them from 4010 to 2500, and oracle was stable,
but as stated is slowing. I know pmon should clear the killed
processes, but they seem to sit there for a long time. Just checked
and there are none at the moment. Maybe pmon is just taking time to
get around to it. There are two instances on the machine and the
second reported slow running yesterday also.

I've just checked statspack now, but it was running since
Friday, and shows nothing out of the ordinary, though the busy time is
only short and won't reflect in there. Guess I'll have to wait until
I'm back in the office and run statpack hour by hour to see if there
is anything funny in it. System has plenty of free memory, shared and
large pool free memory are 8.78M and 9.58M on the main database, and
14.73 and 6.27 respectively on the second. All hit ratios are > 99%
except the db_block_hjit_ratio, at 84 but the MTS average wait time is
up at 50 Ms, from 1.3Ms when oracle starts. Atleast that is I believe
what the sql below displays.

SELECT to_char(sysdate, 'HH24MISS'), DECODE (totalq, 0,
0,to_char((wait / totalq) * 100, '9999.999') ) FROM v$queue WHERE type
= 'COMMON'

Cheers

GJC

The fifty dwarves were reduced to eight,
before anyone suspected hungry.

______________________________________________________
Gary Colbran

==================================================================
This e-mail and its contents are subject to the Telkom SA Limited
e-mail legal notice available at
http://www.telkom.co.za/TelkomEMailLegalNotice.PDF

Oracle LazyDBA home page