On Thu, 30 Nov 2000, John R. Jackson wrote:
> >Just make sure you have plenty of archivelog space for transactions which
> >hit the database during the backup.
>
> As I understand it, this was a major reason we don't do this but use the
> "big backup area" approach (which I proposed in "part I").
?
The space required for archivelogging during a hot backup shouldn't
be anywhere near the size required to take a second copy of the database.
> I'm not an Oracle type, but the guy who put this together here is
> very good. And we've "tested" (well, OK, the thing crashed and we had
> to recover :-) the result -- several times.
>
> >Now, if you want some redundancy *and* faster backups then you could put
> >the database on a raid 1 mirror. When it comes to do the backup, break the
> >mirror and mount the broken mirror somewhere. ...
>
> How does the guarantee the disks in the mirror are up to date, i.e.
> logically consistent from Oracle's point of view?
It doesn't. The broken mirror is the equivalent of a crashed system.
Oracle will have to go through the normal roll forward through the
archivelogs to bring the data files to a consistent state.
> This technique comes up once in a while for normal backups, too, and
> it's never made any sense to me. It won't work any better than what dump
> (or tar, in some cases) does now.
Except that your mirror will be on a second set of disks and SCSI channels
so the disk I/O generated by the backup won't effect the live database.
And since you also have a dedicated backup LAN, users won't be affected
by the network I/O either. It's most useful in 24x7 environments where
you can't have downtime for backups or even degradation in performance
while the backup is running.
You also have plenty of time to do the backup though you do have to
remember that you're exposed while the backup's running. I know of one
site who have two mirrors (They really just need a faster backup
system).
regards,
Colin.
