Oracle RMAN 11g Backup and Recovery (34 page)

46
Part I: Getting Started with RMAN in Oracle Database 11
g
Unused block compression is automatically used, but it cannot be used for all blocks in a database. There are architectural limits to the approach, and it requires the following be true:

■ The backup requested is a full or level 0 incremental backup.

■ The backup is going to disk (or Oracle Secure Backup).

■ COMPATIBLE init parameter is set to 10.2 or higher.

■ There are no guaranteed restore points for the database.

■ The datafile is locally managed (that is, the space management info is in the file header, not in the data dictionary).

It is this final element, locally managed datafiles, that allows RMAN to get the bitmap info it requires for successful unused block compression, as it does not require a round-trip through the (perhaps unavailable) data dictionary.

Binary Compression

In version 10
g,
RMAN finally made available a version of whitespace compression, as would be done by a ZIP utility. This provides actual compression of the backed up blocks themselves. In addition, the new block-change tracking file allows RMAN to skip some blocks during backup without reading them into a memory buffer—so incremental backups begin to save time, if the change tracking is turned on. For more on compression and block-change tracking, see the full coverage in Chapter 9.

In 11
g
R2, you can enable Oracle Advanced Compression, which provides three different levels of compression, so you can match the binary compression to your environment. The levels are High, Medium, and Low: High, for bandwidth-bound environments where limiting access to the network resources is the highest priority; Medium, for a combination of compression ratio to CPU utilization; and Low, where CPU utilization is the limiting factor over network bandwidth or total size of the backup piece.

Backup Performance with Block-Level Backup

Block-level backup also provides performance gains from the perspective of redo generation. As you learned in Chapter 1, if you use old-school hot backup methodology, the amount of redo that you generate while you are running with a tablespace in hot backup mode can sometimes grow exponentially. This causes excess redo log switching, checkpoint failure, and massive amounts of archive log generation that can further cascade into space management challenges in your log archive destination.

RMAN, on the other hand, does not require hot backup mode, because it does not need to guarantee block consistency during a backup. RMAN’s access to the data block allows it to coordinate with DBWR processes writing dirty buffers, and it can wait until the block is consistent before it reads the block into memory. So, blocks aren’t being dumped to redo, and we always have consistent blocks in our backup.

RMAN does require ARCHIVELOG mode, of course. In fact, RMAN will not allow you to back up a datafile while the database is open unless you are in ARCHIVELOG mode. It gives you the following polite error:

ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode

Chapter 2: Introduction to the RMAN Architecture
47

RMAN also leverages block-level backups to provide an often-overlooked but extremely useful recovery option: block media recovery. Now, if you were to receive the stomach-turning

“ora-1578: block corruption detected” error, instead of recovering the entire file and performing recovery, RMAN can simply recover the bad block and perform recovery, meaning the rest of the data in the datafile is available during the recovery. More information on this appears in Chapter 12.

This just touches the surface of all the benefits you get from RMAN, but you get the point.

The payoff is enormous when RMAN is utilized for block-level backups. The rest of this book is dedicated to utilizing this to your advantage.

RMAN in Memory

RMAN builds buffers in memory through which it streams data blocks for potential backup. This memory utilization counts against the total size of the PGA and, sometimes, the SGA. There are two kinds of memory buffers.
Input buffers
are the buffers that are filled with data blocks read from files that are being backed up.
Output buffers
are the buffers that are filled when the memory-to-memory write occurs to determine whether a particular block needs to be backed up.

When the output buffer is filled, it is written to the backup location. The memory buffers differ depending on whether you are backing up to or restoring from disk or tape. Figure 2-3 illustrates input and output buffer allocation. It illustrates a backup of two datafiles being multiplexed into a single backup set.

FIGURE 2-3
Input and output buffers in memory

48
Part I: Getting Started with RMAN in Oracle Database 11
g
Input Memory Buffers

When you are backing up the database, the size and number of input memory buffers depend on the exact backup command being executed. Primarily, they depend on the number of files being multiplexed into a single backup.
Multiplexing
refers to the number of files that will have their blocks backed up to the same backup piece. To keep the memory allocation within reason, the following rules are applied to the memory buffer sizes based on the number of files being backed up together:

■ If the number of files going into the backup set is four or less, then RMAN allocates four buffers per file at 1MB per buffer. The total will be 16MB or less.

■ If the number of files going into the backup set is greater than four, but no greater than eight, then each file gets four buffers, each of 512KB. This ensures that the total remains at 16MB or less.

■ If the number of files being multiplexed is greater than eight, then RMAN allocates four buffers of size 128KB. This ensures that each file being backed up will account for 512KB

of buffer memory.

Bear in mind that these memory amounts are on a per-channel basis. So, if you allocate two channels to back up a database with 32 datafiles, for instance, then RMAN will load-balance the files between the two channels and may not end up with 16 files per channel. If some files are significantly larger than others, you may end up with only 8 files going into one backup set and 24 files going into the other. If this were the case, then the buffers for the first channel with 8 files would allocate 16MB of memory for input buffers (four buffers multiplied by 512KB each, multiplied by 8 files), and the second channel would allocate 12MB of memory buffers (512KB per file multiplied by 24 files).

You can use the following query to monitor the size of buffers on a per-file basis while the backup is running:

SELECT set count, device type, type, filename,

buffer size, buffer count, open time, close time

FROM v$backup async io

ORDER BY set count,type, open time, close time;

Output Buffers When Backing Up to Disk

In addition to input buffers, RMAN allocates output buffers, depending on what the output source is. If you are backing up to disk, then RMAN allocates output buffers that must fill up with data blocks from the input buffers before being flushed to the backup piece on your file system. Per channel, there will be four output buffers, each of which is 1MB. So, the memory footprint per channel will always be 4MB.

Output Memory Buffers When Backing Up to Tape

Memory allocation is different when backing up to tape, to account for the slower I/O rates that we expect from tape devices. When you are backing up to or restoring from tape, RMAN

allocates four buffers per channel process, each of which is 256KB, so that the total memory footprint per channel is 1MB.

Chapter 2: Introduction to the RMAN Architecture
49

Memory Buffers on Restore

Memory utilization during restore operations is slightly different than during backups. This is due to the fact that the roles are reversed: instead of reading from the datafiles and writing to the backup location, we are reading from the backup location and writing to the datafiles. During a restore from a disk backup, the input buffers will be 1MB, and RMAN will allocate four buffers per channel. When restoring from tape, RMAN allocates four input buffers with a size of BLKSIZE, which defaults to 256KB. The output buffers on restore are always 128KB, and there will be four of them per channel.

Multisection Backups and Memory

In 11
g,
Oracle introduced a new feature that allows RMAN to use multiple channels to back up a single, large file. This means that the memory input/output buffer conversation earlier still holds true, but the buffers are per channel, not necessarily per file. So, each channel opens the four input buffers for each section of the file it will be backing up. The output buffers remain the same as the preceding algorithm per backup piece.

RMAN Memory Utilization: PGA vs. SGA

Backups to disk use PGA memory space for backup buffers, which is allocated out of the memory space for the channel processes. If your operating system is not configured for native asynchronous I/O, then you can utilize the parameter DBWR_IO_SLAVES to use I/O slaves for filling up the input buffers in memory. If this parameter is set to any non-zero value, RMAN automatically allocates four I/O slaves to coordinate the load of blocks into the input memory buffer. To coordinate this work, RMAN must utilize a shared memory location. So, the memory buffers for disk backups are pushed into the shared pool, or the large pool if one exists.

Memory for tape output buffers is allocated in the PGA, unless you are using tape I/O slaves.

To enable tape I/O slaves, you set the init.ora parameter BACKUP_TAPE_IO_SLAVES to TRUE.

This can be done dynamically and set in the SPFILE if you desire. When this is set to TRUE, RMAN creates a single slave process per channel to assist with the backup workload. To coordinate this work, RMAN pushes the memory allocation into the SGA.

If either of these I/O slave options is configured, memory will be pulled from the shared pool area in the SGA, unless you have a large pool configured. If you do not have a large pool configured, and you expect to use I/O slaves, we highly recommend that you create a large pool with a size based on the total number of channels you expect to allocate for your backups, plus 1MB for overhead. Allocating how many channels makes sense? Chapter 16 will tell you. If you already have a large pool for Shared Servers (formerly MTS), JDBC connection pooling, or because you have PARALLEL_AUTOMATIC_TUNING set to TRUE, then increase the size of the pool to account for the RMAN memory buffers.

This introduction to the RMAN memory architecture does not include much information on tuning your system to cope with RMAN backups. Obviously, a resource hit takes place while RMAN is running. In fact, you can tune RMAN to use more or less resources, depending on your needs. Chapter 16 discusses how to do this in greater detail.

One last note on memory utilization: If you are backing up to tape, you will be using a media management server product. If you are running your media manager from the same system as your target database, you will need additional system resources for the tape subsystem. Be sure to factor this in when tuning for backups.