Re: Oracle recovery

From: Tim Gorman <tim_at_sagelogix.com>
Date: Mon, 03 May 2004 13:45:52 -0600
Message-ID: <BCBBFD90.143EF%tim@sagelogix.com>

My sympathies. Traditionally, it is the business that calls the shots to IS/IT, not the other way around.

Work with the business to identify and document recovery requirements, not "backup requirements", but requirements for recovery. How quickly? To point-in-time of backup or to point-in-time of failure? How much data loss can be tolerated? How often? Document the business's expectations for recoverability along with their business justification. For example.

Expectations: During 7am-7pm ET period on non-holiday weekdays, application must be available 100% of the time time. If failure occurs, service must be restored within 2 hours max. No loss of data can be tolerated for any reason for any duration during this time period.
Justification: Average volume of orders taken during this period is $200,000 per hour. Union rules dictate that a work stoppage exceeding 2 hours equates to end of shift. All application activity supports customer-facing activity, so loss of data impacts directly on customer perception and service levels.

And so on. Just like journalism: what, where, who, how, when. It doesn't have to be too extensive, but just enough to prove the point that recovery to the point-in-time-of-failure is expected, which the EXP/IMP mechanism is inarguably incapable of supplying.

Assuming that your DBA is rational, then he/she is probably making certain assumptions about your recovery requirements, and he/she should be capable of describing exactly what those assumptions are. Actually, that is a decent "litmus test" to determine rationality. In that case, consider it your responsibility to prove those assumptions incorrect, and work from there.

After you've broken through that barrier, then you might need to perform more extensive requirements-gathering in order to determine which recovery mechanism(s) best fulfill the requirement. That should start a whole discussion about user-managed backup scripts versus RMAN versus BCV splits versus Data Guard versus ... (ad nauseum) ... One way to break through a logjam during that debate is to request a recovery test, as proof.

Of course, if the DBA is not rational, then you can only hope that his/her managers are rational...

Hope this helps...

-Tim

on 5/3/04 1:15 PM, M.Godlewski at mcgodlewski_at_yahoo.com wrote:

> Believe it or not the database I'm currently using the DBA is forcing us to
> use exports as our applications recovery scenario. I'm trying to locate
> information about archive logging and the tablespace point in time recovery
> versus full database recovery. I wanted to find some kind of percentages
> about the number of databases that need full database recovery (ie applying
> all archive logs) and percentages of databases that only needed TSPIR.
>
> I thinking if I can get some type of failure rate it could help sway him into
> using archive log mode which would give us better recovery options.

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org 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
-----------------------------------------------------------------

Received on Mon May 03 2004 - 14:45:00 CDT