RE: Inheriting a "interesting" recovery process

From: Peter McLarty <Peter_McLarty_at_technologyonecorp.com>
Date: Fri, 4 Aug 2006 10:56:50 +1000
Message-ID: <1BFEF5A6856E7C4D89A3DEE609AF884B9BD89E@brimail05.technologyonecorp.com>

You are off to a good start and yes you are correct in that the current system is not perfect

The export is good for a number of reasons the consistent=y is telling you that the export has no grey areas as you put it and at least the strategy has some value in that you are protected up to the last export unless the whole lot goes then only until the last tape went off site Export is also indirectly telling you that you have no block corruption as it block reads to do its work.

You are right in that your archive logging isn't really doing much as it stands and it may have some value in a desperate recovery

First thing as a short term improvement; routinely in your backup script conduct a backup controlfile to trace and copy that with your export file and put it to tape this then provides you with a another part to the recreation of a killed database.

Where would I go next that would depend on budget, service level requirements, like how long to recover and how long to reproduce lost work. It may be that all you need to do to improve is make sure your tapes are recoverable and you can do that in a timely manner.

Otherwise start reading up on the backup and recovery manual create yourself a test database and start learning how to run RMAN and now your archivelogs become part of your recovery strategy and will need backing up.

With RMAM and online backups you are entering a more complex world but you will have the ability to recover up to the minute well pretty close anyway of the database in a crash.
Of course depending on your other hardware you have you may just need to stay where you are until you can get some budget to advance the cause of faster recoveries

Oh and did I mention to make sure you can recovery what ever it is you right to tape

HTH Cheers

Peter McLarty
Technical Consultant
Service Delivery
+61733777542
TechnologyOne

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of stv Sent: Friday, 4 August 2006 9:35 AM
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 Thu Aug 03 2006 - 19:56:50 CDT