1 Introduction to Backup and Recovery

As a backup administrator, your primary job is making and monitoring backups for data protection. A backup is a copy of data of a database that you can use to reconstruct data. A backup can be either a physical backup or a logical backup.

Physical backups are copies of the physical files used in storing and recovering a database. These files include data files, control files, and archived redo logs. Ultimately, every physical backup is a copy of files that store database information to another location, whether on disk or on offline storage media such as tape.

Logical backups contain logical data such as tables and stored procedures. You can use Oracle Data Pump to export logical data to binary files, which you can later import into the database. The Data Pump command-line clients expdp and impdp use the DBMS_DATAPUMP and DBMS_METADATA PL/SQL packages.

Physical backups are the foundation of any sound backup and recovery strategy. Logical backups are a useful supplement to physical backups in many circumstances but are not sufficient protection against data loss without physical backups.

Unless otherwise specified, the term backup as used in the backup and recovery documentation refers to a physical backup. Backing up a database is the act of making a physical backup. The focus in the backup and recovery documentation set is almost exclusively on physical backups.

While several problems can halt the normal operation of an Oracle Database or affect database I/O operations, only the following typically require DBA intervention and data recovery: media failure, user errors, and application errors. Other failures may require DBA intervention without causing data loss or requiring recovery from backup. For example, you may need to restart the database after an instance failure or allocate more disk space after statement failure because of a full data file.

Data archival is related to data protection, but serves a different purpose. For example, you may need to preserve a copy of a database as it existed at the end of a business quarter. This backup is not part of the disaster recovery strategy. The media to which these backups are written are often unavailable after the backup is complete. You may send the tape into fire storage or ship a portable hard drive to a testing facility. RMAN provides a convenient way to create a backup and exempt it from your backup retention policy. This type of backup is known as an archival backup.

In some situations you may need to take a backup of a database or database component and move it to another location. For example, you can use Recovery Manager (RMAN) to create a database copy, create a tablespace copy that can be imported into another database, or move an entire database from one platform to another. These tasks are not strictly speaking part of a backup and recovery strategy, but they do require the use of database backups, and so may be included in the duties of a backup administrator.

Most of the flashback features of Oracle operate at the logical level, enabling you to view and manipulate database objects. The logical-level flashback features of Oracle do not depend on RMAN and are available whether or not RMAN is part of your backup strategy. Except for Oracle Flashback Drop, the logical flashback features rely on undo data, which are records of the effects of each database update and the values overwritten in the update.

Oracle Database includes the following logical flashback features:

• Oracle Flashback Query

  You can specify a target time and run queries against a database, viewing results as they would appear at the target time. To recover from an unwanted change like an update to a table, you could choose a target time before the error and run a query to retrieve the contents of the lost rows. Oracle Database Development Guide explains how to use this feature.

• Oracle Flashback Version Query

  You can view all versions of all rows that ever existed in one or more tables in a specified time interval. You can also retrieve metadata about the differing versions of the rows, including start and end time, operation, and transaction ID of the transaction that created the version. You can use this feature to recover lost data values and to audit changes to the tables queried. Oracle Database Development Guide explains how to use this feature.

• Oracle Flashback Transaction Query

  You can view changes made by a single transaction, or by all the transactions during a specific time period. Oracle Database Development Guide explains how to use this feature.

• Oracle Flashback Transaction

  You can reverse a transaction. Oracle Database determines the dependencies between transactions and in effect creates a compensating transaction that reverses the unwanted changes. The database rewinds to a state as if the transaction, and any transactions that could be dependent on it, had never happened. Oracle Database Development Guide explains how to use this feature.

• Oracle Flashback Table

  You can recover a table or set of tables to a specified point in time earlier without taking any part of the database offline. In many cases, Flashback Table eliminates the need to perform more complicated point-in-time recovery operations. Flashback Table restores tables while automatically maintaining associated attributes such as current indexes, triggers, and constraints, and in this way enabling you to avoid finding and restoring database-specific properties. "Rewinding a Table with Flashback Table" explains how to use this feature.

• Oracle Flashback Drop

  You can reverse the effects of a DROP TABLE statement. "Rewinding a DROP TABLE Operation with Flashback Drop" explains how to use this feature.

A flashback data archive enables you to use some logical flashback features to access data from far back in the past. A flashback data archive consists of one or more tablespaces or parts of tablespaces. When you create a flashback data archive, you specify the name, retention period, and tablespace. You can also specify a default flashback data archive. The database automatically purges old historical data the day after the retention period expires.

You can turn flashback archiving on and off for individual tables. By default, flashback archiving is turned off for every table.

At the physical level, Oracle Flashback Database provides a more efficient data protection alternative to database point-in-time recovery (DBPITR). If the current data files have unwanted changes, then you can use the RMAN command FLASHBACK DATABASE to revert the data files to their contents at a past time. The end product is much like the result of a DBPITR, but is generally much faster because it does not require restoring data files from backup and requires less redo than media recovery.

Flashback Database uses flashback logs to access past versions of data blocks and some information from archived redo logs. Flashback Database requires that you configure a fast recovery area for a database because the flashback logs can only be stored there. Flashback logging is not enabled by default. Space used for flashback logs is managed automatically by the database and balanced against space required for other files in the fast recovery area.

Oracle Database also supports restore points along with Flashback Database and backup and recovery. A restore point is an alias corresponding to a system change number (SCN). You can create a restore point at any time if you anticipate needing to return part or all of a database to its contents at that time. A guaranteed restore point ensures that you can use Flashback Database to return a database to the time of the restore point.

Oracle Enterprise Manager Cloud Control (Cloud Control) is a browser-based management interface for Oracle Database. Cloud Control provides a graphical front end and scheduling facilities for RMAN. You enter job parameters, specify a job schedule, and Cloud Control runs RMAN at the designated time or designated repeat interval to conduct the backup and recovery operations.

Cloud Control provides access to RMAN through a set of wizards. These wizards lead you through a variety of recovery procedures based on an analysis of your database, your available backups, and your data recovery objectives.

By using Cloud Control, you can perform the simpler restore and recovery scenarios outlined in this documentation. You can also use more sophisticated restore and recovery techniques such as point-in-time recovery and Oracle Flashback operations, which allow for efficient repair of media failures and user errors. Using Cloud Control is often simpler than the RMAN command-line client.

To use Cloud Control, you start by accessing the Database Home page as described in Accessing the Database Home Page Using Cloud Control.

Performing Backup and Recovery Tasks with Cloud Control describes how to use Cloud Control for backup and recovery.

1. Access the Database Home page for the target database as described in Accessing the Database Home Page Using Cloud Control.
2. From the Availability menu, select Backup and Recovery, and then select an option.

You can use most RMAN commands to back up to and recover from Recovery Appliance. The following sections provide additional information about using RMAN with Recovery Appliance:

• "About RMAN in a Recovery Appliance Environment"

• "Configuring RMAN to Make Backups to Recovery Appliance"

• "Unregistering a Target Database in a Recovery Appliance Environment"

• "About Real-Time Redo Transport for Recovery Appliance"

• "About the Incremental-Forever Backup Strategy for Recovery Appliance"

If you use RMAN as your principal backup and recovery solution, then begin by reading " Getting Started with RMAN". This brief chapter, which explains the most basic RMAN techniques, may be adequate for your purposes. For a more comprehensive explanation of how to implement a backup and recovery strategy with RMAN, read the chapters in the following order (optional chapters are not listed):

1. Read Starting and Interacting with the RMAN Client.

   This chapter explains how to start the RMAN client and connect to databases.

2. Read Configuring the RMAN Environment.

   This chapter explains how to perform basic tasks such as configuring a fast recovery area, backup retention policy, and archived redo log deletion policy.

3. Read Backing Up the Database.

   This chapter explains how to implement a basic backup strategy.

4. Read Reporting on RMAN Operations.

   This chapter explains how to monitor RMAN backup and recovery operations. Specifically, the chapter explains how to use the reporting commands (LIST, REPORT, and SHOW) and the relevant V$ and recovery catalog views.

5. Read Maintaining RMAN Backups and Repository Records.

   This chapter explains how to verify the existence of backups, change the repository status of backups, delete backups, and perform other maintenance tasks.

6. Read Diagnosing and Repairing Failures with Data Recovery Advisor.

   This chapter explains how to use the Data Recovery Advisor tool. You can use it to list failures, obtain advice about to respond to these failures, and in some cases automatically repair the failures.

7. Read Performing Flashback and Database Point-in-Time Recovery.

   This chapter explains how to use the FLASHBACK DATABASE command and perform point-in-time recovery with the RECOVER DATABASE command.

8. Read Performing Complete Database Recovery.

   This chapter explains how to recover individual tablespaces or the database.

If you do not use RMAN as your principal backup and recovery solution, then you must use third-party tools to make your backups and SQL or SQL*Plus commands to perform recovery. Read the chapters in the following order:

1. Read Making User-Managed Database Backups.

   This chapter explains how to make backups with third-party tools.

2. Read Performing User-Managed Database Flashback and Recovery.

   This chapter explains how to use the SQL statement FLASHBACK DATABASE and to perform recovery with the SQL*Plus RECOVER command.

3. Read Performing User-Managed Recovery: Advanced Scenarios.

   This chapter explains various recovery scenarios.