Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: **Buffer retention in cache to address disk reads problem

RE: **Buffer retention in cache to address disk reads problem

From: Rahul <>
Date: Wed, 6 Sep 2000 11:41:34 +0700
Message-Id: <>

Surya, high number of disk reads could also be a result of a very bad sql issued from within the pro*c !

> ----------
> From: Surya Rao[]
> Sent: Wednesday, September 06, 2000 6:30 PM
> To:
> Subject: **Buffer retention in cache to address disk reads problem
> Sensitivity: Confidential
> List,
> On our prod server, we had instances of high disk i/o - as high
> as 80% on one disk. We then relocated one table to another disk.
> Now this disk is being subjected to the high disk i/o
> I trawled through v$sqlarea and found one SQL being called from
> a pro*c application with a very large number of executions and
> a even higher number of disk reads. This pro*c happens to be
> a daemon process constantly running this SQL, every 3 seconds.
> If records match its 'select' criteria, it does some action.
> the cecking frequency cannot be increased. It has to check every
> 3 seconds.
> Seems that this table buffers are being aged out too fast. What steps
> must I take to ensure that this table is NEVER aged out from buffer and
> so never needs to access the disk. This table has about 3000 records
> at any given point of time. New ones are inserted at about 200 per day
> and also deleted at the same rate.
> Is 'cache' attribute for such a table recommended? Even if I do 'cache'
> it, how should I then go about sizing my buffer pool?
> Am i barking up the wrong tree and should be doing some thing else to
> address this problem?
> This prod server is running Oracle 7.3.2
> _TIA_
> surya
> -------
> -----------------------------------------------------------------
> Visit our Internet site at
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Reuters Ltd.
> --------
> If you're bored, then visit the list's website:
> (updated daily)
> to unsubscribe, send a blank email to
> to subscribe send a blank email to
Received on Tue Sep 05 2000 - 23:41:34 CDT

Original text of this message