Oracle RMAN 11g Backup and Recovery (152 page)

event is numbered and in our case the event we are interested in is the 10046 event. When you set the 10046 event, you are telling the Oracle database that you want it to create a trace file and start tracing. Tracing can be enabled at the database or session level. Because of the overhead involved, you want to be cautious about tracing, and only trace the sessions that need to be traced.

Reading the output of a trace file is beyond the scope of this book, and the need to do such a thing should be very rare, indeed. However, you may want to investigate such things, or Oracle might ask you to trace your RMAN sessions. So, we are going to show you how to do it! Depending on your needs, you might want to enable tracing in one of these ways:

■ From the RMAN prompt, use the SQL command to enable 10046 tracing, as seen in this example. This will start tracing only on the sessions that the RMAN client is already connected to. As a result, some sessions will not be traced. Usually, this is the easiest way to trace a session, and it may produce some fruit.

sql "alter session set events ''10046 trace name context forever, level 12''"; RMAN> backup as compressed backupset database plus archivelog delete input;

■ You may also want to start tracing on the recovery catalog database. You can trace the entire database, or you can use the logon trigger demonstrated in the following bullet.

Here is an example of enabling tracing for the recovery catalog database. This example would enable tracing for the whole database. If you wish to be more tactical, you could use the trigger code in the next bullet to just trace RMAN connections.

ALTER SESSION SET EVENTS '10046 trace name context off';

■ If the trace files in the first session do not help identify the problems you might be dealing with, you can create a login trigger to start tracing when a session logon occurs. This example trigger will enable tracing for any RMAN session that connects to the database: Create or replace trigger tr rman logon

After logon on database

Declare

v program varchar2(1000);

Begin

SELECT distinct program into v program

FROM v$session

WHERE audsid userenv('sessionid')

and program like '%rman.exe%' and rownum < 2;

if v program 'rman.exe'

then

execute immediate 'alter session set events ''10046 trace name context

forever, level 12''';

end if;

Exception

when NO DATA FOUND then

NULL;

End;

/

In Oracle Database 11
g,
the resulting trace file can be found in the Automatic Diagnostic Destination directory structure pointed to by the DIAGNOSTIC_DEST parameter. You can use the
462
Part III: Using RMAN Effectively

show
parameter in 11
g
and to find the setting for DIAGNOSTIC_DEST, or you can also look for the default setting for USER_DUMP_DEST to find this directory (this parameter is deprecated in Oracle Database 11
g,
but is still handy to find the file paths for various files in the ADR). In Oracle Database versions previous to Oracle Database 11
g,
you will find the resulting trace files in the directory path pointed to by the USER_DUMP_DEST parameter.

You can find the location and name of a specific trace file if you can identify the session IDs by using the V$SESSION and V$PROCESS views. These views have a column called TRACEFILE

that will give you the name and location of the trace file.

The 10046 trace files created as a result of the scripts in this book are long and complex beasts, well beyond the scope of this book. Most DBAs are aware of the tkprof tool that Oracle offers for reformatting these trace files, and many DBAs are also aware of generally how to read and interpret the resulting output. If you need more information on how to read trace files, several good sources of information are available including books, the Web, and Oracle Metalink.

Summary

RMAN will support very fast backup and recovery schemes given that the appropriate infrastructure is in place to support it. Often, we find the reason that RMAN does not perform well is not because of the database, or because of RMAN, but because of the underlying network or insufficient numbers of backup devices.

We also talked about the times that RMAN is too fast and takes up too much CPU, or floods the network. We discussed the
duration
parameter and its various options that allow you to reduce the overall runtime impact of RMAN operations.

PART

IV

RMAN in the Oracle

Ecosystem

This page intentionally left blank

CHAPTER

19

Duplication: Cloning the

Target Database

466
Part IV: RMAN in the Oracle Ecosystem

e’ve hinted at this chapter’s content since the earliest part of the book: RMAN will help you leverage your backups beyond disaster recovery. We covered using RMAN

for corruption checking and cross-platform database conversion in Chapter 14. But
W
one of the most highly leveraged ways to use backups is to make copies of the production database for testing and development purposes. In the database world, we refer to this as
cloning.

Database cloning can provide an excellent way to test version upgrades, new application rollouts, and even bug patches. Cloning can also be used to prepare reporting databases that are kept separate from transaction processing databases. In these ways, database backups can be put to work. They can be used to restore the database to another system, or even just to another disk on the same system. We can then do load testing for performance reasons, or try out a new hardware configuration. With clone databases at our disposal, we can leave little to chance and have an almost perfect grasp of what will happen if we change our production environment.

RMAN can be also be used to create a standby database that can be kept up to date for disaster recovery. But we are getting ahead of ourselves.

RMAN helps you create clones via the
duplicate
command. This simple little command hides many levels of complexity that are worth knowing about before you begin to use it. In addition, there is a fair amount of prep work required so that duplication goes smoothly. But once understood, and after you’ve had a little time to practice, you’ll find that database duplication is one of the real “killer apps” within the backup and recovery world. Or perhaps you already know this. But leveraging the RMAN interface will save you hours of scripting pain.

RMAN Duplication: A Primer

The RMAN
duplicate
command is a simple command that hides a high level of complexity.

If you’ve ever been through the process of restoring image copy backups of your database to another system, you know the amount of information that you have to keep track of: filenames, file locations, backup locations, archive log information, ftp processes, moving tapes around…

there’s plenty to keep track of. RMAN, on the other hand, has a straightforward command: duplicate target database to aux1;

This will perform the entire process of cloning your target database to another database.

Granted, you have to do a little legwork first, but once you become familiar with the architecture, you’ll see that the legwork is not too bad a trade-off.

Why Use RMAN Duplication?

Why is duplication necessary? Why can’t we just copy the control file to a new location and run a restore and recovery? The answer is: you can! There is no reason that this won’t work. The only problem is, you will have an exact copy—not just of the data in the database (the part you want to be the same), but also of the metadata about the database (this will cause headaches). If you use a recovery catalog, you will run into problems if you clone your database without using duplication. You see, RMAN registers databases in the catalog based on the database ID (DBID), which is a number that identifies your database as unique, even if it has the same DB_NAME as another database. If you don’t use the
duplicate
command, you will have two databases with the