Lesson 1

Let us assume there is a media failure. You perform an ARCHIVELOG database recovery and get a message saying Oracle cannot find the archived log ARC_480.ora. In this case you cannot apply all of the redo information generated since your last backup to the restored datafiles. As a result, you have to terminate your recovery before the archived log ARC 480.ora is applied. The process you are performing is called incomplete recovery. This module covers the basic concepts of incomplete recovery when archiving. It investigates the different situations in which incomplete recovery must be applied, the different types of incomplete recovery, and how to handle recovery in different situations.
After completing this module, you will be able to:

1. Identify an incomplete recovery situation
2. List incomplete database recovery steps
3. Monitor recovery progress information using the alert log
4. Perform a time-based recovery
5. Perform a cancel-based recovery
6. Use a backup control file for recovery
7. Recover a database without the current redo log
8. Handle recovery through RESETLOGS
9. Perform tablespace point-in-time recovery
   The next lesson describes the situations in which an incomplete recovery is required.

Incomplete recovery, or point-in-time recovery, uses a backup to produce a noncurrent version of the database. In other words, you do not apply all of the redo records generated after the most recent backup. You usually perform incomplete recovery of the whole database in the following situations:

1. Media failure destroys some or all of the online redo logs.
2. A user error causes data loss, for example, a user inadvertently drops a table.
3. You cannot perform complete recovery because an archived redo log is missing.
4. You lose your current control file and must use a backup control file to open the database.

To perform incomplete media recovery, you must restore all datafiles from backups created prior to the time to which you want to recover and then open the database with the RESETLOGS option when recovery completes. The RESETLOGS operation creates a new incarnation of the database, in other words, a database with a new stream of log sequence numbers starting with log sequence 1. Before using the OPEN RESETLOGS command to open the database in read/write mode after an incomplete recovery, it is a good idea to first open the database in read-only mode, and inspect the data to make sure that the database was recovered to the correct point. If the recovery was done to the wrong point, then it is easier to re-run the recovery if no OPEN RESETLOGS has been done. If you open the database read-only and discover that not enough recovery was done, then just run the recovery again to the desired time. If you discover that too much recovery was done, then you must restore the database again and re-run the recovery.