From: Dereck L. Dietz on
The below is a portion of an email describing how the plan for disaster
recovery has been explained to us. 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.
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.
3.. Export every table by schema (all table data) - This is all the data.
Step2: Every export file is zipped and encrypted using gpg

Step3: Move the whole archive to USB drive.

The entire process takes about 5 full days. Which is ok considering its
once a month job. Most of it is automatically done except for moving to usb
and preparing the scripts. The total size of this is about 170GB.

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




From: sybrandb on
On Tue, 22 Jul 2008 21:28:53 -0400, "Dereck L. Dietz"
<dietzdl(a)ameritech.net> wrote:

>The below is a portion of an email describing how the plan for disaster
>recovery has been explained to us. 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.
> 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.
> 3.. Export every table by schema (all table data) - This is all the data.
>Step2: Every export file is zipped and encrypted using gpg
>
>Step3: Move the whole archive to USB drive.
>
> The entire process takes about 5 full days. Which is ok considering its
>once a month job. Most of it is automatically done except for moving to usb
>and preparing the scripts. The total size of this is about 170GB.
>
>We have 1tb disks which can hold up to 5 or 6 of these copies.
>
>
>
This is not about disaster recovery. This is about flagrant
incompetence.
First of all export is NOT a disaster recovery option. Export is a
*logical* dump. This means if you use exp imp to recover a database
you do NOT have a physically identical copy, so you CAN'T use archives
to recover your database.

Secondly: you describe this nonsense is going to take 5 (FIVE) full
days. Will the 'export' be consisted? OF COURSE NOT.

Apart from that : a 170 Gb 'export' is nonsense. Did you take into
account how much time it takes to import it?

The only option if you insist on misusing exp as a disaster recovery
mechanism for this database, is using transportable tablespaces.

However, I would recommend using this 'plan' or the paper it was
printed on as toilet paper.

--
Sybrand Bakker
Senior Oracle DBA
From: gazzag on
On 23 Jul, 02:28, "Dereck L. Dietz" <diet...(a)ameritech.net> wrote:
> The below is a portion of an email describing how the plan for disaster
> recovery has been explained to us.  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.
>   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.
>   3.. Export every table by schema (all table data) - This is all the data.
> Step2:     Every export file is zipped and encrypted using gpg
>
> Step3:     Move the whole archive to USB drive.
>
>  The entire process takes about 5 full days. Which is ok considering its
> once a month job. Most of it is automatically done except for moving to usb
> and preparing the scripts. The total size of this is about 170GB.
>
> We have 1tb disks which can hold up to 5 or 6 of these copies.

Who devised this "strategy"? Have they not heard of RMAN, for
example?

-g
From: Ed Prochak on
On Jul 22, 8:28 pm, "Dereck L. Dietz" <diet...(a)ameritech.net> wrote:
> The below is a portion of an email describing how the plan for disaster
> recovery has been explained to us. 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.
> 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.
> 3.. Export every table by schema (all table data) - This is all the data.
> Step2: Every export file is zipped and encrypted using gpg
>
> Step3: Move the whole archive to USB drive.
>
> The entire process takes about 5 full days. Which is ok considering its
> once a month job. Most of it is automatically done except for moving to usb
> and preparing the scripts. The total size of this is about 170GB.
>
> We have 1tb disks which can hold up to 5 or 6 of these copies.

Along with other comments, I will add that this is at best half of
disaster recovery planning. Have you ever actually tried to restore
from these backups? Until you can successfully do that, you do not
have a recovery plan.
Ed
From: Dereck L. Dietz on

"gazzag" <gareth(a)jamms.org> wrote in message
news:28dd705b-5d2c-4962-a960-cdb88031e91a(a)d1g2000hsg.googlegroups.com...
On 23 Jul, 02:28, "Dereck L. Dietz" <diet...(a)ameritech.net> wrote:
> The below is a portion of an email describing how the plan for disaster
> recovery has been explained to us. 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.
> 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.
> 3.. Export every table by schema (all table data) - This is all the data.
> Step2: Every export file is zipped and encrypted using gpg
>
> Step3: Move the whole archive to USB drive.
>
> The entire process takes about 5 full days. Which is ok considering its
> once a month job. Most of it is automatically done except for moving to
> usb
> and preparing the scripts. The total size of this is about 170GB.
>
> We have 1tb disks which can hold up to 5 or 6 of these copies.

Who devised this "strategy"? Have they not heard of RMAN, for
example?

-g

Our off site DBA.

I've been harping about RMAN since I first started here (as a contractor
before being hired in). Other than having my head bit off I was told he
wasn't using RMAN because he didn't have an RMAN repository set up. I think
I got in trouble for calling him on the fact that the repository isn't
mandatory for using RMAN.