Re: Online backups

In article <1995Mar14.005335.2421_at_rossinc.com>

           joelga_at_rossinc.com "Joel Garry" writes:

> In article <3j2q4s$1pnc_at_news-s01.ny.us.ibm.net> colipha_at_ibm.net writes:
> >We are getting conflicting advice on whether or not to use online backups.
> >What is the feelings of this group?
> >
>
> A lot depends on your configuration. Do you have a huge budget to spend
> on failsafe hardware? Use noarchivelog mode and ordinary backups. Do
> you have a high volume of non-critical data and a large budget that
> will always be there for lots of well-trained people? Then you might
> consider online backups. Do you have a 7/24 requirement? Do you have
> full-time operators? Full-time DBA's? A graveyard shift? Which
> environment are you on? Mixed? How much will an ARCH bug hurt you?
>

There are as many pros and cons to warm backups as there are things that can go wrong... Warm backups are primarily intended IMHO as protection from fairly simple hardware type things, i.e. a data file gets trashed or scribbled (don't you just love technical terminology?), and you can restore a *warm* datafile backup (don't try this with cold) and roll forward archive logs assuming you were in that mode. The files you need to protect more than any are your archived logs (we mirror ours, and write them to parity tape on a rolling basis, only deleting them when they are the oldest ones in a dedicated filesystem, and we back them up with other backups redundantly too) and your online redo logs (Oracle7 allows duplicate log groups, and we mirror them as well). Control files you can have multiple in O6 and O7, and we mirror them, and you can reconstruct them in certain circumstances from backups taken with BACKUP CONTROL FILE. We also do full database exports as often as possible, because warm backups often don't help if what you have done is screwed up a logical change, i.e. mistakenly updated all rows in a table or dropped it. What I'm really trying to say is, if you have the disk space and overall capacity to handle the overhead for log archiving, and operators or software that can watch to see that archived logs haven't filled their filesystem up (the database will stop dead till space is available), and you can put up with having to plan large updates much more carefully, then you need the protection that log archiving and warm backups give you (do exports too if you can!).

-- 
Tom Cooke               tom_at_tomcooke.demon.co.uk             +44 (0)1782 748027
North Staffordshire Hospital Computer Centre, Stoke-on-Trent, Staffordshire, UK