Oracle RMAN 11g Backup and Recovery (157 page)

480
Part IV: RMAN in the Oracle Ecosystem

If you are using an SPFILE, you need to execute the following:

alter system set remote login passwordfile exclusive scope spfile;

Both operations require a database restart to take effect.

Step 2.
Decide what your password will be, and then navigate to your ORACLE_HOME/dbs directory (ORACLE_HOME/database on Windows) and type the following:

orapwd file orapwprod password

Step 3.
Check that the file was created successfully, and then test it by making a remote connection as SYSDBA.

After your password file has been created for your auxiliary instance, you need to configure the listener to route incoming connections to the auxiliary instance. As you may have already noticed, there is no need in 10
g
or 11
g
for a listener.ora file if you will be connecting only to open databases. This is because the database PMON process automatically registers the database with a running listener daemon on the system. So, you will often see that after a default 11
g
R2

installation, a listener is running, and it is listening for your database, even though you’ve done no configuration.

While this is excellent news, it does nothing for us in a duplication environment, because we must be able to make a remote connection to an auxiliary instance that is started (in NOMOUNT

mode) but not open. Because it is not open, there is no PMON process to register the auxiliary instance with the listener, so the listener has no idea the auxiliary instance exists. To get past this, you must set up an old-fashioned listener.ora file, with a manual entry for the auxiliary database.

We recommend using the Oracle Net Manager utility, shown here, to build this entry:

Chapter 19: Duplication: Cloning the Target Database
481

After you have configured the listener.ora at your auxiliary instance location, you must also build a tnsnames.ora entry at the site from which you will be running RMAN. This is the same as almost any other entry, except that when you build it, you must specify the auxiliary SID_NAME

instead of the SERVICE_NAME. From the Net Manager, you fire up the Net Service Name Wizard by clicking Service Naming and then going to the menu and choosing Edit | Create. After you give the Net Service Name (Step 1), then provide the protocol (Step 2), provide the hostname and port number (Step 3), and finish with specifying the Service Name.

Duplication to the Same Server

Okay, so enough of the explanations, it’s time to run through the duplication itself. First, we give a detailed step-by-step workshop for duplicating to the same server on which the target resides, using disk backups. Then, we briefly explain what you would need to do the same thing with tape backups.

Setting an until Clause When Duplicating

When performing duplication, you sometimes will encounter a situation that requires you to specify an
until
clause when duplicating. If you have ever used RMAN to restore your database using a backup control file, and you are now attempting to duplicate that database, you will be required to set an
until
clause. It is recommended to determine the most recent archive log available to duplication and then to use it as the ending point during duplication: run { set until sequence
n
thread 1;

duplicate target database… }

Or, as a fix-all, you can set the SCN to an impossibly high value:

set until scn 281474976710655;

482
Part IV: RMAN in the Oracle Ecosystem

RMAN Workshop:
Duplication to the Same Server, Using

Disk Backups

Workshop Notes

Make sure that your OS has been configured to handle another Oracle instance and that adequate memory and disk space exists. In the following example, our target database, v112, has all of its datafiles, control files, and redo log files located at /u01/app/oracle/product/oradata/v112. All backups have been going to the local flash recovery area (FRA) at /u01/app/oracle/product/flash_

recovery_area. We will set the ORACLE_SID for the auxiliary instance to be aux1.

Step 1.
Build your auxiliary database directory structures:

$ pwd

/u01/app/oracle/product/oradata

$ mkdir aux1

$ mkdir aux1/arch

$ cd ../admin

$ mkdir aux1

$ cd aux1

$ mkdir pfile bdump udump cdump

$ ls

bdump cdump pfile udump

Step 2.
Copy the target init.ora file to the auxiliary location. If your target database uses an SPFILE, you need to create a PFILE from the SPFILE to capture parameters to move over.

If you use an SPFILE at your target, enter the following:

SQL> connect / as sysdba

Connected.

SQL> create pfile '/u01/app/oracle/product/admin/aux1/pfile/init.ora'

from spfile;

If you use an init.ora file at your target, enter the following:

cp u01/app/oracle/product/admin/v112/pfile/init.ora

u01/app/oracle/product/admin/aux1/pfile/init.ora

Step 3.
Make all necessary changes to your aux1 init.ora file:

audit file dest '/u01/app/oracle/product/admin/aux1/adump'

background dump dest '/u01/app/oracle/product/admin/aux1/bdump'

compatible '11.2.0.1.0'

control files '/u01/app/oracle/product/oradata/aux1/control01.ctl',

'/u01/app/oracle/product/oradata/aux1/control02.ctl',

'/u01/app/oracle/product/oradata/aux1/control03.ctl'

core dump dest '/u01/app/oracle/product/admin/aux1/cdump'

db block size 8192

db file multiblock read count 16

db name 'aux1'

db recovery file dest '/u01/app/oracle/product/flash recovery area'

Chapter 19: Duplication: Cloning the Target Database
483

db recovery file dest size 4294967296

dispatchers '(PROTOCOL TCP) (SERVICE aux1XDB)'

job queue processes 10

open cursors 300

pga aggregate target 93323264

processes 150

remote login passwordfile 'EXCLUSIVE'

sga target 279969792

undo management 'AUTO'

undo tablespace 'UNDOTBS1'

user dump dest '/u01/app/oracle/product/admin/aux1/udump'

db file name convert ('v112','aux1')

instance name 'aux1'

Step 4.
Build your aux1 password file. See the “Build a Password File” RMAN Workshop earlier in this chapter.

Step 5.
Start up the aux1 instance in NOMOUNT mode:

ORACLE SID aux1

export ORACLE SID

sqlplus /nolog

sql>connect / as sysdba

SQL> startup nomount

pfile /u01/app/oracle/product/admin/aux1/pfile/init.ora

Step 6.
Configure your network files for connection to aux1. After making any changes to your listener.ora file, be sure that you bounce your listener, or the change will not take effect.

$ lsnrctl reload

The tnsnames.ora file should have an entry like this:

AUX1

(DESCRIPTION

(ADDRESS LIST

(ADDRESS (PROTOCOL TCP)(HOST horatio)(PORT 1521))

)

(CONNECT DATA

(SID aux1)

(SERVER DEDICATED)

)

)

The listener.ora file should have an entry like this:

SID LIST LISTENER

(SID LIST

(SID DESC

(GLOBAL DBNAME aux1)

(ORACLE HOME /u01/app/oracle/product/11.2.0/dbhome 1)

(SID NAME aux1)

)

)

484
Part IV: RMAN in the Oracle Ecosystem

Step 7.
From RMAN, connect to the target and auxiliary instance and run the
duplicate
command:

$ ORACLE SID aux1;export ORACLE SID

$ rman target /

RMAN> connect auxiliary sys/ora10g@aux1

RMAN> duplicate target database to aux1

pfile /u01/app/oracle/product/admin/aux1/pfile/init.ora

logfile

'/u01/app/oracle/product/oradata/aux1/redo01.dbf' size 100m,

'/u01/app/oracle/product/oradata/aux1/redo02.dbf' size 100m,

'/u01/app/oracle/product/oradata/aux1/redo03.dbf' size 100m;

Using Tape Backups

If you were to perform the preceding exercises but with your backups on tape, little would change. In fact, none of the code itself would change; you would simply insert an additional step prior to running the
duplicate
command itself. That step would be to configure your auxiliary channel(s) to resemble the channels that the backups were taken with. In other words, do a
show
command:

RMAN> show channel;

RMAN configuration parameters are:

CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT TAPE' PARMS

"env (nb ora serv mgtserv)";

CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT TAPE' PARMS

"env (nb ora serv mgtserv)";

Then, simply create the auxiliary channels to match:

CONFIGURE AUXILIARY CHANNEL 1 DEVICE TYPE 'SBT TAPE' PARMS

"env (nb ora serv mgtserv)";

CONFIGURE AUXILIARY CHANNEL 2 DEVICE TYPE 'SBT TAPE' PARMS

"env (nb ora serv mgtserv)";

Duplication to a Remote Server

Duplication to a remote server has many of the same configuration steps as duplication to the same server. In particular, if you are duplicating remotely but will use disk backups, the steps would be identical, although you could forgo all file-renaming steps. In addition, you would have to either copy your backups to the remote server or use NFS to mount the backups at the remote site. Covering NFS is outside the scope of this book, so we assume in the following RMAN

Workshop that you have the same file systems on both the target and auxiliary servers and have copied the backups to the auxiliary system.

Chapter 19: Duplication: Cloning the Target Database
485

RMAN Workshop:
Duplication to a Remote Server, Using

Disk Backups

Workshop Notes

This workshop assumes the use of two servers: dex, the target, and horatio, the auxiliary. It assumes that you have the same file system on both nodes and have copied your backups from dex to horatio. The most important thing to note here is that we maintain the v112 database SID

throughout the process (instead of changing it to aux1, which we do when duplicating to the same server).

Step 1.
At horatio (the auxiliary server), build your auxiliary database directory structures: $> pwd

/u01/app/oracle/oradata

$> mkdir v112

$> cd ../admin

$> pwd

/u01/app/oracle/admin

$> mkdir v112

$> cd v112

$> mkdir pfile bdump udump cdump adump

$> ls

adump bdump cdump pfile udump

Step 2.
At dex (the source server), make a copy of the target init.ora file so that it can be moved to the auxiliary server. If your target database uses an SPFILE, you need to create a PFILE from the SPFILE in order to capture parameters to move over.

If you use an SPFILE at your target, enter the following: