Oracle RMAN 11g Backup and Recovery (184 page)

#/bin/ksh

# Script name: backup.ksh

# Usage: backup.ksh

# Note: We assume the oracle environment is already setup except for

# ORACLE HOME. If not, you will need to setup your environment correctly.

set ORACLE SID $1

if [ "$2" "backup" ]; then

rman target / cmdfile /home/oracle/scripts/backup.scr

fi

if [ "$2" "arch" ]; then

rman target / cmdfile /home/oracle/scripts/arch.scr

fi

The backup.scr script is the same as you saw earlier:

Backup as compressed backupset database plus archivelog delete input;

As is the arch.scr script:

Backup as compressed backupset archivelog all delete input;

This page intentionally left blank

APPENDIX

C

Setting Up an RMAN

Test Environment

626
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
Oracle9
i
RMAN Backup & Recovery,
the test environment was
A
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 10
g
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 exact OS running (RHEL) and exact database version, he has gone a long way toward assurance that he knows what he’s doing and how it will behave.

As stated back in
Oracle9
i
RMAN Backup & Recovery,
test environments can be tricky to describe or to provide advice about. Every shop has its own concept of what testing is required, and at what level, for application design, quality assurance, version control, and so forth. And with RMAN playing a more integral role in a wider array of DBA activities, it’s increasingly difficult to separate an RMAN test environment from other test environments. But, you are looking at this book now, and we have opinions on testing backup strategies. As we like to say, everyone has a backup strategy. Few have a recovery strategy. Testing backups is only a fraction of the work. If you do not test your recovery strategies, then you don’t have backups, no matter how many files you’ve written to how many thousands of dollars’ worth of equipment.

A test environment for backup and recovery is different from other testing environments. First of all, you have to be able to remove datafiles, or even the entire database, on a whim, without having to clear it with other users. In other words, you need your own database. Or two. If you begin testing RMAN functionality on a shared database, pretty soon you’ll either start getting angry phone calls from other users, or find yourself locked out of the machine by the SA.

Appendix C: Setting Up an RMAN Test Environment
627

A backup and recovery test environment is simply too volatile to share. Think about it from the other end: you’re busy testing a backup yourself, when suddenly the backup aborts because someone started removing datafiles in order to test their own restore and recovery.

On the other hand, you need to test your strategies in an environment that most closely matches that of your production databases. Therefore, you can’t always run in isolation, because you might need to tune your backup on a large, production-grade server that has the same kind of load as production.

What we suggest, then, is that you approach RMAN backup and recovery testing as a two-tiered investigation: First, get comfortable with functionality and behavior in the isolation of a small test server. Second, take the lessons you’ve learned, and schedule time to test on a larger, 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
10
g
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.

628
Part V: Appendixes

■
Memory
You need enough memory to run three Oracle instances simultaneously, along with your media management software. If you will be testing with OEM or some other management software package, factor that in as well. This means that you need 2GB minimum. Don’t cut corners on memory, or you will get sucked down into time-consuming swap rat holes from which there is no escape.

■
Disk space
Disks are cheap, and you don’t need some SCSI disk or anything, just space.

Speed, again, is not important at this level. A 200GB hard drive should be sufficient.

You’re doing concept testing at this level, so you can limit the size of databases to keep things under control. But keep in mind that you’re going to have more than one database, and you will also be backing up to disk (most likely), so you need space for RMAN

backup pieces, as well. So load up on disk space if you can.

If you decide to do a RAC tester, you need an external SCSI or FireWire drive in addition to whatever you load internally into your box. Again, consult
Oracle Database 10
g
High Availability
with RAC, Flashback, and Data Guard
for a blow-by-blow description of RAC home clusters.

The Oracle Configuration

After you get your test box up and running, you need to think about your Oracle installation and configuration. This step depends on what you need to test: Will you be backing up multiple versions of Oracle? Will you be using OEM?

Multiple Homes

If you will be testing multiple versions of Oracle, be sure to install them in chronological order from oldest to newest; for example, install version 9.2.0 before 10.1.0, and 10.1.0 before 10.2.0.

Before you get very far, patch Oracle to the latest patch level. There are always RMAN bugs getting fixed, so it makes sense to be at the most recent patch level.

Creating Databases

Obviously, you need at least one database created in each ORACLE_HOME that you have installed. These databases may be default databases created during Oracle installation, but an 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.

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 administration headaches. However, make the choice that matches your production environment: if you deploy Grid Control management in production, use Grid Control to manage RMAN backups in the test environment.