Re: archivelog v/s nonarchivelog

Throwing this reply into the thread at no particular point, I notice a lot of the replies talk about archivelog guaranteeing complete recovery, and noarchivelog meaning restore can only be accomplished to the time of the last backup.

Leaving aside the fact that the last part of that statement is not invariably true (it depends on the size of your online redo logs), I wanted to just mention another consequence of archivelog mode:

The unit of backup is the datafile in archivelog mode. But in noarchivelog mode, because you must shut down the database to perform the backup, and because you can't have different parts of the backup at different times (because you can't guarantee to supply the redo needed to re-synchronise the different parts) the unit of backup is inevitably the dataBASE. You have to back the whole lot up in one go, the database remaining unavailable for the duration.

So one of the factors determining archivelog/noarchivelog is: how big is my database. If it is mammoth, a complete backup of it at one sitting might not fit into your available downtime window. If so, archivelog would allow you to backup up some of the database on one night, and some on another. Together, the two backups constitute a complete backup set... but each backup session fits comfortably into the maintenance window.

Likewise restores: ignoring the issue of perhaps being able to find the required redo in your online logs, the unit of recovery in noarchivelog is usually the database. Restore the lot and roll it all forward. In noarchivelog mode, the unit of recovery is the datafile (actually, in 9i, using RMAN, it becomes the data BLOCK). That could mean the difference between an hours-long recovery and mere minutes.

In short, in archivelog mode you can think 'pieces'. In noarchivelog mode, you have to think 'whole'.

~QM Received on Thu Aug 07 2003 - 04:44:15 CDT