Re: Redo logs backup??

From: Philip Vassar <philv_at_atlas.com>
Date: 1996/06/14
Message-ID: <31C19D86.1E31_at_atlas.com>#1/1


Ed Kulis wrote:

> Sounds like a good reference, Thanks.
>
> I've further questions.
>
> How long should you save archive log files?

The archived redo logs are "good" for applying changes made to the database during and after the last succesful backup that the control file has registered (alter tablespace begin backup). The backup can be hot or cold. Most sites I have administered performed backups in a cycle so that there were three sets of backup tapes. This involved saving the redo logs in the follwing manner

     Today -2             Today -1                  Today
 Tape1    Tape2       Tape3    Tape4       Tape5            Disk/Tape6
Bckup1 - archlogs1 - Bckup2 - archlogs2 - Current_backup - archlogs3

The archived redolog set(s) needed to restore a database is determined by the point in time a failure occurs. Usually Tape3 and Tape 4 would be used to retore an instance that fails before the completion of the "current backup" along with the archlog3 set on the disk, Worst case would be that Tape3 was "bad" and you would have to use Tapes 1,2,and 4 to restore the instance. Tape 1 and 2 are used for tomorrow's backup in this schema. Once the archive logs are moved to tape they can deleted. This assumes that instance failures not related to media can be recovered from the online redo logs and rarely need archived redo logs applied. In a perfect world tapes 1 and 2 will never be needed, if you are ballsy you can substitute tapes 1 and 2 for tapes 5 and 6.

>
> Does an offline tablespace backup with the instance in multiuser mode
> count as "cold backup"?
>

I would not consider that a cold backup but others might. A cold backup <IMO> is an full export of the instance while mounted exclusive. Another definition would be a set of level zero dumps in single user mode of all database file systems along with a dd of any raw partitions used for table spaces. Whenever a cold backup is done the database needs to be "informed" of the fact by setting markers in the control file, this allows the user to discard "old" archived redo logs.

I'm not sure what kind of 7/24 application allows you to take a tablespace offline but if it is allowed then OK..... In this case you will be performing a tablespace recovery specifically. The control file will have recorded the last time the tablespace was backed up (alter tablespace begin backup/alter tablespace end backup) and ask for the archived redo logs created after that point. Please note that if you do NOT use the alter tablespace begin backup/end backup commands the database will require all redo logs archived from table creation.

> I'd rather not administrate a series of special archive tapes if I could
> just keep a manageable amount of archive logs on line and have them
> backed up as part of the normal Unix filesystem backups.
>

  I always keep my Oracle backups and file system dumps seperate, in a   7/24 implementation you should use the hot backup strategy described   in the Oracle documentation. Recovery requires that the set of archived redo logs be intact from the start of the backup until the   desired point of recovery.

  I hope this helps. My prayer for all DBA's is that a you will never experience a media failure that causes recovery to become necessary. I've had recovery sessions that were a matter of pointing the database at the archived redo logs and waiting and I've had recovery sessions that involved "magic cookies", sweat,blood and tears....hours on the phone with Oracle support and finally writing sql to generate lost data from other tables.... Once had 500 archived redo logs to apply and was missing ONE file at about the 386 point not a thing could be done.... didn't know it was missing until I got there, no one knew what happened to it either as it was in the middle of a sequence had the one before it and the one after it..... Enough war stories...

Good luck!

Philip Vassar
Systems Engineer
Atlas Telecom Received on Fri Jun 14 1996 - 00:00:00 CEST

Original text of this message