Database Recovery Techniques
By: Mharolkar Saurabh
Tags: Dbms, Database, Oracle

Types Of Oracle Recovery

Instance and Crash recovery

Media Recovery

Instance and Crash recovery

The Oracle Real Application Cluster database and its single-instance database can be recovered through crash recovery. In Oracle Real Application Cluster, instance restoration refers to taking over an instance that has failed and restoring it.

Rollbacking back changes to a data block in the dead instance cache and closing the open chain of rollbacks are features of crash and version rollback. Oracle restores versions and crashes by using only the current log files and data files. It reconstructs the repeat patterns of the dead versions together.

Instance and Crash Recovery have the following characteristic in common:

Revert changes using current online data files (as left on disk after crash or SHUTDOWN ABORT)

Only use online restore logs and never ask to use archived logs

The recovery time is governed by the number of repetitions generated in each dead repeat sequence since the last checkpoint, and by possible factors configured such as the number and size of log files, the frequency of checkpoints and parallel restore settings

Oracle does the automatic recovery on two occasions:

For the first database opened after a single database or all instances of the Oracle Real Applications Cluster database crash (crash recovery).

Rollback occurs automatically by an existing instance in the configuration when some of the Real Application Pools configuration instances fail (restore instances).

There’s no user intervention required in both cases: Oracle implements automatic recovery: recovery logs are automatically generated. However, the database server can be set so that instance duration and disaster recovery performance can be tuned. In addition, you can separately adjust the progress and cancellation phases of the cancellation process. Finally, you can adjust the checkpoint for optimized recovery time.

Media Recovery

Media recovery is divided into the following types:

Datafile media recovery

Block media recovery

Datafile Media Recovery:

Recovery of lost or damaged data files and control files is another use for media recovery. It can also be used to restore changes lost when a table space went offline without the OFFLINE NORMAL option. In addition, the database integrity is repaired. here are some differences in the additional capabilities offered by different types of recovery.

Media recovery has the following functions:

Apply the necessary changes using restored backups of corrupted data files.

You can use archived logs and online logs.

Requires an explicit call by a user.

Does not automatically detect media errors (ie the need to restore a backup). However, once a backup has been restored, it will automatically detect that it needs to be restored using media recovery.

Has a recovery time that is determined solely by the user policy (e.g. frequency of backups, parallel recovery parameters) and not by internal Oracle mechanisms.

The database cannot be opened if any of the online data files require media recovery, nor can a data file requiring media recovery come online until the media recovery is performed. The following scenarios require media recovery:

You restore a backup of a data file.

You restore a backup management file (even if all data files are current).

A data file is taken offline (either by you or mechanically by Oracle) while not the OFFLINE traditional option.

Data file media recovery is only possible with offline data files unless the database has been opened by an instance. You can begin data file media recovery prior to opening a database, even if crash recovery would have been sufficient. If the database is opened with crash recovery set to automatic, the process will continue to run. Be aware that you must perform a media recovery if a file needs to be recovered even if all the required changes have already been made. do nothing and report a “No Restore Needed” error when invoked for files that do not need to be restored.

Block Media Recovery

Recovery of data from block media involves recovering individual chunks of information while maintaining access and availability to all files within the database. A mass media recovery technique may be preferable to data file recovery when corruption affects only a few blocks within a subset of database files.

The media recovery blocking interface is provided by RMAN. If you are not already using RMAN as your primary backup and recovery solution, you can still perform bulk media recovery by cataloging the required user-managed data file and archived redo log in the RMAN repository Fuses. Crosschecks will update noncurrent repository info regarding backups and copies whose repository records don’t match their physical standing. For example, somebody removes archived logs from disk with an software system command so the repository indicates that the logs are on disk once of course they need deleted. In the case of a tape backup, the CROSSCHECK command simply verifies that the backup exists. If the backup is on disk, the CROSSCHECK command checks whether the header is valid. Backups and copies are assigned status values of AVAILABLE, UNAVAILABLE, and EXPIRED. For more information about backups and copies, please refer to the output of the LIST command.

Redo Application During Recovery

The media recovery is performed by redoing the data file by the data application. Whenever a change is made to the data file, the change is first recorded in the online redo log. Media recovery selectively applies the changes recorded in the online and archived redo logs to the recovered data files to move on.

What is Redo Application

The database buffer in the SGA buffer cache is only written to disk using the least recently used (LRU) algorithm when necessary. Because the database writing process uses this algorithm to write the database buffer into the data file, the data file may contain some data blocks that have not been committed by transaction changes and some data blocks that lack committed transaction changes.

If your instance fails, there may be two potential problems:

The data block changed by the transaction may not be written to the data file at the time of commit, but will only appear in the redo log. Due to this, changes in redo logs have to be applied to the database again during recovery.

To ensure transactional consistency, uncommitted changes in the data file must be reverted after the roll-forward phase. During a roll-forward phase, these changes are added to the data file before failing.

Cache recovery and transaction recovery are the two steps used by Oracle to recover from a system failure.

Cache Recovery

Online redo logs are software files used to track all changes made to data segments such as the associated info buffer, knowledge, index, and rollback segments, regardless of whether they are committed or uncommitted. A redo log is the repository for all changes to Oracle blocks. When recovering from an instance or disk failure, the primary step is rolling forward or cache recovery, and it involves reapplying all of the changes recorded in the redo log. Taking into account that rollback data is now additionally captured in the redo log, rolling forward also regenerates the corresponding rollback segments. Rolling forward takes the InfoBase through the relevant redo log files several times if necessary. Redo log files are sometimes rolled forward (instance recovery and media recovery) and archived redo log files are sometimes added (media recovery only).When moving forward, all changes are contained in the data blocks. Additional uncommitted changes were either recorded in the redo logs during the recovery process or saved to the data files before the failure.

Transaction Recovery

You can run Oracle in manual undo administration mode or in automatic undo administration mode. In manual mode, you must create and maintain rollback segments to record the previous image of changes in the database. The automatic undo management tool creates one or more undo table spaces. These undo table spaces contain undo segments that are similar to traditional rollback segments. The main difference is that Oracle does the undo for you. Undo blocks (either in rollback segments or in table spaces with automatic undo) record the database actions that must be undone during certain database operations. During database recovery, undo blocks reverse the effects of uncommitted transactions that were previously applied by the rollforward phase After the trailer, any changes that were not committed must be rolled back. Oracle uses undo blocks to undo uncommitted changes to data blocks that were written before the lock or entered by the redo application while it was being cached. This process is known as transaction rollback or recovery.