Oracle RMAN 11g Backup and Recovery (32 page)

backup or recovery process.

The control file has a day job already; it is responsible for the physical schematics of the database. The name says it all: the control file controls where the physical files of a database can be found, and what header information each file currently contains (or should contain). Its contents include datafile information, redo log information, and archive log information. It has a snapshot of each file header for the critical files associated with the database. Because of this wealth of information, the control file has been the primary component of any recovery operation prior to RMAN (Chapter 1 discusses this in greater detail).

Because of the control file’s role as the repository of database file information, it makes sense that RMAN would utilize the control file to pull information about what needs to be backed up.

And that’s just what it does: RMAN uses the control file to compile file lists, obtain checkpoint information, and determine recoverability. By accessing the control file directly, RMAN can compile file lists without a user having to create the list herself, eliminating one of the most tiresome steps of backup scripting. And RMAN does not require that the script be modified when a new file is added. It already knows about your new file. RMAN knows this because the control file knows this.

The control file also moonlights as an RMAN data repository. After RMAN completes a backup of any portion of the database, it writes a record of that backup to the control file, along with checkpoint information about when the backup was started and completed. This is one of the primary reasons that the control file grew exponentially in size between Oracle version 7

and Oracle version 8—RMAN tables in the control file. These records are often referred to as
metadata
—data about the data recorded in the actual backup. This metadata will also be stored in a recovery catalog when one is used (see Chapter 3).

Record Reuse in the Control File

The control file can grow to meet space demands. When a new record is added for a new datafile, a new log file, or a new RMAN backup, the control file can expand to meet these demands. However, there are limitations. As most databases live for years, in which thousands of redo logs switch and
40
Part I: Getting Started with RMAN in Oracle Database 11
g
thousands of checkpoints occur, the control file has to be able to eliminate some data that is no longer necessary. So, it ages out information as it needs space and reuses certain “slots” in tables in round-robin fashion. However, some information cannot be eliminated—for instance, the list of datafiles. This information is critical for the minute-to-minute database operation, and new space
must
be made available for these records.

The control file thus separates its internal data into two types of records: circular reuse records and noncircular reuse records.
Circular reuse records
are records that include information that can be aged out of the control file if push comes to shove. This includes, for instance, archive log history information, which can be removed without affecting the production database.
Noncircular
reuse records
are those records that cannot be sacrificed. If the control file runs out of space for these records, the file expands to make more room. These records include datafile and log file lists.

The record of RMAN backups in the control file falls into the category of circular reuse records, meaning that the records will get aged out if the control file section that contains them becomes full. This can be catastrophic to a recovery situation: without the record of the backups in the control file, it is as though the backups never took place. Remember this: if the control file does not have a record of your RMAN backup, the backup cannot easily be used by RMAN for recovery (we’ll explain how to re-add backups to the control file records in Chapter 12). This makes the control file a critical piece in the RMAN equation. Without one, we have nothing. If records get aged out, then we have created a lot of manual labor to rediscover the backups.

Fear not, though. Often, it is unimportant when records get aged out; it takes so long for the control file to fill up, the backups that are removed are obsolete. You can also set a larger timeframe for when the control file will age out records. This is controlled by the init.ora parameter CONTROL FILE_RECORD_KEEP_TIME. By default, this parameter is set to 7 (in days).

This means that if a record is less than seven days old, the control file will not delete it, but rather expand the control file section. You can set this to a higher value, say, 30 days, so that the control file always expands, until only records older than a month will be overwritten when necessary.

Setting this to a higher day value is a good idea, but the reverse is not true. Setting this parameter to 0 means that the record section never expands, in which case you are flirting with disaster.

In addition, if you will be implementing a recovery catalog, you need not worry about circular reuse records. As long as you resync your catalog at least once within the timeframe specified by the CONTROL FILE_RECORD_KEEP_TIME parameter, then let those records age out—the recovery catalog never ages out records.

The Snapshot Control File

As you can tell, the control file is a busy little file. It’s responsible for schematic information about the database, which includes checkpoint SCN information for recovery. This constant SCN and file management is critical to the livelihood of your database, so the control file must be available for usage by the RDBMS on a constant basis.

This poses a problem for RMAN. RMAN needs to get a consistent view of the control file when it sets out to make a backup of every datafile. It only needs to know the most recent checkpoint information and file schematic information at the time the backup begins. After the backup starts, RMAN needs this information to stay consistent for the duration of the backup operation; in other words, it needs a
read consistent
view of the control file. With the constant updates from the database, this is nearly impossible—unless RMAN were to lock the control file for the duration of the backup. But that would mean the database could not advance the checkpoint or switch logs or produce new archive logs. Impossible.

To get around this, RMAN uses the
snapshot control file,
an exact copy of your control file that is only used by RMAN during backup and resync operations. At the beginning of these

Chapter 2: Introduction to the RMAN Architecture
41

Re-Creating the Control File: RMAN Users Beware!

It used to be that certain conditions required the occasional rebuild of the database control file, such as resetting the MAXLOGFILES parameter or the MAXLOGHISTORY parameter.

Certain parameters cannot be set unless you rebuild the control file, because these parameters define the size of the internal control file tables that hold noncircular reuse records. Therefore, if you need that section to be larger, you have to rebuild the control file.

If you use RMAN and you do not use a recovery catalog, be very careful of the control file rebuild. When you issue the command

alter database backup control file to trace;

the script that is generated does not include the information in the control file that identifies your backups.
Without these backup records, you cannot access the backups when they are
needed for recovery.
All RMAN information is lost, and you cannot get it back. The only RMAN information that gets rebuilt when you rebuild the control file is any permanent configuration parameters you have set with RMAN. In Oracle 10
g
and higher, a new mechanism generates limited backup metadata within a control file, but you are still building in a lot of manual work that never used to exist. Therefore, we encourage you to avoid a control file rebuild at all costs.

If you back up the control file to a binary file, instead of to trace, then all backup information is preserved. This command looks like the following:

alter database backup controlfile to '/u01/backup/bkup cfile.ctl';

operations, RMAN refreshes the snapshot control file from the actual control file, thus putting a momentary lock on the control file. Then, RMAN switches to the snapshot and uses it for the duration of the backup; in this way, it has read consistency without holding up database activity.

By default, the snapshot control file exists in the ORACLE_HOME/dbs directory on Unix platforms and in the ORACLE_HOME/database directory on Windows. It has a default name of SNCF.ORA. This can be modified or changed at any time by using the
configure
snapshot controlfile
command:

configure snapshot controlfile name to '';

Certain conditions might lead to the following error on the snapshot control file, which is typically the first time a person ever notices the file even exists:

RMAN-08512: waiting for snapshot controlfile enqueue

This error happens when the snapshot control file header is locked by a process other than the one requesting the enqueue. If you have multiple backup jobs, it may be that you are trying to run two backup jobs simultaneously from two different RMAN sessions. To troubleshoot this error, open a SQL*Plus session and run the following SQL statement:

SELECT s.sid, username AS "User", program, module, action, logon time

"Logon", l.*

FROM v$session s, v$enqueue lock l

WHERE l.sid s.sid and l.type 'CF' AND l.id1 0 and l.id2 2;