Backup and Recovery Basis
The crash recovery process is a special form of recovery, which happens the first time an Oracle database instance is started after a crash (or SHUTDOWN ABORT). In crash recovery, the goal is to bring the datafiles to a transaction-consistent state, preserving all committed changes up to the point when the instance failed.
Like crash recovery, datafile media recovery is intended to restore database integrity. However, there are a number of important differences between the two:
Media recovery must be explicitly invoked by a user. The database will not run media recovery on its own.
Media recovery applies needed changes to datafiles that have been restored from backup, not to online datafiles left over after a crash.
Media recovery must use archived logs as well as the online logs, to find changes reaching back to the time of the datafile backup.
Unlike the forms of recovery performed manually after a data loss, crash recovery uses only the online redo log files and current online datafiles, as left on disk after the instance failure. Archived logs are never used during crash recovery, and datafiles are never restored from backup.
The database applies any pending updates in the online redo logs to the online datafiles of your database. The result is that, whenever the database is restarted after a crash, the datafiles reflect all committed changes up to the moment when the haven't said failure occurred. (After the database opens, any changes that were part of uncommitted transactions at the time of the crash are rolled back.)
The duration of crash recovery is a function of the number of instances needing recovery, amount of redo generated in the redo threads of crashed instances since the last checkpoint, and user-configurable factors such as the number and size of redo log files, checkpoint frequency, and the parallel recovery setting.
You can set parameters in the database server that can tune the duration of crash recovery. You can also tune checkpointing to optimize recovery time.