Databases Reference
In-Depth Information
Media Recovery
When a disk drive fails and you can't access the contents of an Oracle data file, you're looking at a potentially much
more serious situation than a crash recovery, since the server won't be able to automatically recover from such a
catastrophe. You must provide the lost data files from backup. Since it's likely that data has changed in the meantime,
you must provide the changes stored both in the archived redo log files and in the online redo log files. When the
Oracle database issues an error indicating media problems, you must first find which files to recover by querying the
V$RECOVER_FILE view, which lists all files that need media recovery.
RMAN completely automates the process of media recovery. You use two basic commands—
restore
and
recover
—to perform media recovery. The
restore
command restores the necessary data files from RMAN's backup
sets or image copies to the same or an alternate location on disk. The
recover
command performs the recovery
process by applying necessary archived redo logs or incremental backups to the restored data files. You must do the
following as part of a media recovery operation:
•
Restore the necessary data files from backup, either to the old or to an alternate location.
•
Rename the data files, if necessary, so the database will know about their new location.
•
Recover the data files (bring them up-to-date), if necessary, by applying redo information
to them.
To open the database after a successful restore and recovery, the following must be true:
•
You must have synchronized copies of all the control files.
•
You must have synchronized online data files.
•
You must have at least one member of each redo log group.
If all these are true, you can open the recovered database.
Complete and Point-in-Time Recovery
You perform a complete recovery when you bring a database, a tablespace, or a data file up-to-date with the most
current point in time possible. It's important to emphasize that complete recovery isn't synonymous with recovering
the complete database. Rather, completeness here alludes to the completeness of the entire database or part of
it (tablespace or data file) with reference to the time element. If you update the database tablespace or data file
completely by applying all changes from the archived redo logs to the backup files, you're performing a complete
backup. In other words, complete recovery will ensure that you haven't lost any transactions. Note that when using
RMAN, you may also use incremental backups as well, in addition to archived redo logs, during the recovery process.
When you perform media recovery, it isn't always the case that you can or should bring the database up-to-date
to the latest possible point in time. Sometimes you may not want to recover the database to the current point in time.
Following a loss of a disk or some other problem, the complete recovery of a database will make the database current
by bringing all of its contents up to the present. A
point-in-time recovery
, also known as
incomplete recovery
, brings the
database to a specified time in the past. A point-in-time recovery implies that changes made to the database after the
specified point may be missing. On the face of it, a point-in-time recovery may seem strange. After all, why would you
recover your database only to a past period in time and not bring it up-to-date? Well, there may be situations where a
point-in-time recovery is your best bet, as in the following examples:
•
You lose some of the archived redo logs or incremental backups necessary for a complete
recovery following a media failure.
•
The DBA or the users delete data by mistake or make wrong updates to a table.
•
A batch job that's making updates fails to complete.
