|
Step 9 - Configuring Your Database for Basic Backup and Recovery
|
Learn Oracle - Configuring Your Database for Basic Backup and Recovery
To take maximum advantage of Oracle’s features for automatic managing backup and
recovery, configure your database as follows:
Use a flash recovery area, to automate storage management for most
backup-related files.
Run your database in ARCHIVELOG mode, so that Oracle DBA 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 archive log destination for your database.
Oracle DBA 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. Finally, Oracle DBA should make a record of two pieces of
information about your database: the DBID and the DB_UNIQUE_NAME. This
information is needed in some disaster recovery situations, such as restoring a lost
database control file.
Planning Space Usage and Location for the Flash Recovery Area
To better protect your data, put the flash recovery area on a separate disk from the
working set files of your database, to avoid the disk being 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 log files, and your recovery objectives, which dictate what kinds of backups Oracle DBA
take, when Oracle DBA take them, and how long Oracle DBA must keep them.
Retention Policy and the Flash Recovery Area
Space management in the flash recovery area is governed by a backup retention policy.
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 a recovery window.
Under a redundancy-based policy, the flash recovery area considers a backup of a file
to be obsolete only when a specified number of more recent backups of that file are
present. For example, if Oracle DBA specify a retention policy requiring two backups of each
file be kept, and make backups nightly starting on a Monday night, then 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, Oracle DBA specify a time interval measured in days,
and 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, if Oracle DBA 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 since that backup.
A redundancy-based retention policy makes it easier to predict space usage in the
flash recovery area, but do not allow Oracle DBA 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, even a short recovery window combined with a poorly designed
backup strategy can cause unexpectedly high space requirements. (A reasonable
backup strategy would include more frequent datafile backups.) Oracle recommends
the use of a recovery-window-based backup retention policy as part of your backup
strategy.
Even after they are obsolete, files 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.
Sizing the Flash Recovery Area
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, described
in "Incremental Backups of Datafiles" on page 9-10, add enough space to the flash
recovery area to accommodate these files as well. If Oracle DBA can move some backups to
tape, Oracle DBA can reduce the size of the flash recovery area somewhat, although retrieving
those files from tape will cause longer database restore and recovery times.
Credentials for Performing Oracle Enterprise Manager Backup and Recovery
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. Two sets of
credentials are required: the Oracle user you use when Oracle DBA log in to Enterprise
Manager, and the host operating system user whose credentials Oracle DBA provide when
performing backup and recovery tasks. The host operating system credentials are used
when RMAN is started behind the scenes, to actually perform the tasks you specified
or scheduled through Enterprise Manager.
If Oracle DBA log in to Enterprise Manager with SYSDBA privileges, any valid host operating
system user who has execute permission for the RMAN command line client will
suffice for scheduling and running RMAN tasks.
For those tasks where host operating system credentials are required, a Host
Credentials form where they can be entered appears at the bottom of the page used to
perform the task. This form always includes a checkbox labelled Save as Preferred
Credential. If you check this box before performing your action, the credentials you
provide will be stored persistently for the currently logged-in Oracle user, and re-used
whenever you log in as that user and perform operations requiring host credentials. (If
the database is down, however, as is required for some database recovery operations,
Oracle DBA will have to enter host credentials manually.)
Configuring the Flash Recovery Area and ARCHIVELOG Mode
It is possible to configure a flash recovery area and set the database archiving mode
when first creating the database. If you did not perform these tasks at database
creation time, however, you can add them to an existing database with the procedure
described here.
Configuring the flash recovery area and setting ARCHIVELOG mode requires the
following steps:
1. Under the host operating system, create a directory to hold the flash recovery area.
Make sure that the permissions on this directory allow Oracle to create files here.
2. From the Database Home page, go to the Maintenance page. On this page, under
the Backup/Recovery heading, select Configure Recovery Settings. The
Configure Recovery Settings page appears.
3. Under the Flash Recovery Area heading, 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 make these changes take effect.
4. Under the Media Recovery heading, check ARCHIVELOG Mode if it was not
already checked. Below the ARCHIVELOG Mode checkbox is a list of up to ten
possible log archiving locations. Enter USE_DB_RECOVERY_FILE_DEST as one of
the destinations, to specify the flash recovery area as a destination. For ease of
database management, the best practice is to use the flash recovery area as your
only redo log archiving destination. Oracle DBA can, however, specify other locations on
disk, filling them in starting with the first one.
5. Click Apply to make these changes take effect.
Configuring Backup Settings
Assuming Oracle DBA have a flash recovery area configured and are running in ARCHIVELOG
mode, Oracle DBA can configure a number of settings and policies that determine how
backups are stored, which data is backed up, how backups perform, and how long
backups are retained before being purged from the flash recovery area. There are also
settings Oracle DBA can configure to improve backup performance. This section provides
change them through Enterprise Manager.
Understanding Backup Device Settings for Disk
The settings available on the Device property page of Configure Backup Settings 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.
Backup File Types: Image Copies, Backup Pieces, and Backup Sets 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. However, unlike
copying files at the operating system level, creating image copy backups through
Recovery Manager or Enterprise Manager causes a record of those image copies to be
made in the RMAN repository. This 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.
Backup sets are logical entities containing the results of running various backup tasks.
In fact, a backup set consists of several physical files called backup pieces. Backup
pieces use an Oracle-proprietary format to store the contents of one or several files
from a backup job. Backup pieces cannot be meaningfully manipulated individually;
they can only be accessed as part of backup sets. When datafiles are backed up into
backup sets, data blocks that have not yet been used to store data are not written into
the backup pieces, saving space. This is referred to as unused block compression.
Unused block compression is fundamental to how backup sets are created, and cannot
be disabled.
An additional binary data compression algorithm can be applied during the writing of
backup sets to save more space, at some cost in performance. Using binary
compression for backup sets stored on disk is recommended if conserving disk space
is more important than backup speed.
Oracle backups to disk can be saved as image copies or backup sets. Image copy
backups can only be created on disk. Backups to tape and similar media management
devices must be stored as backup sets.
Parallelism and RMAN Backups RMAN depends upon server sessions, processes that run
on the database server, to actually 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, the use of multiple channels
and server sessions to carry out the work of one backup or recovery task. If a task can
be usefully executed in parallel on your hardware, Oracle DBA can set the level of parallelism
to use on that task. Oracle DBA can also set a default level of parallelism to use when working
with specific devices. Proper exploitation of parallelism can greatly increase
performance on backup and recovery tasks.
The Configure 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 Oracle DBA have had time to review
the information in Oracle Database Backup and Recovery Advanced User's Guide on
parallelism and performance in RMAN, Oracle DBA may want to change this value.
Disk Backup Location: Should be 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.
Oracle DBA can also provide the host credentials for the backup. Enter a username and
password for a host operating system account that is a member of the DBA group.
After these settings are filled in, Oracle DBA 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.
Configuring Backup Policy Settings
From the Backup Settings page, choose the Policy property page. On this page, Oracle DBA
can set the backup policies governing control file and SPFILE backups, tablespaces to
exclude from whole database backup, and the backup retention policy.
Configuring Backup Policies For now, check the box to Automatically back up 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 disk space overhead. Leave the
Autobackup Disk Location field blank, so that the autobackups are sent to the flash
recovery area.
Check the option to Optimize the whole database backup by skipping unchanged
files such as read-only and offline datafiles that have been backed up. This will save
space in the flash recovery area.
Check the Enable block change tracking for faster incremental backups box to take
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.
Configuring Exclusions from Backup Oracle DBA can list tablespaces to exclude from backup. If,
for example, you have a read-only tablespace, you do not need to back it up. For now,
make sure this list is empty, so that all tablespaces are backed up.
Configuring Backup Retention Policy You can choose between three forms of retention
policy:
Retain All Backups (in effect, no retention policy at all, so that all backups are
kept in the flash recovery area until Oracle DBA explicitly delete them)
Retain backups that are necessary for a recovery to any time within the specified
number of days (point-in-time recovery) for a recovery window-based retention
policy
Retain at least the specified number of full backups for each datafile for 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. Then click OK to save the new settings.
Recording Your DBID and DB_UNIQUE_NAME
If you lose your database control file or SPFILE, Enterprise Manager can restore them
from backup, as long as you can provide the DB_UNIQUE_NAME and DBID for your
database.
To find out your DB_UNIQUE_NAME, from the database home page, from the
Administration page, under Instance, click All Initialization Parameters. On the
Current property page, for Filter enter DB_UNIQUE_NAME and click Go. The resulting
page displays a row with DB_UNIQUE_NAME listed in the Name column, and the DB_
UNIQUE_NAME value for your database in the Value column.
To find out your DBID, from the database home page, select the Administration page,
then under Storage, click Controlfiles, then select the Advanced property page. The
Database ID field contains the value of the DBID.
Record these two pieces of information offline in case they are needed for disaster
recovery.
|
|
|
