Time-based restore and recovery is commonly used when you know approximately the date and time to which you want to recover your database. For example, you may know approximately the time you want to stop the recovery process but not a particular SCN.
- Log sequence–based and cancel-based recovery work well in situations where you have missing or damaged log
files. In such scenarios, you can recover only up to your last good archived redo log file.
- SCN-based recovery works well if you can pinpoint the SCN at which you want to stop the recovery process.
You can retrieve SCN information from views such as V$LOG and V$LOG_HISTORY.
- You can also use tools such as LogMiner to retrieve the SCN of a particular SQL statement.
- Restore point recoveries work only if you have established restore points. In these situations, you restore and
recover up to the SCN associated with the specified restore point.
- Tablespace point-in-time recovery is used in situations where you can restore and recover just a few tablespaces.
- You can use RMAN to automate many of the tasks associated with this type of incomplete recovery.
- Table point-in-time recovery may be appropriate if you accidentally dropped a table or erroneously deleted data.
- Flashing back your database works only if you have enabled the flashback database feature. DBAs often use this
feature in environments where the database needs to be rolled back to a baseline (like a test environment), or also in
production environments to capture the state of the database right before an application upgrade takes place.
This allows you to restore the database back to a point in time in the event the upgrade doesn’t go as planned.