Return-Path: <oracle-l-bounce@freelists.org>
Delivered-To: 2-oracle-l@orafaq.com
Received: (qmail 5443 invoked from network); 20 Jan 2007 15:04:44 -0600
Received: from softdnserror (HELO turing.freelists.org) (206.53.239.180)
  by softdnserror with SMTP; 20 Jan 2007 15:04:40 -0600
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 86F485A9CD3;
 Sat, 20 Jan 2007 16:02:25 -0500 (EST)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 01442-04-4; Sat, 20 Jan 2007 16:02:25 -0500 (EST)
Received: from turing (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id F398E5A9CD4;
 Sat, 20 Jan 2007 16:02:24 -0500 (EST)
Received: with ECARTIS (v1.0.0; list oracle-l); Sat, 20 Jan 2007 16:01:15 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8B8485A944D
 for <oracle-l@freelists.org>; Sat, 20 Jan 2007 16:01:15 -0500 (EST)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 01105-09 for <oracle-l@freelists.org>;
 Sat, 20 Jan 2007 16:01:15 -0500 (EST)
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 537905A9B30
 for <oracle-l@freelists.org>; Sat, 20 Jan 2007 16:01:11 -0500 (EST)
Received: by ug-out-1314.google.com with SMTP id a2so725862ugf
        for <oracle-l@freelists.org>; Sat, 20 Jan 2007 13:02:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=YNQZBKykFAWRw5Z40q8LQ5WhPQZxO4a2+2OusdVKqke8kWEexwMXijQ4wNhu8oC7FhNeLxA6Iw3FpXqpcWw+hLr00DGnHX9qKensGGE+53HPZvh2RxFnMSJqSKJzFxBGpvkB2cGTTrIeZ+nZpiOFVbZKGkw1KoTWbEea5BmD8B0=
Received: by 10.82.111.8 with SMTP id j8mr3240209buc.1169326925213;
        Sat, 20 Jan 2007 13:02:05 -0800 (PST)
Received: by 10.78.206.15 with HTTP; Sat, 20 Jan 2007 13:02:04 -0800 (PST)
Message-ID: <7765c8970701201302r61de6701xca91ec083fa70120@mail.gmail.com>
Date: Sat, 20 Jan 2007 21:02:04 +0000
From: "Niall Litchfield" <niall.litchfield@gmail.com>
To: ajoshi977@yahoo.com
Subject: Re: statistics stability
Cc: oracle-l@freelists.org
In-Reply-To: <398604.30993.qm@web58004.mail.re3.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_117098_33114062.1169326924975"
References: <398604.30993.qm@web58004.mail.re3.yahoo.com>
X-archive-position: 44542
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: niall.litchfield@gmail.com
Precedence: normal
Reply-to: niall.litchfield@gmail.com
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <oracle-l-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: oracle-l <oracle-l.freelists.org>
X-List-ID: oracle-l <oracle-l.freelists.org>
List-subscribe: <oracle-l-request@freelists.org?Subject=subscribe>
List-owner: <mailto:steve.adams@ixora.com.au>
List-post: <mailto:oracle-l@freelists.org>
List-archive: <http://www.freelists.org/archives/oracle-l>
X-list: oracle-l
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at avenirtech.net
------=_Part_117098_33114062.1169326924975
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In many/most database operations a lot of data access is rather date
dependent 'orders in the last week','profits this quarter' etc etc. After a
while of not gathering stats, the optimizer will 'know' that it is returning
no data for this sort of query. :(

On 1/20/07, A Joshi <ajoshi977@yahoo.com> wrote:
>
> Hi,
>   Question : Is it advisable to stop generating periodic (weekly, monthly)
> statistics if I think I am getting the right query plans for my tables and
> major application are running fine. Then generate statistics for new tables
> and tables with new index and I think new column too.  I assume new
> statistics would be needed in case of index rebuild. I do not have
> histograms for any tables and the I think general distribution of data will
> remain same. I am thinking the reason for statistics is to guard against
> change in data distribution and if that is remaining same then no need to
> generate statistics periodically. Please correct me if I am wrong and if
> there are other reasons for periodic generate. I am on 9i. This way if there
> is reported performance degradation then we can be sure that it is not due
> to change in plan due to statistics. Right now I am saving statistics
> weekly/monthly but still sometimes it is difficult to trouble shoot. I also
> do not know the impact if generate statistics gets interrupted or some other
> impact like database crash during the generate. Like losing statistics or
> having only table statistics change but index statistics do not change. Or
> some other issue.
>
> Has anyone tried this approach or generate statistics with periodic
> interval like 6 months? Any other factors to consider?
> Thanks for help.
>
> ------------------------------
> TV dinner still cooling?
> Check out "Tonight's Picks"<http://us.rd.yahoo.com/evt=49979/*http://tv.yahoo.com/>on Yahoo! TV.
>
>


-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

------=_Part_117098_33114062.1169326924975
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In many/most database operations a lot of data access is rather date dependent &#39;orders in the last week&#39;,&#39;profits this quarter&#39; etc etc. After a while of not gathering stats, the optimizer will &#39;know&#39; that it is returning no data for this sort of query. :( 
<br><br><div><span class="gmail_quote">On 1/20/07, <b class="gmail_sendername">A Joshi</b> &lt;<a href="mailto:ajoshi977@yahoo.com">ajoshi977@yahoo.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Hi,</div>  <div>&nbsp;&nbsp;Question : Is it advisable to stop generating periodic (weekly, monthly) statistics if I think I am getting the right query plans for my tables and major application are running fine.&nbsp;Then generate statistics for new tables and tables with new index and I think new column too.&nbsp; I assume new statistics would be needed in case of index rebuild. I do not have histograms for any tables and the I think general distribution of data will remain same. I am thinking the reason for statistics is to guard against change in data distribution and if that is remaining same then no need to generate statistics periodically. Please correct me if I am wrong and if there are other reasons for periodic generate.&nbsp;I am on 9i. This way if there is reported performance degradation&nbsp;then&nbsp;we can be sure that it is not due to change in plan due to statistics. Right now I am saving statistics weekly/monthly but still sometimes it is difficult to
 trouble shoot. I also do not know the impact if generate statistics gets interrupted or some other impact like database crash during the generate. Like losing statistics or having only table statistics change but index statistics do not change. Or some other issue. 
</div>  <div>&nbsp;</div>  <div>Has anyone tried this approach or generate statistics with periodic interval like 6 months? Any other factors to consider?&nbsp; </div>  <div>Thanks for help. </div><span class="ad"><p> 

</p><hr size="1">TV dinner still cooling?<br><a href="http://us.rd.yahoo.com/evt=49979/*http://tv.yahoo.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Check out &quot;Tonight&#39;s Picks&quot;
</a> on Yahoo! TV.
<p></p></span></blockquote></div><br><br clear="all"><br>-- <br>Niall Litchfield<br>Oracle DBA<br><a href="http://www.orawin.info">http://www.orawin.info</a>

------=_Part_117098_33114062.1169326924975--
--
http://www.freelists.org/webpage/oracle-l


