You can start performing backups with RMAN executable from the $ORACLE_HOME/bin directory.
- The target database control file will always store the RMAN repository, which is the set of RMAN related backup and recovery information —> RMAN METADATA.
- It’s smarter to use a dedicated database to store the RAMN repository then create a special schema called the recovery catalog.
- Thus avoiding the risk of the critical metadata being overwritten when the control files runs out of space.
- Flash Recovery Area :
- This is a location on disk where the database will store the backup and recovery related files.
- MML -Media Management Layer
- RMAN can directly interact only with disk drives.
- if you want to use tape drives to store your backups, you’ll need a MML in addition to RMAN.
- RMAN can’t directly inteact with the tape drives.
- Oracle also provides Oracle Secure backup , most well integrated media management layer for RMAN backup.
Benefits of using RMAN
- The powerful Data Recovery Advisor Feature which enables you to easily diagonse and repair data failures and corruption.
- It automatically manages the backup files without DBA intervention.
- It automatically deletes unnecessary backup datafiles and archived redo log files both from disk and tape.
- Reporting of backup actions.
- Duplicating a database or creating a standby database.
- Verify available backups are useable for recovery
- Incremental backup
- I lets you perform database duplication without backups by using the network enabled database duplication feature also known as active duplication.
- It automatically detects corrupt data blocks during backups V$DATABASE_BLOCK_CORRUPTION view.
- when only a few data blocks are corrupted, you can recover at the data block level.
- Unused block complession feature, wherein RMAN skips unused data blocks during a backup.
- RMAN provides the ability to perform encrypted backups.
- You can use a powerful scrpting language which lets you write custom backup and recovery scripts quickly.
Database Recovery and Consistent VS 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 :
- The Oracle server will perform an automatic crash recovery when you restart the instance.
- Don’t need to restore or recovery tasks.
- The server will use the information in the undo tablespace to perform automatic instance recovery by rolling back uncommitted transactions in the database.
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.
- The database server must apply all transactions b/w the last checkpoint and end of the redo log to the data files.
- Number of seconds you want the crash recovery to take.
- Oracle will try to recover the instance as close as possible to the time that you specify for the FAST_START_MTTR_TARGET
- MAX value is 3,600 seconds (1 hour).
- The server won’t be able to automatically recover from such a catastrophe
- Must provide the lost datafiles from backup.
- If error occured, Find V$RECOVER_FILE view, which lists all files that need media recovery
- You use two basic commands RERTORE OR RECOVER
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 alternative 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
- 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
Deciding on the Appropriate Recovery Technique
- If you run into logical errors, perform a TSPITR or consider using an appropriate flashback technique to make a point in time recovery.
- If you have data corruption in a few blocks in a data files or a set of data files, use block media recovery.
- 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.