Oracle RMAN 11g Backup and Recovery (31 page)

38
Part I: Getting Started with RMAN in Oracle Database 11
g
you time in the long run. There are drawbacks to deploying your RMAN backups in this fashion, but with many deployments under our belt, we feel that it is the best way to go.

Running RMAN locally means you can always make a bequeath connection to the database, requiring no password file setup and no tnsnames.ora configuration. Bear in mind that the simplicity of this option is also its drawback: as soon as you want to introduce a recovery catalog, or perform a database duplication operation, you introduce all the elements that you are trying to avoid in the first place. This option can also lead to confusion during usage: because you always make a local connection to the database, it is easy to connect to the wrong target database. It can also be confusing to know which environment you are connecting from; if you have more than one Oracle software installation on your system (and who doesn’t?), then you can go down a time-sucking rat hole if you assume you are connecting to your PROD instance, when in fact you set up your ORACLE_HOME and ORACLE_SID environment variables for the TEST instance.

Perhaps the true difference between running RMAN from your desktop workstation and running it locally at each target database server comes down to OS host security. To run RMAN

locally, you always have to be able to log into each database server as the oracle user at the OS

level and to have privileges defined for such. However, if you always make an Oracle Net connection to the database from a remote RMAN executable, you need never have host login credentials.

Choose your option wisely. We’ve stated our preference, and then given you its bad news. As Figure 2-2 depicts, even our simplification into two options—client RMAN or server RMAN—can be tinkered with, giving you a hybrid model that fits your needs. Figure 2-2 shows five different scenarios:

1.
RMAN runs as a client connection from the DBA’s workstation, because the DBA in charge of backing up PRODWB and DW_PROD does not have the oracle user password on the production database server.

FIGURE 2-2
Running different versions of the RMAN executable in the enterprise
Chapter 2: Introduction to the RMAN Architecture
39

2.
RMAN backs up DW_PROD remotely, as with PRODWB, due to security restrictions on the database production server.

3.
The 10.2 TEST database is backed up with a local RMAN executable that runs from the TEST $ORACLE_HOME.

4.
The 11.1.0 DEV database is backed up locally. Because the DBA has oracle user privileges on the Test and Dev Server, this is feasible, and it minimizes the number of client installs to maintain at the local workstation.

5.
The 11.2.0 DEV database is backed up locally as well, for the same reasons as the 11.1.0

DEV database.

Remember to remain flexible in your RMAN topology. At times you will need to run your backups in NOCATALOG mode, using the local RMAN executable. And there may come a time when you need to run a remote RMAN job as well.

The Database Control File

So far, we have discussed the RMAN executable and its role in the process of using server-managed recovery with Oracle 11
g.
As we said, the real work is being done at the target database—it’s backing itself up. Next, we must discuss the role of the control file in an RMAN