Oracle RMAN 11g Backup and Recovery (159 page)

[oracle@dex oracle]$ sqlplus "/ as sysdba"

SQL> alter database open resetlogs;

Summary

In this chapter, we discussed the architecture behind the RMAN duplication process. Using duplication, we can produce clone databases from our RMAN backups to either the local system or a remote server. There are different configuration steps, depending on whether you will be duplicating locally or remotely. In addition, you have specific guidelines to follow depending on whether your backups are on disk or on tape. Two RMAN Workshops gave step-by-step instructions for duplication. We wrapped everything up with a brief discussion of the DBNEWID

utility that comes with Oracle Database 10
g
and later
.

This page intentionally left blank

CHAPTER

20

RMAN and Data Guard

492
Part IV: RMAN in the Oracle Ecosystem

any DBAs are already familiar with the functionality known as Oracle Standby Database. It is an architectural feature that adds a little functionality to operations
M
that already take place on your system: the archiving of every single change that happens on a database. The Standby Database started as a simple concept, and although the overall architecture is now referred to as Data Guard, the foundation is still simple: take the archive logs from your production database, move them to another computer that has a copy of that database, and apply the archive logs to the copy. In such a way, Data Guard is able to provide an efficient disaster recovery solution by maintaining transactionally consistent copies of the production database at a remote site. These copies, or standbys, can be one of two types, physical or logical. Which one you choose to include in your Data Guard configuration depends on what business needs you are trying to satisfy.

A
physical
standby database is kept in sync with the primary database by using media recovery to apply redo that was generated on the primary database. Because media recovery is used, we can be assured that a physical standby is a block-for-block identical copy of the primary database.

Because of its nature, a physical standby database is an excellent choice for disaster recovery. In the event of a failure, we can rest assured that our data will be intact and consistent with data that existed on the primary database.

A
logical
standby database is kept in sync with the primary database by transforming redo data received from the primary database into logical SQL statements, and then executing those SQL statements against the standby database. Because we are applying SQL statements instead of performing media recovery, it is possible for the logical standby database to contain the same logical information as the primary database, but at the same time to have a different physical structure. Because a logical standby database is open for user access while applying changes, it is an ideal solution for a reporting database while maintaining its disaster recovery attributes.

RMAN and Data Guard are complementary technologies that together make a complete Oracle solution for disaster recovery and high availability. RMAN backups can be used to create the underlying standby database, along with providing the initial recovery phase. Then, after you have created the standby database and configured the Data Guard broker, RMAN can connect to the standby database and take backups that can be restored to the primary database. In this way, the resources used to perform a backup can be completely removed from your production environment.

Obviously, this book is about RMAN and not Data Guard. If you have more questions about standby databases or Data Guard, check out the Oracle Press titles on Data Guard (the latest from Larry Carpenter and company is excellent). From here on in this chapter, we assume that you are familiar with the basics of Data Guard standby databases and are ready to create one using RMAN.

RMAN and the Standby Database

Primarily, the relationship between RMAN and the standby database is a simple one: RMAN is used to create the standby database. If you are implementing a backup strategy that has RMAN

doing all of your backups, you wouldn’t really have any choice but to use RMAN, because the standby database must have primary database datafiles copied into place to begin with.

As of Oracle Database 10
g,
RMAN backups can be used to create both physical and logical standby databases. This was not the case in Oracle9
i
Database, because the primary database had to be quiesced prior to taking a backup to be used for a logical standby. Now, however, a hot backup can be used as the basis for a logical standby database, and that means RMAN

backups can be used.

Chapter 20: RMAN and Data Guard
493

However, if you were a reader of our
Oracle10
g
RMAN Backup & Recovery
book, you may find that we have changed little in the instructions that follow. This is because RMAN does not discriminate between creating a physical and a logical standby database. RMAN does not discriminate because the first step to creating a logical standby database is to create a physical standby database. After you create a physical standby database, a conversion takes place to turn it into a logical standby database.

And RMAN is involved only in the physical creation, leaving the logical standby conversion to you.

Requirements for Using RMAN for Standby

Database Creation

Before RMAN can create the standby database, you have to walk through a few initial steps.

These steps are identical to those outlined in the duplication process in Chapter 17:
1.
Make all necessary changes in both the primary and standby database init.ora files.

2.
Complete all necessary Oracle Net configuration.

3.
Start the standby database in NOMOUNT mode.

The reason for these steps is that RMAN uses the
duplicate
command to create the standby database, so all rules that apply to duplication also apply to standby database creation. This means that any file-renaming issues are the same, the password file requirement is the same, and the way that you have to configure the listener.ora and tnsnames.ora files is the same. If you’re not sure what we’re talking about, review Chapter 19 prior to proceeding: everything from here on is in addition to the duplication requirements and restrictions laid out in Chapter 19.

In addition to reviewing Chapter 19, you must also have a specific kind of control file backup.

A regular control file backup is not used when we create a standby database, because a standby database control file is different from a regular control file. It places more stringent conditions on applying archive logs during media recovery. A standby control file also does not allow a standby database to be opened with an
alter database open
command. Instead, you must activate a standby database (and thus make it the primary database) by using
alter database activate standby
database
.

To create a standby control file, you can use a SQL command:

alter database create standby controlfile as

'/u04/backup/stby cfile01.ctl';

If you create a standby control file in this fashion, you have to catalog it with RMAN before RMAN can use it in a
duplicate…for standby
operation:

RMAN>catalog controlfilecopy '/u04/backup/stby cfile01.ctl';

Even simpler, you can use RMAN to create a standby control file. That way, you can create a copy on your tape device (if you use tape backups) using the
backup
command: RMAN> backup current controlfile for standby;

Once you’ve got a standby control file ready, you can move forward with your standby database creation using RMAN.

Finally, before we discuss the commands for creating your standby database, a little vocabulary lesson will come in handy. As you know from Chapter 19, the RMAN duplication process refers to two databases: the target database and the auxiliary database. The
target database
is where the