Oracle RMAN 11g Backup and Recovery (160 page)

494
Part IV: RMAN in the Oracle Ecosystem

backups came from, and the
auxiliary database
is the clone database being created from the target database backups.

In the language of the standby database architecture, you have two databases, as well: the
primary database,
which is your current production database, and the
standby database,
which is the unopened copy of the primary database that receives the archived redo logs from the primary database. When you are using RMAN to create a standby database, remember this: the target database is the primary database, and the auxiliary database is the standby database.

The duplicate…for standby Command

The
duplicate
command is used a bit differently when you are using it for standby database creation. As we stated previously, all duplication rules apply, but we must add a few caveats and restrictions.

Memory Considerations

First of all, the DB_NAME parameter in the init.ora file of the standby database must match the DB_NAME of the primary database. This is only marginally interesting news if you are creating your standby database on a different server, but it has important implications if you are building the standby database on the same server as the primary database. Oracle uses the DB_NAME

to lock memory segments at the OS level, so if you try to mount two instances with the same DB_NAME, you will get an error:

To get around this, you can modify the init.ora file of the standby database, and add the parameter LOCK_NAME_SPACE. You set this to a value different from the DB_NAME, and then Oracle uses this to lock memory segments without changing the DB_NAME:

lock name space 'stby'

Because the DB_NAME must be the same, the
duplicate for standby
command does not use the format
duplicate target database to
. This format was necessary to reset the database name in the new control file during duplication, but during standby database creation, we don’t create a new control file. Therefore, the command looks like this: duplicate target database for standby;

Log File Considerations

In addition to not using the missing
to
clause of the
duplicate
command, you cannot use the
logfile
clause when creating a standby. The reason for this has everything to do with standby database options, such as the standby redo log file that is available as part of a Data Guard solution. None of these options applies to the duplication process, but because of them, RMAN

disallows the
logfile
clause. Instead, if you are doing a straight standby database configuration and need to specify a different location for the log files, you need to use the LOG_FILE_NAME_

CONVERT parameter in your standby init.ora file. This parameter acts exactly like DB_FILE_

NAME_CONVERT in that it is a simple string conversion and can be used to change a single directory name, or can be used in pairs to make multiple changes.

Datafile Considerations

If you will be creating your standby database to a different server from the one that holds the primary database, you do not have to change anything about the datafile location, so long as the

Chapter 20: RMAN and Data Guard
495

standby database server has the same mount point and directory structure as the primary database server. As with regular duplication, if you will be using the same datafile locations on the standby database that exist on the primary database, you will need to use the
nofilenamecheck
keyword in the
duplicate
command:

duplicate target database for standby nofilenamecheck;

If you are creating the standby database on the same server as the one that holds the primary database, you are required to change the file locations for the standby datafiles. You can do this in any of the same ways that you would with regular duplication: using the
configure auxname
command, using
set newname
in a
run
block, or using DB_FILE_NAME_CONVERT in the standby init.ora file.

Media Recovery Considerations

A physical standby database is never opened for read/write activity. It is mounted and placed in a state of media recovery, or it is opened in READ-ONLY mode, and users are allowed to perform
select
statements only. Because of this peculiarity, the RMAN duplication performs a little differently than it would if you wanted to clone the database. It doesn’t re-create the control file; it restores a standby control file. It does not, by default, perform any media recovery on the datafiles after restoring them, and then it skips the steps that reset the DBID and open the database reset logs.

So, when the
duplicate…for standby
completes, your standby database is mounted but not open, and you will need to decide how to proceed with media recovery.

If you would like RMAN to perform the initial media recovery and apply archive logs that have been backed up by RMAN, you can use the keyword
dorecover
in your
duplicate
command: duplicate target database for standby dorecover;

Typically, you will want to provide an
until
clause along with your
duplicate
command if you will be doing recovery, particularly if you are creating the standby database at a remote site. If you are at a remote site, using
set until time
or
set until sequence
will enable you to make sure that the recovery attempts to use only archive logs that are available at the other site. Of course, because we aren’t setting the DBID or opening the clone, a failed media recovery session out of the
duplicate
command is no big deal: you can just pick up manually where it left off.

RMAN Workshop:
Create a Standby Database Using RMAN

Workshop Notes

This exercise creates a standby database on the same server as the primary database. The ORACLE_SID for the standby database is stby, but the DB_NAME will be the same as for the primary database: v112. We will use both the DB_FILE_NAME_CONVERT and LOG_FILE_

NAME_CONVERT parameters, and we will perform media recovery.

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

ORACLE SID v112;export ORACLE SID

rman target /

RMAN> backup current controlfile for standby;

496
Part IV: RMAN in the Oracle Ecosystem

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: SQL> alter system switch logfile;

SQL> alter system switch logfile;

SQL> select sequence# from v$archived log;

Step 2.
Build your standby database directory structures:

$ cd $ORACLE BASE

$ cd oradata

$ pwd

/u01/app/oracle/oradata

$ mkdir stby

$ cd ../admin

$ pwd

/u01/app/oracle/admin

$ mkdir stby

$ cd stby

$ mkdir pfile adump bdump cdump udump

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 in order to capture parameters to move over.

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

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

2 from spfile;

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

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

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

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

*.audit file dest '/u01/app/oracle/admin/stby/adump'

*.background dump dest '/u01/app/oracle/admin/stby/bdump'

*.compatible '11.2.0.1.0'

*.control files '/u01/app/oracle/oradata/stby/control01.ctl',

'/u01/app/oracle/oradata/stby/control02.ctl',

'/u01/app/oracle/oradata/stby/control03.ctl'

*.core dump dest '/u01/app/oracle/admin/stby/cdump'

*.db block size 8192

*.db domain ''

*.db file multiblock read count 16

*.db name 'v112'

*.db recovery file dest '/u01/app/oracle/flash recovery area'

*.db recovery file dest size 4294967296

*.job queue processes 10

*.open cursors 300

*.pga aggregate target 93323264

*.processes 150

*.remote login passwordfile 'EXCLUSIVE'

Chapter 20: RMAN and Data Guard
497

*.sga target 279969792

*.undo management 'AUTO'

*.undo tablespace 'UNDOTBS1'

*.user dump dest '/u01/app/oracle/admin/stby/udump'

lock name space 'stby'

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

log file name convert ('v112','stby')

lock name space 'stby'

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

Step 6.
Start up the stby instance in NOMOUNT mode:

ORACLE SID stby; export ORACLE SID

sqlplus "/ as sysdba"

sql>startup nomount

pfile /u01/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 reload

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

STBY

(DESCRIPTION

(ADDRESS LIST

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

)

(CONNECT DATA

(SERVICE NAME stby)

)

)

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

(SID DESC

(GLOBAL DBNAME stby)

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

(SID NAME stby)

)

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

ORACLE SID v112; export ORACLE SID

rman target /

RMAN> connect auxiliary sys/password@stby

RMAN>run {

set until sequence 789 thread 1;

duplicate target database for standby

dorecover;}

498
Part IV: RMAN in the Oracle Ecosystem

Taking Backups from the Standby Database

After creating your standby database, you can use it for a number of purposes. Its primary reason for existence, of course, is to provide a disaster recovery solution for your production database.

However, you can also suspend media recovery against the standby database, open it as readonly, and perform any number of data-mining operations that would suck too many resources away from your production system.

From the RMAN perspective, there is another excellent way to put the standby database to work. As you know from Chapter 16, there is a price to pay for running RMAN against your production database in terms of resources used. You utilize precious memory, CPU, and disk I/O