Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 29346 invoked from network); 5 Mar 2008 19:39:57 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by static-ip-69-64-49-119.inaddr.intergenia.de with SMTP; 5 Mar 2008 19:39:56 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 630798177D0; Wed, 5 Mar 2008 20:39:55 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29828-06; Wed, 5 Mar 2008 20:39:55 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CFF8F81786B; Wed, 5 Mar 2008 20:39:54 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 05 Mar 2008 20:37:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1095B818094 for ; Wed, 5 Mar 2008 20:37:48 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29021-10 for ; Wed, 5 Mar 2008 20:37:47 -0500 (EST) Received: from usy90mx04.tycoelectronics.net (usy90mx04.tycoelectronics.net [198.137.214.6]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id AF8CC818081 for ; Wed, 5 Mar 2008 20:37:47 -0500 (EST) Received: from us194mx16.tycoelectronics.net ([163.241.185.153]) by usy90mx04.tycoelectronics.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 20:37:46 -0500 Received: from us194mx20.tycoelectronics.net ([163.241.185.250]) by us194mx16.tycoelectronics.net with Microsoft SMTPSVC(6.0.3790.2499); Wed, 5 Mar 2008 20:37:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87F2A.ADBC2C6B" Subject: RE: Log file sync and log file parallel write. Date: Wed, 5 Mar 2008 20:37:45 -0500 Message-ID: <70C6CD0D975AFC43859A976DFD98C2FE0757C780@us194mx20.tycoelectronics.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Log file sync and log file parallel write. References: <70C6CD0D975AFC43859A976DFD98C2FE073E026A@us194mx20.tycoelectronics.net> <489203.90609.qm@web56610.mail.re3.yahoo.com> From: "Johnson, William L (TEIS)" To: "Jared Still" , Cc: X-OriginalArrivalTime: 06 Mar 2008 01:37:46.0476 (UTC) FILETIME=[AE01B2C0:01C87F2A] X-archive-position: 6044 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: WLJohnson@tycoelectronics.com Precedence: normal Reply-to: WLJohnson@tycoelectronics.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain ------_=_NextPart_001_01C87F2A.ADBC2C6B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can someone help point me to documentation that will show me the silver bullet for not rebuilding indexes? I can provide countless examples over the past several years where rebuilding indexes corrected performance problems that developed over months. Are we saying that something else fixed the problem and that the index rebuild was not the real solution? Is the index rebuild forcing explain plans out of the shared_pool and giving false results? If so, wouldn't a DB stop/start accomplish the same result? I am by no means an optimizing expert, but won't Oracle switch to something like full table scans if the index is no longer an effective method to obtain your data? This quickly becomes a problem when joining multiple tables with 10+ million rows each. I deal a lot with third party applications like SAP, Click Commerce and Matrix One Engineering modules where we can not alter the sql running behind the scenes. =20 I would really like to understand. =20 Bill =20 ________________________________ From: Jared Still [mailto:jkstill@gmail.com]=20 Sent: Wednesday, March 05, 2008 7:39 PM To: asif_oracle@yahoo.com Cc: Johnson, William L (TEIS); oracle-l@freelists.org Subject: Re: Log file sync and log file parallel write. =20 =09 Lastly, why are you rebuilding your indexes??? Regards Asif Momen http://momendba.blogspot.com =20 Same question. Why are you rebuilding the indexes? You *could* just stop doing that. --=20 Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist ------_=_NextPart_001_01C87F2A.ADBC2C6B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can someone help point me to = documentation that will show me the silver bullet for not rebuilding indexes?  I = can provide countless examples over the past several years where rebuilding = indexes corrected performance problems that developed over months.  Are we = saying that something else fixed the problem and that the index rebuild was not = the real solution?  Is the index rebuild forcing explain plans out of = the shared_pool and giving false results?  If so, wouldn’t a DB stop/start accomplish the same result?  I am by no means an = optimizing expert, but won’t Oracle switch to something like full table scans = if the index is no longer an effective method to obtain your data?  This = quickly becomes a problem when joining multiple tables with 10+ million rows = each.   I deal a lot with third party applications like SAP, Click Commerce and = Matrix One Engineering modules where we can not alter the sql running behind = the scenes.

 

I would really like to = understand.

 

Bill

 

From: Jared = Still [mailto:jkstill@gmail.com] =
Sent: Wednesday, March = 05, 2008 7:39 PM
To: = asif_oracle@yahoo.com
Cc: Johnson, William L = (TEIS); oracle-l@freelists.org
Subject: Re: Log file = sync and log file parallel write.

 


Lastly, why are you rebuilding your indexes???
Regards
Asif Momen
http://momendba.blogspot.com

 



Same question. Why are you rebuilding the indexes?

You *could* just stop doing that.

--
Jared Still
Certifiable Oracle DBA and Part Time Perl = Evangelist

------_=_NextPart_001_01C87F2A.ADBC2C6B-- -- http://www.freelists.org/webpage/oracle-l