Oracle RMAN 11g Backup and Recovery (161 page)

resources when the backup is running. So, we recommend running your backups during the off-peak hours of your database. Sometimes, though, there are no off-peak hours. You could be a 24-hour operation, with constant database updates, or your database could be so large that backups are pretty much running around the clock.

If you have a physical standby database, you can take your production backups from the standby database; these backups can then be restored to the primary database if the primary database has a failure. Because the standby database has the same DBID as the primary database and is always from the same incarnation, the RMAN datafile backups are interchangeable between the standby database and the primary database. The standby database is a true clone of the primary database.

The thing to understand about using a standby database to take production backups is that RMAN will connect to the standby database as the target database. Remember, up to this point, we’ve encouraged you to think of the standby database as the auxiliary database. But that only holds true for duplication operations. Once the standby database is established, you can connect to it as the target database and perform
backup
commands. These backups can then be used for restore operations at the primary database.

To use the standby database in this fashion, you must have a recovery catalog set up. Without a recovery catalog, there is no way to propagate the records of the backups from the standby control file to the primary control file. With a recovery catalog, you resync with the standby control file after a backup, so the records of the backup are put in the catalog. Then, you connect to the primary database as the target and make your catalog connection. To RMAN, the primary and standby databases are indistinguishable, so it accesses the same record set in the catalog when connected to either. Therefore, you can perform a resync operation while connected to the primary database, and it will refresh the primary control file with the records of backups taken while connected to the standby database.

Using the UR=A Parameter

If you are using instance registration, there will not be any entries in the listener.ora file by default for the database. You can manually configure the database entry in the listener. Or, you can update the tnsnames.ora file with the parameter UR=A. This is to allow administrative connections only; for example:

CONNECT DATA ((SID ....) (UR A))

There is also the possibility of changing from using a pfile to an spfile in 11
g
that allows you to get past the blocked connection errors due to instance registration. This is effective for duplication from backups or from an active database.

Chapter 20: RMAN and Data Guard
499

Impact of the DB_UNIQUE_NAME Initialization Parameter

In 11
g,
the parameter DB_UNIQUE_NAME must be set for a database if that database will exist in a database ecosystem with other databases with the same DB_NAME parameter—for example, when a reporting database is in the same environment as the production database, or when a standby database exists for a primary database. The value of DB_UNIQUE_NAME must be unique for every database in the enterprise.

RMAN, as we stated, requires access to the recovery catalog in order to perform backups from the standby database. To assist in this, RMAN is aware of the setting of DB_UNIQUE_NAME in the recovery catalog, and when it is set, RMAN can track the exact location where a backup is taken, without limiting where it can be restored to (based on the DBID being the same).

For example, in some situations, you will use two standby databases as part of your overall solution: standby1 database has a lag of 5 minutes, and standby2 has a lag of 30 minutes to ensure no errors are propagated to standby2 in case standby1 is corrupted. In this environment, you would set each database’s DB_UNIQUE_NAME to standby1 and standby2, respectively.

Then, RMAN can connect to any of the databases to back up from, and RMAN will know exactly which database the backup came from. Keep in mind if you are backing up from the standby1

and it goes down for any amount of time, recovery is still running on standby2, and backups can continue without impacting production.

Datafile Backups from the Standby Database

Backing up the datafiles from the standby database is the most common activity. To back up the datafiles and then use them at the primary database, you would do something like this:
1.
From RMAN, connect to the standby database as the target, and connect to the recovery catalog:

RMAN> connect target sys/pswd@stby

RMAN> connect catalog rman/rman@rcat

2.
Take your database backup. The catalog is automatically resynchronized after any
backup
command.

RMAN>backup database;

3.
Exit RMAN and then start it again (this is the only way to disconnect from the target and catalog):

RMAN> exit

$ rman

4.
Connect to your primary database as the target, and connect to the catalog: RMAN> connect target sys/pswd@sun92

RMAN>resync catalog;

5.
Perform a
restore
operation that utilizes backups taken from the standby database: RMAN> restore datafile 3;

RMAN> recover datafile 3;

Archive Log Backups from the Standby Database

Backing up the archive logs from the standby database is a somewhat trickier affair because of how RMAN determines which archive logs need to be backed up: it checks the view V$ARCHIVED_LOG.

On the primary database, this view is incremented with each new archive log after it has been
500
Part IV: RMAN in the Oracle Ecosystem

successfully created in the LOG_ARCHIVE_DEST. However, on the standby database, this view is updated only if your standby database is in MANAGED RECOVERY mode (where the archive logs are automatically applied at the standby database). If your standby database is not in MANAGED

RECOVERY mode, or if, due to your setup, you will get archive log gaps at the standby database on a regular basis, it may be hard to get all the required archive logs backed up successfully from the standby database. In this case, we recommend using your primary database for its own archive log backups and using the standby database just for datafile backups.

Using Flashback Database for Standby Database

Reinstantiation

We weren’t sure where to mention this neat little trick that crosses the boundaries of multiple distinct Oracle technologies. We decided that if you were reading this chapter, you were interested in Data Guard implementations, but if you read Chapter 13 on Flashback Technology, you may not be. So, here it is.

One of the toughest moments of a Data Guard implementation is failing over your production database to the standby database. Despite all the preparation and testing, failing over still leaves a knot in the belly. When (if!) it happens to you, we hope it all goes well.

The second toughest moment is coming to terms with how to put the Data Guard deployment back into operation. In other words, now that your standby database has become your primary database, what do you do next? This is truly a question for another book, but it’s worth mentioning in this context because Oracle used some of its own tricks to help you out with the tough next step: rebuilding a new standby database after failover.

Here’s how it went down in the old days: Suppose your production database is PROD, and your standby is PROD2. You lose PROD for some reason. You fail over to PROD2, which becomes your new primary database. Then, you take a full new backup of PROD2, move it over to the computer housing PROD, and lay it down over the top of PROD. Next, you start shipping logs from PROD2 to PROD. At some point, perhaps, you purposefully fail back over to PROD, and then this labor- and resource-intensive process repeats.

Fast forward to modern times, and a new way of rebuilding the standby database emerges: you can use Flashback Database for standby database reinstantiation. When a failover occurs from the primary database to the standby database, in the past you were forced to use backups to restore a copy of the new primary database back to the old primary database and make it a standby database, and then to fail back over. Now, you can instead use Flashback Database on the old primary database to move it back to the exact SCN where the standby database was prior to activation. Then, you set up the flow of archive logs from the new primary database to the old primary database, give it a new standby control file, and you are back in business in minutes.

Summary

In this chapter, we discussed the relationship that RMAN can have with the standby database architecture. Primarily, RMAN can be used to create the standby database using the
duplicate…

for standby
command. We discussed the means by which you use the
duplicate
command to create the standby database and included an RMAN Workshop that walked through the steps of creating the standby database on the same server as the primary database. Then, we discussed how you could use an existing standby database to create backups using RMAN that could be restored to the primary database, as a means of offloading the work away from the production environment.

CHAPTER

21

RMAN and Real

Application Clusters

502
Part IV: RMAN in the Oracle Ecosystem

hile it is well beyond the scope of this book to guide you through the intricacies of Oracle Real Application Clusters (RAC), we can provide some guidance on preparing
W
your RAC configuration for backup and recovery. As with Data Guard in Chapter 20, we assume that you have a working knowledge of RAC in Oracle Database 11
g,
and thus, our brief discussion of RAC architecture is intended more as a reminder than as an education.

Throughout this chapter, we will use an example cluster database that has only two nodes: winrac1 and winrac2. These nodes share a disk array, which is configured with Oracle ASM as its volume manager. Each node has an instance: prod1 on winrac1, and prod2 on winrac2. While we will limit our explanations to the simplest of RAC environments—a two-node cluster—nothing changes when you scale out to three, four, or more nodes. In our examples, you simply change the number of nodes from 2 to 3, and the number of channels from 2 to 3, and so on. The more nodes you have, the more complex your backup/recovery strategies and scripts, but the basic rules apply no matter the number of instances.

There are two basic ways to share a file system across multiple computers. The first, which was also available with Oracle9
i
Database, is to use a clustered file system. This is frequently provided by a third-party vendor, such as VERITAS. On Windows and Linux, Oracle provides its own Cluster File System (OCFS). A cluster file system is defined by its ability to properly handle and queue requests for files coming from multiple nodes simultaneously—which is a requirement if you are going to cluster your databases.

The second way to share a file system across multiple computers, introduced in Oracle Database 10
g,
is to use Automatic Storage Management (ASM). ASM is Oracle’s first volume management product and can be used to manage raw disks that have no other formatting on them. Because of its architecture, ASM is built for cluster configurations and can easily handle the demands of RAC. You could say that ASM was built for RAC, because if you decide to deploy RAC on Oracle Standard Edition, ASM is the
only
file system allowed for the shared Oracle database files.

And that is all you’re going to get from us on the subject, except to say this: you can still use manually built raw partitions on a shared disk array to arrange your RAC datafiles and log files.

So, if you desire, you do not need a cluster file system or ASM. You just need raw, uncooked, shared disks. However, we do not recommend this, nor will we spend more than a fleeting moment explaining how to configure RMAN to back up a RAC database running on raw disks.

This is because, given the opportunity to simplify your life with OCFS or ASM, manually maintaining raw disks is folly. There, we said it. In particular, when it comes to backup and recovery on RAC, OCFS and ASM will save your life. Using raw disks will only lead to blood, sweat, tears, and updated résumés.