Re: what to do with redo logs before backup

On Mon, 10 Mar 2003 12:06:39 +0000, Chuck Lucas wrote:

> Hey,
>
> I've been reading on this for some time, but the more I read, the more
> confused I become. So I thought I'd run my problem by some of the experts
> here, to see if I'm understanding things, even remotely.
>
> I'm running Oracle 8i on Solaris 8, and have archivelogs enabled. I am
> trying to set up my RMAN scripts to backup my database and
> archivelogs--which is going along swimmingly--that's no problem. In fact,
> I'm doing nightly cold backups as my application isn't required 24x7.
>
> Here's where I'm becoming confused:
> Should I issue an ALTER SYSTEM ARCHIVE LOG CURRENT before I take the
> database down to begin the backups? I'm worried that if I don't, then after
> I backup the archive logs, the current redo log may still have information
> needed to restore the database to the point-in-time that I performed the
> shutdown normal. But backing up the archivelogs doesn't catch this info,
> nor does backing up the datafiles/controlfile (database).
>
> Any light that could be shed my way would be greatly appreciated.
>
> Chuck
>
> P.S. Please also CC my e-mail address when replying to this post.

You're using RMAN. Yet you are doing cold backups. Fair enough, though the real point of RMAN is to make hot backups doable.

I've answered this one several times in the past, though the message never seems to get through.

If you view a backup as a standalone, single event, then yes, the archive log current (or a switch logfile, which does much the same thing) is useful. Because it is true that to make use of a hot backup, and to recover it completely, there would be redo in the current log which would have to be applied.

With a cold backup (and being in MOUNT state to run RMAN counts as a cold backup) then it is NOT necessary at all, because the shutdown normal command you issued to get there causes a complete system checkpoint to take place. Meaning that all dirty buffers are flushed to disk, and hence there is no need for redo to reconstruct them ab initio. And by definition, since the database is not open, there can be no further dirtying of buffers for the duration of the backup.

My long-held view has further been that the log switch is even unnecessary in a hot backup scenario, however. That's because backups are not standalone, single events, but are repeated nightly (or whenever). That therefore, what was sitting in the current redo log last night will be sitting in an archive log file tonight, and will thus be included in the next backup. That, if you like, what you don't backup today you will backup tomorrow.

Always assuming that you verify your backups complete successfully, and that you look after them so that one doesn't 'go missing', a complete recovery of a hot backup is perfectly possible with or without the 'archive log current' or extra log switch. This approach also requires that you never lose your current redo log in its entirety, but that's what multiplexing is for.

Regards
HJR Received on Mon Mar 10 2003 - 12:17:35 CST