Oracle RMAN 11g Backup and Recovery (164 page)

mkdir /u02/32bit/app/oracle/oradata/aux1/arch

cd /u02/32bit/app/oracle/admin

mkdir aux1

cd aux1

mkdir pfile bdump udump cdump

ls

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

create pfile '/u02/32bit/app/oracle/admin/aux1/pfile/init.ora'

from spfile;

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

cp /u02/32bit/app/oracle/admin/V112B/pfile/init.ora

/u02/32bit/app/oracle/admin/aux1/pfile/init.ora

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

control files

'/u02/32bit/app/oracle/oradata/aux1/control01.dbf'

core dump dest '/u02/32bit/app/oracle/admin/aux1/cdump'

background dump dest '/u02/32bit/app/oracle/admin/aux1/bdump'

user dump dest /u02/32bit/app/oracle/admin/aux1/udump

log archive dest 1

'location /u02/32bit/app/oracle/oradata/aux1/arch'

db name 'aux1'

instance name 'aux1'

remote login passwordfile exclusive

Chapter 21: RMAN and Real Application Clusters
511

db file name convert

('/dev/vx/rdsk/usupport dg', '/u02/32bit/app/oracle/oradata/aux1')

You can remove the following parameters entirely, including those that refer to the other instance:

cluster database instances 2

cluster database true

V112A.instance name 'V112A'

V112B.instance name 'V112B'

V112B.instance number 2

V112A.instance number 1

V112B.thread 2

V112A.thread 1

V112B.undo tablespace 'UNDOTBS2'

V112A.undo tablespace 'UNDOTBS1'

You can replace them by just having the following:

undo tablespace 'UNDOTBS2'

Step 4.
Build your aux1 password file. Refer to the “Building a Password File” RMAN Workshop in Chapter 19.

Step 5.
Start the aux1 instance in NOMOUNT mode:

ORACLE SID aux1

export ORACLE SID

SQLplus /nolog

SQL>connect / as sysdba

SQL>startup nomount

pfile /u02/32bit/app/oracle/admin/aux1/pfile/init.ora

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

LSNRCTL>stop

LSNRCTL>start

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

AUX1

(DESCRIPTION

(ADDRESS LIST

(ADDRESS (PROTOCOL TCP)(HOST opcbsol2)(PORT 1526))

)

(CONNECT DATA

(SID aux1)

(SERVER DEDICATED)

)

)

512
Part IV: RMAN in the Oracle Ecosystem

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

(SID DESC

(GLOBAL DBNAME aux1)

(ORACLE HOME /u02/32bit/app/oracle/product/11.2.0/dbhome 1)

(SID NAME aux1)

)

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

ORACLE SID V112B

export ORACLE SID

rman

rman>connect target /

rman> connect auxiliary sys/password@aux1

rman>duplicate target database to aux1

pfile /u02/32bit/app/oracle/admin/aux1/pfile/init.ora

logfile

'/u02/32bit/app/oracle/oradata/aux1/redo1.dbf' size 100m,

'/u02/32bit/app/oracle/oradata/aux1/redo2.dbf' size 100m,

'/u02/32bit/app/oracle/oradata/aux1/redo3.dbf' size 100m;

The Single-Node Standby Database

Of course, if we can duplicate to a single node, then we can also use the
duplicate
command to create a standby database for our RAC cluster on a single node. Perhaps more so than even straight duplication, this feature gives us an excellent cost-to-performance strategy for providing a disaster recovery solution for our RAC database. Instead of purchasing all the hardware and software necessary to have a complete second RAC system set up but unused for a standby database, you can create the standby database on a single-node system. Obviously, it won’t have the computing power or load-balancing features of the RAC database, but it gives a reasonable disaster recovery solution so that you can hobble along until the RAC database is restored.

As with the duplication process, the secret lies in using the DB_FILE_NAME_CONVERT

parameter to switch the files from OCFS or ASM disk groups to normal, nonclustered file systems.

In addition, the single-node standby database can receive archive logs from each of the nodes in the RAC cluster and apply them in the correct chronological order.

RMAN Workshop:
Creating a Single-Node Standby Database

from a RAC Database

Step 1.
Use RMAN to create a standby control file:

ORACLE SID V112B

export ORACLE SID

rman

Chapter 21: RMAN and Real Application Clusters
513

rman> connect target /

rman> backup current controlfile for standby

format '/u02/backup/stby cfile.%U';

You need to specify a point in time after you created this standby control file, so perform a few log switches, and then record the last log sequence number from V$ARCHIVED_LOG. It doesn’t matter which thread you choose, because the following command will force a log switch at all nodes:

SQL> alter system archivelog current;

SQL> select sequence# from v$archived log;

Step 2.
Build your standby database directory structures:

mkdir /u02/32bit/app/oracle/oradata/stby

mkdir /u02/32bit/app/oracle/oradata/stby/arch

cd /u02/32bit/app/oracle/admin

mkdir stby

cd stby

mkdir pfile bdump udump cdump

ls

Step 3.
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

create pfile '/u02/32bit/app/oracle/admin/stby/pfile/init.ora'

from spfile;

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

cp /u02/32bit/app/oracle/admin/V112/pfile/init.ora

/u02/32bit/app/oracle/admin/stby/pfile/init.ora

Step 4.
Make all necessary changes to your stby init.ora file:

control files '/u02/32bit/app/oracle/oradata/stby/control01.dbf'

background dump dest /u02/32bit/app/oracle/admin/stby/bdump

user dump dest /u02/32bit/app/oracle/admin/stby/udump

log archive dest 1

'location /u02/32bit/app/oracle/oradata/stby/arch'

standby archive dest

'location /u02/32bit/app/oracle/oradata/stbyarch'

lock name space 'stby'

remote login passwordfile exclusive

db file name convert

('/dev/vx/rdsk/usupport dg', '/u02/32bit/app/oracle/oradata/aux1')

log file name convert

('/dev/vx/rdsk/usupport dg', '/u02/32bit/app/oracle/oradata/aux1')

514
Part IV: RMAN in the Oracle Ecosystem

You can remove the following parameters entirely, including those that refer to the other instance:

cluster database instances 2

cluster database true

V112A.instance name 'V112A'

V112B.instance name 'V112B'

V112B.instance number 2

V112A.instance number 1

V112B.thread 2

V112A.thread 1

V112B.undo tablespace 'UNDOTBS2'

V102A.undo tablespace 'UNDOTBS1'

You can replace them by just having the following:

instance name 'V112B'

undo tablespace 'UNDOTBS2'

Step 5.
Build your stby password file. Refer to the “Building a Password File” RMAN Workshop in Chapter 19.

Step 6.
Start the stby instance in NOMOUNT mode:

ORACLE SID stby

export ORACLE SID

SQLplus /nolog

SQL>connect / as sysdba

SQL>startup nomount

pfile /u02/32bit/app/oracle/admin/stby/pfile/init.ora

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

LSNRCTL>stop

LSNRCTL>start

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

STBY

(DESCRIPTION

(ADDRESS LIST

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

)

(CONNECT DATA

(SID stby)

(SERVER DEDICATED)

)

)

Chapter 21: RMAN and Real Application Clusters
515

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

(SID DESC

(GLOBAL DBNAME aux1)

(ORACLE HOME /u02/32bit/app/oracle/product/11.2.0/dbhome 1)

(SID NAME aux1)

)

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

ORACLE SID V112B

export ORACLE SID

rman

rman>connect target /

rman> connect auxiliary sys/password@stby

rman>run {

set until sequence 43 thread 1;

duplicate target database for standby

dorecover;}

Backing Up the Multinode RAC Database

Once you have created the single-node standby database, you can take all of your backups from the standby database, just as you would in a normal environment. This means that you can offload your production RAC backups from the RAC cluster itself to the node that is set up and running as a standby database. This takes the load off the cluster, gives you a disaster recovery solution, and gives you a simplified backup solution for archive logs, because all the archive logs from all nodes will necessarily exist on the standby database.

Again, the secret is in the DB_FILE_NAME_CONVERT parameter. You are taking backups from the standby database that has the datafiles on a cooked file system, but even the standby database control file knows the original location of the files (the raw system). So, when you go to restore a backup taken from the standby on the production RAC database, RMAN checks with the control file, finds the raw locations, and places the files there.

For such a solution to work for you, you must use a recovery catalog. The recovery catalog acts as the transition agent for the metadata about the backups from the standby database control file to the primary database control file. After you take the backup from the standby database, RMAN resyncs with the recovery catalog, recording the backup metadata. Then, when you connect RMAN to the primary database and perform a manual resync, the backup metadata from the standby database control file is placed in the primary database control file records.

It is important to make sure that you connect to the standby database as the target database when performing backups from the standby database. Then, you connect to the primary database as the target database as well, to perform the resync. RMAN can do this smoothly because it sees no functional difference between the two databases: they have the same DB_NAME, the same DBID, and the same redo stream history.

516
Part IV: RMAN in the Oracle Ecosystem

Summary

In this chapter, we discussed the means by which RMAN interacts with databases in RAC clusters.

We discussed how RMAN can allocate channels on each node for backup, but that recovery requires that all backups be accessible from a single node. We discussed the complications caused in archive log backups due to multiple threads of redo being generated at different nodes. We concluded with examples for duplicating a RAC database to a single-node database and for creating a single-node standby database from a RAC database.

CHAPTER

22

RMAN in Sync and Split

Technology