From oracle-l-bounce@freelists.org Tue Jun 29 11:19:47 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i5TGJWg02072 for ; Tue, 29 Jun 2004 11:19:42 -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 i5TGJM602037 for ; Tue, 29 Jun 2004 11:19:32 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5C3BB72C3A7; Tue, 29 Jun 2004 11:01:58 -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 02453-34; Tue, 29 Jun 2004 11:01:58 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6268A72C6AB; Tue, 29 Jun 2004 11:01:57 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 29 Jun 2004 11:00:25 -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 755C872C6ED for ; Tue, 29 Jun 2004 11:00:24 -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 02403-20 for ; Tue, 29 Jun 2004 11:00:24 -0500 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id EEB6972C6C7 for ; Tue, 29 Jun 2004 11:00:23 -0500 (EST) Received: from phys-giza-1 ([129.147.4.102]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5TGMtil000047 for ; Tue, 29 Jun 2004 10:22:55 -0600 (MDT) Received: from conversion-daemon.giza-mail1.Central.Sun.COM by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I0200501W0CC7@giza-mail1.Central.Sun.COM> (original mail from Daniel.Fink@Sun.COM) for oracle-l@freelists.org; Tue, 29 Jun 2004 10:22:55 -0600 (MDT) Received: from sun.com (sr1-ubrm-15.Central.Sun.COM [129.147.4.62]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I02004C2W3VS2@giza-mail1.Central.Sun.COM> for oracle-l@freelists.org; Tue, 29 Jun 2004 10:21:32 -0600 (MDT) Date: Tue, 29 Jun 2004 10:21:31 -0600 From: Daniel Fink Subject: Re: Question of degrees in Oracle DB recovery In-reply-to: <9F3E28811297F44CBE71EC2C91712E1A748C1D@amcw2ms512.amc.ds.af.mil> To: oracle-l@freelists.org Message-id: <40E1970B.8080000@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 References: <9F3E28811297F44CBE71EC2C91712E1A748C1D@amcw2ms512.amc.ds.af.mil> X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 3957 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Daniel.Fink@Sun.COM Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Stephen, I would suggest (gently) that you purchase the Oracle Backup and Recovery Handbook to get the fundamentals of how Oracle performs B&R. It is a very enlightening book in many ways. The Oracle doc is not bad either and the Recovery 101 book has its good points (no offense to either author intended, I just prefer B&R Handbook). I also have a paper (started to get out of data) called "Real Life Recovery" on my website (www.optimaldba.com) that might help. All of the production/qa databases our team supports can be recovered to a point in time. Some of the development databases are able to be recovered to a PIT, others not. I am not an expert in RMAN (here comes Tim with a big stick), so I am only going to address the fundamentals. You can implement this approach regardless of the backup software you are using. In terms of your situation, all of the components for a PIT recovery in Oracle already exist. With the proper information, Oracle can recover to the last *committed* transaction (before a failure/shutdown). The key to this is to enable archiving and properly manage the archived redo logs. Key point - Redo logs (online and archived) are the *MOST* important files in your database system. If you are unable to read a log during recovery (missing or corrupted), you cannot move forward. (Yes, I know there are ways around this, but they are not for the faint of heart and have serious side-effects). Keeping a copy on the SAN and another storage device (local disk for example) is not a bad idea. My rule of thumb for logs is that they are on at least 2 backup sets (tape or other offline storage) in non-compressed format and 3 more sets in compressed format. There is nothing worse than going to management and saying "We can't recover the database as the archived redo logs are corrupted." (yup, been there, done that, got the t-shirt). If you have all of the redo logs from the beginning of the database, you can (in theory, I've never tried this myself) recover the database to the point of failure without having a single backup of the datafiles. One of the advantages to this approach is that you do not need to change your backup process at this time. If you want to eventually perform online (hot) backups, you will need to enable archiving anyway. I hope this answers some of your questions. Feel free to ask more or request clarification...that's what we are here for. Regards, Daniel Fink Wolfe Stephen S GS-11 6 MDSS/SGSI 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=20 > > > ---------------------------------------------------------------- > 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 -----------------------------------------------------------------