Presented By
Shailendra Kumar Misra

---

[attachment=12529]
Abstract
Backup and recovery are more important today than ever before. Take, for example, a recent announcement from a major database vendor that it now has the ability to process nearly half a million transactions per minute. That's three times the speed of the next-fastest database.
What is significant about that kind of increase? It clearly shows that businesses today are demanding higher throughput as they continue to store and process more data. It wasn't long ago that people were measuring data volumes in terms of gigabytes. Today, however, it is commonplace to manage a full terabyte of data on a single server --that's roughly equivalent to the data contained in ten thousand 300-page novels.
These huge volumes demonstrate our extreme reliance on data in today's business environment. But even as our reliance increases and volumes swell, so grows the importance of each individual piece of data making up those volumes. Few organizations can succeed without the assurance that each of their orders, payments, requests and inquiries are being properly fulfilled and processed.
1. Introduction of Backup and Recovery
In general, backup and recovery refers to the various strategies and procedures involved in protecting our database against data loss and reconstructing the data should that loss occur. The reconstructing of data is achieved through media recovery which refers to the various operations involved in restoring, rolling forward, and rolling back backup database files.
1.1. Oracle Backups: Basic Concepts
A backup is a copy of data. This copy can include important parts of the database such as the control file and data files. A backup is a safeguard against unexpected data loss and application errors. If you lose the original data, then you can reconstruct it by using a backup.
Backups are divided into physical backups and logical backups. Physical backups, which are the primary concern in a backup and recovery strategy, are copies of physical database files. We can make physical backups with either the Recovery Manager (RMAN) utility or operating system utilities. In contrast, logical backups contain logical data (for example, tables and stored procedures) extracted with the Oracle Export utility and stored in a binary file. We can use logical backups to supplement physical backups.
1.2. Oracle Recovery: Basic Concepts
To restore a physical backup of a data file or control file is to reconstruct it and make it available to the Oracle database server. To recover a restored datafile is to update it by applying archived redo logs and online redo logs, that is, records of changes made to the database after the backup was taken. If We use RMAN, then you can also recover restored datafiles with incremental backups, which are backups of a datafile that contain only blocks that changed after a previous incremental backup.
After the necessary files are restored, media recovery must be initiated by the user. Media recovery can use both archived redo logs and online redo logs to recover the datafiles.
Figure illustrates the basic principle of backing up, restoring, and performing media recovery on a database.
Restoring and Recovering a Database
Unlike media recovery, Oracle performs crash recovery and instance recovery automatically after an instance failure. Crash and instance recovery recover a database to its transaction-consistent state just before instance failure. By definition, crash recovery is the recovery of a database in a single-instance configuration or an Oracle Real Application Clusters configuration in which all instances have crashed. In contrast, instance recovery is the recovery of one failed instance by a live instance in an Oracle Real Application Clusters configuration.
Crash and instance recovery involve two distinct operations: rolling forward the current, online datafiles by applying both committed and uncommitted transactions contained in online redo records, and then rolling back changes made in uncommitted transactions to their original state.
2.Common problems
Several problems can halt the normal operation of an Oracle database or affect database I/O operations. The following are the most common types of problems.
• Media Failure
• User Error
• Database Instance Failure
• Statement Failure
• Process Failure
• Network Failure
2.1. Media Failure
An error can occur when trying to write or read a file on disk that is required to operate an Oracle database. This occurrence is called media failure because there is a physical problem reading or writing to files on the storage medium.
A common example of media failure is a disk head crash that causes the loss of all database files on a disk drive. All files associated with a database are vulnerable to a disk crash, including data files, control files, online redo logs, and archived logs.
The appropriate recovery from a media failure depends on the files affected. Media failure is the primary concern of a backup and recovery strategy, because it typically requires restoring some or all database files and the application of redo during recovery.
2.2. User Error
As an administrator, We can do little to prevent user errors such as accidentally dropping a table. Often, user error can be reduced by increased training on database and application principles .We can also avoid user errors by administering privileges correctly so that users are able to do less potential damage. Furthermore, by planning an effective recovery scheme ahead of time, We can ease the work necessary to recover from user errors.
2.3. Database Instance Failure
Database instance failure occurs when a problem prevents an Oracle database instance from continuing to run. An instance failure can result from a hardware problem, such as a power outage, or a software problem, such as an operating system crash. Instance failure also results when We issue a SHUTDOWN ABORT or STARTUP FORCE statement.
2.4. Statement Failure
Statement failure occurs when there is a logical failure in the handling of a statement in an Oracle program. For example, assume that all extents of a table (in other words, the number of extents specified in the MAXEXTENTS parameter of the CREATE TABLE statement) are allocated, and are completely filled with data. A valid INSERT statement cannot insert a row because no space is available. Therefore, the statement fails.
If a statement failure occurs, then the Oracle software or operating system returns an error. A statement failure usually requires no recovery steps: Oracle automatically corrects for statement failure by rolling back any effects of the statement and returning control to the application. The user can simply re-execute the statement after the problem indicated by the error message is corrected. For example, if insufficient extents are allocated, then the DBA needs to allocate more extents so that the user's statement can execute.
2.5. Process Failure
A process failure is a failure in a user, server, or background process of a database instance such as an abnormal disconnect or process termination. When a process failure occurs, the failed subordinate process cannot continue work, although the other processes of the database instance can continue.
The Oracle background process PMON detects aborted Oracle processes. If the aborted process is a user or server process, then PMON resolves the failure by rolling back the current transaction of the aborted process and releasing any resources that this process was using. Recovery of the failed user or server process is automatic. If the aborted process is a background process, then the instance usually cannot continue to function correctly. Therefore, We must shut down and restart the instance.
2.6. Network Failure
When your system uses networks such as local area networks and phone lines to connect client workstations to database servers, or to connect several database servers to form a distributed database system, network failures such as aborted phone connections or network communication software failures can interrupt the normal operation of a database system. For example:
• A network failure can interrupt normal execution of a client application and cause a process failure to occur. In this case, the Oracle background process PMON detects and resolves the aborted server process for the disconnected user process, as described in the previous section.
• A network failure can interrupt the two-phase commit of a distributed transaction. After the network problem is corrected, the Oracle background process RECO of each involved database automatically resolves any distributed transactions not yet resolved at all nodes of the distributed database system.
3. Oracle's Backup and Recovery Solutions
We have two methods for performing Oracle backup and recovery: Recovery Manager (RMAN) and user-managed backup and recovery. RMAN is a utility automatically installed with the database that can back up any Oracle database. RMAN uses server sessions on the database to perform the work of backup and recovery. RMAN has its own syntax and is accessible either through a command-line interface or though the Oracle Enterprise Manager GUI. RMAN comes with an API that allows it to function with a third-party media manager.
One of the principal advantages of RMAN is that it obtains and stores metadata about its operations in the control file of the production database. We can also set up an independent recovery catalog, which is a schema that contains metadata imported from the control file, in a separate recovery catalog database. RMAN performs the necessary record keeping of backups, archived logs, and so forth using the metadata, so restore and recovery is greatly simplified.
An alternative method of performing recovery is to use operating system commands for backups and SQL*Plus for recovery. This method, also called user-managed backup and recovery, is fully supported by Oracle Corporation, although use of RMAN is highly recommended because it is more robust and greatly simplifies administration.
Whether we use RMAN or user-managed methods, one can supplement there physical backups with logical backups of schema objects made using the Export utility. The utility writes data from an Oracle database to binary operating system files. We can later use Import to restore this data into a database.
4. Backup Principles
• Physical and Logical Backups
• Whole Database and Partial Database Backups
• Consistent and Inconsistent Backups
• Online and Offline Backups
• RMAN and User-Managed Backups
4.1. Physical and Logical Backups
Physical backups are backups of physical database files: datafiles and control files. If we run the database in ARCHIVELOG mode, then the database also generates archived redo logs. one can back up the datafiles, control files, and archived redo logs.
Physical backups are divided into two categories:: image copies and backups in a proprietary format. An image copy is an exact duplicate of a datafile, control file, or archived log. one can create image copies of physical files with operating system utilities or the RMAN COPY command, and you can restore them as-is without performing additional processing by using either operating system utilities or the RMAN RESTORE command.
Logical backups are exports of schema objects into a binary file. Import and Export are utilities used to move Oracle data in and out of Oracle schema. Export writes data from an Oracle database to binary operating system files. These export files store information about schema objects, for example, tables and stored procedures. Import is a utility that reads export files and restores the corresponding data into an existing database.
Although Import and Export are designed for moving Oracle data, we can also use them as a supplemental method of protecting data in an Oracle database. We should not use Import and Export as the sole method of backing up our data.