RE: DBMS_STATS [resend chomped version]

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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

  ---