Before Oracle 8 and the new touch count algorithm the cache attribute made sense. If a small, frequently used table was read by a full scan, it would have been put at the end of the LRU chain eligible to be aged out immediately, quite possibly by itself if it consisted of more than ~ db_file_multiblock_read_count blocks, i.e. the 2nd or 3rd full scan read would already override the previously read blocks. Marking the table as CACHEd prevented that.

At 01:09 PM 10/21/2003, you wrote:
I always wondered why Oracle thought this was a useful table attribute.

My gut feeling is that it is an extra that does little.

For example, say we want to keep a code table in memory because it is
constantly being hit for column verifiction.  By definition, if a table is
constantly being queried, it's segments will be in memory because they never
age out.  That sounds like cacheing to me.

And then I remember a specific piece of Oracle documentation saying that,
even though we may mark a table to be "cached", it *still* may be aged out
if memory is needed for other data blocks.

Like I said, sounds a little like "here you have it, and here you don't".

I'm sure that my impression is wrong and someone will correct me.  But I
doubt I will use the "CACHE" option anytime soon.

Tom Mercadante
Oracle Certified Professional

Wolfgang Breitling
Oracle7, 8, 8i, 9i OCP DBA
Centrex Consulting Corporation
http://www.centrexcc.com



-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Wolfgang Breitling 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