backup ORACLE

[Chen Yingjie]

We are try to backup ORACLE8i on the HP-UX 11.00 by Omniback II 3.1 use DLT 8000.
Our Server machine is L2000.

We want to backup following filesystems during Oracle shutdown.(Cold Backup)

/PRODUCTS 5GB
/ORA_LOG 10GB
/ORA_CONTROL 4GB
/INDEX 20GB
/DBS/sys 15GB
/DBS/TBL 75GB
Total Size: 129GB

To backup above files, it will spend 6.5hours. and while to restore above,it will spend 8hours to 10hours.

In case of system failure, it is mean we should spend 10hours to recover the system.

Can someone advise me how to backup(restore) above files speedy?

Thank you and best regards.

Chen Yingjie

[Stefan Farrelly]

129GB to backup to a DLT8000, you should be able to get the DLT drive working at almost 30GB/hour if its on its own dedicated SCSI bus (with no disks on the same bus). That means your backup should take around 4.5 hours - if you back it up raw using Omniback (raw backup much faster than non-raw). The only other way to increase your backup and restore times is to use an additional DTL8000, that will halve your backup time to <3 hours and restore time to not much more. On some of our large servers here we have 8xDLT8000 drives, we can backup and restore a couple of hundred GB in around 2 hours!

[James R. Ferguson]

Chen:

I may be reading your objective differently, but I'm wondering if the following might make backup time more bearable:

If you define "cold" backup as a period in which only the ORACLE export is run, then if you split your export into multiple streams fed to multiple filesystems, then you could return ORACLE to your users; do your backups to tape; and "gain" a reduction in overall downtime.

There is a formum post which discusses the use of exporting through pipes over multiple filesystems and references Oracle Note 30528.1.

This link is:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xcc4668c57f64d4118fee0090279cd0f9,00.html

Perhaps all this helps.

...JRF...

[Dieter Degrendele]

We have also the same problem. We use 10 DLT tape drives, but it is very slowly. We worked out the following situation. Make mirror(s) of your disk to backup. Take one mirror offline and do the backup. Like this we can assure 99.99999% uptime. Of course this is only advised when you work with clusters.

With regards,
Dieter Degrendele

[Chris Garman]

If downtime to take the backup is an issue, have you looked into performing a hot backup?

To reduce recovery time without additional drives, you could backup to another disk, or get a faster tape drive. The option of backing to another disk is different to mirroring cos only the backup operation updates it. If the users corrupt the data in a mirrored environment both copies are damaged.

[CHRIS ANORUO]

I will go with Chris for a 100% system uptime. In my environment, we backup to another disk and tak the backup to tape from that disk while users are working without interruptions. You can create directories with date timestamps and backup into it

[CHRIS ANORUO]

I will go with Chris for a 100% system uptime. In my environment, we backup to another disk and tak the backup to tape from that disk while users are working without interruptions. You can create directories with date timestamps and backup into it

[Tom Danzig]

There's even an Oracle specific hot backup routine built into Omniback specificly for this purpose. While I haven't used it yet (were still doing hot backups manually though scripts) I would definitly give it a try. No downtime with this option.

[GE CompuNet (Einfeldt)]

Hi,

if you have Mirror-UX you can make an mirror and for backup use lvsplit.

Another idea is an snapshot- filesystem, but i have no experience with snapshots on tablespaces.....

regards

[Sandro Schaer]

hi there
there are different ways to reduce backup time. on possible way is to online backup your database. refer to the according oracle manuals.
i decided to "business copy" all database files :
1. shutdown the database
2. copy all files to another filesystem
3. startup the database
4. now you have lot's of time to backup the copy.

Depending on your disk subsystem you can minimize the downtime of your database. we currently backup a 500gb database this way. the downtime is 25 minutes.... all you need is lots of fast disks....


have fun