Re: Archiving Redo logs while tablespace is in backup mode.

On Tue, 7 Aug 2001 23:38:37 -0700, "Sean Fitzgerald" <sfitzgerald_at_centurytel.net> wrote:

>You are not quite correct. While the tablespace is in hot backup mode, the
>change number of the blocks are frozen. Changes are still applied to the
>blocks and redo is still generated (Oracle does not "save up" all the
>changes during the backup and then replay them at the end -- otherwise your
>database query results would be quite stale). At the end of the backup, the
>change numbers are updated, but the actual row changes have already taken
>place as they would any other time. The reason the hot backup works is
>because if you restored the files backed up during the hot backup, the
>change number would be at the point of the beginning of the backup and then
>normal recovery with redo logs can take place.
>
>

I thought I read that somewhere, and that confused me. There is much here that I do not (yet) understand.

First, a basic question. If the blocks are being updated, how is the backup getting a consistent tablespace? Especially, if the tablespace has more than one file, whilst one is being copied to the archive (by the OS) another filke for that same tablespace may change. In the case of row chaining, wouldn't that make the chain itself inconsistent?

>Oracle does not "save up" all the changes during the backup and then replay
> them at the end

Thank you for addressing that straight on. I was obviously missing what happened.

>-- otherwise your database query results would be quite stale)

How would they be stale? I figured that all I/O is really done in memory anyway, and that the DBWn processes write to disk. When a tablespace is put in BACKUP mode, DBWn processes were just suspended until the backup was ended. The only problem being running out of memory. In that case, the REDO logs are used in case of a crash, in which the archive logs could be applied as well.

Brian Received on Wed Aug 08 2001 - 08:02:52 CDT