From oracle-l-bounce@freelists.org Mon Jun 14 02:38:23 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i5E7cDF17485 for ; Mon, 14 Jun 2004 02:38:23 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i5E7c2617460 for ; Mon, 14 Jun 2004 02:38:12 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id EC43F72CC43; Mon, 14 Jun 2004 02:22:57 -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 05013-26; Mon, 14 Jun 2004 02:22:57 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4779F72CC19; Mon, 14 Jun 2004 02:22:57 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 14 Jun 2004 02:21:38 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3DCA572C5DD for ; Mon, 14 Jun 2004 02:21:38 -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 03599-97 for ; Mon, 14 Jun 2004 02:21:38 -0500 (EST) Received: from ahmet.cerebrussolutions.com (unknown [194.202.36.50]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id 9612872C5BB for ; Mon, 14 Jun 2004 02:21:37 -0500 (EST) Received: from louis.cerebrus.com ([192.168.2.1]) by ahmet.cerebrussolutions.com (SAVSMTP 3.1.5.43) with SMTP id M2004061408501510563 for ; Mon, 14 Jun 2004 08:50:15 +0100 Content-class: urn:content-classes:message Subject: RE: SAP Reorgs MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Ecartis Date: Mon, 14 Jun 2004 08:45:29 +0100 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SAP Reorgs Thread-Index: AcRRT3Mga6U7TfKDRrWN6Pwar9PDtQAd1sgAAAco8TAFrom: "David Sharples" To: X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 2644 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: dsharples@cerebrussolutions.com Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l From: oracle-l-bounce@freelists.org X-Virus-Scanned: by amavisd-new at freelists.org No-one says a re-org will never help, just that you need to identify areas which might benefit from it. Blindly re-org tables and rebuilding indexes is a waste of time unless you are sure it needs to be done -----Original Message----- From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Vergara, Michael (TEM) Sent: 14 June 2004 05:32 To: oracle-l@freelists.org Subject: RE: SAP Reorgs Dan: I am surprised at the responses you are receiving about doing Reorgs. Everyone seems to think it's dumb and unnecessary. We use SAP here at Guidant. It's our 900-lb gorilla application. As goes SAP, so goes most if not all of the other systems and databases. We reorg regularly. We see a palpable return on several levels from performing this activity. We archive data on a active schedule, and reorging the tables/tablespaces that have just been archived brings down the tablespace size, rebuilds the indexes for improved performance, and allows us better management of our disk space. It is for performance and savings that we reorg. We do not need to buy as much disk every year, and the performance remains acceptable to the users. I know...everybody says disk is cheap; try telling my manglement when we submit a purchase req for more EMC disk. Cheap? Not from our budget! With that off my chest, we use Quest Live Reorg to perform our reorgs. Basically, LR does a CTAS, and then mines the redo logs to keep the current table and the reorged table in sync until 'cutover', which is when the new table becomes the main table and the former main table becomes baggage. We cutover late on Saturday night, when we can safely take SAP down without impacting too many users - Quest claims to the contrary, SAP does notice (and complains bitterly) when the cutover happens if you try it with SAP up. But cutover only takes minutes, and we've not yet (hear the sound of me knocking on wood, crossing myself, and lighting a candle) had an issue with the cutover that was not recoverable. Cheers, Mike -----Original Message----- From: Dan Hotka [mailto:dhotka@earthlink.net] Sent: Sunday, June 13, 2004 7:04 AM To: oracle-l@freelists.org Subject: SAP Reorgs Hi, I have a gig where they have a rather large SAP database...they want to reorg it...then periodically reorg it. I'll find out this next week all the specifics. I am wondering if anyone has any experience in doing reorgs on SAP databases. What I should look for...what I should look out for...SAP specific things...which objects needs periodic reorgs...which objects needs a better storage parameters... Any help/comments would be most appreciated. Thank you in advance. Dan Hotka ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@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 ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@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 -----------------------------------------------------------------