| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Caching a huge table's data in memory
I have never delved into just what gets cache and how permanently it gets cached when a table is cached. In the case of a monstrosity of an application, to cache or not to cache (that is the question) a large table, is a case of tweedle-dee and tweedle-dum. But when people are grabbing at any straw that can be grabbed, you just go with the flow and hope the real problems and what needs to be done become self-evident.
-----Original Message-----
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.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Stephen Lee
INET: slee_at_dollar.com
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: ListGuru_at_fatcity.com (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). Received on Tue Jan 07 2003 - 11:54:36 CST
 |
 |