Why recovery is needed in database

It ensures that the database is reliable and remains in consistent state in case of a failure. Database recovery can be classified into two parts; 1. Rolling Forward applies redo records to the corresponding data blocks. Rolling Back applies rollback segments to the datafiles.

It is stored in transaction tables. We can recover the database using Log—Based Recovery. Log-Based Recovery Logs are the sequence of records, that maintain the records of actions performed by a transaction. In Log — Based Recovery, log of each transaction is maintained in some stable storage. If any failure occurs, it can be recovered from there to recover the database.

If the underlying architecture fails or crashes, then there must be some techniques and procedures by which the lost data during a transaction gets recovered. It is the method of restoring the database to its correct state in the event of a failure at the time of the transaction or after the end of a process.

Earlier, you have been given the concept of database recovery as a service that should be provided by all the DBMS for ensuring that the database is dependable and remains in a consistent state in the presence of failures.

In this context, dependability refers to both the flexibility of the DBMS to various kinds of failure and its ability to recover from those failures. DBMS is a highly complex system with hundreds of transactions being executed every second.

The durability and robustness of a DBMS depends on its complex architecture and its underlying hardware and system software. If it fails or crashes amid transactions, it is expected that the system would follow some sort of algorithm or techniques to recover lost data. This is called transaction failure where only a few transactions or processes are hurt. For example, in case of deadlock or resource unavailability, the system aborts an active transaction.

For example, interruptions in power supply may cause the failure of underlying hardware or software failure. In early days of technology evolution, it was a common problem where hard-disk drives or storage drives used to fail frequently.

Disk failures include formation of bad sectors, unreachability to the disk, disk head crash or any other failure, which destroys all or a part of disk storage. We have already described the storage system. Each entry shows the time the archive started and stopped. If ARC n encounters an error when attempting to archive a log group for example, due to an invalid or filled destination , ARC n continues trying to archive the group. If the problem is not resolved, eventually all online redo log groups become full, yet not archived, and the system halts because no group is available to LGWR.

Therefore, if problems are detected, you should either resolve the problem so that ARC n can continue archiving such as by changing the archive destination or manually archive groups until the problem is resolved.

If automatic archiving is disabled, the database administrator is responsible for manually archiving all filled groups. For most systems, automatic archiving is chosen because the administrator does not have to watch for a group to become inactive and available for archiving.

Furthermore, if automatic archiving is disabled and manual archiving is not performed fast enough, database operation can be suspended temporarily whenever LGWR is forced to wait for an inactive group to become available for reuse. When a group is archived manually, the user process issuing the statement to archive a group actually performs the process of archiving the group. Even if the ARC n background process is present for the associated instance, it is the user process that archives the group of online redo log files.

The control file of a database is a small binary file necessary for the database to start and operate successfully. A control file is updated continuously by Oracle during database use, so it must be available for writing whenever the database is open.

If for some reason the control file is not accessible, the database will not function properly. A control file contains information about the associated database that is required for the database to be accessed by an instance, both at startup and during normal operation.

A control file's information can be modified only by Oracle; no database administrator or end-user can edit a database's control file. The database name and timestamp originate at database creation. Each time that a datafile or an online redo log file is added to, renamed in, or dropped from the database, the control file is updated to reflect this physical structure change. These changes are recorded so that. Oracle can identify files that are required or available in case database recovery is necessary.

Therefore, if you make a change to your database's physical structure, you should immediately make a backup of your control file. Additional Information: See Oracle8i Backup and Recovery Guide for information about backing up a database's control file. Control files also record information about checkpoints. Every three seconds, the checkpoint process CKPT records information in the control file about the checkpoint position in the online redo log.

This information is used during database recovery to tell Oracle that all redo entries recorded before this point in the online redo log group are not necessary for database recovery; they were already written to the datafiles. As with online redo log files, Oracle allows multiple, identical control files to be open concurrently and written for the same database. By storing multiple control files for a single database on different disks, you can safeguard against a single point of failure with respect to control files.

If a single disk that contained a control file crashes, the current instance fails when Oracle attempts to access the damaged control file. However, other copies of the current control file are available on different disks, so an instance can be restarted easily without the need for database recovery.

The permanent loss of all copies of a database's control file is a serious problem to safeguard against. If all control files of a database are permanently lost during operation several disks fail , the instance is aborted and media recovery is required. Even so, media recovery is not straightforward if an older backup of a control file must be used because a current copy is not available.

Therefore, it is strongly recommended that multiplexed control files be used with each database, with each copy stored on a different physical disk. You can use Oracle mirrored logs, Oracle mirrored control files, and archive logs to recover from media failure, but some or all of the data may not be available while recovery is proceeding. To achieve a higher level of recovery, Oracle recommends that you use operating system or hardware data redundancy for at least the datafiles and the control files.

This will make sure that any one media failure will be recoverable while the system is fully available. No matter what backup and recovery scheme you devise for an Oracle database, backups of the database's datafiles and control files are absolutely necessary as part of the strategy to safeguard against potential media failures that can damage these files. The following sections provide a conceptual overview of the different types of backups that can be made and their usefulness in different recovery schemes.

Additional Information: The Oracle8i Backup and Recovery Guide provides more details, along with guidelines for performing database backups. Whole Database Backups A whole database backup is an operating system backup of all datafiles and the control file that constitute an Oracle database.

You can take a whole database backup when the database is shut down or while the database is open. You should not normally take a whole backup after an instance failure or other unusual circumstances. Following a clean shutdown, all of the files that constitute a database are closed and consistent with respect to the current point in time.

Thus, a whole backup taken after a shutdown can be used to recover to the point in time of that backup. A whole backup taken while the database is open is not consistent to a given point in time and must be recovered with the online and archived redo log files before the database can become available. The datafiles obtained from a whole backup are useful in any type of media recovery scheme:.

Because an archived redo log is not available to bring the database up to the current point in time, all database work performed since the backup must be repeated.

After restoring the necessary datafiles from the whole backup, database recovery can continue by applying archived and current online redo log files to bring the restored datafiles up to the current point in time. A partial database backup is any backup short of a whole backup, taken while the database is open or shut down.

The following are all examples of partial database backups:. Because an archived redo log is present, the datafiles restored from a partial backup can be made consistent with the rest of the database during recovery procedures. A partial backup includes only some of the datafiles of a database.

Individual or collections of specific datafiles can be backed up independently of the other datafiles, online redo log files, and control files of a database. You can back up a datafile while it is offline or online. Choosing whether to take online or offline datafile backups depends only on the availability requirements of the data--online datafile backups are the only choice if the data being backed up must always be available.

Another form of a partial backup is a control file backup. Because a control file keeps track of the associated database's physical file structure, a backup of a database's control file should be made every time a structural change is made to the database. Note: The Recovery Manager automatically backs up the control file in any backup that includes datafile 1, which contains the data dictionary.

Multiplexed control files safeguard against the loss of a single control file. However, if a disk failure damages the datafiles and incomplete recovery is desired, or a point-in-time recovery is desired, a backup of the control file that corresponds to the intended database structure should be used, not necessarily the current control file.

Therefore, the use of multiplexed control files is not a substitute for control file backups taken every time the structure of a database is altered. If you use Recovery Manager to restore the control file prior to incomplete or point-in-time recovery, Recovery Manager automatically restores the most suitable backup control file. Export and Import are utilities used to move Oracle data in and out of Oracle databases. Export is a utility that writes data from an Oracle database to operating system files in an Oracle database format.

Export files store information about schema objects created for a database. Import is a utility that reads Export files and restores the corresponding information into an existing database. Although Export and Import are designed for moving Oracle data, they can be used also as a supplemental method of protecting data in an Oracle database. Additional Information: See Oracle8i Utilities. Read-Only Tablespaces and Backup You can create backups of a read-only tablespace while the database is open.

Immediately after making a tablespace read-only, you should back up the tablespace. As long as the tablespace remains read-only, there is no need to perform any further backups of it.

After you change a read-only tablespace to a read-write tablespace, you need to resume your normal backups of the tablespace, just as you do when you bring an offline read-write tablespace back online. Bringing the datafiles of a read-only tablespace online does not make these files writeable, nor does it cause the file header to be updated.

Thus it is not necessary to perform a backup of these files, as is necessary when you bring a writeable datafile back online. In the event of a power failure, hardware failure, or any other system-interrupting disaster, Oracle offers the automated standby database feature.

The standby database is intended for sites where survivability and disaster recovery are of paramount importance. Another option is to use database replication. This feature is described in Chapter 34, "Database Replication". The only way to ensure rapid recovery from a system failure or other disaster is to plan carefully. You must have a set plan with detailed procedures.