Pro Oracle Database 11g Administration (76 page)

accesses information in the control file and passes that to the RMAN server processes. The DBMS_BACKUP_RESTORE package performs most of RMAN’s work.

For example, this package creates the system calls that direct the channel processes to perform B&R operations.

Memory buffers (PGA or SGA):
RMAN uses a memory area in the program global area (and sometimes in the system global area) as a buffer when reading from datafiles and copying subsequent blocks to back up files.

Auxiliary database:
A database to which RMAN restores target database datafiles for the purpose of duplicating a database, creating a Data Guard standby database, or performing a database point-in-time recovery.

Channel(s):
Oracle server processes for handling I/O between files being backed up and the backup device (disk or tape).

Backups and backup sets:
When you run an RMAN BACKUP command, it creates one or more backup sets. A
backup set
is an internal RMAN construct that logically groups backup piece files. You can think of the relationship of a backup set to a backup piece as similar to the relationship between a tablespace and a datafile. One is a logical construct, and the other is a physical file.

Backup piece file:
RMAN binary backup files. Each logical backup set consists of one or more backup piece files. These are the physical files that RMAN creates on disk or tape. They’re binary, proprietary format files that only RMAN can read or write to. A backup piece can contain blocks from many different datafiles. Backup piece files are typically smaller than datafiles because backup pieces only contain blocks that have been used in the datafiles.

Image copy:
A type of backup in which RMAN creates identical copies of a datafile, archive-redo log file, or control file. Image copies can be operated on by OS utilities such as the Linux cp and mv commands. Image copies are used as part of incrementally updated image backups. Sometimes it’s preferable to use image copies over backup sets if you need to be able to restore quickly.

Recovery catalog:
An optional database schema that contains tables used to store metadata information regarding RMAN backup operations. Oracle

strongly recommends using a recovery catalog, because it provides more options for B&R.

Media manager:
Third-party software that allows RMAN to back up files directly to tape. Backing up to tape is desirable when you don’t have enough room to back up directly to disk or when disaster-recovery requirements necessitate a backup to storage that can be easily moved offsite.

Fast-recovery area:
An optional disk area that RMAN can use for backups (formerly known as the flash recovery area). You can also use the FRA to multiplex control files and online-redo logs. You instantiate a fast recovery with the database initialization parameters DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST.

459

CHAPTER 17 ■ CONFIGURING RMAN

Snapshot control file:
RMAN requires a read-consistent view of the control file when either backing up the control file or synchronizing with the recovery catalog (if it’s being used). In these situations, RMAN first creates a temporary copy (snapshot) of the control file. This allows RMAN to use a version of the control file that is guaranteed not to change while backing up the control file or synchronizing with the recovery catalog.

You can make several types of backups with RMAN:

Full backup:
All modified blocks associated with the datafile are backed up. A full backup doesn’t refer to backing up the entire database. For example, you can make a full backup of one datafile.

Incremental level 0 backup:
Backs up the same blocks as a full backup. The only difference is that you can use a level 0 backup with other incremental backups, whereas you can use a full backup that way.

Incremental level 1 backup:
Backs up only blocks that have been modified since the previous backup. Level 1 incremental backups can be either differential or cumulative. A
differential
level 1 backup backs up all blocks that have been modified since the last level 0 or level 1 backup. A
cumulative
level 1 backup backs up all blocks that have changed since the last level 0 backup.

Incrementally updated backup:
First creates an image copy of the datafiles, after which subsequent backups are incremental backups that are merged with the image copy. This is an efficient way to use image copies for backups. Media recoveries using incrementally updated backups are fast because the image copy of the datafile is used during the restore.

Block-change tracking:
Database feature that keeps track of blocks that have changed in the database. A record of the changed blocks is kept in a binary file.

RMAN can use the contents of the binary file to improve the performance of incremental backups: instead of having to scan all modified blocks in a datafile, RMAN can determine which blocks have changed from the binary block-change tracking.

Now that you understand the RMAN architectural components and the types of backups you can make, you’re ready to start up RMAN and configure it for your environment.

Starting RMAN

To connect to RMAN, you need to establish the following:

• OS environment variables

• Access to a privileged operating-system account or a database user with SYSDBA privileges

The easiest way to connect to RMAN is to log on to the server where the target database resides and log in as the owner of the Oracle software (usually named oracle on Linux/Unix boxes). When you log in as oracle, you need to establish several OS variables before you can use utilities such as rman, sqlplus, and so on. Setting these required OS variables is covered in detail in Chapter 2.

At minimum, you need to set ORACLE_HOME and ORACLE_SID. Additionally, it’s convenient if the PATH

variable includes the directory ORACLE_HOME/bin. This is the directory that contains the Oracle utilities.

After you’ve established your OS variables, you can invoke RMAN from the OS as shown: 460

CHAPTER 17 ■ CONFIGURING RMAN

■
Note
If you want to connect remotely to RMAN via Oracle Net, you need to first implement a password file.

RMAN Architectural Decisions

If archiving is enabled for your database, you can use RMAN out of the box to run commands such as this to back up your entire target database:

$ rman target /

RMAN> backup database;

If you experience a media failure, you can restore all datafiles as follows: RMAN> shutdown immediate;

RMAN> startup mount;

RMAN> restore database;

After your database is restored, you can fully recover it:

RMAN> recover database;

RMAN> alter database open;

You’re good to go, right? No, not quite. RMAN’s default attributes are reasonably set for simple backup requirements. The RMAN out-of-the-box settings may be appropriate for small development or test databases. But for any type of business-critical database, you need to carefully consider items such as where the backups are stored, how long to store backups on disk or tape, which RMAN features are appropriate for the database, and so on. The following sections in this chapter walk you through many of the B&R architectural decisions that you need to consider when implementing RMAN in a production environment. RMAN has a vast and robust variety of options for customizing B&R; and typically, you don’t need to implement many of its features. However, each time you implement RMAN to back up a production database, you should think through each decision point and decide whether you require an attribute.

Table 17–1 summarizes the RMAN implementation decisions and recommendations. Each of the decision points in the table is elaborated on in subsequent sections in this chapter. Many DBAs will disagree with some of these recommendations; that’s fine. The point is that you need to consider each architectural aspect and determine what makes sense for your business requirements.

Table 17–1.
Overview of Architectural Decisions and Recommendations
Decision Point

Recommendation

1. Running the RMAN client remotely or locally

Run the client locally on the target database server.

2. Specifying the backup user

Use SYS unless you have a security requirement

that dictates otherwise.

3. Using online or offline backups

Depends on your business requirements. Most

production databases require online backups,

which means you must enable archiving.

462

CHAPTER 17 ■ CONFIGURING RMAN

Decision Point

Recommendation

4. Setting the archive-redo log destination and file

If you’re using an FRA, archive logs are written

format

there with a default format. I prefer to use the

LOG_ARCHIVE_DEST_N initialization parameter to

specifically set the location outside of the FRA.

5. Configuring the RMAN backup location and file

Depends on your business requirements. Some

format

shops require tape backups. If you’re using disk,

place the backup in the FRA or specify a location

via channel settings. I prefer not to use an FRA and

to explicitly specify the location and file format via

a CONFIGURE command.

6. Setting autobackup of the control file

Always enable autobackup of the control file.

7. Specifying the location of the autobackup of the

Either place it in the FRA or configure a location. I

control file

prefer to write the autobackup of the control file to

the same location as the database backups (usually

outside of the FRA).

8. Backing up archive-redo logs

Depends on your business requirements. For

many environments, I back up the archive-redo

logs on a daily basis with the same command I use

to back up the database.

9. Determining the location for the snapshot

Use the default location.

control file

10. Using a recovery catalog

Depends on your business requirements. For

many environments, I don’t use a recovery

catalog. Oracle recommends that you do use a

recovery catalog. If the RMAN retention policy is

greater than CONTROL_FILE_RECORD_KEEP_TIME, then

I recommend that you use a recovery catalog.

11. Using a media manager

Required for backing up directly to tape.

12. Setting the CONTROL_FILE_RECORD_KEEP_TIME

Usually, the default of seven days is sufficient.

Initialization Parameter

13. Configuring RMAN’s backup-retention policy

Depends on your database and business

requirements. For many environments, I use a

backup-retention redundancy of 1 or 2.

14. Configuring the archive-redo logs’ deletion

Depends on your database and business

policy

requirements. In many scenarios, applying the

backup-retention policy to the archive-redo logs is

sufficient (this is the default behavior).

463

CHAPTER 17 ■ CONFIGURING RMAN

Decision Point

Recommendation

15. Setting the degree of parallelism

Depends on the available hardware resources and

business requirements. For most production

servers, where there are multiple CPUs, I configure

a degree of parallelism of 2 or more.

16. Using backup sets or image copies

I prefer backup sets. Backup sets are usually

smaller and easier to manage.

17. Using incremental backups

Use incremental backups for large databases

where a small percentage of the database changes

between backups and where you want to conserve

on disk space.

18. Using incrementally updated backups

Use this approach if you require image copies of

datafiles.

19. Using block-change tracking

Use this to improve the performance of

incremental backups.

20. Configuring binary compression

Depends on your business requirements.

Compressed backups consume less space but

require more CPU resources (and time) for backup

and restore operations.

21. Configuring encryption

Depends on your business requirements.

22. Configuring miscellaneous settings

You can set many channel-related properties, such

as the backup-set size and the backup-piece size.

Configure as needed.

1. Running the RMAN Client Remotely or Locally

It’s possible to run the rman utility from a remote server and connect to a target database via Oracle Net: $ rman target sys/foo@remote_db

This allows you to run RMAN backups on disparate remote servers from one central location. When you run RMAN remotely, the backup files are always created on the target database server.