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

> 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?
>

The file(s) that are backed up are not consistent and by themselves are useless. If you restore a file that was backed up during the hot backup, you must apply all the logs generated from the beginning of the hot backup.

> >-- 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

The DBWR process is not suspended for during the backup. Everything continues as normal except the change numbers on the blocks in the datafiles are not updated. By putting a tablespace in hot backup mode, all the datafiles associated with that tablespace are put in backup mode. Changes are still written to disk by the DBWR. One of the biggest problems of leaving a tablespace in hot backup mode is that more redo is actually written (because full blocks are written). So if you only have a small archive destination it could fill up a lot faster than if the tablespace wasn't in hot backup mode. Received on Wed Aug 08 2001 - 13:03:45 CDT