Re: Backup Tool Alternative to RMAN and BMC's SQL Backtrack

If you were afraid by the "backed up are not consistent, and in one sense of the word, are corrupted." part, you need to read some more on recovery before you can sleep again at night.

Don't think RMAN backups are any less inconsistent. But RMAN knows how to make your datafiles consistent again after a restore. And you should know, too:
Just apply the required archived redo logs.

It's true that Oracle RMAN is not a complete solution to backups, if you want to backup to tape.
You need to buy something (Tivoli or else) in between the tape and Oracle to make the link (unless you accept to do a disk backup first then move it to tape later). And depending on your infrastructure that may be (very) expensive.

RMAN is a good tool and should be used whenever possible.

-- 
Syltrem

http://pages.infinit.net/syltrem (OpenVMS related web site, en français)
"Mahesh Rajendran" <Magvivek_at_gmail.com> a écrit dans le message de
news:1109625617.695846.238140_at_f14g2000cwb.googlegroups.com...


> >>RMAN demands WAY TOO MUCH infrastructure to be in place to get a

> >>successful recovery.

>

> Nothing is more important to me, other than a successful recovery.

>

> >>O7-style backups are necessary in many areas - adding a datafile to

> the

> >>standby, for instance. I would be suspicious of any DBA that relied

> on

> >>RMAN too much and was uncomfortable with ALTER TABLESPACE BEGIN

> >>BACKUP.

> ALTER TABLESPACE xxx  BEGIN BACKUP.

> is truly not a great option.

> DOes that

>    handle block level corruptions?

>    look into incremental backups/restores?

>    backup the control file, spfile,archived logs ?

> NO.

> RMAN does!.

>

> Above all , here is the most scaring information , which gave us

> nightmares before. I stole the wordings of a wise man ( Tim Gorman).

> ----------- from an article by Tim Gorman -------

> When the ALTER TABLESPACE ... BEGIN BACKUP command is issued, a global

> database checkpoint

> occurs. This means that the current system change number (SCN) is

> logged to the redo log

> stream in a checkpoint record, and all buffers in the Buffer Cache

> modified prior to that

> SCN must be flushed down to the datafiles. Once the checkpoint

> completes, then the header

> block of each datafile in the tablespace is frozen, meaning that the

> header will not be

> updated to record the SCN of future checkpoints.

> However, the writing of database blocks to the body of the datafiles is

> not changed in

> any way. During future checkpoints, while the tablespace remains in

> backup mode,

> blocks continue to be written to the datafiles, just like normal. When

> the DBWR process

> flushes blocks to the datafiles outside of checkpoint processing, this

> continues in the

> datafiles belonging to the tablespace being backed up, just like

> normal.

> Meanwhile, while this normal I/O occurs to and from the tablespace in

> backup mode,

> some type of operating-system utility is copying the datafiles, backing

> them up.

> This utility, which on UNIX might be the dd, cp, tar, cpio, or dump

> commands, is actually

> backing up datafiles that are in flux. The files are being changed, as

> they are being saved

> to backup media. To put it another way, the datafiles that are being

> backed up are not consistent, and in one sense of the word, are

> corrupted.

>