Well, I'm close.

I just ran this on the DEV database for an app that is in the 'upgrade' 
process.


     FILE#     DBABLK   COUNT(*)
---------- ---------- ----------
        10      38968          6
        11      22753          6
        11      40180          6
        11      74893          6
        16     104388          6
        16     104511         66

6 rows selected.

Which resolves to index PK_MATERIAL_ORDER_POOL.

Looks like further investigation is in order.

Jared







"Jonathan Lewis" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
 01/23/2003 11:49 AM
 Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
        cc: 
        Subject:        Re: Slow database, too MANY buffers???



You could try:

    select    file#, dbablk, count(*)
    from    x$bh
    group by 
        file#, dbablk
    having count(*) > 5
    ;

(technically you should include the 
tablespace number, but that won't 
matter if you have less than 1022 
files).

This will report the blocks which have an
unusually large number of CR copies in the
buffer.  There is a nominal limit of 7, but
if your buffer is excessive for the work done
then there is a fair chance that the most
intensively used blocks will have far more 
buffers.  (The worst case I saw was something
like 75).

The side effects of this would include lots of
spinning and sleeping on the cache buffers
chains latch.






Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

Next Seminar dates: 
(see http://www.jlcomp.demon.co.uk/seminar.html )

____England______January 21/23
____USA_(CA, TX)_August


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html





-----Original Message-----
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: 23 January 2003 19:05


I've got a cust that is showing some signs that one would
think is having a horrible problem on I/O...

I suspect it is the "error" of having a **HUGE** value
in db_block_buffers and it's constantly crunching memory
trying to figure out which ones to free up. It's only
256 meg, but depending on load, it may be too much. SGA
is 687 meg.

While I've got hundreds of SQL, I'm not sure I have one
to diagnose buffer utilization. It's also version 8.1.7
and I could probably do some tweaking of buffers.

It's Oracle CRM with a lot of customization and I'm also
finding some SQL that's getting a bit ugly under there.

Maks.


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jonathan Lewis
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to