RelationalDBDesign RelationalDBDesign

Backup Options   «Prev  Next»
Lesson 4 Implications of NOARCHIVELOG database recovery
Objective Explain the recovery implications for a NOARCHIVELOG database.

Database Recovery Implications of NOARCHIVELOG

To recover a NOARCHIVELOG database, the only available option is to restore the database from a consistent closed database backup. Since no redo logs after the last backup can be applied, the database can only be recovered to the point in time when the last backup was made. All changes made after the closed database backup will be lost and must be reentered manually by users. Thus, it becomes the DBA's responsibility to inform users and management about the risk of operating a database in NOARCHIVELOG mode.


Recovering a database in NOARCHIVELOG mode is easy. Since you only have to restore all the files from a consistent whole database backup, the risks of recovery are minimal. At the same time, to ensure a valid backup, be careful that you don't restore the wrong backup copy, overwrite the backup, or shut down the database before restore. These risks can be greatly reduced by training the DBA properly or by setting up some automated procedures using batch files.
Recovering the database can be a quick procedure. The time required for recovery is determined by how fast your hardware can copy all the essential files.


There are two main disadvantages to recovering a database in NOARCHIVELOG mode. First, because all data entered by the user since the last backup will be lost, the data must be reapplied manually. Second, all the datafiles have to be restored from the last whole closed database backup, even if only one of them is damaged.
The next lesson describes the steps to recover a NOARCHIVELOG database.