Oracle RMAN 11g Backup and Recovery (158 page)

SQL> connect / as sysdba

Connected.

SQL> create pfile '/home/oracle/scratchpad/init.ora'

from spfile;

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

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

/home/oracle/scratchpad/init.ora

Step 3.
Move the target init.ora file to the auxiliary site:

cd /home/oracle/scratchpad/

ftp horatio.hadba.com

username: oracle

password:

cd /u01/app/oracle/admin/v112/pfile

put init.ora

exit

486
Part IV: RMAN in the Oracle Ecosystem

You also need a local copy of the init.ora file at the target server dex, for reference by RMAN

in the
duplicate
command itself. We will reference the copy that we left in /home/oracle/

scratchpad/init.ora when we run the
duplicate
command in Step 9.

Step 4.
Start the auxiliary instance in NOMOUNT mode at quixote:

ORACLE SID v112; export ORACLE SID

sqlplus /nolog

SQL>connect / as sysdba

SQL>startup nomount

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

Step 5.
Configure the listener.ora at the auxiliary site (proto): SID LIST LISTENER

(SID LIST

(SID DESC

(GLOBAL DBNAME v112)

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

(SID NAME v112)

)

)

Step 6.
Configure the tnsnames.ora file at the target site (dex): V112 HORATIO

(DESCRIPTION

(ADDRESS LIST

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

)

(CONNECT DATA

(SERVICE NAME v112)

)

Step 7.
Create a password file at the remote server (proto). Follow the instructions from the earlier RMAN Workshop, “Build a Password File.”

Step 8.
Move the FRA files from dex to horatio.

Step 9.
From the target system (dex), run your
duplicate
command: ORACLE SID v112; export ORACLE SID

rman target /

RMAN> connect auxiliary sys/password@v112 horatio

duplicate target database to v112

pfile /home/oracle/scratchpad/init.ora

logfile

'/u01/app/oracle/11.2.0/oradata/v102/redo01.dbf' size 100m,

'/u01/app/oracle/11.2.0/oradata/v102/redo02.dbf' size 100m,

'/u01/app/oracle/11.2.0/oradata/v102/redo03.dbf' size 100m;

Chapter 19: Duplication: Cloning the Target Database
487

Using Tape Backups for Remote Server Duplication

All the steps in the preceding RMAN Workshop apply if you are using tape backups instead of disk backups; again, the only difference is that you would also have to configure your auxiliary channels to reflect the needs of your media manager. In addition to specifying the media management server, and any classes or pools that you have for your regular channels, you also need to specify the target client name:

RMAN> configure auxiliary channel 1 device type sbt parms

2> "env (nb ora serv mgtserv,
nb_ora_client=dex
)";
Target-Less Duplication in 11
g

Starting in 11
g
R2, RMAN has been innovated to break some of the dependencies that made the duplication process complex in previous versions. Primarily, it is now possible to duplicate a database from RMAN backups without making a connection to the target database. While providing access to the active target database makes some aspects of duplication simpler, it sometimes simply isn’t possible. In fact, we’ve been involved in “fake target database” operations where we have pulled a backup control file from an inaccessible target database, mounted the control file, and pointed RMAN at this “instance” long enough to kick off duplication. Perhaps Oracle heard our cries of anguish.

To duplicate without a target, the next best thing is a connection to your recovery catalog, where the requisite target database metadata can be extracted with little effort. The primary element to be concerned with in this situation is to care for the database ID (DBID) when performing the duplication. When you are connected to the target database, RMAN has no difficulty understanding what “prod” means. But if you have multiple “prod” databases in your catalog, you may run into ambiguity issues. Therefore, you should dig into the recovery catalog and get your DBID:

SQL> select dbid, name, resetlogs time from rc database;

DBID NAME RESETLOGS

---------- -------- ---------

2203908660 V112 20-JUN-09

Once the DBID is known, you can kick off your nontarget duplication in much the same way as our previous workshops:

RMAN> connect auxiliary sys/password@v112 horatio

Connect catalog rman2/rman2@rcv cat

duplicate database v112 to aux1

dbid 2203908660

until time "to date('2009-07-08', 'YYYY-MM-DD')"

pfile /home/oracle/scratchpad/init.ora

logfile

'/u01/app/oracle/11.2.0/oradata/v102/redo01.dbf' size 100m,

'/u01/app/oracle/11.2.0/oradata/v102/redo02.dbf' size 100m,

'/u01/app/oracle/11.2.0/oradata/v102/redo03.dbf' size 100m;

488
Part IV: RMAN in the Oracle Ecosystem

Incomplete Duplication: Using the DBNEWID Utility

One of the most frustrating elements of performing duplication is that there is no “restartable duplication.” What we mean by this is that if you make it through the step that restores all your files—arguably the longest step of the process—but a failure occurs, say, during the recovery, you must restart the duplication process from scratch and restore all the files again. There is no way to correct the recovery process (by making missing archive logs available, for instance) and then pick up where you left off.

With RESTORE OPTIMIZATION turned ON, RMAN will not restore files again that already exist in the restore location with the same datafile header SCN information. This applies to duplication as well: if duplication restores a file, and then duplication restarts, RMAN will not restore the file again. However, if you have applied even one archive log to the file, it will be restored again.

Starting in version 9
i
Release 2
,
Oracle Database includes the DBNEWID utility, which gives your clone database a new DBID in a safe and controlled manner. This allows you to do manual recovery against a duplicated database, prepare all the elements, and then run DBNEWID, which will complete the process started by duplication. This allows you to at least manually complete a duplication.

DBNEWID usage is simple. First, you must make sure you have a good backup taken prior to using DBNEWID. Although it has a verification process, DBNEWID can still encounter unrecoverable errors during the changing of the DBID. After confirming a good backup, you need to get the database shut down in a consistent state and then brought back up to a mounted state: shutdown immediate;

startup mount

Then, run the DBNEWID utility from the command line:

nid target /

DBNEWID: Release 10.2.0.1.0 - Production on Sat Sep 3 14:06:43 2005

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to database AUX1 (DBID 366194736)

Connected to server version 10.2.0

Control Files in database:

/u01/app/oracle/product/oradata/aux1/control01.ctl

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

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

Change database ID of database AUX1? (Y/[N]) > Y

Proceeding with operation

Changing database ID from 366194736 to 366203699

Control File /u01/app/oracle/product/oradata/aux1/control01.ctl

– modified

Control File /u01/app/oracle/product/oradata/aux1/control02.ctl

– modified

Control File /u01/app/oracle/product/oradata/aux1/control03.ctl

– modified

Datafile /u01/app/oracle/product/oradata/aux1/system01.dbf

- dbid changed

Datafile /u01/app/oracle/product/oradata/aux1/undotbs01.dbf

- dbid changed

Chapter 19: Duplication: Cloning the Target Database
489

Datafile /u01/app/oracle/product/oradata/aux1/sysaux01.dbf

- dbid changed

Datafile /u01/app/oracle/product/oradata/aux1/users01.dbf

- dbid changed

Datafile /u01/app/oracle/product/oradata/aux1/temp01.dbf

- dbid changed

Control File /u01/app/oracle/product/oradata/aux1/control01.ctl

- dbid changed

Control File /u01/app/oracle/product/oradata/aux1/control02.ctl

- dbid changed

Control File /u01/app/oracle/product/oradata/aux1/control03.ctl

- dbid changed

Instance shut down

Database ID for database AUX1 changed to 366203699.

All previous backups and archived redo logs for this database are unusable.

Database is not aware of previous backups and archived logs in Recovery

Area.

Database has been shutdown, open database with RESETLOGS option.

Successfully changed database ID.

DBNEWID - Completed successfully.