Jonathan, >Agree completely - it's a bit of a luxury to have the time, >and hard to get the correct information, but every (complex) >system needs a table-driven stats gathering process to >minimize the work done, and maximise the return on effort. Someone on this list suggested (don't remember who) turning on Table monitoring on most (if not all) tables and using a script to analyze the top-N tables by 'staleness' (i.e. %age rows changed) in a cyclic fashion. This way, active tables would get analyzed more often while keeping down the system-load and avoiding a carpet-bomb type analyze. One of the questions then is the amount of overhead that MONITORING would place on the system - in the SGA as well as on processing. My very sketchy understanding (based on Steve Adams' website) is that the updates to the in-memory structures behind DBA_TAB_MONITORING is unlatched and not overhead-heavy. However, there was no hard evidence. Do you have any? Is this data collected off the mechanism that updates values in V$SQL? [Apps has a _lot_ of tables (about 15,000), although some of them may be inactive based on what modules have been implemented] Any thoughts on this welcome! John Kanagaraj <>< DB Soft Inc Phone: 408-970-7002 (W) Disappointment is inevitable, but Discouragement is optional! ** The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers ** ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------