Re: Hot backups vs RMAN, the rebuttal

Hi Jared,

        Responses in line.

Jared Still wrote:
>
> I think your list of reasons for using RMAN is incomplete.
>
> The database backup window may need to be shrunk not
> because the database is so big, but because there are a lot
> of systems to backup, and they use a lot of time and tape.
>
> RMAN backs up blocks, hot backup backs up files.

Agreed

Yet many sites do not have this pressure on their backup window. These sites often panic when one of the incrementals is corrupt/not found. Mind you the same thing happens with hot backups, "What do you mean we can recover from 2 different backups?" It's just easier to do and explain at the file level.

And I admit I have a prejudice against block level backups as I was trained by an old-timer from the mainframe days in the 60's who swore the best thing that ever happened in his career was when filesystem backups became possible.

This is probably a myth now that should die, but old prejudices die hard.

>
> Also, finding and retrieving the correct files for restoration is
> rather tricky when using a tape library. It can be somewhat
> error prone. A recovery at odd hours doesn't help much.
>
> When you have an automated repository that can be told
> 'restore database', and it knows the file names to request
> and makes that request to the tape management system,
> restores are simplified.

This is the problem for the tape management system, I can tell netbackup (Veritas) "Give me the backups from this filesystem on this machine at this time" or "Give me the files from this backup job run on this date" I can restore to any machine and/or any SID very easily.

Once you are past as simple recovery in RMAN, (ie a file is corrupt, you have to change the SID, naming conventions on your redo logs are messed up because filesystems are full) it becomes much harder. Not impossible, but much harder.

The management of backups once they are on tape is a sysadmin task, the DBA tells the sysadmin the date and the job he wants restored.

>
> SQL Backtrack was good for that, and now RMAN.
>
> Our tape library is rather small, and I'm still thankful that
> I don't have to browse it for database files to do a restore.
>
> At a previous employer, we used a couple of StorageTek silos:
> you don't really want to browse that to get all the correct files
> for a database. Try it when you have several hundred files.
>

But tape libraries are just about always managed by a backup manager whether it is Veritas, Legato, Omniback .... I don't browse, I request date and job/filesystems, restore all the files.

StorageTek, you lucky guy, I probably wouldn't mind browsing just for the pleasure of playing with the new toy :-)

> Dave, it seems that you do work for clients scattered all around,
> hot backups probably works best for you.
>
> Yes, RMAN adds some complexity. It also adds some power
> and efficiency.
>

I agree, big complex sites have to use RMAN, maybe. If you have various versions of Oracle how many versions of RMAN do you need? Makes the site even bigger and more complex. And yet at alot of the places I work where they have ample disk and space I leave RMAN running because it is quicker to restore simple failures and it is a useful traing exercise on what dependencies can do to your availability. RMAN is administratively expensive.

The hot backups at these sites are solely used for cloning and complex recoveries.

> Just test those recoveries. :)

Amen, I can not emphasis this point enough, hots, colds, RMAN or hardware array splits, test your recoveries. If you have done it before you will be able to handle the crisis when it occurs.

>
> Jared
>

Dave

Off to interview for a contract where they do nightly colds and yet when I ask if they can afford a day's loss of data/work answer "Of course not"

-- 
Dave Morgan
Operations Manager, Rigskills Canada
Canada's Geographical Oilfield Services Locator
http://www.rigskills.ca
dvmrgn_at_rigskills.ca
403 399 2442
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Dave Morgan
  INET: dvmrgn_at_1001111.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).