Oracle RMAN 11g Backup and Recovery (37 page)

Chapter 2: Introduction to the RMAN Architecture
55

After the memory is allocated, RMAN initializes the backup piece. The backup piece will be given a default name that guarantees uniqueness. RMAN then begins the backup. In database versions 9.2, 10.1, and 10.2, RMAN allocates disk space in 50MB increments: 50MB is allocated on disk and filled with output buffers; when full, another 50MB is grabbed, until the last block is dumped to the backup piece. When the backup is complete, any remaining space in the final 50MB chunk is freed. It is worth pointing out that RMAN no longer does a check to see if there is enough space to complete the entire backup at the onset. This is due to the fact that null compression, and new 10
g
whitespace compression, will significantly reduce the backup from being the size of the datafiles. Instead, RMAN will run its backup until it runs out of space, and then fail.

Once the backup piece is initiated, the channel process can begin the database backup process. RMAN determines if you are using an SPFILE, and if so, it backs it up automatically as part of your backup set. Then RMAN will back up the current control file to the backup set. This control file backup is automatic whenever the SYSTEM tablespace is backed up; this behavior is changed if you have control file autobackup turned on (see Chapter 9).

So, we have the SPFILE and the control file backed up, and it is time to begin the datafile reads to pull data blocks into memory. The channel process does this by doing a read-ahead on the disk and pulling several blocks into memory at the same time. Then, the memory-to-memory write from input buffer to output buffer occurs. During this write, RMAN determines if the block has ever been initialized, or if the block header information is still zeroed out. If it is an unused block, the write to the output buffer never occurs and the block is discarded. If the block has been used, RMAN performs a checksum on the block. If the header and footer of the block do not match, RMAN indicates a corrupt block and aborts the backup. If the block has been initialized, and it passes the checksum, then that block is written to the output buffer.

Once the output buffer fills to capacity, we dump the buffer to the backup file location. The RMAN buffers are being filled up with blocks from all of the datafiles, so there is no order to the blocks in the dump file. The file is merely a bucket, and only RMAN will be able to restore the blocks to their proper location upon restore. While the blocks are being written out to the backup piece, the status of the backup is being polled by the RMAN shadow process. It checks in on the RPCs at the target and passes that information to V$SESSION_LONGOPS for your review. Based on the information gathered at the beginning of the backup operation, RMAN has an estimated completion percentage for each channel process. This can be viewed in 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

/

SID SERIAL# CONTEXT SOFAR TOTALWORK % COMPLETE

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

17 167 1 4784 116328 4.11

You can reissue this query throughout the backup process to get an update on the work still needing to be completed:

SID SERIAL# CONTEXT SOFAR TOTALWORK % COMPLETE

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

17 167 1 96999 116328 83.38

56
Part I: Getting Started with RMAN in Oracle Database 11
g
Once every block in a datafile has been read into an input buffer and its status determined, then RMAN completes the file backup by writing the datafile header out to the backup piece.

After all the files have their file headers written to the backup piece, RMAN makes a final call to SYS.DBMS_BACKUP_RESTORE, which writes backup information to the control file. This information includes the name of the backup piece, the checkpoint SCN at the time it started, and the time it completed.

And that is the entire process. Obviously, it gets more complex if we exercise more backup options, such as using multiple channels, using the FILESPERSET parameter, and backing up to tape. But each of these configurations shares the same fundamental process as previously described. If at any time during your study or testing of RMAN you want a more intimate look at the internal steps RMAN takes during backup, you can turn the debug option on for the backup and get a complete list of the entire process:

rman target / debug trace /u02/oradata/trace/rmanbkup.out

Be warned, though, that this output is extremely verbose, and it can hamper backup performance. Only use debug for learning purposes on TEST instances, unless otherwise instructed to do so by Oracle Support Services when you are troubleshooting a production backup problem.

The Flash Recovery Area

The flash recovery area (FRA) is not a requirement for using RMAN, but it should be. New in 10
g,
the FRA is a specific location on disk that you set up to house all the Oracle recovery files.

Recovery files
refers to all files that might be required for a media recovery operation: full datafile backups, incremental backups, datafile copies, backup control files, and archive logs. The FRA also functions as a repository for mirrored copies of online redo log files, the block-change tracking file, and for a current control file. If set up, flashback logs for using the flashback database option also live in the FRA. (We discuss flashback technologies in Chapter 13.) The concept behind the FRA is to simplify the management of your backup and recovery duties by consolidating the requisite files into a single location that Oracle and RMAN can then micromanage, while the DBA moves on to other important duties. This simplification is based on some underlying principles of a solid backup strategy that focuses on availability:

■ At least one copy of important datafiles, if not the entire database, should be kept on disks that are locally accessible to the database.

■ Backups past a certain age should be moved to tape based on storage pressure on local disks.

■ Long-term backup management should be almost completely automatic, based on business rules.

The FRA that you set up can be either a directory on a normal disk volume or an Automatic Storage Management (ASM) disk group. The FRA is determined by two initialization parameters: DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. The first determines the location and the second, the size. These can be set in your init.ora file, if you still use one, or in the SPFILE via an
alter system set
command.

Chapter 2: Introduction to the RMAN Architecture
57

With an FRA configured, you are not required to set any other LOG_ARCHIVE_DEST_
n
parameter for archive logs; by default, with an FRA, Oracle will default LOG_ARCHIVE_DEST_10

to the FRA. It should also be noted that with an FRA in use, you cannot use LOG_ARCHIVE_DEST

or LOG_ARCHIVE_DUPLEX_DEST—but, of course, you rid yourself of these outdated parameters long ago…right?

The FRA manages recovery files internally, first based on database name, then on types of files, and then by the dates the files are generated. The files themselves are named according to the Oracle Managed Files (OMF) format. As such, the files are hard to decipher (except for archive logs, which still maintain the structure you give them with the LOG_ARCHIVE_FORMAT parameter).

Significant internal directory structures exist for file management. However, the point of an FRA is that you don’t need to spend much time worrying about the files. That being said, it’s worth taking note of the internal structure and familiarizing yourself with where the files go. Sooner or later, you will end up digging for a particular file manually. Trust us.

The same FRA can be used by multiple databases. This can provide significant advantages, particularly for a Data Guard configuration, but also if you have a large ASM disk group and multiple databases on the same system. It can come in handy, as well, when it comes time to clone production for test purposes. Here’s the catch: all the databases that share the FRA either have a different value for DB_NAME or have a different name for the value DB_UNIQUE_NAME.

Summary

In this chapter, we discussed the underlying architecture employed by RMAN to perform backups of an Oracle Database 11
g
database
.
We covered the RMAN executable, the target database packages, and the control file. We discussed in detail the process architecture and how memory is allocated for RMAN backups. We discussed the usage of an RMAN recovery catalog and how to connect to an auxiliary database. After discussing the different architectural components, we gave a brief run-through of a typical backup operation to show the different components in use.

This page intentionally left blank

PART

II

Setup Principles and

Practices

This page intentionally left blank

CHAPTER

3

RMAN Setup and

Configuration