Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Two questions

Two questions

From: Keith Boulton <kboulton_at_ntlunspam-world.com>
Date: Sat, 18 Aug 2001 15:27:24 +0100
Message-ID: <aRuf7.1856$Qh2.29091@news11-gui.server.ntli.net>


I started this as a new thread to avoid giving the impression that I was just continuing that argument.

Tom Kyte very kindly put a reference to the Oracle Docs re inconsistent backups which I've just read, but they don't seem to make sense to me:

"If you run your database in NOARCHIVELOG mode, only back it up when you
have closed it cleanly using the IMMEDIATE or NORMAL options. Inconsistent whole database backups of databases running in NOARCHIVELOG mode are usable only if the redo logs containing the changes made prior to the backup are available when you
restore it--an unlikely occurrence. "

Why is this unlikely? The set of non-archived redo logs and the database data files are sufficient to redo any outstanding changes - that's why we can't reuse a redo log until the database checkpoint is complete. There is no need to use archived redo logs. Surely, if you were doing a cold backup, you would be backing up both the database data files and the redo logs?

"The reason that NOARCHIVELOG inconsistent backups are not recommended is
that the datafile headers of the backed up files contain different SCNs (a normal shutdown guarantees the consistency of these SCNs), and because the database is in NOARCHIVELOG mode, no archived redo logs are available to apply the lost changes. For this reason, RMAN does not allow you to back up a database that has been running in NOARCHIVELOG mode and shut down abnormally because the backup is not usable for recovery. "

There is *never* a need to use archived redo logs to perform instance recovery after a shutdown abort, so why this statement? Received on Sat Aug 18 2001 - 09:27:24 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US