1. Understanding basic recovery strategy

Basic recovery involves two parts: restoring a physical backup and then updating it with the changes made to the database since the last backup. The most important aspect of recovery is making sure all data files are consistent with respect to the same point in time. Oracle has integrity checks that prevent the user from opening the database until all data files are consistent with one another. When preparing a recovery strategy, it is critical to understand the answers to these questions:

• How does recovery work?
• What are the types of recovery?
• Which recovery method should be used?

• If a disk failed and destroyed some of the database files, such as datafiles, control files, and online redo logs, how would you recover the lost files?
  Media Failure: Restore and Media Recovery techniques available to you

• If a logic error in an application or a user error caused the loss of important data from one or several tables or tablespaces, how could you recover that data, and what would happen to database updates since the error?
  Point-in-Time Recovery, Flashback Features, Logical Import and Exports techniques available to you

• If the instance alert log indicates that one or more tables contain corrupt blocks, how can you repair the corruption?
  Block Media Recovery, the RMAN BLOCKRECOVER command can help you in this situation. Also, troubleshoot recovery with the SQL*Plus RECOVER ... TEST command.

• If the entire data center is destroyed, can you perform disaster recovery?  Assume that all you have is an archive tape containing backups. How would you recover the database? How long would that recovery take?

• If you were not available to recover your database, could someone else recover it in your absence? Are your recovery procedures sufficiently automated and documented?

With these needs in mind, decide how you can take advantage of features related to backup and recovery.

• Recovery Manager,
• Flashback Database,
• Block media recovery may be better than datafile media recovery if availability is critical.
• While block media recovery is possible even if you do not base your backup and recovery strategy on RMAN,
• RMAN-based block media recovery can be performed more quickly and with less effort.

Once you decide which features to use in your recovery strategy, you can plan your backup strategy,

• How and where will you store your recovery-related files?
• Will you use a flash recovery area?
• Will you use an ASM disk group to provide redundancy?
• Will you store backups on tape or other offline storage, or only on disk?
• At what intervals will you take scheduled backups?
• And what form of physical backups will you take in each situation?
• What situations require you to take a database backup outside of the regular schedule?
• How can you validate your backups, to ensure that you can recover your database when necessary?
• How do you manage records of your backups? Do you use RMAN with a recovery catalog?
• Do you have detailed recovery plans that cover each type of failure?
• How do your DBAs can execute these plans in a crisis?
• Can scripts be written to automate execution of these plans in a crisis?
• Can you apply Oracle database availability technologies, such as Data Guard or Real Application Clusters, to improve availability during a database failure?
• How does using these availability technologies affect your backup and recovery strategy?

Instance Recovery
The FAST_START_MTTR_TARGET initialization parameter specifies the number of seconds estimated for crash recovery. Oracle converts this number into a set of internal parameters and sets the recovery time as close as possible to these parameters. Setting FAST_START_MTTR_TARGET to 0 will disable this functionality.

1.1. How does recovery work?

Recovery typically involes two phases.

1. Reteriving a copy of datafile from backup.
2. Reapplying changes to the files since the backup from the archived and online redo logs.

In every type of recovery, Oracle sequentially applies redo data to data blocks. Oracle uses information in the control file and datafile headers to ascertain whether recovery is necessary. Recovery has two parts:

Rolling forward.
When Oracle rolls forward, it applies redo records to the corresponding data blocks. Oracle systematically goes through the redo log to determine which changes it needs to apply to which blocks, and then changes the blocks. For example, if a user adds a row to a table, but the server crashes before it can save the change to disk, Oracle can use the redo record for this transaction to update the data block to reflect the new row.

Rolling back
Once Oracle has completed the rolling forward stage, the Oracle database can be opened. The rollback phase begins after the database is open. The rollback information is stored in transaction tables. Oracle searches through the table for uncommitted transactions, undoing any that it finds. For example, if the user never committed the SQL statement that added the row, then Oracle will discover this fact in a transaction table and undo the change.

1.2. What are the types of recovery?

There are three basic types of recovery:

1. instance recovery
2. Crash recovery
3. Media recovery : Restore Datafiles, Apply Redo
   1. Complete,
   2. Incomplete
   3. Point-In-Time Recovery

Oracle performs the first two types of recovery automatically at instance startup. Only media recovery requires the user to issue commands.

An instance recovery, which is only possible in an Oracle Real Applications Cluster configuration, occurs in an open database when one instance discovers that another instance has crashed. A surviving instance automatically uses the redo log to recover the committed data in the database buffers that was lost when the instance failed. Oracle also undoes any transactions that were in progress on the failed instance when it crashed, then clears any locks held by the crashed instance after recovery is complete.

A crash recovery occurs when either a single-instance database crashes or all instances of a multi-instance database crash. In crash recovery, an instance must first open the database and then execute recovery operations. In general, the first instance to open the database after a crash or SHUTDOWN ABORT automatically performs crash recovery.

• Happen when DB is started after a crash ( or shutdown abort). Preserve all committed data when the instance failed. Performed automatically.
• Crash recovery uses online redo log files and current online data files

A media recovery is executed on the user's command, usually in response to media failure. In media recovery, online or archived redo logs can be used to make a restored backup current or to update it to a specific point in time.

Media recovery can restore the whole database, a tablespace or a datafile and recover them to a specified time. Whenever redo logs are used or a database is recovered to some non-current time, media recovery is being performed. A restored backup can always be used to perform the recovery.

• Can be used to recover from lost or damage current data-files, SPFILE or control file
• The first step is to manually restore the datafile by copying it from a backup.
• When data-file is restored, DB automatically detect that this datafile is out of date and must undergo media recovery.
• Media recovery is required if a datafile I taken offline without  the offline normal.
• The DB the data-file belongs to must not be open or must be offline if DB is open.
• A data-file can not be open until media recovery has been completed.
• A DB can not be opened if any of the online data-file needs media recovery.

Complete recovery

Recovering a DB to the most recent point-in-time without the loss of any committed transaction. involves using redo data combined with a backup of a database, tablespace, or datafile to update it to the most current point in time. It is called complete because Oracle applies all of the redo changes to the backup

Incomplete recovery

Also known as point-in-time recovery, restore the DB to it states at some previous targe SCN or Time

Point-in time recovery

Is only option if your have to perform recovery and discover that that you are missing an archive log which is required for recovery (OPEN RESETLOGS)

Recovery Options
If the user does not completely recover the database to the most current time, Oracle must be instructed how far to recover. The user can perform:

• Tablespace point-in-time recovery (TSPITR), which enables users to recover one or more tablespaces to a point-in-time that is different from the rest of the database.
• Time-based recovery, also called point-in-time recovery (PITR), which recovers the data up to a specified point in time.
• Cancel-based recovery, which recovers until the CANCEL command is issued.
• Change-based recovery or log sequence recovery. If O/S commands are used, change-based recovery recovers up to a specified SCN in the redo record.

If Recovery Manager is used, log sequence recovery recovers up to a specified log sequence number. When performing an incomplete recovery, the user must reset the online redo logs when opening the database. The new version of the reset database is called a new incarnation. Opening the database with the RESETLOGS option tells Oracle to discard some redo. In Oracle Database 10g and following releases, the control file added new structures that provides the ability to recover through a RESETLOGS operation using backups from a previous incarnation.

Recovering From Human Errors
Flashback Technology provides a set of new features to view and rewind data back and forth in time. The Flashback features offer the capability to query past versions of schema objects, query historical data, perform change analysis or perform self-service repair to recover from logical corruptions while the database is online.

1.3. Which recovery method should be used?

Users have a choice between two basic methods for recovering physical files. They can:

• Use Recovery Manager to automate recovery.
• Execute SQL commands.

Recovering with Recovery Manager
The basic RMAN commands are RESTORE and RECOVER. RMAN can be used to restore datafiles from backup sets or image copes, either to their current location or to a new location. If any archived redo logs are required to complete the recovery operation, RMAN automatically restores and applies them. In a recovery catalog, RMAN keeps a record containing all the essential information concerning every backup ever taken. If a recovery catalog is not used, RMAN uses the control file for necessary information. The RM AN RECOVER command can be used to perform complete media recovery and apply incremental backups, and to perform incomplete media recovery.

Recovering with SQL*Plus
Administrators can use the SQL*Plus utility at the command line to restore and perform media recovery on your files. Users can recover a database, tablespace, or datafile. Before performing recovery, users need to:

• Determine which files to recover. Often the table V$RECOVER_FILE can be used.
• Restore backups of files permanently damaged by media failure. If the user does not have a backup, recovery can still be performed if the user has the necessary redo log files and the control file contains the name of the damaged file.
• If a file cannot be restored to its original location, then the user must relocate the restored file and inform the control file of the new location.
• Restore necessary archived redo log files.

Before performing recovery, users need to:

• Determine which files to recover. Often the table V$RECOVER_FILE can be used.
• Restore backups of files permanently damaged by media failure. If the user does not have a backup, recovery can still be performed if the user has the necessary redo log files and the control file contains the name of the damaged file.
• If a file cannot be restored to its original location, then the user must relocate the restored file and inform the control file of the new location.
• Restore necessary archived redo log files.

Index of Introduction to backup and recovery article.

1. Types of Backup
2. Key data structures
3. Common questions, should know before starting backup and recovery process
   1. Types of Error and Failures
   2. What information should be backed up?
   3. Which backup method should be used?
   4. Should backups be made online or offline?
   5. How often should backups be made?
   6. How can dangerous backup techniques be avoided?
   7. Should a standby database be created?
4. Understanding basic recovery strategy