Re: Backing up Oracle using Vertas Backup Exec

Howard J. Rogers wrote:

> Backup Exec has long had the ability to backup all sorts of open files. I
> use it on a W2K server at home... it backs up plenty of files which W2K's
> in-built backup utility skips because it doesn't like them being open.
>
> So far, so good. But we return to the usual subject of the last few days
> here: hot copies of database files are useless, unless you've a mechanism
> for resolving their internal inconsistency. The mechanism we use for
> datafiles is to apply redo from the earliest moment they started being
> copied. How do we know what that 'earliest time' is? Because the headers
> of the data files tell us... or, rather, they *would* tell us reliably so
> long as it was the datafile header block that was always, guaranteed, copied
> *first*.
>
> But O/S copies and agentless Backup Exec don't know anything about the
> internal structure of datafiles, so which bit they happen to grab first is
> in the lap of the gods -which is why we have the 'alter tablespace X begin
> backup' command, which freezes the datafile header, so that whenever the
> utility finally gets around to copying it, it still tells us the time the
> datafile started to be copied.
>
> Unless your systems department is issuing that command left right and
> centre, a Backup Exec backup is going to be of zero use in recovery
> situations.
>
> With the agent, however, it's all rather different... suddenly Backup Exec
> understands the internal structure of data files, and can make an
> intelligent grab for the datafile header as the first thing to copy as it
> arrives at each file. Works a treat. And rather like RMAN in that respect
> (which also doesn't need the 'begin backup' technique for the same reasons).
>
> From memory, the Oracle agent is horrendously expensive... but not as
> expensive as a pile of useless datafiles are going to be one day.
>
> Regards
> HJR
> --
> ----------------------------------------------
> Resources for Oracle: http://www.hjrdba.com
> ===============================
>
>
> "Robert Bollinger" <robert_bollinger_at_hotmail.com> wrote in message
> news:a966437c.0201091056.4656d418_at_posting.google.com...
>

>>Hello -- I am not familiar with Veritas BU Exec, but it seems that our
>>Systems department is using it to back up our Oracle databases.  We've
>>never done a recovery so the assumption is that everything will be
>>okay at recovery time.  That is NOT what I assume, which is why I am
>>exploring this issue.
>>
>>I noticed a number of references to the "Oracle Agent" for BE and
>>found that we are NOT using it.  Is the Oracle agent necessary?
>>
>>Can anyone point me to a good reference for using Backup Exec as the
>>primary BU strategy?  Does BE Exec compare to Norton Ghost, or is that
>>a different animal altogether?  Is there a dramatic change of
>>procedure when using Backup Exec as opposed to doing the usual cold or
>>hot backups with Oracle.
>>
>>Many thanks for your help!  We're getting down to the wire with this
>>thing.
>>
>>Bob Bollinger
>>

I would like to clearify a few things here. Seems some confusion on how hot BU are made and work.
Old fassion alter tblsp X begin backup, freeses the SCN number in all datafiles belonging to tblsp X. When U then copy the datafiles, the copy util might make 'fuzzy' copies of datablocks, ie. the util takes a chunk of data and copies it, this chunk can end in the middle of a datablock, and while the copy process is busy, the database writer updates the very same 'divided' block, thus the util will make a copy of a datablock where the two halves are from different 'timezones' ie. internaly inconsistent. Thats why the hole datablock is copied to redolog the first time it is changed, if the tablespace is in begin backup mode, and thus generating a lot more redo while in backup mode. Having a sound consistent copy of the block in the redolog, makes it possible to recover from fuzzy copies. When the tblsp is set back in normal mode, the SCN in datafile headers are updated to 'current' SCN. The 'frozen' SCN in the datafile headers tell the recovery process when to start to apply redo's - ending up with a (hopefuly) consistent file.

RMAN uses the same mechanism as a users shadow processes, it makes consistent reads of (hole) datablocks, with latching, locking and all the stuff and then there is no need to make extra block copies to redolog.

I dont know what mechanism Veritas BU exec uses.

/svend jensen Received on Fri Jan 11 2002 - 14:10:03 CST