Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Global Stats

RE: Global Stats

From: Deshpande, Kirti <kirti.deshpande_at_verizon.com>
Date: Wed, 29 Jan 2003 21:19:34 -0800
Message-ID: <F001.0053E1E2.20030129211934@fatcity.com>


X$KG,

Are you certain?
What platform?

Just did a small test on Win 2000. It's been over 10 minutes and no new info in user_tab_modifications.

Secondly, Lisa is running 8i. So she is stuck with this ~3 hour delay :(

Thirdly, if the interval is really going to be 5 minutes, why bother with a new procedure? I know I can live with 5 minute delay, but 3 hours can be a long time.

They should consider making this procedure available in 8i !!

Regards,

-----Original Message-----

From:	K Gopalakrishnan [mailto:kaygopal_at_YAHOO.COM]
Sent:	Wed 1/29/2003 10:38 PM
To:	Multiple recipients of list ORACLE-L
Cc:	
Subject:	RE: Global Stats

Kirti:

I think the interval is changed to 5 minutes from 3 hours starting from 9i (rel2?).

Best Regards,
K Gopalakrishnan

-----Original Message-----
Kirti
Sent: Wednesday, January 29, 2003 8:19 PM To: Multiple recipients of list ORACLE-L

Lisa,
 Monitoring, by itself, does not fire any automatic analyze. It simply montiors the DML activity on the monitored table and counts inserts/deletes/upates. Those counts may not be 100% accurate, but are very close. These can be viewed in dba_tab_modifications, and are dumped there by SMON every 3 hours or so (in 9i there is a new procedure, flush_database_monitoring_info, to flush these counts to this view on demand). These counts do not affect the ones maintained in *_tables views.

Monitoring is basically there to help identify which tables may need statistics computed again. 'Gather stale' option will only analyze tables that have undergone DML activity (inserts/deletes/updates) that amounts to more than 10% of the number of rows (from previous analyze) in the table. And 'gather auto' option 'figures' out what tables to analyze, but you must execute dbms_stats. So, there is nothing automatic in gathering table stats.

You can test it yourself..... remember there is a last_analyzed column ;)

HTH,

-----Original Message-----

From:	Koivu, Lisa [mailto:Lisa.Koivu_at_efairfield.com]
Sent:	Wed 1/29/2003 9:09 AM
To:	Multiple recipients of list ORACLE-L
Cc:
Subject:	RE: Global Stats

Hi Jared,

Actually I think monitoring won't work in my case. Data loads fire throughout the day and the docs say that in 8i, analyze can fire based upon table monitoring sometime within 3 hours after data changes. I would rather include a manual fire of analyze in my data load and avoid any locking issues or contention for resources.

In addition, if temp space is blown during "auto-analyze" (fired based upon monitoring), would I know about it?

Just my thoughts. Am I wrong?

Lisa

-----Original Message-----
Sent: Wednesday, January 29, 2003 3:55 AM To: Multiple recipients of list ORACLE-L

You may want to read up on table monitoring.

Jared

On Tuesday 28 January 2003 11:10, Koivu, Lisa wrote:
> Hi everyone,
>
> Back to the lovely world of Oracle :) I've been reading up on statistics.
> Out of the 8.1.7 doco:
> /*
> Partitioned schema objects may contain multiple sets of statistics. They
> can have statistics which refer to the entire schema object as a whole
> (global statistics), they can have statistics which refer to an individual
> partition, and they can have statistics which refer to an individual
> subpartition of a composite partitioned object.
>
> Unless the query predicate narrows the query to a single partition, the
> optimizer uses the global statistics. Because most queries are not likely
> to be this restrictive, it is most important to have accurate global
> statistics. Intuitively, it may seem that generating global statistics
from
> partition-level statistics should be straightforward; however, this is
only
> true for some of the statistics. For example, it is very difficult to
> figure out the number of distinct values for a column from the number of
> distinct values found in each partition because of the possible overlap in
> values. Therefore, actually gathering global statistics with the
DBMS_STATS
> package is highly recommended, rather than calculating them with the
> ANALYZE statement
>
> */
> The table I need to generate stats for is currently 32GB and grows by ~2GB
> per week. Even the smallest estimate with calculating global stats will
> take a long long time and I may not be able to spring for all the required
> temp space.
>
> How does the list feel about global stats? Does anyone agree with the
> documentation that they "most important"? I'm thinking my partitioned
> statistics are the "most important".
>
> Any input is appreciated. Thanks
>
> Lisa Koivu
> Oracle Database Administrator
> Fairfield Resorts, Inc.
> 5259 Coconut Creek Parkway
> Ft. Lauderdale, FL, USA 33063

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: K Gopalakrishnan
  INET: kaygopal_at_yahoo.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).







Content-Type: text/plain; name="ReadMe.txt"; charset="us-ascii" Content-Transfer-Encoding: 7bit The previous attachment was filtered out by the ListGuru mailing software at fatcity.com because binary attachments are not appropriate for mailing lists. If you want a copy of the attachment which was removed, contact the sender directly and ask for it to be sent to you by private E-mail. This warning is inserted into all messages containing binary attachments which have been removed by ListGuru. If you have questions about this message, contact Postmaster_at_fatcity.com for clarification. ------_=_NextPart_001_01C2C81F.68CF0746-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Deshpande, Kirti INET: kirti.deshpande_at_verizon.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 Wed Jan 29 2003 - 23:19:34 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US