You perform a complete recovery when you bring 1) a database, 2) a tablespace, or 3) a data file up-to-date with the most current point in time possible. It is important to emphasize that complete recovery is not 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 are performing a complete backup. In other words, complete recovery will ensure that you have not 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?
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.
Oracle Flashback Technology
In all of these situations, you can use either 1) point-in-time recovery or 2) Oracle's flashback technology to get the database back to a previous point in time. Prior to the introduction of the flashback technology, a (DBPITR) database point-in-time recovery and a tablespace point-in-time recovery (TSPITR) were the automatic solutions when confronted by situations such as an erroneous data entry or wrong updates. Flashback technology offers you the capability to perform point-in-time recovery much quicker than the traditional point-in-time recovery techniques that rely on media recovery. The flashback database feature is the alternative to traditional database point-in-time recovery, while the flashback table feature lets you avoid having to perform a media recovery in most cases.
1) To begin a tablespace point-in-time recovery, perform a consistent backup of the primary database. Once this is done, you find any dependences and restrictions on the primary database. If any exist, try to resolve them.
2) Next, copy the backup of the current control file to a different location and edit the parameter file for the cloned database.
3) Create a copy of the primary database.
4) Restore all the datafiles to an alternate location for the cloned database. Then you, mount the database for recovery.
5) Perform the time-based incomplete recovery by applying the archived logs and open the database.
6) Export the recovered data files using the Oracle Export utility from the cloned database.
7) Import the data using the Oracle Export utility into the primary database. When finished, remember to make a backup of the primary database and delete the data files for the cloned database to conserve disk space.