Re: Hot backups on Digital Alpha

Eddy Lootens <lootens_at_luc.ac.be> wrote:

>In article <4qu995$8c0$1_at_mhafn.production.compuserve.com> Dennis
>Williams, 104052.3374_at_CompuServe.COM writes:
>>We are a Digital Alpha ( Digital Unix 3.2C) shop running a
> Hello,
 

> Your problem could be solved using AdvFS.

Maybe but I wouldn't recommended it, see later.

> I think you will also need the AdvFS tools.

Yes, cloning is part of the ADVfs utilities, which should be bundled with the O/S on the AlphaServer 2000 and larger.

> If you use AdvFS on the disk(s) your database is running
>on, you can make a "snapshot" or clone of a filegroup (more or less the
>equivalent of a UFS file system). Then you backup the cloned filegroup
>and remove it.

Make sure your database is shutdown cleanly when you create the cloned filesets.

> Making this clone goes very fast and does not take a lot of space, roughly only
> the difference between the clone and the original is needed as diskspace.

Which, depending on the amount of writing you do during the backup means the clone could grow to the same size as it's progenitor, unlikely but possible in the worst case.

> The main disadvantage of this solution is that the performance of
>your database may go down considerably when making the backup.

There are a few performance related disadvantages, mostly due to the need to shutdown and lose all the nice caches in the SGA.

There is another risk that is triggered by a subtle interaction between ADVfs and Oracle. Very few people are aware of this and I consider it serious enough that I would never use this technique.

When a clone runs out of free space in the domain (and the less free space you have the faster it will happen) the next write that Oracle does to a block that hasn't been cloned yet can't complete, ADVfs returns an ENOSPC error to the DBWR and it flips out, ENOSPC is an error that just doesn't make sense since it thinks (correctly) it was updating a block that already existed, it assumes the worst, issues an ORA-600 error, declares the file corrupt and does a shutdown abort.

Funny thing is that the backup is still good (provided you caught all the control files and the redo logs). Unfunny thing is that as soon as it's finished you have to use it to restore the database to the state at the start of the backup. There really no way of doing a media recovery right up to the point of failure so even if you do a manual database recovery after the restore you won't get all the work that was done while the backup was running back.

Norm Soley
Just a guy with a computer who knows a little about SAP R/3 and a little more about UNIX.

                                                     nsoley_at_ibm.net