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: [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).
