Database Reference
In-Depth Information
For a more deterministic backup volume another option is available. Instead of specifying a time window for
when you want to be able to perform a point-in-time-recovery you could specify the number of backups you want to
keep. The default RMAN retention policy is to have one backup available, which is not very realistic. Depending on
your company's requirements and enterprise Service Level Agreements you should increase the number of backups
to a more sensible number. Your consolidation project's product manager is the best person to ask for advice. To
increase the number of backups to be preserved you need to issue the following command:
RMAN> configure retention policy to REDUNDANCY X;
As a direct result, X backups will be preserved; backup X+1 is considered obsolete by RMAN. If you are using a
Fast Recovery Area then the retention policy can help you when space pressure arises. Careful though: unplanned
backups can cause a really important backup to be declared obsolete and removed!
If backups (or flashback logs for that matter) are considered obsolete by the retention policy they can
automatically be purged from the FRA should it come under space pressure. This can be quite useful when you need
space for additional archived redo logs. On the other hand, it is something to know about. You can see the impact if
changing the retention policy quite clearly in the view v$recovery_area_usage, column percent_space_reclaimable.
If a backup falls outside the limits set by the retention policy then it will be considered obsolete. An obsolete
backup can be removed by the media manager. In the context of RMAN it is important that the media manager lets
RMAN manage the removal of backups. Removing backups outside of RMAN using operating system commands
or—if stored on tape—letting the media manager remove them causes problems with RMAN as it does not know that
a backup no longer exists. A backup that has been removed outside of RMAN is considered expired . Expired backups
can become a problem when you need to rely on them to restore a database. Nothing is worse than being in the
middle of a database restore operation when the backups you so desperately need are reported to be missing. The
RMAN crosscheck command can be used at regular intervals to test if a backup is actually available. If it is not, it will
be marked as expired in the catalog or control file.
Defining how and where backups should be stored by default
By default backups are stored on disk using the Fast Recovery Area if possible. The “CONFIGURE DEFAULT DEVICE
TYPE TO DISK” setting in Listing 11-1 shows this. If you wish to change the default behavior and switch to tape
backups, you can do so by issuing the “ configure default device type to sbt ” command. Bear in mind though
that tape backups require additional configuration, both on the operating system as well as within Oracle. In most
cases the system administrator will install the required software packages for interaction with the tape library. It often
is the backup team's responsibility to configure the media manager to allow communication between the database
server and the tape library. Finally the database administrator will be given the necessary information to be supplied
for the channel allocation. A channel in Recovery Manager is responsible for reading data into the server process's
PGA and writing it to the output device: disk or tape. Unlike in the first versions of RMAN you no longer have to
explicitly allocate channels for a command to succeed. A well-balanced design however will require you to allocate
channels to find a compromise between satisfying the backup window and throughput to the array or tape library.
It is entirely possible to send more data down the pipe than the other end can digest!
Generally speaking multiple channels will back your database up quicker if you are not overwhelming the server
and/or backup destination. During the initialization phase outstanding work is distributed to each channel. A great
enhancement came with Oracle 11g, where RMAN can use multiple channels to work on a single file. Why is that
useful? Using the default backup mode it was possible for a multi-channel backup channel to finish while the other
one was still working on an enormous bigfile tablespace for quite a while. Using the then-new “section” keyword you
can back up datafiles or the whole database using sections of a specific size. In the author's opinion this makes the
most sense with databases made up of many very large bigfile tablespaces or any other system with a mix of small and
comparatively large data files. Alternatively you could back up individual data files using the section size command as
shown here. Two channels are manually allocated to back up datafile 1 in 250M chunks.
 
Search WWH ::




Custom Search