An inconsistent backup is a backup of one or more database files that you make while the database is open or after the database has been shut down abnormally. A consistent backup is a backup of one or more database files that you make after the database has been closed cleanly. Unlike an inconsistent backup, a consistent backup does not require instance recovery after it is restored

Whether you make consistent or inconsistent backups depends on a number of factors. If your database must be open and available all the time, then inconsistent backups are your only option. If there are recurring periods of minimal use, then you may decide to take regular consistent backups of the whole database and supplement them with online backups of often-used tablespaces.

Oracle determines whether a restore backup is consistent by checking all the datafile headers against the datafile header information contained in the control file.

Oracle makes the control files and datafiles consistent during a database checkpoint. The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to these tablespaces and so no recovery is required. If the offline datafile's checkpoint SCN matches the offline-SCN in the control file, then Oracle know the datafile needs no redo.

The only way to make a consistent whole database backup is to shut down the database using the NORMAL or IMMEDIATE options and make the backup while the database is closed. If a database is not shut down cleanly, for example, an instance fails or you issue a SHUTDOWN ABORT statement, the database's datafiles are always inconsistent--unless you opened the database in read-only mode. Instance recovery will be required at open time.

To make a consistent database backup current or to take it to a non-current point in time, perform media recovery. If you use a current control file for recovery, Oracle starts media recovery beginning at the lowest checkpoint SCN in the datafile headers. If you use a backup control file, then Oracle starts media recovery using the lowest of the following: the control file SCN and the lowest SCN in the datafile headers.

An inconsistent backup s a backup in which all read-write datafiles and control files have not been checkpointed with respect to the same SCN. For example, one read-write datafile header may contain an SCN of 100 while others contain an SCN of 95. Oracle cannot open the database until these SCNs are consistent, that is, until all changes recorded in the online redo logs have been made to the datafiles.

If your database must be up and running 24 hours a day, 7 days a week, then you have no choice but to perform inconsistent backups of a whole database.

If you run the database in ARCHIVELOG mode, then you can construct a whole database backup using backups of datafiles taken at different times. For example, if your database contains seven tablespaces, and you back up the control file as well as a different tablespace each night, in a week you will back up all tablespaces in the database as well as the control file. You can consider this backup as a whole database backup.

You have the option of making inconsistent closed backups if a database is backed up after a system crash or SHUTDOWN ABORT. This type of backup is valid if the database is running in ARCHIVELOG mode, because both online and archived redo logs are available to make the backup consistent.

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