1.) Change your database to archivelog mode.
2.) Make sure your on-line redo log is mirrored, if not in hardware, =
than in Oracle.
3.) Same for controlfiled, mirror them.
4.) Once you 're in archive log mode, you don 't *need* to do hot =
backups,
it is nice to have that ability and not impact database uptime.
5.) Consider RMAN, if at all possible. RMAN is the future, and it
also helps make your backups less error-prone.
6.) When you think you have a valid backup and recovery strategy, TEST =
IT!
7.) TEST IT AGAIN!
8.) Come up with more scenarios, and test it again!
Additional reading:
Oracle Concepts Manual
Oracle Backup and Recovery Manual
Oracle Recovery Manager (RMAN) Manual
Rama Velpuri 's Backup and Recovery Book
Hope that helps,
-Mark
-- --Original Message-- --
From: oracle-l-bounce@(protected)
[mailto:oracle-l-bounce@(protected)]On Behalf Of Wolfe Stephen S GS-11
6 MDSS/SGSI
Sent: Tuesday, June 29, 2004 12:00 PM
To: oracle-l@(protected)
Subject: Question of degrees in Oracle DB recovery
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@(protected)
(813) 827-9972 DSN 651-9972=3D20
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe send email to: oracle-l-request@(protected)
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@(protected)
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
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
