From oracle-l-bounce@freelists.org Tue Jun 29 11:40:03 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i5TGdcQ05785 for ; Tue, 29 Jun 2004 11:39:48 -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 i5TGdR605713 for ; Tue, 29 Jun 2004 11:39:38 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D545872CAFC; Tue, 29 Jun 2004 11:22:03 -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 05876-41; Tue, 29 Jun 2004 11:22:03 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1522872CB13; Tue, 29 Jun 2004 11:22:02 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 29 Jun 2004 11:20:34 -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 A0D5B72C977 for ; Tue, 29 Jun 2004 11:20:33 -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 05211-69 for ; Tue, 29 Jun 2004 11:20:33 -0500 (EST) Received: from mail.sagelogix.com (unknown [69.15.85.3]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 440DD72C215 for ; Tue, 29 Jun 2004 11:20:33 -0500 (EST) Received: by mail.sagelogix.com (Postfix, from userid 16) id 529F2A8131; Tue, 29 Jun 2004 10:39:55 -0600 (MDT) Received: from ocs.sagelogix.com (ocs.sagelogix.com [192.168.25.20]) by mail.sagelogix.com (Postfix) with ESMTP id 8CC75A8512 for ; Tue, 29 Jun 2004 10:39:11 -0600 (MDT) Received: from sl132.sagelogix.com by ocs.sagelogix.com with ESMTP id 7638181088527281; Tue, 29 Jun 2004 10:41:21 -0600 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 29 Jun 2004 10:43:16 -0600 Subject: Re: Question of degrees in Oracle DB recovery From: Tim Gorman To: Message-ID: In-Reply-To: <9F3E28811297F44CBE71EC2C91712E1A748C1D@amcw2ms512.amc.ds.af.mil> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail.sagelogix.com X-Spam-Status: No, hits=0.0 required=3.0 tests=none autolearn=no version=2.63 X-Spam-Level: X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 3963 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: tim@sagelogix.com Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Stephen, One good rule of thumb is that nothing can be considered recoverable until it is copied to tape, at least once. Regardless of where your archivelog destination is located on disk, the files that reside there should simply be considered a convenience for faster recovery and not a recoverable repository of saved transactions. In other words, if they are there, then OK -- but don't count on them being there. The key is to get those archived redo logfiles backed up, very often and redundantly if possible. My advice is to create (at least) two "classes" or "policies" (terminology varies between tape-management packages) of backup jobs for each Oracle database: * a class of higher priority and frequency for backups of archived redo logfiles * a class of lower priority for datafile backups Backing up the archived redo logfiles is a much more urgent process than backing up datafiles, for many reasons, some of which you've touched upon. Thus, backing up those files should be a different higher-priority "job stream" separate from backing up datafiles. And, if both types of jobs are queued waiting for a tape drive, the jobs for archivelog files should "win". Datafile backups can wait -- archivelog backups should not wait. In this fashion, you can choose how close to real-time you are able recover to. For example, at one site running Oracle Apps R11.0.3, we scheduled archivelog backups to tape every 8 mins, which includes a call to ALTER SYSTEM SWITCH LOGFILE just before starting the backup. Datafile backups are nightly. We don't remove those archivelog files from disk after they are backed up, but have a separate job which removes the oldest when the file-system gets full or when they are 3 days old, which ever happens first. The devil is in the details, of course, but those are some important points to bear in mind. Hope this helps... -Tim on 6/29/04 9:59 AM, Wolfe Stephen S GS-11 6 MDSS/SGSI at Stephen.Wolfe@macdill.af.mil wrote: > First off, I'm an Oracle newbie for sure. My main question now is more > DR policy/intent > Oriented than technical. I'm still in the discovery process of all the > ways an Oracle instance can be recovered, I'm now reading a PDF on > online point-in-time recovery strategies and this is where I have a > question. > > How many of you guys provide as close as possible to the > transaction-on-the-fly point-in-time recovery? > > Currently, we do only an offline, once a day backup to a SAN on two > Oracle applications. I was asked last Friday if we had a catastrophic > failure (server destruction or totally non-recoverable disk failure) how > would I recover our TPOCS database. I replied I could recover to > whatever was there at 00:15 that day, because, with Crondsys we stop the > database, then backup the entire Oracle directory and all of its > subdirectories (I was told I actually only needed to keep the oradata > folder but we have a large SAN so why not get all the stuff config file, > etc) and an interface directory where daily interface files and archives > are kept from a system that sends data to TPOCS via importable text > delimited flat files. > > I received a few concerned looks because the using departments were > under the impression that I could bring them back to just before the > failure. I can't and the vendor that was tasked to provide the database > application was only tasked to provide a 24 hour backup scenario. If a > site wants anything better they have to do it on their own after > submitting the plan and procedures to the tier 3 helpdesk (the vendor) > for approval. > > I am doing a lot of reading right now, but I would like to get your > ideas on the cost and complexity of getting a true PIT recovery system > in place or can a near PIT be established like configuring the redo logs > to reside on the SAN instead of the local server? > > v/r > > Stephen S. Wolfe, GS-11, DAFC > Data Services Manager > stephen.wolfe@macdill.af.mil > (813) 827-9972 DSN 651-9972 ---------------------------------------------------------------- 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 -----------------------------------------------------------------