Re: CRIT: RBLIVE statspack report

As already appreciate, your rollback segments seem to be much too big for activity shown, and the optimal is too high - little known rule of thumb, rollback segments should be as small and as few as possible to reduce redundant I/O. In your case the size of the rollbacks doesn't seem to have resulted in any significant I/O cost.

There seems to be little point in worrying (yet) about cursor_sharing - there seems to be virtually no latch contention - either as a measure of misses, or in the wait-time.

I would be most interested in two points -

Table scans - your rows fetched by scan
exceed your rows fetched by rowid, and
you are doing 2 'long' tablescans per minute. (long in your case could mean 240 blocks). I think this could be costing you a lot of CPU.

Secondly the number of rollbacks you have is surprising - a rollback is usually an expensive operation. Why are so many happening.

Quite possibly your 'hot object in kcadata' is the one being scanned all the time - but the low 'blocks per read' figure - despite the multiblock readcount being 32 suggests
that you may be seeing 'skip' effects - check the 'only_sequential_access ' bit (19) in the FLAG - it may give you a clue.

I'm not sure you will ever get a fantastic execute to parse' ratio from a forms front-end,

Are you actually getting any complaints
about performance on this one at present ?

--
Jonathan Lewis
Yet another Oracle-related web site:  http://www.jlcomp.demon.co.uk

Practical Oracle 8i:  Building Efficient Databases
Publishers:  Addison-Wesley

Reviews at: http://www.jlcomp.demon.co.uk/book_rev.html



andrew_webby at hotmail wrote in message
<990197009.29157.0.nnrp-07.c30bdde2_at_news.demon.co.uk>...


>Seeing as it was my idea, here's a statspack report for anyone who fancies

>looking over it. I'm prepared to accept any criticism on it. Except any

 that


>suggest I collect my P45 ;-)

>

>I wasn't sure whether to just copy the report in as body text, but I reckon

>a simple TXT attachment would be acceptable (to preserve formatting a bit).

>

>Let's keep it clean folks! (And try to enjoy it as well....)

>

>ps. at the risk of sounding redundant, I know opinions can get a bit heated

>in here at times, but let's try and remember why we're doing this, m'kay?

>(see above)

>

>

>