Oracle RMAN 11g Backup and Recovery (156 page)

The one caveat to this simplicity is if the auxiliary host does not have the same file structure and mount point setup that the target host has. If you have different mount points or drive configurations, you still need to change your file specifications for the auxiliary instance so that RMAN can restore to a location that actually exists.

The Backup Location: Disk

The complicating factor for restoring to a different server comes from providing the auxiliary channel process access to backups that were taken at a different server. You must account for whether you backed up to disk or to tape.

If you are duplicating from disk backups, your choices are limited. Remember that RMAN

passes the calls to DBMS_BACKUP_RESTORE to a channel process at the auxiliary instance, but it cannot take into account any file system differences. It must look for the backup pieces in the exact location and format that was recorded in the target database control file. For example, suppose you took a full database backup at your target system using the following command: backup database format '/u04/backup/prod/%U.full.PROD';

This created your backup piece as a file called 01DSGVLT_1_1 in the directory /u04/backup/

prod. This is recorded in the target control file. Then, during duplication, RMAN passes the
file
restore
command to the auxiliary instance and tells it to restore from /u04/backup/prod/

01DSGVLT_1_1. That means your auxiliary instance must have a mount point named /u04, and there must be a directory named backup/prod in which a file called 01DSGVLT_1_1 resides. If not, the duplication will fail with an error:

RMAN-03002: failure of Duplicate Db command at 07/02/2002 14:49:55

RMAN-03015: error occurred in stored script Memory Script

ORA-19505: failed to identify file "/u04/backup/prod/01dsgvlt 1 1"

ORA-27037: unable to obtain file status

SVR4 Error: 2: No such file or directory

Additional information: 3

Chapter 19: Duplication: Cloning the Target Database
477

You can make duplication from disk work in three ways. The first, and most straightforward, is to simply copy the backups from your target host to the auxiliary host, and place them in the same location. Obviously, this involves a huge transfer of files across your network.

The second way to proceed is to NFS mount the backup location on the target host from the auxiliary host. This works only if you can mount the target location with the same mount point name as RMAN will use (in the preceding example, you would have to NFS mount /u04/backup/

prod as /u04/backup/prod). For example, you would need to do the following from your auxiliary instance:

mount cervantes:/u04/backup/prod /u04/backup/prod

That way, from your auxiliary node, you should be able to do the following: cd /u04/backup/prod

ls –l

touch testfile

ls –l

If you get an error when you try to change directories, or when you try to touch a file, you need to sort out your NFS and permissions issues before you proceed with duplication. Figure 19-2 illustrates the mounted file system approach to duplicating to a different server using disk backups.

If you are on a Windows platform instead of NFS, you will be mounting a network drive. The same rule applies: the drive specification must be the same on the auxiliary as it is on the target.

So if the backup was written to F:\backup, then you must be able to use F: as a network drive, or duplication will fail. In addition, you will have to set up your auxiliary service (oracleserviceaux1) and your listener service (oracleOraHome92tnslistener) to log on as a domain administrator that
FIGURE 19-2
Duplication to a different server using disk backups
478
Part IV: RMAN in the Oracle Ecosystem

has read/write privileges at both the auxiliary host and the target host. Otherwise, you will not be able to access the backups over the networked drive.

As you may have already noticed, it could be difficult to make a network file system operation be successful. If you have the same file systems on both the target and the auxiliary servers, you would not be able to use a straight NFS mount from the auxiliary node to the target location of the backups on disk. Therefore, your only option would be to copy the backup pieces from one node to the other.

The source of these types of headaches, of course, is the fact that RMAN hard-codes the backup location when we back up to disk, and this location cannot be changed. In Oracle Database 10
g,
however, there are now two options for us to change the backup location: the
backup backupset
command and the
catalog backupset
command.

With the
backup backupset
command, we can back up a previous backup set that was on disk and move it to a different disk location. This gives us considerable flexibility. Now, we can move the backup pieces from /u04/backup/prod to, say, /u06/backup/prod, which could then be NFS mounted from our auxiliary system. Or, from the target host, we could NFS mount a drive at the auxiliary host and then use the
backup backupset
command to move the backups to the auxiliary host. For more information on this command, see Chapter 11.

The
catalog backupset
(and
catalog datafilecopy
) command offers another, simpler means of relocating backup sets on a new server. To make RMAN aware that a backup set exists in any location, you need only tell RMAN to catalog a certain file (or a certain directory), and it will look for any valid backups in that location and generate metadata for them. For more details on the
catalog
command, see Chapter 16.

The Backup Location: Tape

By all estimations, duplicating to a remote server using tape backups is far less complicated or demanding than using disk backups, because a tape backup does not have a location, per se, just a file handle. This file handle is all that RMAN knows or cares about; how that file handle relates to a location on a specific tape is completely controlled by the media manager. Therefore, all configuration steps that occur for duplication from tape come from the media management layer.

First, you must configure your MML file at the auxiliary site in the same way as at the target site. Because an auxiliary channel is doing the restore operations, it must be able to initialize the MML, as outlined in Chapter 4. So, make sure you’ve linked your MML at the auxiliary site.

Next, you need to make sure that your media management server is configured correctly. This means that your auxiliary node must be registered as a client in the same media management server that your target node is registered in, and it must have the necessary privileges to access the tapes for restore purposes. In particular, you must enable the auxiliary node to restore backups that were taken from a different server. This functionality is usually disabled by default in most media management software, because allowing files to be restored from one client to another is a potential security hole. The steps for enabling clients to restore files from a different client are outlined in each of our four media management chapters (Chapters 5, 6, 7, and 8), depending on your software vendor.

After configuring your media management server, your final configuration step is to set up your auxiliary channels. As mentioned earlier, RMAN allocates one or more channels at the auxiliary instance to perform the restore and recovery steps of duplication. You configure these channels via the
configure
command when you are connected to your target database from RMAN. The
parms
parameter for the auxiliary channels must contain the usual media management environment control variables. In particular, it needs to specify the client from which the backups were taken. For instance, let’s say your target node is named cervantes, and

Chapter 19: Duplication: Cloning the Target Database
479

your auxiliary node is named quixote. Because you have been backing up from cervantes, this client name is encoded with your RMAN backups at the media management server. So, to be able to access these backups from the client quixote, you must specify from within RMAN that the client name is cervantes. Your auxiliary channel configuration command, then, would look something like this (given a NetBackup media management system):

RMAN> configure auxiliary channel 1 device type sbt parms

2> "env (nb ora serv mgtserv,
nb_ora_client=cervantes
)"; new RMAN configuration parameters:

CONFIGURE AUXILIARY CHANNEL 1 DEVICE TYPE 'SBT TAPE' PARMS

"env (nb ora serv mgtserv,
nb_ora_client=cervantes
)";

new RMAN configuration parameters are successfully stored

Then, when the auxiliary channel makes its sbt( ) calls to the MML, it is telling the media management server to access backups that were taken using the client cervantes, instead of checking for backups made by quixote.

Duplication and the Network

Take a deep breath; we’re almost through explaining all the intricacies of duplication and are about to walk you through the steps themselves. There’s one more area that you need to prepare prior to running a
duplicate
command from RMAN: the network. By
network,
we mostly mean configuring your Oracle Net files—tnsnames.ora and listener.ora. However, take this opportunity to consider your overall network as well. Make sure that the target node, auxiliary node, and media management server can all access each other okay and that you have plenty of bandwidth.

From an Oracle perspective, we have to configure the Oracle Net files. As discussed in Chapter 2, RMAN must make a SYSDBA connection to the target database. If you are connecting remotely, you have to configure a password file for the target node. In addition, you need a tns alias that uses a dedicated server process instead of a shared server process. For duplication, this still holds true, but you must also be able to connect to the auxiliary instance as SYSDBA using only dedicated servers.

This means that, no matter what, you have to create a password file for either your target or your auxiliary machine. You may have been forgoing this step until now by always making a local connection to the target database. But you cannot simultaneously make a local connection to both the target and the auxiliary instance. So now, if you haven’t done so already, it’s time to build a password file.

RMAN Workshop:
Build a Password File

Workshop Notes

On Unix platforms, the name of the password file must be orapw, where is the value of the ORACLE_SID to which the password is giving access. In this workshop, the ORACLE_SID =

prod. On Windows, the filename must be in the format pwd.ora. The locations given in this workshop must be used; the password file cannot be created anywhere else or it will be unusable.

Step 1.
Edit the init.ora file and add the following parameter:

remote login passwordfile exclusive