Note:This topic was updated for 9.3.1.
Oracle manages changes to its contents and structure in such a manner as to guarantee recovery of the database to the last committed transaction after any single point of failure. To the last committed transaction means that once control is returned to the user after executing a COMMIT statement, Oracle guarantees the committed data has been written to disk in some form and is recoverable. Single point of failure means that any single file or process can fail without losing the contents of any committed transaction. If a data file is lost or corrupted, the contents of the redo logs guarantee that the data is recoverable. If a control file breaks, the other control files ensure that the information remains safe. A process may be killed, but committed data is never lost.
To recover a database after any failure, Oracle takes these steps:
Reads the init.ora file to determine the names and locations of the control files
Reads the control files to verify their consistency with each other and to determine the physical file structure of the database
Opens each data file mentioned in the control file to determine whether that data file is current and reflects the latest committed change or is in need of recovery
Opens each redo log file in sequence and applies the information found there to each data file, as necessary, to bring each data file to the state where it contains all its committed transactions
If the database has lost a control file, the database is recovered by replacing the lost control file with a copy of a current control file.
If the database has lost one or more data files, the database is recovered by first replacing the lost data file or data files with backup copies, then using the redo logs (online or archived) to make the restored copies current. If the backup copies are restored to different locations from the original files they are intended to replace, you must use the ALTER DATABASE > RENAME FILE command to tell the Oracle instance where the restored files are to be found.
If the database has lost the current online redo log, the database instance halts when it attempts to commit more transactions. No data will have been lost, but the latest transaction will not be committed and may need to be reentered when the database comes back up. However, the current online redo log must be replaced, and a backup of the database should immediately be performed.
If the database has lost any archived redo logs, the database instance continues to function, because it has no knowledge of the loss. However, the ability to recover the database in the event of a second media failure or file loss may be compromised. A fresh backup should be taken if the archived redo logs are lost.
