Re: Comments?

Comments embedded.
On Jul 22, 8:28 pm, "Dereck L. Dietz" <diet..._at_ameritech.net> wrote:
> The below is a portion of an email describing how the plan for disaster
> recovery has been explained to us.  

This plan is a disaster, and now that I've recovered from reading it ...

> This is an Oracle 10g database running
> on Windows 2003 server.
>
> The way we did the disaster recovery backup is:
>
>  Step1:
>
>   1.. Export the entire db (with no rows option) - This will get a copy of
> export to recreate the database with all users and system settings.

And you can use imp with rows=n from a full export including rows to do the exact same thing.

>   2.. Export the entire schema (with no rows option) - This will get a copy
> of export to recreate empty table shells with indexes, keys and all
> procedures, packages, functions and any other metadata for each user.

And, gee whiz gollee whilikers, you can do THAT, too, from a full export including rows by using both the rows=n command-line parameter and the fromuser/touser options.

>   3.. Export every table by schema (all table data) - This is all the data.

Again, which you'd have in a full export including data. So can someone explain why THREE exports are taken when ONE will suffice???

> Step2:     Every export file is zipped and encrypted using gpg
>

And you can do that with the single, fully loaded export someone seems to think is unnecessary.

> Step3:     Move the whole archive to USB drive.

Oh, joy, now you have mobile media that can be subject to tampering carrying these three wonderful exports, which are nothing more than point in time copies of the database structures and data. Absolutely NO recovery via archived redo log application can be effected (as already stated by Sybrand) so how can anyone seriously consider this three-ring-circus of busywork a backup strategy? Any series of database 'backup/recovery' events that requires 5 full days of attention to complete isn't a disaster recovery plan, it's a planned disaster. It certainly isn't a usable recovery method.

>
>  The entire process takes about 5 full days.

Sourdough starter takes less time to ferment.

> Which is ok considering its
> once a month job.

Because when you finally finish the current 'backup' it's time to start the process over again.

> Most of it is automatically done except for moving to usb
> and preparing the scripts. The total size of this is about 170GB.

Ridiculous, really.

>
> We have 1tb disks which can hold up to 5 or 6 of these copies.

You can perform 6 of these 'backups' in a month's time ... and no one has mentioned the issue of someone changing object definitions between the time the first glorious export is taken and the second is begun, thus invalidating the first effort and requiring the entire process to begin anew.

[from a subsequent response by you]

> ... I was told he wasn't using RMAN because he didn't have an RMAN repository set up.

As you stated in a follow-up post that's hogwash. Possibly he's having difficulty spelling RMAN ... what could be simpler than issuing two commands to RMAN

restore database;
recover database;

to put your database in working order again? I must agree with Sybrand and state this is nothing except flagrant incompetence. I think you need a new off-site DBA.

David Fitzjarrell Received on Sat Jul 26 2008 - 15:26:15 CDT