Skip Headers
Oracle® Database 2 Day DBA
11g Release 1 (11.1)

Part Number B28301-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

Configuring Your Database for Basic Backup and Recovery

This section explains how to set up your database to take advantage of Oracle suggested backup strategies. If you already configured the database for automated backups with the Oracle Database Configuration Assistant (DBCA), then skip this section.

To take maximum advantage of Oracle Database features that automatically manage backup and recovery files and operations, configure your database as follows:

You must also set a number of policies governing which files are backed up, what format is used to store backups on disk, and when files become eligible for deletion. See "Creating and Managing a Database with DBCA" to learn how to create a database preconfigured for automated daily backups.

Specifying Credentials for Backup and Recovery Using Database Control

You must have the proper credentials to perform some of the configuration tasks for backup and recovery, and to schedule backup jobs and perform recovery. The following credentials may be required:

  • The Oracle Database user you specify when you log in to Oracle Enterprise Manager Database Control (Database Control)

  • The host operating system user whose credentials you provide when performing backup and recovery tasks

To enter credentials for backup and recovery tasks:

  1. Log in to Database Control as a database user with SYSDBA privileges, or provide host operating system credentials for a user in the dba group on UNIX or Linux, or the ora_dba group on Microsoft Windows.

    The host operating system user must also have execute permission for the RMAN command-line client.

    Note:

    The host user may require certain host privileges to run background jobs such as database backups. For example, on UNIX and Linux, the host user must belong to the OSDBA group (typically dba), and on Windows, the host user must be a member of the Administrators group and must be granted the Log on as batch job logon right. See your platform documentation for more information.

    For tasks requiring host operating system credentials, a Host Credentials form appears at the bottom of the page used to perform the task. Enterprise Manager uses the credentials when it starts RMAN jobs that you requested or scheduled.

  2. Optionally, in the Host Credentials form, select Save as Preferred Credential.

    If you select this option before performing your action, then the provided credentials are stored persistently for the currently logged-in Oracle Database user. The preferred credentials are reused by default whenever you log in as that user and perform operations requiring host credentials.

    Note:

    In situations in which the database is shut down, you may still be prompted for host credentials even if you have saved the preferred credentials.

Planning Space Usage and Location for the Flash Recovery Area

You should place the flash recovery area on a separate disk from the working set of database files. Otherwise, the disk becomes a single point of failure for your database.

The amount of disk space to allocate for the flash recovery area depends on the size and activity levels of your database, which determine the size of your datafiles and redo logs files in addition to your recovery objectives. Your objectives dictate what kinds of backups you use, when you make them, and how long to keep them.

About the Backup Retention Policy and the Flash Recovery Area

Space management in the flash recovery area is governed by a backup retention policy. A retention policy determines when files are obsolete, meaning that they are no longer needed to meet your data recovery objectives.

Retention policies can be based on redundancy of backups or on a recovery window (period of time). When using a policy based on redundancy, the flash recovery area considers a backup of a file obsolete only when the RMAN repository has records of a specified number of more recent backups of that file. When using a recovery policy based on a period of time (or window), you specify a time interval in days. Files are obsolete only when they are no longer needed for complete recovery or point-in-time recovery to a system change number (SCN) within the window. Therefore, a recovery retention policy based on a window is recommended.

Even after files in the flash recovery area are obsolete, they are typically not deleted until space is needed for new files. As long as space permits, files recently moved to tape remain on disk to avoid restoring them from tape for a recovery. The automatic deletion of obsolete files and files moved to tape from the flash recovery area makes it a convenient archiving destination. Other destinations require manual deletion of logs.

About the Flash Recovery Area Size

Oracle Database Backup and Recovery User's Guide explains how to size the flash recovery area. As a general rule, the larger the flash recovery area, the more useful it is. Ideally, the flash recovery area should be large enough for copies of the datafiles, control files, online redo logs, and archived logs needed to recover the database, and also the copies of these backup files that are kept based on the retention policy.

If your backup strategy includes incremental backups, which are described in "Incremental Backups of Datafiles", then add enough space to the flash recovery area for these files. If you can move some backups to tape, then you can reduce the size of the flash recovery area. Note that retrieving files from tape causes longer database restore operations and recovery times.

Configuring Recovery Settings

In the Recovery Settings page, you can configure settings for instance recovery, media recovery, and flash recovery. In this section, you configure the flash recovery area and enable archiving for the database.

You can configure a flash recovery area when first creating the database. If you did not perform this task at database creation time, however, then you can create a flash recovery area for your database now.

To configure a flash recovery area and put the database in ARCHIVELOG mode:

  1. On the host operating system, create a directory to hold the flash recovery area.

    Make sure that the operating system permissions for this directory allow the database to create files.

  2. Log in to Enterprise Manager Database Control as user SYS.

  3. On the Database Home page, click Availability to display the Availability subpage.

  4. In the Backup/Recovery section, click Recovery Settings.

    The Recovery Settings page appears.

  5. Complete the following steps:

    1. In the Media Recovery section, select ARCHIVELOG Mode.

    2. If USE_DB_RECOVERY_FILE_DEST is not already set as an archiving destination, then set it.

      This initialization parameter indicates that the flash recovery area should be an archiving destination.

      For ease of database management, the best practice is to use the flash recovery area as your only archiving destination.

    3. In the Flash Recovery section, enter the path to the flash recovery area created in Step 1 in Flash Recovery Area Location, and select a value for Flash Recovery Area Size.

    4. Select Enable Flashback Database.

      This option specifies that the database should generate flashback logs in the flash recovery area, enabling you to use Flashback Database. During usual operation, the database occasionally logs images of data blocks to the flashback logs. The database automatically creates, deletes, and resizes flashback logs.

    5. Ensure that the Apply changes to SPFile only box is not selected.

    6. Click Apply to save your changes.

      A message prompts you to restart the database.

  6. Click Yes.

    The Restart Database: Specify Host and Target Database Credentials page appears.

  7. Enter your host and database credentials, and then click OK.

    See "Specifying Credentials for Backup and Recovery Using Database Control" for information about credentials.

  8. On the Restart Database: Confirmation page, click Yes to begin the restart operations.

    You can click Refresh periodically to monitor the progress of the operation.

  9. Make a consistent (that is, offline) backup of your entire database immediately after switching your database to ARCHIVELOG mode.

    Caution:

    You cannot use backups from before the switch to ARCHIVELOG mode to restore and recover the database to a point in time after the switch. Thus, if you do not immediately make a backup after switching, you are running your database without a backup. See "Performing and Scheduling Backups Using Database Control" to learn how to make database backups.

See Also:

Monitoring Flash Recovery Area Usage

It is important to monitor space usage in the flash recovery area to ensure that it is large enough to contain backups and other recovery-related files.

To monitor available space in the flash recovery area:

  • In the High Availability section of the Database Home page, click the link next to Usable Flash Recovery Area (%).

    The Recovery Settings page appears.

    The Reclaimable Flash Recovery Area (GB) and Free Flash Recovery Area (GB) settings indicate how much space is available.

Configuring Backup Settings

You can configure a number of backup-related settings and policies. For example, you can determine how backups are stored, which data is backed up, and how long backups are retained. You can also configure settings to optimize backup performance.

This section explains the concepts behind the available settings and also explains how to change them using the Backup Settings page in Database Control. The settings on the Device subpage affect how RMAN writes backups to disk and to tape.

About RMAN Backups

Database backups created by RMAN are stored as image copies or backup sets.

Image copies are exact byte-for-byte copies of files. You can create an image copy by copying a file at the operating system level. Unlike copying files at the operating system level, however, image copies created through RMAN or Database Control are recorded in the RMAN repository so that RMAN can use these copies during database restore operations and recovery. RMAN can restore files only if they are recorded in the RMAN repository. RMAN can create image copies only on disk.

Backup sets are logical entities produced by the RMAN BACKUP command. This command can produce one or more backup sets on disk or media management devices. RMAN can write backup sets only to a media manager.

Each backup set contains several physical files called backup pieces. A backup piece stores the backup of one or more database files in a compact RMAN-specific format. One advantage of backup sets is that RMAN uses unused block compression to save space in backing up datafiles. Only those blocks in the datafiles that have been used to store data are included in the backup set.

RMAN depends on server sessions, processes that run on the database server, to create backups and restore them. Each server session, in turn, corresponds to an RMAN channel, representing one stream of data to or from a backup device. Channels are either of type disk or type SBT (tape).

RMAN supports parallelism, which is the use of multiple channels and server sessions to carry out the work of one backup or recovery task. Proper use of parallelism can greatly increase performance on backup and recovery tasks.

See Also:

Configuring Backup Device Settings

For disk-based backups, you can configure the default format for backups, the location on disk where backups are stored, and whether or not backup tasks run in parallel.

For tape backups, you can configure settings such as the number of tape drives and whether or not backups are compressed. On most platforms, you must integrate a media manager with the Oracle database to use sequential media for storage.

You can use Oracle Secure Backup, which supports both database and file system backups to tape, as your media manager. Oracle Secure Backup provides the same services for RMAN as other third-party SBT interfaces, but is better integrated with Database Control. This section assumes that you will make only disk backups.

To configure backup settings for disk:

  1. On the Database Home page, click Availability to display the Availability subpage.

  2. In the Backup/Recovery section, click Backup Settings.

    The Backup Settings page appears.

  3. Click Device.

    The Device subpage of Backup Settings appears.

  4. Complete the following steps:

    1. In Parallelism, enter 1.

      Later, when you have had time to review the information in Oracle Database Backup and Recovery User's Guide about parallelism and performance in RMAN, you may want to change this value.

    2. Leave the Disk Backup Location field blank so that RMAN directs backups to the flash recovery area.

    3. In the Disk Backup Type section, select Backup Set.

      One advantage of backup sets is that RMAN uses unused block compression to save space when backing up datafiles. Only those blocks in the datafiles that have been used to store data are included in the backup set.

  5. In Host Credentials, enter values in the Username and Password fields.

    Host credentials are described in "Specifying Credentials for Backup and Recovery Using Database Control".

  6. Click Test Disk Backup to ensure the credentials and backup location are correct.

    A message appears that states whether or not the test was successful.

    In this example you do not change the settings on the Backup Set subpages.

See Also:

Configuring Backup Policy Settings

You can set the backup policies that govern control file and server parameter file backups, tablespaces to exclude from an entire database backup, and the backup retention policy.

To configure the backup policy settings:

  1. On the Database Home page, click Availability to display the Availability subpage.

  2. In the Backup/Recovery section, click Backup Settings.

    The Backup Settings page appears.

  3. Click Policy.

    The Backup Policy subpage appears.

  4. Perform the following actions:

    • Select the Automatically backup the control file and server parameter file (SPFILE) with every backup and database structural change option. Leave the Autobackup Disk Location field blank so that RMAN stores the automatic backups in the flash recovery area.

      The server parameter file and control file are critical to the database and RMAN, and are also relatively small compared to typical datafiles. Backing them up frequently results in relatively little storage overhead.

    • Select the Optimize the whole database backup by skipping unchanged files such as read-only and offline datafiles that have been backed up option.

      This option saves space in the flash recovery area.

    • Select the Enable block change tracking for faster incremental backups option. Either leave the Block Change Tracking File field blank (if you configured a database area in "Step 7 - Database File Locations") or enter a file name.

      This option takes advantage of the block change tracking feature, which greatly improves incremental backup performance at a small cost of overhead.

  5. In the Tablespaces Excluded From Whole Database Backup section, leave the settings as they are.

    This feature enables you to specify a list of tablespaces to exclude from a backup. For example, you do not need to include read-only tablespaces in every backup.

  6. In the Retention Policy section, select Retain backups that are necessary for a recovery to any time within the specified number of days (point-in-time recovery). In Days, enter 31.

    This setting enables a recovery policy with retention based on a period of time.

  7. In the Archivelog Deletion Policy section, select None.

    This option specifies that logs are eligible for automatic deletion only when they have been backed up to tape or are obsolete based on the retention policy.

  8. Click OK to save your changes.

See Also: