| Oracle® Database 2 Day DBA 10g Release 2 (10.2) Part Number B14196-02 |
|
|
View PDF |
| Oracle® Database 2 Day DBA 10g Release 2 (10.2) Part Number B14196-02 |
|
|
View PDF |
To take maximum advantage of Oracle Database features that automatically manage backup and recovery files and processes, configure your database as follows:
Use a flash recovery area, which automates storage management for most backup-related files.
Run your database in ARCHIVELOG mode, so that you can perform online backups and have data recovery options such as complete and point-in-time media recovery.
Use the flash recovery area as an archived log destination for your database.
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 from 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 upon the size and activity levels of your database, which determine the size of your datafiles and redo logs files as well as your recovery objectives. Your objectives dictate what kinds of backups you use, when you make them, and how long you must keep them.
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.
Under a redundancy-based policy, 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. For example, assume your policy requires that two backups of each file be kept. You make backups nightly starting on a Monday night. After the Wednesday night backup succeeds, the Monday night backup becomes redundant because the Tuesday and Wednesday backups are available.
Under a recovery window-based policy, you specify a time interval measured in days. Files become obsolete only when they are no longer needed for successful complete recovery or point-in-time recovery to any point within that number of days into the past. For example, assume that you specify a recovery window of three days. A backup of all datafiles from at least three days ago must be retained, along with a full set of archived redo logs generated since that backup.
Note:
With a badly designed backup strategy, a recovery window-based retention policy can require the retention of large quantities of data. For example, assume that you specify a retention policy with a three-day recovery window and make a full database backup only on the first day of each month and no other backups. By the 28th day, recovery to any point in the three day window requires the full database backup from the first day as well as 28 days of archived redo logs.Furthermore, recovery time may be quite long after you restore from this backup. The reason is that a minimum of 25 days' worth of transactions must be applied to the restored backup to reach the beginning of the recovery window. Thus, this strategy both wastes disk space usage and results in poor recovery performance.
A redundancy-based retention policy makes it easier to predict space usage in the flash recovery area, but it does not allow you to predict how far into the past you can recover your database. A recovery window-based policy offers better protection for your data, but can make storage requirements for backups harder to predict. As already noted, a poorly designed backup strategy can cause unexpectedly high space requirements, even with a short recovery window. Oracle recommends the use of a recovery window-based retention policy as part of a well-designed backup strategy.
Even after files in the flash recovery area are obsolete, they are generally not deleted from the flash recovery area until space is needed to store new files. As long as space permits, files recently moved to tape will remain on disk as well, so that they will not have to be retrieved from tape in the event of a recovery.
The automatic deletion of obsolete files and files moved to tape from the flash recovery area makes the flash recovery area a very convenient redo log archiving destination. Other archiving destinations require manual cleanup of archived redo logs no longer needed on disk for recovery.
An approach for sizing the flash recovery area is described at length in Oracle Database Backup and Recovery Basics, but as a general rule, the larger the flash recovery area, the more useful it becomes. Ideally, the flash recovery area should be large enough to hold a copy of all of your datafiles and control files, the online redo logs, and the archived redo log files needed to recover your database using the datafile backups kept under your 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 to accommodate these files as well. If you can move some backups to tape, then you can reduce the size of the flash recovery area somewhat. Note that retrieving those files from tape will cause longer database restore and recovery times.
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 user you use when you log in to Enterprise Manager
The host operating system user whose credentials you provide when performing backup and recovery tasks
To perform or schedule RMAN tasks, you must either log in to Enterprise Manager as a user with SYSDBA privileges, or provide host operating system credentials for a user who is a member of the DBA group. The host operating system user must also have execute permission for the RMAN command-line client.
For tasks requiring host operating system credentials, a Host Credentials form appears at the bottom of the page used to perform the task (see Figure 9-1, "Schedule Backup Page"). Enterprise Manager uses the credentials when it invokes RMAN to perform jobs you requested or scheduled.
The Host Credentials form always includes a checkbox labelled Save as Preferred Credential. If you check this box before performing your action, then the provided credentials are stored persistently for the currently logged-in Oracle 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, as is required for some database recovery operations, you may still be prompted for host credentials even if you save preferred credentials.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:
On the host operating system, create a directory to hold the flash recovery area. Make sure that the permissions for this directory allow Oracle to create files here.
From the Database Home page, click Maintenance.
The Maintenance property page appears.
In the Backup/Recovery section, select Recovery Settings.
The Recovery Settings page appears.
In the Flash Recovery section, enter the path to the flash recovery area location (the path to the directory on disk you created in step 1), and your desired flash recovery area size. Make sure the Apply changes to SPFILE only box is not checked, then click Apply to save your settings.
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. The High Availability section of the home page lists the percentage of flash recovery area space available. Click Usable Flash Recovery Area to navigate to the Recovery Settings page, which contains a Flash Recovery Area Usage graph showing how much space is allocated to each type of file and how much space is free.
If you did not configure ARCHIVELOG mode when you first created your database, then configure it now with the following procedure. This procedure specifies that archived logs should be stored only in the flash recovery area, which is the best practice for managing archived redo logs.
To place the database in ARCHIVELOG mode:
On the Maintenance page, click Recovery Settings.
The Recovery Settings property page appears.
In the Media Recovery section, check ARCHIVELOG Mode if it is not already checked. Under the ARCHIVELOG Mode checkbox is a list of up to ten possible log archiving locations. The last one is set to USE_DB_RECOVERY_FILE_DEST, indicating that the flash recovery area should be an archiving destination. You can specify other locations on disk as well.
For ease of database management, the best practice is to use the flash recovery area as your only redo log archiving destination. Leave the other locations blank to store your archived logs in the flash recovery area only.
Click Apply to save your changes.
If your database was not previously running in ARCHIVELOG mode, you are prompted to restart your database so that the switch to ARCHIVELOG mode can take effect.
Click Yes to indicate that you want to restart the database.
The Restart Database:Specify Host and Target Database Credentials page appears.
Enter your credentials and click OK.
The Restart Database:Confirmation page appears.
Click Yes to begin the restart process.
Make a consistent (that is, offline) backup of your whole database immediately after switching your database into ARCHIVELOG mode.
Caution:
Backups from before the switch to
ARCHIVELOG mode cannot be used to restore and recover the database to a point in time after the switch. Thus, if you do not immediately take a backup after switching, you are running your database without a backup.
See "Performing and Scheduling Backups with Enterprise Manager" for more details on offline database backups.
Assuming you have a flash recovery area configured and are running in ARCHIVELOG mode, you can configure a number of settings and policies that determine how backups are stored, which data is backed up, and how long backups are retained before being purged from the flash recovery area. You can also configure settings to optimize backup performance for your environment. This section provides information on concepts underlying the available settings, and information on how to change them through Enterprise Manager.
The settings on the Device property page of the Backup Settings page affect how backups will be written to disk and to tape. For disk-based backups, you can configure the default format for storing backups, the location on disk where backups are stored, and whether backup tasks are run in parallel for improved performance.
Database backups created by RMAN can be stored in one of two forms: image copies or backup sets.
Image copies are exact byte-for-byte copies of the files they back up. You can create an image copy by copying a file at the host operating system level. Unlike copying files at the operating system level, however, creating image copy backups through RMAN or Enterprise Manager records those copies in the RMAN repository. This technique allows RMAN to use these copies during database restore and recovery. RMAN can only use files in restore operations if they are recorded in the RMAN repository. RMAN can only create image copies on disk.
Backup sets are logical entities containing backups produced by RMAN backup commands. Individual RMAN BACKUP commands can produce one or more backup sets. Each backup set consists of several physical files called backup pieces. A backup piece stores the backup of one or more database files in a compact format that can only be manipulated by RMAN. Backup pieces cannot be usefully manipulated individually; they can only be accessed as part of backup sets. Backup sets can be created on disk or media management devices such as tapes. Backup sets are the only form in which backups can be written to a media manager.
RMAN depends on server sessions, processes that run on the database server, to perform backup and restore tasks. Each server session in turn corresponds to an RMAN channel, representing one stream of data to or from a backup device. 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 exploitation of parallelism can greatly increase performance on backup and recovery tasks. For more conceptual material on channels and parallelism in RMAN backups, see Oracle Database Backup and Recovery Advanced User's Guide.
From the Database Home page, click Maintenance. In the Backup/Recovery section, choose Backup Settings.
The Backup Settings page contains three property pages: Device, Backup Set, and Policy. The settings you pick here are defaults which can apply to all backup jobs. When performing individual backup tasks, you can override these defaults.
The Device property page is shown first by default. Review the following fields under the Disk Settings section:
Parallelism
For now, set this value to 1. Later, when you have had time to review the information in Oracle Database Backup and Recovery Advanced User's Guide on parallelism and performance in RMAN, you may want to change this value.
Disk Backup Location
Leave this blank to direct backups to the flash recovery area.
Disk Backup Type
Make sure that Backup Set is selected. One advantage to backing up Oracle datafiles to backup sets is that RMAN uses unused block compression to save space in backing up datafiles. Only those blocks in your datafiles that have been used to store data are included in the backup set.
You can also provide the host credentials for the backup. Enter credentials as described in "Credentials for Performing Oracle Enterprise Manager Backup and Recovery".
After these settings are filled in, you can click Test Disk Backup to make sure the credentials and backup location are correct.
The settings on the Backup Set property page should not be altered at this time.
From the Backup Settings page, click Policy. On the Policy property page, you can set the backup policies governing control file and SPFILE backups, tablespaces to exclude from whole database backup, and the backup retention policy.
Check the following options in the Backup Policy page:
Automatically backup the control file and server parameter file (SPFILE) with every backup and database structural change
The SPFILE and control file are critical to the operation of your database and RMAN and are also relatively small compared to typical datafiles. Backing them up frequently imposes relatively little storage overhead. Leave the Autobackup Disk Location field blank so that the autobackups are sent to the flash recovery area.
Optimize the whole database backup by skipping unchanged files such as read-only and offline datafiles that have been backed up
This option saves space in the flash recovery area.
Enable block change tracking for faster incremental backups
This option takes advantage of the block change tracking feature of Oracle, which substantially improves performance of incremental backups at a small cost of overhead during normal operations.
You can specify a list of names for tablespaces to exclude from a backup. For example, you do not need to include read-only tablespaces in every backup. For now, make sure the list of excluded tablespaces is empty so that all tablespaces are backed up.
You can choose among the following forms of retention policy:
Retain All Backups
This option keep backups in the flash recovery area until you explicitly delete them. This option amounts to no retention policy at all.
Retain backups that are necessary for a recovery to any time within the specified number of days (point-in-time recovery)
This option enables a recovery window-based retention policy.
Retain at least the specified number of full backups for each datafile
This option enables a redundancy-based retention policy.
For now, choose the recovery window-based retention policy, with a recovery window of 31 days.
Verify that the Host Credentials section at the bottom of the page contains proper credentials. Click OK to save the new settings.
