Oracle RMAN 11g Backup and Recovery (33 page)

42
Part I: Getting Started with RMAN in Oracle Database 11
g
The RMAN Server Processes

RMAN makes a client connection to the target database, and two server processes are spawned.

The primary process is used to make calls to packages in the SYS schema in order to perform the backup or recovery operations. This process coordinates the work of the channel processes during backups and restores.

The secondary, or shadow, process polls any long-running transactions in RMAN and then logs the information internally. You can view the results of this polling in the view V$SESSION_

LONGOPS:

SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,

ROUND(SOFAR/TOTALWORK*100,2) "% COMPLETE"

FROM V$SESSION LONGOPS

WHERE OPNAME LIKE 'RMAN%'

AND OPNAME NOT LIKE '%aggregate%'

AND TOTALWORK ! 0

AND SOFAR <> TOTALWORK

/

You can also view these processes in the V$SESSION view. When RMAN allocates a channel, it provides the session ID information in the output:

allocated channel: ORA DISK 1

channel ORA DISK 1:
sid=16
devtype DISK

The “sid” information corresponds to the SID column in V$SESSION. So you could construct a query such as this:

SQL> column client info format a30

SQL> column program format a15

SQL> select sid, saddr, paddr, program, client info

from v$session where sid 16;

SID SADDR PADDR PROGRAM CLIENT INFO

---------- -------- -------- --------------- ------------------------

16 682144E8 681E82BC RMAN.EXE rman channel ORA DISK 1

RMAN Channel Processes

In addition to the two default processes, an individual process is created for every channel that you allocate during a backup or restore operation. In RMAN lingo, the
channel
is the server process at the target database that coordinates the reads from the datafiles and the writes to the specified location during backup. During a restore, the channel coordinates reads from the backup location and the writing of data blocks to the datafile locations. There are only two kinds of channels: disk channels and tape channels. You cannot allocate both kinds of channels for a single backup operation—you are writing the backup either to disk or to tape. Like the background RMAN process, the channel processes can be tracked from the data dictionary, and then correlated with a SID at the OS level. It is the activity of these channel processes that gets logged by the polling shadow process into the V$SESSION_LONGOPS view.

Chapter 2: Introduction to the RMAN Architecture
43

RMAN and I/O Slaves

RMAN can utilize I/O slaves if they are configured on the target database. For the purposes of RMAN backups and restores, two kinds of slaves are used: disk I/O slaves and tape I/O slaves.

Disk I/O slaves
are configured using the parameter DBWR_IO_SLAVES. This parameter can be set to any number of values, and its primary use in life is to wake up extra DBWR slaves for disk writes when the dirty buffers are flushed to disk from the buffer cache. However, if this parameter is set to any non-zero value, be it 1 or 12 or 32, RMAN throws a switch that will automatically engage four I/O slaves per channel to assist with reading data blocks into RMAN

memory buffers. This is a nice feature, but it changes considerably the way in which RMAN

allocates memory. Using DBWR_IO_SLAVES is only important if your OS platform does not support native asynchronous I/O, or if you have disabled asynchronous I/O for the Oracle RDBMS. If you have asynchronous I/O enabled, then you do not need to use disk I/O slaves.

Tape I/O slaves
assist with server process access to the tape device. If you have the parameter BACKUP_TAPE_IO_SLAVES set to TRUE, then RMAN will allocate a single I/O slave per tape channel process to assist with writes to the tape location. Unlike disk I/O slaves, this parameter affects no part of the database other than RMAN tape backups. Because there is no native asynchronous I/O to tape devices, we recommend you set this parameter to TRUE. It will help keep your tape drives streaming, meaning better performance on backups and restores. Chapter 16 discusses tape streaming in more depth.

The SYS Packages Used by RMAN

The RMAN server process that coordinates the work of the channels has access to two packages in the SYS schema: DBMS_RCVMAN and DBMS_BACKUP_RESTORE. These two packages compose the entirety of the RMAN functionality in the target database.

SYS.DBMS_RCVMAN

DBMS_RCVMAN is the package that is used to access the tables in the control file and pass this information to RMAN so it can build backup and restore operations that accurately reflect the database schematics. This package is responsible for setting TIME operators and verifying checkpoint information in the datafile headers prior to running any operation. It also checks file locations and sizes, along with other information concerning node affinity (in a RAC environment) and disk affinity. This kind of information affects performance, and RMAN has automatic load-balancing and performance-enhancing algorithms that it runs through prior to building the actual backup/restore commands. Chapter 16 talks in depth about these performance gains. Stay tuned.

SYS.DBMS_BACKUP_RESTORE

SYS.DBMS_RCVMAN accesses the control file and verifies all the requisite information. It passes this information back to the RMAN server process, which can then create PL/SQL blocks based on code in the recover.bsq file. These PL/SQL blocks are made up of calls to the package DBMS_

BACKUP_RESTORE, the true workhorse of RMAN. DBMS_BACKUP_RESTORE is the actual package that creates system calls to back up datafiles, control files, and archived redo logs.

RMAN takes the information returned from DBMS_RCVMAN, divvies out the work among the channels based on the load-balancing algorithm, and then creates a series of calls to DBMS_

BACKUP_RESTORE.

44
Part I: Getting Started with RMAN in Oracle Database 11
g

It is the work of DBMS_BACKUP_RESTORE that you can track in V$SESSION_LONGOPS. It performs the backup and restore operations. In addition, it accesses the control file, but only in a very limited way. It accesses it to back it up (actually, it backs up the snapshot control file), and to write backup information to it after backups have completed. Once it has completed a backup set, it writes to tables in the control file the information about when the backup was taken, how long it took to complete, and the size and name of the backup.

RMAN Packages in the Kernel

Both of these RMAN packages are installed by default by running the catproc.sql script when the database is created. There is no way to omit them during database creation, and therefore they exist in every Oracle database since version 8.0.3. What this means to you is that no configuration by you is required for RMAN to work. You can run RMAN right now and start backing up your database.

These packages have another important trait: they are hard-coded into the Oracle software library files, so they can be called even when the database is not open. Most packages, as you know, would only be available when the database is open. However, RMAN can write calls to DBMS_BACKUP_RESTORE when the database instance is in nomount or mount mode. This is a critical element, and the reason is clear: we need to be able to back up and restore the database even when it is not open.

Which brings us to an interesting point: what state must the target be in if we are to connect to it using RMAN? Does the instance need to be started, or do we need to mount it, or must it be open? The answer is that RMAN can connect to the target database in any of these three states, but it must at least be in nomount mode (otherwise, there’s no
there
there!).

Backing Up the Data Block

As you learned in Chapter 1, even when you used advanced techniques for backups, the units you were backing up were files. The OS utility that ultimately made the backup was looking at the entire file and backing it up, and because of this, you had to go to extraordinary lengths to protect the integrity of the Oracle data blocks within the files. RMAN, however, is different.

Because RMAN is integrated into the RDBMS, it has access to your data at the same level that the database itself uses: the data block.

Block-level access is what distinguishes RMAN from any other backup utility, and even if you didn’t already know this, it’s why you are reading this book and implementing an RMAN backup strategy. This is an extremely powerful level of access that provides nearly all the benefits that you will get from using RMAN. It is because of this access that we can utilize the data block for more efficient backup and recovery.

The Data Block Backup Overview

Here’s how it works: RMAN compiles the list of files to be backed up, based on the backup algorithm rules. Based on the number of channels and the number of files being simultaneously backed up, RMAN creates memory buffers in the Oracle shared memory segment. This is typically in the Private Global Area (PGA), but there are circumstances that push the memory buffers into the Shared Global Area (SGA). The channel server process then begins reading the datafiles and filling the RMAN buffers with these blocks. When a buffer is full, it pushes the blocks from an input buffer into an output buffer. This memory-to-memory write occurs for each individual data block in the datafile. If the block meets the criteria for being backed up and the Chapter 2: Introduction to the RMAN Architecture
45

memory-to-memory write detected no corruption, then the block remains in the output buffer until the output buffer is full. Once full, the output buffer is pushed to the backup location—a disk or a tape, whichever it may be.

Once the entire set of files has been filtered through the memory buffers, the backup piece is finished, and RMAN writes the completion time and name of the backup piece to the target database control file.

The Benefits of Block-Level Backups

Memory-to-memory writes occur for each block that is moved from disk into memory. During this operation, the block can be checked for corruption. Corruption checking is one of the nicest features of RMAN, and we discuss it in more detail in Chapter 12. Be aware that block checking is not used if you are performing a proxy copy.

Null Block Compression

Null block compression becomes an option when we have access to the data block. We can eliminate blocks that have never been used (have a zeroed header) and discard them during the memory-to-memory write. Therefore, we only back up blocks that have been used and that have a more efficient backup.

This is a good place to mention the different misconceptions related to null block compression.

The first misconception is that null compression eliminates empty blocks. The null compression algorithm has only two access points that RMAN has to the database: the file header and the block header. RMAN can only draw conclusions about the contents of a block from its header or from the file header information. Why no space management information? Space management information is only available when the database is open, and RMAN null compression cannot rely on the database being open. We must rely only on that information that we can get without an open database: namely, file headers and block headers. So, if you truncate a table, all the blocks that had information in them but are now empty will be backed up, because RMAN only knows that the block has been initialized by a segment. It does not know that the block is empty.

The second common misconception about null block compression is that null compression saves time during the backup, as less is being backed up. This is true, to a certain extent, but only if your backup device is an extremely bad bottleneck. If you stream very quickly to your disk or tape backup location, then the act of eliminating blocks in memory saves little time, because RMAN is still reading every block in the file into memory—it just is not writing every block to the output device. Even during incremental backups, which eliminate blocks based on an incremental checkpoint SCN, we still have to check the header of each block to discover if it has changed since the last incremental backup. Incremental backups, then, save space in our backup location, and they provide a faster form of recovery, but they are not meant to be a significant or reliable time-saver during the actual backup.

Unused Block Compression

Unused block compression is the second mechanism for skipping unused blocks. It matches null block compression in its outcome: namely, never-initialized blocks will not be backed up. However, after version 10.2.0.3, it also can exclude used but empty blocks. This algorithm lends itself to saved time during backup, because it accesses space management information and checks the bitmaps for each segment. From this information, it builds the lists of initialized blocks and does not even attempt to back up the others. This means there is less total data read into memory, which translates into saved time.