RE: Question of degrees in Oracle DB recovery
- From: "Goulet, Dick" <DGoulet@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 29 Jun 2004 14:22:13 -0400
Dennis,
"A backup practice can't be trusted unless you've tested it with an
actual recovery."
Point WELL taken. Try to do that as often as possible.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: DENNIS WILLIAMS [mailto:DWILLIAMS@xxxxxxxxxxxxx]
Sent: Tuesday, June 29, 2004 12:27 PM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Question of degrees in Oracle DB recovery
Stephen
You are getting some excellent responses. I don't see where the =
following
point was mentioned (forgive me if I have overlooked it)=20
- A backup practice can't be trusted unless you've tested it with an
actual recovery.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx=20
I said it "looked" clear - Riddick
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Daniel Fink
Sent: Tuesday, June 29, 2004 11:22 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Question of degrees in Oracle DB recovery
Stephen,
I would suggest (gently) that you purchase the Oracle Backup and =
Recovery
Handbook to get the fundamentals of how Oracle performs=20
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=20
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=20
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=20
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=20
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=20
can recover to the last *committed* transaction (before a =
failure/shutdown).
The key to this is to enable archiving and properly=20
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=20
during recovery (missing or corrupted), you cannot move forward. (Yes, I
know there are ways around this, but they are not for the=20
faint of heart and have serious side-effects). Keeping a copy on the SAN =
and
another storage device (local disk for example) is not=20
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=20
format and 3 more sets in compressed format. There is nothing worse than
going to management and saying "We can't recover the=20
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=20
from the beginning of the database, you can (in theory, I've never tried
this myself) recover the database to the point of failure=20
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=20
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.
>=20
> How many of you guys provide as close as possible to the
> transaction-on-the-fly point-in-time recovery?
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20
> v/r
>=20
> Stephen S. Wolfe, GS-11, DAFC
> Data Services Manager
> stephen.wolfe@xxxxxxxxxxxxxx
> (813) 827-9972 DSN 651-9972=3D20
>=20
>=20
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
