Rman backups

Database Recovery and Consistent VS Inconsistent Backups

Consistent Backups


Inconsistent Backups
If you shutdown your database using shutdown norml, shutdown immediate and shutdown transactional, you’ll have a consistent backup. Shutdown abort or shutdown force or if there is an instance failure , you’ll end up with an inconsistent database.
All uncommitted changes are rolled back Any committed changes are not rolled back automatticaly
The contents of the database buffer cache written to the datafiles on disk. Changes made to the database buffer cache aren’t written to the datafiles on disk.
All resources such as lock and latches are released. No need for instance recovery. All resources such as locks and latches are still held and aren’t released

Crash Recovery :

1. The Oracle server will perform an automatic crash recovery when you restart the instance.
2. Don’t need to restore or recovery tasks.
3. The server will use the information in the undo tablespace to perform automatic instance recovery by rolling back uncommitted transactions in the database.

Rolling Forward


Rolling Back


The Oracle server will update all data files with the information from the redo log file. The log files are always written to before the data is recorded in the data file. thus ,an instance recovery may usually leave the online log files “ahead” of the data files.


Uncommitted changes that were added to the data files during the roll forward operation are rolled back. Undo tablespace contents uncommitted changes to their Original states. At the end of rollback stage, only committed data at the time of the instance failure is retained in the data files.

FAST_START_MTTR_TARGET

1. The database server must apply all transactions b/w the last checkpoint and end of the redo log to the data files.
2. Number of seconds you want the crash recovery to take.
3. Oracle will try to recover the instance as close as possible to the time that you specify for the FAST_START_MTTR_TARGET
4. MAX value is 3,600 seconds (1 hour).

Media Recovery

1. The server won’t be able to automatically recover from such a catastrophe
2. Must provide the lost datafiles from backup.
3. If error occured, Find V$RECOVER_FILE view, which lists all files that need media recovery
4. You use two basic commands RERTORE OR RECOVER

You must do the following as part of a Media Recovery operation

1. Restore the necessary data files from backup ,either to the old or to an alternative location
2. Rename the data files , if necessary, so the database will know about their new location
3. 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

1. You must have synchronized copies of all the control files
2. you must have synchronized online data files.
3. you must have at least one member of each redo log group

Deciding on the Appropriate Recovery Technique

1. If you run into logical errors, perform a TSPITR or consider using an appropriate flashback technique to make a point in time recovery.
2. If you have data corruption in a few blocks in a data files or a set of data files, use block media recovery.
3. If a user error affects a large set of tables or the entire database ,use the flashback feature to revert the database to a previous “good” time by undoing all the changes since that point in time.