RE: Inheriting a "interesting" recovery process
- From: "Peter McLarty" <Peter_McLarty@xxxxxxxxxxxxxxxxxxxxx>
- To: <stvsmth@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 4 Aug 2006 10:56:50 +1000
Hi
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of stv
Sent: Friday, 4 August 2006 9:35 AM
To: oracle-l@xxxxxxxxxxxxx
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:
//www.freelists.org/archives/oracle-l/06-2004/msg02261.html
Scanned stuff here:
http://www.orafaq.com/faq/backup_recovery
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts: