Oracle RMAN 11g Backup and Recovery (36 page)

52
Part I: Getting Started with RMAN in Oracle Database 11
g
the backups in the target database control file to coordinate the restore of those backups to the auxiliary database location. The following shows the connection to both the target database (locally) and the auxiliary database (using an Oracle Net connection):

rman>connect target /

rman>connect auxiliary sys/pwd@aux1

RMAN makes a simultaneous connection to each database and requires access to the SYS.

DBMS_BACKUP_RESTORE and SYS.DBMS_RCVMAN packages in both the target database and the auxiliary database. As such, RMAN requires sysdba privileges at the auxiliary, just as it does at the target. Because RMAN must make a sysdba connection to two separate databases, you are required to configure at least one of them with a password file and make an Oracle Net connection to it—there is no way to connect locally to two different databases.

We discuss the exact auxiliary database setup in great detail in Chapter 19. Figure 2-5 shows the network topology of an RMAN configuration when an auxiliary database is used. In Oracle8
i,
a recovery catalog was required in order to perform any actions at the auxiliary database, so this figure shows the topology with a catalog, as well.

FIGURE 2-5
Network topology with an auxiliary database in the mix
Chapter 2: Introduction to the RMAN Architecture
53

Compatibility Issues

Given the number of different components that we have to work with, you must stick with database version restrictions when working with RMAN. There are five different pieces to the compatibility puzzle, each of which has a version number:

■ The RMAN executable version (the client utility)

■ The target database

■ The recovery catalog schema

■ The recovery catalog database

■ The auxiliary database (for duplication, TSPITR, and standby creation) The easiest answer, of course, is to make sure all of these components are on the latest version, 11.2. If they are all at the same level, then there is no problem, right? Of course, in the world where all of your databases are at the same level, everyone has their very own pony, fairies roam the earth, babies never cry, and no one ever has to take backups because failures never occur. But for the world we live in, there are some things to understand about RMAN version compatibility.

The Target and the RMAN Executable

The first general rule to stick with is to ensure that the target database and the RMAN executable are the same version. This is easy, if you will always be running RMAN from the target database environment. It gets trickier if you will be running all of your RMAN jobs from a centralized client interface. It means your client system will have to have an ORACLE_HOME client installation that corresponds in version to every database version that you will need to connect to and back up.

The level of complexity is pretty high with this solution. This can also be avoided by using Oracle Enterprise Manager Grid Control
.
This allows a centralized interface so you can use the remote RMAN executables from a single console, or more consoles if the backup tasks are divided among DBAs. We discuss the Enterprise Manager interface in Chapter 11.

The Catalog Database and Catalog Schema

There are essentially three tiers to worry about with compatibility: Oracle9
i,
Oracle 10
g,
and Oracle 11
g.
From the perspective of the catalog database and the catalog schema, there’s a simpler answer: If you create a 11.2 recovery catalog in a 11.2 database, all databases down to 8.1.7.4 can be registered in it. If that is not possible, then read closely: All Oracle8 versions can be registered in an 8.1.
x
catalog. However, a 9.0.1 or 9.2.0 database cannot be registered in an 8
i
catalog, nor a 10.
x
in a 9
x
catalog, nor an 11
g
database in a lower version catalog. So, if you do not have an available database to use for the 11
g
recovery catalog, you will need to run it in NOCATALOG mode until one becomes available. Don’t even think about running multiple-versions catalogs—it’s just not worth it. Remember, as soon as you introduce a new version of the RDBMS into production anywhere in your ecosystem, then you need to get your RMAN catalog to that version as well.

54
Part I: Getting Started with RMAN in Oracle Database 11
g
The Auxiliary Database

From a compatibility standpoint, the auxiliary database must be the same version as the target database that it will be cloned from. In fact, we would go so far as to encourage you to match the ORACLE_HOME to which you will duplicate to the same level as the target database’s ORACLE_

HOME. In Chapter 17, we discuss in greater detail the use of an auxiliary database.

The RMAN Process: From Start to Finish

So far, we have discussed the different architectural components of taking a backup using Recovery Manager. As you may have noticed, there are a number of pieces to keep straight. To put it into a little perspective, we will run through a typical backup operation and explain the underlying RMAN activity at every step. That way, you should be able to associate the lengthy exposition in this chapter to the actual steps that you will take to perform a backup.

The following example illustrates a backup of a database called PROD. The backup will be going to a disk location; the discussion of setting up and utilizing a media manager for backups to tape will be deferred to Chapters 4 through 8. The target database PROD has 20 datafiles and is running in ARCHIVELOG mode. The database is up and running during this operation. Here is our backup command:

C$>rman

rman>connect target /

rman>backup database;

That’s it. That’s all it takes. The following discussion explains what happens.

RMAN makes the bequeath connection to the target database that we have set up in our environment. This means it checks the variable ORACLE_SID for an instance name, then spawns a server process at that instance, logging in as a sysdba user. This connects as the internal database user SYS. RMAN immediately spawns the channel processes that will be used to perform the backup. In this case, we are using default settings, so only one channel is allocated. We are not using I/O slaves, so the process allocates memory in the PGA.

Next, RMAN compiles a call to SYS.DBMS_RCVMAN to request database schematic information from the target database control file, starting with a determination of the target database version. It gathers version information from the control file, along with control file information itself: What type of control file is it? What is the sequence number current in it?

When was it created?

Because we have specified a full database backup, RMAN requests information for each datafile in the database and determines if any files are offline. As part of this information, it gathers which disk each file is on and how to dole out the work. Because we are using default settings, there will be only one channel and only one backup set. Therefore, RMAN ignores all disk affinity information and concentrates on compiling the list of files for inclusion in the backup set.

After the list is compiled, RMAN is ready to begin the backup process itself. To guarantee consistency, it then builds the snapshot control file. If one already exists, it overwrites it with a new one. Then RMAN creates the call to the DBMS_BACKUP_RESTORE package to create the backup piece. The backup piece will be built in the default file location; on Unix, this is ORACLE_HOME/dbs, and on Windows, it is ORACLE_HOME/database. RMAN has the file list, so it can allocate the memory buffers for performing the read from disk. With 20 files, RMAN

allocates input buffers of size 128KB. There will be four buffers per file, for a total memory utilization of 10MB for input buffers. RMAN will only allocate four output buffers, each of 1MB. This brings our total memory utilization to 14MB for the backup.