Title: RE: Caching a huge table's data in memory
Read Cary Millsap's papers on Misunderstandings about Oracle Internals at his site www.hotsos.com. They are excellent!
-----Original Message-----
From: Orr, Steve [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 9:54 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Caching a huge table's data in memory

I don't think a cache table is actually "pinned" in memory. It just means
that its blocks stick around once they are read and are not recycled as
much as "normal" tables. That having been said, due diligence should be
taken to tune the queries and caching large tables should be avoided. What
good is it if you "tune", or rather, speed up one query if it takes resources
away from other queries and slows down the overall system? Sounds like a
good opportunity to educate a DUHveloper. Tune the query and show her/him
before and after tkprof stats. Better yet, teach her/him how to use tkprof
and make them run it on each query before putting it into code. Make sure
your test/development data set reflects production volumes.


Steve Orr
Bozeman, Montana



-----Original Message-----
From: Stephen Lee [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 8:09 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Caching a huge table's data in memory


Pro: It is in memory

Con: You must buy the memory.  You must be sure you don't cause the box to
start paging to swap ... very bad ... VERY bad.

When you live in the land of bad applications, sometimes the politics of the
situation are such that you just do what you know is the equivalent of
"fixing" things with duct tape  -- a whole lot of duct tape -- rather than
attempt to engage in a hopeless fight.  Consider the case of an application
that is so bad that a box with more than 50 Gb of RAM and 16 Alpha CPU's are
required to handle from 6 to 10 active connections.  Hey, if they want to
spend the money ....


> -----Original Message-----
> What are the pros and cons of caching a table's data? 
--

Reply via email to