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.