Oracle RMAN 11g Backup and Recovery (35 page)

50
Part I: Getting Started with RMAN in Oracle Database 11
g
The Large Pool in the Oracle SGA

The large pool is a specific area in the SGA of Oracle’s memory space. It is configured using the LARGE_POOL_SIZE parameter in your init.ora or SPFILE, and the value is specified in bytes. The large pool is utilized for certain memory activities that require shared space but tend to walk all over the usual operations in the shared pool. Its occupants are primarily restricted to RMAN memory buffers if I/O slaves are used, and Shared Servers for connection pooling. Sometimes the large pool is used for Java connections, and it will also house parallel query slaves if you set PARALLEL_AUTOMATIC_TUNING to TRUE (this is deprecated in 10
g
).

Do you need a large pool? No. Without one, all of its potential occupants simply take up space in the shared pool. This is not the end of the world, but it’s highly desirable to separate out RMAN buffers into their own space in the PGA. That way, SQL and PL/SQL parsing and other normal shared pool operations are not affected by RMAN backups, and vice versa. It also makes tuning the Oracle memory space for RMAN simpler and more straightforward.

The Recovery Catalog

So far, we have discussed the two most important RMAN components: the RMAN client utility and the internal database packages. However, another component is involved with RMAN

backups, although its usage is entirely optional: the recovery catalog.

The recovery catalog is a repository for metadata about RMAN backups. In a sense, you can think of the recovery catalog as merely a copy of the pertinent information out of the control file that RMAN requires for backup and recovery purposes. You create the recovery catalog in a user’s schema in an Oracle database, and it is no more than a few packages, tables, indexes, and views.

These tables contain data that is refreshed from the target database control file upon a resync command from within RMAN. The difference, of course, is that the recovery catalog can contain information about all the databases in your enterprise—and the control file holds only information about its own database.

To use a recovery catalog, you first connect from RMAN to the target database. Then, you make a second Net connection to the recovery catalog from within RMAN, like this: rman>connect target /

rman>connect catalog rman/password@rcat

In the connect string to the catalog, you pass the username and password for the user that owns the RMAN catalog. Unlike with the target, the connection to the catalog is not a sysdba connection and does not need this privilege granted to it.

Once connected, you can manually resync the catalog, or it will be implicitly resynchronized on any backup operation. A
resync
refers to the refreshing of the information from the target database control file to the tables in the recovery catalog.

A recovery catalog can serve as a repository for more than one target database, and as such can help centralize the administration of backups of many different databases. It has views that can be queried from SQL*Plus to determine the number, size, and range of backups for each target database that has been registered in that catalog.

Figure 2-4 details the network topology when a catalog is used. Inside of the recovery catalog are two packages: DBMS_RCVMAN and DBMS_RCVCAT. The first one, DBMS_RCVMAN, is identical in form to that same package in the SYS schema. It is in this way that the RMAN utility Chapter 2: Introduction to the RMAN Architecture
51

FIGURE 2-4
Connecting to a recovery catalog

can use either the recovery catalog or the target database control file for information about backup and recovery, and not worry about different implementations.

The package name DBMS_RCVMAN in the recovery catalog can lead to some confusion on the database that houses the recovery catalog. This database is usually referred to as the
catalog
database.
The catalog database is also a potential target database, so it also has a package in the SYS schema called DBMS_RCVMAN; thus, if you select from DBA_OBJECTS on your catalog database, there are two packages with the same name, in two different schemas. This is not a mistake or a problem. One of them is built by the catproc.sql at the time of database creation (in the SYS schema), and the other is built when we create the recovery catalog (in a regular user schema).

The second package in the recovery catalog is DBMS_RCVCAT, and it is only used to perform operations specific to the recovery catalog during RMAN operations. In essence, you can think of this package as being the recovery catalog implementation of DBMS_BACKUP_RESTORE; whereas DBMS_BACKUP_RESTORE writes backup completion information to the target database control file, DBMS_RCVCAT does this in the recovery catalog.

The base tables that contain information in the recovery catalog are unimportant, as you do not want to manually modify them. Instead, for the catalog’s protection, Oracle created a series of views, all prefixed with RC_, that can be used to extract information from the catalog. Manually issuing any DML against catalog objects is a dangerous prospect, and we don’t recommend it.

The RC_* views, and what you can get from them, are outlined in Chapter 10. As noted there, these views are different implementations of corresponding v$views in the database control file.

The Auxiliary Database

The
auxiliary database
refers to the instance that will become host to restored files from the target database in the event of a tablespace point-in-time recovery (TSPITR), a duplication operation (cloning the database), or the creation of a standby database using RMAN backups. When you perform any of these tasks, you will be connecting to the target database and the auxiliary database at the same time from within RMAN. In this way, you can utilize the information about