618
Part V: Appendixes
recordSpec
This subclause defines which objects that commands such as change, crosscheck, delete, and list
will work on.
Syntax Diagram
ARCHIVELOG
’
filename
’
,
primaryKey
,
BACKUPSET
primaryKey
,
BACKUPPIECE
PROXY
’
media_handle
’
,
primaryKey
,
TAG
’
tag_name
’
CONTROLFILECOPY
DATAFILECOPY
’

This subclause is used to specify a directory or an Automatic Storage Management disk group for
disk backups for the RMAN operation that the subclause is used in.
Syntax Diagram
’
toDest_string
’
untilClause
This subclause defines a limit based on time, SCN, restore point, or log sequence number that is
referenced by the parent RMAN command.
Syntax Diagram
UNTIL SCN
integer
UNTIL SEQUENCE
integer
THREAD
integer
UNTIL TIME
’
date_string
’
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
This page intentionally left blank
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
APPENDIX
B
RMAN Scripting
Examples
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
622
Part V: Appendixes

set oracle sid %1
if "%2" "backup" rman target / cmdfile c:\oracle\scripts\backup.scr
if not ERRORLEVEL 0 echo "WARNING - FAILURE OCCURRED"
if "%2" "arch" rman target / cmdfile c:\oracle\scripts\arch.scr
if not ERRORLEVEL 0 echo "WARNING - FAILURE OCCURRED"
Note that this script calls two command files, backup.scr and arch.scr, which in this case are
located in the c:\oracle\scripts directory.
Here is the backup.scr script:
Backup as compressed backupset database plus archivelog delete input;
This is the arch.scr script:
Backup as compressed backupset archivelog all delete input;
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Appendix B: RMAN Scripting Examples
623
Again, each of these scripts would be created using a text editor and placed in the c:\oracle\
scripts directory. If you put them somewhere else, you will need to edit the backup.bat script to
point to the correct location of these scripts.
Scheduling the Backup
Now, we want to schedule the backup. We will use the Windows schtasks utility to perform this
operation. In our experience, schtasks is a rarely used but powerful scheduling utility. In this
example, we are scheduling a daily database backup using the backup.bat file. We also have
an example of scheduling the archived redo log backup and an example of how to remove a
scheduled task:
schtasks /create /tn "database backup" /sc weekly /d SUN /st 14:50:00 /tr
"c:\bc\rman\backup.bat rob10r2 backup>\>c:\bc\rman\backup.output"
rem schtasks /delete /tn "database backup"
schtasks /create /tn "archivelog backup" /sc daily /st 14:50:00 /tr
"c:\bc\rman\backup.bat rob10r2 arch>\>c:\bc\rman\backup.output"
You have a number of scheduling options when using the schtasks scheduler. The schtasks
scheduler will request the login ID of the user that will be running the job.

Part V: Appendixes
s the complexity of production enterprise environments grows with each passing
year, we DBAs are finding the same complexity creeping into our test environments.
For example, in Oracle9i RMAN Backup & Recovery, the test environment was
seemingly complex for us: a Windows laptop for minor tweaks and screen shots,
another Windows server for more robust testing, and a Sun Blade 150 for multi-OS
interaction and Unix commands. Among these three machines, we were able to do all technical
reviews (combined with years of actual experience in the workplace, of course).
For the 10g RMAN book, the test environment included two Linux boxes with a shared
FireWire disk drive (running RAC, of course), Matthew’s trusty Windows laptop, that old Sun
Blade, and a stand-alone Linux box. And Matthew still went hunting with his colleagues looking
for other RAC clusters, tape storage jukeboxes, and Oracle Enterprise Manager repositories.
That being said, things have taken an interesting turn since the last book. We authors had to
travel significantly during the production of this book, so the needs changed dramatically, from
a tactical standpoint. Because of the up and down, thrashed and trashed nature of B&R testing,
testing from a remote location can be difficult. And you can’t connect to your datacenter from a
plane yet. Yet. In addition, this was the first time that we wrote against Beta code (long story), so
there are plenty of hiccups that simply prevented traditional solutions.
So, what did our test environment look like this time? One late-model Apple MacBook Pro,
running VMWare Fusion, and an external hard drive. That’s it. (Okay, Matthew still relied on
those RAC clusters in the datacenter.) He installed RHEL 5, copied the VMWare slice, and had a
multiserver environment running from his laptop—gotta love modern times. Now, Matthew had
a completely mobile lab environment, with plenty of hard-drive space and a built-in way to trash
everything and start over using his virtual snapshots. The only limit was that his late-model Mac
had 3GB of memory, so he had to pick and choose environments carefully when running them
simultaneously. With new models running up to 8GB, Matthew’s looking forward to having that
problem solved soon as well.
Granted, as discussed later in this appendix, this does not, in any way, come close to looking
like a true production environment. Therefore, he can’t do any performance benchmarking on his
laptop, or expect that he has ensured that scripts are free of bugs in production. But, with the

production-grade database server. That way, you can schedule time on a test box for a backup/
recovery test outage, and avoid spending that valuable time trying to learn lessons that you could
have figured out on your workstation.
So, what does this approach look like more specifically? The answer is provided in this
appendix.
The Test Box
The first-level test machine for RMAN functionality doesn’t need to be a supercomputer. In fact,
you should think of the first level of testing as just a rehearsal—you’re reading through your lines,
getting the placement right, and talking through the steps with the other actors and the director.
Match Your Production Environment
If possible, your RMAN testing should take place on the same operating system that you run
in production. This is a rather humorous thing to say, we know: who has a single OS in their
environment anymore? Anyway, if you will be backing up only Solaris servers, it makes sense
to invest a little money in a Sun workstation. That way, you can begin production environment
matching as soon as possible.
Go Cheap
It’s not that critical to have your first wave of testing take place on the same OS as your
production environment. RMAN acts the same on all platforms, and the exercises in this book
work on all platforms. So, if you’re in the market for an RMAN test box, we have only two words:
go cheap. Buy a commodity-priced computer that runs Windows or Linux. I’ve grown quite fond
of my cut-rate Linux cluster that Scott Jesse outlined in the Oracle Press book Oracle Database
10g High Availability with RAC, Flashback, and Data Guard (2004). It is a two-node RAC tester
for under $1,500, bought refurbished from Dell’s Outlet. As far as what to look for in a cheap test
environment, we provide the following advice:
Processor speed Don’t worry about processor speed at the RMAN proof-of-concept
level. RMAN simply does not rely on CPUs that heavily. As you move into heavy
parallelization in production, CPU speeds might grow in testing importance. Even if you
monitor for performance at this level, the data is meaningless when compared with your
production environment. Instead, spend money on other resources, mainly disk space
and memory.

even better scenario would be to use databases that are configured somewhat like production
databases. From a size perspective, that may not be possible, but you can scale datafile sizes
down while keeping the same number of datafiles and tablespaces.
In addition, try scaling down the memory utilization of these test boxes to be as low as
possible. You won’t actually be doing that much processing, so you don’t need a lot of buffer
cache available. The smaller you keep the System Global Area (SGA), the better off your little
test box will be.
You also need a recovery catalog database that is separate from the target databases that you
are using for testing. We always recommend that your recovery catalog database be the most
recent version, so put this in a 11.2 home. In a pinch, this can also be used as a target database,
but try to keep your recovery catalog database out of the mix of databases that you blow away
and rebuild. It just makes life easier. If at all possible, put your recovery catalog database on a
different server. Put it on a Windows workstation or an old Linux box. Keep it out of the crash-
and-burn destruction path.
■
■
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Appendix C: Setting Up an RMAN Test Environment
629
Using Oracle ASM
If you plan to test Oracle’s volume manager, Automatic Storage Management (ASM), you have to
make preparations when you first configure your RMAN test box. In a production environment,
you would simply add full, raw disks to an ASM disk group. In a test environment, if you want
to test multiple ASM disk groups, you can simply use logical partitions on a single disk. But this
means you have to think ahead and create some unused, raw partitions on your disks before you
get too far into your OS setup.
Oracle Enterprise Manager
If you plan to use OEM, make sure there is enough memory to do so. As you learned in Chapter
13, there are two flavors of OEM you can choose from: Database Control and Grid Control. From
a testing perspective, it might make sense to go with Database Control to save on resources and

backups to a disk location. This is described in the RMAN Workshop “Test Tape Channels with
the Oracle Default SBT Interface” in Chapter 4.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
630
Part V: Appendixes
The RMAN Configuration
Now that you have your system set up with Oracle installed and databases built, we have a few
hints on the testing process:
Have a cold backup that remains untouched. Before you do any RMAN testing, shut
down your database, take a cold OS copy backup, and place it in a folder that doesn’t
get touched. This is your last line of defense if you completely mess everything up during
your RMAN testing.
Switch your redo logs a lot. One of the biggest mistakes that happens with RMAN testing
is that the timeframe between the backup and restore is unrealistically short. Confusion
sets in because there is no space between the completion time of the backup and the
“until time” of the restore operation. So, after any backup, make sure you switch the log
file three or four times, just to put a little “distance” between operations.
Set the NLS_DATE_FORMAT environment variable. This is good advice for RMAN in
general, but particularly in a test situation, where the timeframe between a backup and a
restore will be unrealistically short, and you will want to know the timeframe of a backup
to the second. So, before starting RMAN, be sure to run the following:
export NLS DATE FORMAT 'mon-dd-yyyy hh24:mi:ss'
Then, when you start RMAN and issue a list backup command, the time will always
show details to the minute and second.
Leave your catalog database alone. You will be tempted to use the database that houses
your catalog as a target and to perform some tests with it. That is fine—that’s why it’s
called a test environment. But you can seriously undermine your testing if you foul up
your catalog. Do yourself a favor and leave the catalog database alone. And export your
catalog schema with a user-level export before any new test session begins.
Keep up with catalog maintenance. This may be your test environment, but you will be

gained, and schedule some time on a production-grade system to make sure that everything is
going to scale up to your enterprise. You’ll be glad you took the time to learn it before you went
live.
■
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
This page intentionally left blank
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.