Oracle RMAN 11g Backup and Recovery (49 page)

Chapter 3: RMAN Setup and Configuration
97

RMAN> Configure encryption algorithm 'AES128';

using target database control file instead of recovery catalog

new RMAN configuration parameters:

CONFIGURE ENCRYPTION ALGORITHM 'AES128';

new RMAN configuration parameters are successfully stored

Configuring Archive Log Deletion Policies

You can configure RMAN to manage your archived redo log deletion policy for you. By default, Oracle applies the configured backup retention policy to the archived redo logs. In Oracle Database 11
g,
you can also configure a separate deletion policy for archived redo logs. This policy will get applied to archived redo logs in both the FRA and in those stored outside the FRA.

Only those in the FRA will be removed by Oracle, however. If logs are in the FRA, Oracle will try to keep them as long as possible, only removing them when additional space is required. If you are using a non-FRA location, then you will need to use the
delete obsolete
or
delete archivelog
command to remove archived redo logs marked as obsolete. In this example we use the
configure
command to configure an archive log deletion policy. In this case, all archived redo logs that are backed up three times will be eligible for removal:

RMAN> Configure archivelog deletion policy to backed up 3 times to device type disk; new RMAN configuration parameters:

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 3 TIMES TO DISK;

new RMAN configuration parameters are successfully stored

In versions of Oracle before Oracle Database 11
g,
the archived redo log deletion policy applied only to archived redo logs being applied on a standby database. In these versions, you could configure RMAN to mark archived redo logs as eligible for removal after they have been applied to a mandatory standby database by using the
configure archivelog deletion policy to applied on
standby
command. In this case, once the archived redo log has been successfully applied to a mandatory standby database location, it is eligible for removal from the FRA by Oracle. This functionality remains in Oracle Database 11
g
and later.

If You Are Using Shared Servers

If you are using Oracle’s Shared Servers option (known as Multi-Threaded Server, or MTS, in previous Oracle versions), then you have to configure a dedicated server for use with RMAN

because RMAN cannot use a Shared Servers session to connect to the database. If you are using a Shared Servers architecture, refer to Chapter 5 of the
Oracle Database Backup and Recovery
Advanced Users Guide (11
g
Release 2)
for more information on how to configure RMAN for use with the Oracle Database 11
g
Shared Servers option.

Essentially, you must configure a dedicated connection in Oracle Net for your server by using the
SERVER=dedicated
syntax, as shown in this example (note that Oracle Net configurations vary greatly, so what may be required of you might differ):

Rob1 ded

(DESCRIPTION

(ADDRESS (PROTOCOL tcp)(HOST robpc)(port1521))

(CONNECT DATA (SERVICE NAME rob1 ded)(SERVER dedicated)))

98
Part II: Setup Principles and Practices

Summary of RMAN Configuration Tasks

We have thrown a great deal of information at you in this chapter. The following summarizes the tasks that you will need to perform to get set up to do database backups with RMAN. We also provide a few suggestions along the way. Each of the steps listed here has detailed instructions included earlier in this chapter:

1.
Determine whether you wish to run the database in ARCHIVELOG mode or NOARCHIVELOG mode. Configure the database accordingly. In most cases, we would recommend ARCHIVELOG mode since it provides a large number of recovery options.

2.
We recommend that you configure and use the FRA.

3.
Set up a separate database user account (not sys) for use with RMAN.

4.
In the database parameter file, set the CONTROL_FILE_RECORD_KEEP_TIME parameter to a number of days equivalent to or greater than the number of days you wish to retain database backups. Retention is one area within RMAN that can have “gotchas.” Make sure that your retention policies in RMAN, the CONTROL_FILE_RECORD_KEEP_TIME

parameter, and any retention policies established by your tape administrators (if you are backing up to tape) are aligned.

5.
If you are using shared servers, set up a dedicated server address for RMAN to connect to.

6.
Using RMAN, connect to the target database to ensure that the database is set up correctly (error messages will appear if your RMAN account is not correctly set up).

7.
Use the
configure
command to establish your default RMAN values. In particular, consider configuring the following:

■

Configure the default degree of parallelism for tape or disk backups. Set it to a default value equivalent to the number of disks or tape drives that you will be backing up to. If you are backing up to a SAN with many disk drives, consider using parallel channels to back up to those disk devices.

■

Configure automatic channels and device types. The number of channels that you configure should equal the degree of parallelism that you have configured. Configure as many channels as you have individual devices, and configure the same number of channels as you have.

■

Configure automated control file/database parameter file autobackups.

■

If you own ASO (Advanced Security Option, which is the license required to use encryption), then configure automated database backup encryption.

8.
Configure the retention policy as required. Make sure this retention policy is in sync with any other retention policies, such as those associated with tape management systems.

Also, if required, consider retention criteria for your archived redo logs.

9.
Configure RMAN for control file and SPFILE automatic backups.

10.
Before you use it for production database backups, test your RMAN configuration by doing a backup and recovery as demonstrated in later chapters.

Chapter 3: RMAN Setup and Configuration
99

Other Backup and Recovery Setup and

Configuration Considerations

Finally, let’s consider the other backup and recovery implications of your database. RMAN will not back up certain things that you need to consider as a part of your overall backup and recovery strategy planning. These include such things as the base Oracle RDBMS software and the parameter files (tnsnames.ora, names.ora, sqlnet.ora, and so on). You need to make plans to back up and recover these files as a part of your overall backup and recovery planning.

You also need to consider your disaster planning with regard to RMAN and non-RMAN

backups. How will you protect these backups from flood, fire, and earthquake? In advance is a very good time to consider these questions, not when the fire is burning two flights below!

Summary

Whew! We have covered a great deal of ground in this chapter, and, indeed, there are several things you need to do before you start using RMAN. First, we described how to set up the database in ARCHIVELOG mode if that is what you wish to do. Next, we looked at the RMAN

command line and at how to configure your database for use with RMAN, including setting up the password file and configuring a user account for use with RMAN. We also looked at configuring RMAN default settings. We strongly suggest you take advantage of this feature in RMAN, because it can make your life much easier. Finally, we provided you with a summary of RMAN configuration tasks and talked about other backup and recovery considerations.

This page intentionally left blank

CHAPTER

4

Media Management

Considerations

102
Part II: Setup Principles and Practices

he RMAN utility in Oracle Database 11
g
focuses on the best way to leverage disk backups as the media recovery solution. With the price of disks falling, massive storage area networks (SANs) have found a permanent place in many data centers.

T
With the business evolving toward cheaper and larger disks, upgrades in RMAN

functionality (such as the flash recovery area) were implemented to make best use of the available storage space.

It’s a logical progression for the RMAN backup utility, and, of course, writing to disk is something that the Oracle Database is extremely good at. So, anytime it gets to leverage its disk-writing muscle, the RDBMS will do so for performance improvements.

But, for many customers, the world of unlimited disk storage has not arrived. For many, the size of the database, or its location, keeps it from being backed up to disk. Or, there still may be a business requirement to make a copy of the data and archive it offsite. So, what does RMAN do if it needs to write to good, old-fashioned tape?

Tape backups of the Oracle database require third-party assistance. This is primarily due to the disparate nature of the different sequential media subsystems that are on the market and that are used every day. Instead of trying to employ different system calls for each different type of tape device, RMAN’s development team decided to employ those software vendors that already earn a living by selling products that can read and write from tape.