From oracle-l-bounce@freelists.org Thu Feb 17 23:10:13 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j1I5AD2s015490 for ; Thu, 17 Feb 2005 23:10:13 -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 j1I5ADem015486 for ; Thu, 17 Feb 2005 23:10:13 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3289373502; Thu, 17 Feb 2005 23:09:01 -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 19850-01; Thu, 17 Feb 2005 23:09:01 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A6BFF732E8; Thu, 17 Feb 2005 23:09:00 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 17 Feb 2005 21:08:19 -0700 Subject: Re: RMAN and VLDB's: managing RO tablespaces From: Tim Gorman To: "'oracle-l@freelists.org'" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 16367 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: tim@evdbt.com Precedence: normal Reply-To: tim@evdbt.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=AWL autolearn=ham version=2.60 X-Spam-Level: Use SKIP READONLY in your BACKUP command. on 2/17/05 7:35 PM, Teehan, Mark at mark.teehan@csfb.com wrote: > > Does anyone use 9i RMAN for VLDB's? I need to keep the a full backupset > compressed on disk: by directing files for RO tablespaces to one directory, > and rotating RW tablespaces in another directory to try and keep a consistent > backup on disk at all times. 9i Incrementals are no good as it will scan > hundreds of GB of RO tablespaces daily searching for changed blocks. > Does anyone see a problem with this sort of RO/RW split? Or does anyone know > if SQL*Backtrack does anything clever for large(ly) RO VLDBs? > > Thanks! > Mark -- http://www.freelists.org/webpage/oracle-l