From oracle-l-bounce@freelists.org Tue Mar 15 00:55:55 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j2F6tjVT032435 for ; Tue, 15 Mar 2005 00:55:46 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j2F6them032410 for ; Tue, 15 Mar 2005 00:55:43 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 336D286379; Tue, 15 Mar 2005 00:53:49 -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 19456-04; Tue, 15 Mar 2005 00:53:49 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id AB1B8861D9; Tue, 15 Mar 2005 00:53:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain Subject: Performance impact of MONITORING and GATHER_STALE Date: Tue, 15 Mar 2005 16:50:45 +1100 Message-ID: <18D551B1B928FF47A65B2D91F705906A0123E40F@HSNDON-EX01.hsntech.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Performance impact of MONITORING and GATHER_STALE Thread-Index: AcUpIu6zYE5jbcymQaKXJV7fxxfL7w== From: "Leng Kaing" To: X-OriginalArrivalTime: 15 Mar 2005 05:50:30.0765 (UTC) FILETIME=[E59A51D0:01C52922] Content-Transfer-Encoding: 8bit X-archive-position: 17302 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Leng.Kaing@hsntech.com Precedence: normal Reply-To: Leng.Kaing@hsntech.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on air891.startdedicated.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Hi guys, Apologies if I'm revisiting a beaten path but I've tried to search the archive, metalink and google and couldn't find my answer (or it may have been hiding). So I'll ask the question (again)... What is the performance impact of turning on MONITORING at the table level? Ie. ALTER TABLE x MONITORING. Will it have a negative impact on our production system? We'd like to make use the GATHER_STALE option rather than just blindly re-analyzing the entire schema. Is GATHER_STALE any more efficient than the normal estimate using dbms_stats.gather_table_stats command? Are you using MONITORING and GATHER_STALE in your production systems in the first place? TIA, Leng. --------------------------------------------------- Leng Kaing Hansen Technologies Phone: +61-3-9840-3832 -- http://www.freelists.org/webpage/oracle-l