Return-Path: Received: from ensim.rackshack.net (root@localhost) by orafaq.net (8.11.6/8.11.6) with ESMTP id h8TNY6n25875 for ; Mon, 29 Sep 2003 18:34:06 -0500 X-ClientAddr: 66.27.56.210 Received: from ns3.fatcity.com (rrcs-west-66-27-56-210.biz.rr.com [66.27.56.210]) by ensim.rackshack.net (8.11.6/8.11.6) with ESMTP id h8TNY6c25870 for ; Mon, 29 Sep 2003 18:34:06 -0500 Received: from ns3.fatcity.com (localhost.localdomain [127.0.0.1]) by ns3.fatcity.com (8.12.8/8.12.8) with ESMTP id h8TKo1Rw009784 for ; Mon, 29 Sep 2003 13:53:50 -0700 Received: (from root@localhost) by ns3.fatcity.com (8.12.8/8.12.5/Submit) id h8TKZPSl004435 for oracle-l@orafaq.net; Mon, 29 Sep 2003 13:35:26 -0700 Received: by fatcity.com (05-Jun-2003/v1.0g-b73/bab) via fatcity.com id 005D1656; Mon, 29 Sep 2003 13:34:39 -0800 Message-ID: Date: Mon, 29 Sep 2003 13:34:39 -0800 To: Multiple recipients of list ORACLE-L X-Comment: Oracle RDBMS Community Forum X-Sender: "Niall Litchfield" Sender: ml-errors@fatcity.com Reply-To: ORACLE-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: "Niall Litchfield" Subject: RE: BAARF Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 73; ListGuru (c) 1996-2003 Bruce A. Bergman Precedence: bulk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cary writes > It *is* a good idea to separate index data from heap data > into different tablespaces. But the reason isn't solely to > eliminate I/O competition. Even if I/O competition isn't an > issue for you (and the OFA Standard doesn't say that it will > be), then it's *still* a good idea to separate your index > data from your heap data, for reasons including: > > * Index segments have different backup and recovery > requirements than their corresponding heap segments. For > example, as Peter mentioned, if you have an index block > corruption event, then it's convenient to just offline, kill, > and rebuild an index tablespace. If the indexes and data are > mixed up in a single tablespace, this is not an option. Another > example: If you construct your backup schedule to make media > recovery time a constant, then you probably don't need to > back up your indexes on the same schedule as you back up your > heaps. But unless they're in different tablespaces, this > isn't an option either. Hmmm maybe I'm going to start having to rethink some stuff, when you and Howard agree and I disagree it seems likely I'm being dense. My concern goes Indexes are largely built for one of two reasons A) to make performance acceptable. B) to enforce constraints. In a media recovery situation, recovering but with unacceptable performance or locking issues probably doesn't really constitute recovery. Now If it can be shown that trashing the index tablespace and rebuilding is generally faster than restoring datafiles and applying logs I might be more convinced but at the moment I'm not so sure. So is this garbage Or not.? Niall -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Niall Litchfield INET: niall.litchfield@dial.pipex.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@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).