Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Inheriting a "interesting" recovery process

RE: Inheriting a "interesting" recovery process

From: Guerra, Abraham J <AGUERRA_at_amfam.com>
Date: Fri, 4 Aug 2006 08:11:28 -0500
Message-ID: <A787F31512A25E4F9782045CFE320C8014B4A41F@NHQ1ACCOEX05VS1.corporate.amfam.com>


Hello whoever you are (you forgot you sing your email)...

An export is only good as a last resource when everything else fails... or when you want to migrate a schema to another database and stuff like that.

Your very best friends are: 'Cold Backup' (hot whenever you can't do colds) and make sure your database is in archivelog mode if you want full recovery...

If your database stores traffic tickets, then keep doing whatever you're doing ;-)

Thanks.

Abraham Guerra
Oracle DBA
American Family Insurance

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of stv Sent: Thursday, August 03, 2006 6:35 PM
To: oracle-l_at_freelists.org
Subject: Inheriting a "interesting" recovery process

Greetings all,

Summary



I'm a newbie Oracle DBA in a new job [non-profit in a small town, life is like that sometimes ;-) ]. I'm busting my butt reading up on everything I can, but there is one issue that I want to understand immediately: RECOVERY. Right now, we are covered only by a nightly export using the EXP utility. Archived redo logs exist, but are not backed up.

Exactly how much data do we stand to lose? My guess is anything that happened after the export (i.e. the redo logs don't help much as things stand), but I'm not sure of that.

Does EXP have read consistency like a normal select? Or will there be some gray areas in the dump file if open transactions existed at the time of export?

Details



We are running Oracle 9.2.0.6.0 64bit on Solaris 8. However, the database has evolved since 1993 (starting, I believe, with Oracle 7.?), living through several front-end applications. There was one DBA for most of those years, self-taught, and one short-term guy before me (he lasted less than a year).

The nightly dump file is copied to an offsite machine, a local machine and, once a week, tape. There is only one copy of the archived redo logs (on a separate disk from the datafiles). These logs are not copied off the production machine at any time. The control files appear to be saved on a variety of disks, but are not copied off of the machine.

As I understand things, this is odd. Having archived logs is a Very Good Thing, but I read everything to say they are intended to be used with an official hot backup (i.e. ALTER TABLESPACE xyz BEGIN BACKUP).

Given that we are already in archived log mode, I think I have a basic understanding of where things need to go, using the proper hot backup commands, having more copies of the redo logs & such. But that's another post.

Right now I'd like to make sure the Powers That Be understand where we are and why I'm gonna be busy on something they perhaps thought was solid. I intend to start testing the recovery process ASAP ... is it even worth testing the current system?

Configurations



The export command:

exp USERID=system/secret BUFFER=30720 \

        GRANTS=Y ROWS=Y COMPRESS=Y \
        INDEXES=Y CONSTRAINTS=Y FULL=Y \
        CONSISTENT=Y STATISTICS=none

Some relevant init.ora settings:

# ARCHIVE

log_archive_dest=/u07/oradata/SID/archive
log_archive_format=arch_%t_%s.arc
log_archive_start=TRUE

#FILE CONFIGURATION
control_files=("/u02/oradata/SID/control01.ctl", "/u03/oradata/SID/control02.ctl", "/u04/oradata/SID/control03.ctl")

Resources



Saw this 2004 thread:
http://www.freelists.org/archives/oracle-l/06-2004/msg02261.html

Scanned stuff here:
http://www.orafaq.com/faq/backup_recovery

--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 04 2006 - 08:11:28 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US