10 Things I Love About RMAN

I was looking at an old backup script the other day.  We acquired a new client who was stiil using shell scripts to execute hot tablespace backups and it got me thinking about how much I take RMAN for granted these days.

Remember how meticulous we used to be about backup shell scripts?

In the “old days” you had to manage everything in the scripts like finding file locations, compression, labeling tarballs, error logging, etc.  DBAs took one of two paths:

• Write a robust, reusable sript with lots of dynamically generated variables for maximum portability, or
• Just hard-code the blasted thing so it works – we’ll make it nice and clean and portable later.  *cough* sure *cough*

But RMAN did away with all of that.  It’s so easy to do 90% of everything you ever did with a script or collection of scripts, that just about the only thing you need the shell for anymore is to schedule the backup (which isn’t strictly required, either, but hey, old habits die hard.)

Anyway, I thought I’d make a list of the best things that come to mind when I think about RMAN.  Some are wonderfully simple:

1.  Automatic archive log cleanup.

Yep, #1 for a reason.  This was the command that sold me on ditching all my scripts in favor of RMAN.  The “backup archivelog all delete input” command saved me and anyone who used it a tedious pile of shell and sql code.  Without this phrase you had to backup the logs to somewhere (defining “somewhere” was its own little subroutine); make sure they copied successfully; keep track of what was copied and what was written while you copied; delete only successfully copied logs (careful!); make a note regarding which logs were stored with the full backup (if you were running a full backup); GAH!!

Such a simple, clean, readable line of instruction to complete a task that, if not handled, will cause your database to hang.  It won’t delete anything it shouldn’t unless you force it to (by using the “force” command, incidentally.)  Very nice.

2.  Simple commands to do all the basics.

Let’s see…. “backup database” “restore database” “backup controlfile” “recover database” …need I go on?  You don’t need to know very much about Oracle to know what these commands do.  Sure, it can get a lot more complicated if you want, but the beauty of RMAN is it doesn’t need to be complicated to get the job done much of the time.

3.  No need for backup software.

I understand why people pay for Veritas, Commvault, etc., but at the same time, I don’t understand why they pay for expensive Oracle agents.  RMAN takes care of everything, and at best those expensive clients only wrap standard RMAN functionality.

What I love, getting back to the point, is that with minimal creativity and skill, you can save yourself or your client a tidy sum by leveraging RMAN instead of paying for Oracle backup agents.  Yes, you can still let the backup software do the scheduling, but there’s no need to pay hundreds if not thousands per server for scheduling alone.

4.  Seamless integration with Data Guard and RAC.

This should probably be #2, because RMAN’s integration is one of the rarities in enterprise software:  It works as advertised.  Try to delete an archive log that hasn’t been applied to a standby?  RMAN won’t let you.  Restoring a RAC backup to a single instance or vice versa?  RMAN makes the process transparent.  No fuss, no muss.

5.  Complexity is there when you want it.

If I decide that a corrupt block on a scratch tablespace is OK, RMAN will obey.  If I decide not to back up a couple of tablespaces, or that I really do want to force-delete a bunch of old backup pieces or archivelogs, I can do that, too.  I can even do amazing things like migrate a database from Linux to Windows, or Solaris to Linux.  (Remember all those export/import excercises?  For large databases??)  Need to migrate to ASM?  Done.

It would take waaaay too much time to list all of the complex backup, recovery, and utility functions supported by RMAN, but suffice to say, when you’re ready to move beyond “backup database” you certainly can.

6.  Duplicate database.

Clone, clone, clone, clone.  As an Oracle Applications DBA, I don’t copy anything in life:  I clone it.  My daughter wants pancakes for breakfast?  I make one and clone the others.

Scripting database clones was a huge pain.  Sure, once a system and process was stabilized you could get it to work just fine, but if anything changed you had to make sure to check your scripts and run a battery of tests and likely alter your scripts.  Don’t get me wrong, copying a database wasn’t _hard_ per se, just tedious.  Remember editing the create controlfile statement or trying to automate it with sed to account for any possible change in file systems?

Duplicate database made everything simpler.  With 11g, hot copies are just as simple as they should be.  The automation is no longer so brittle, so it can become appreciably more sophisticated – dynamic point-in-time copies, for example.  Again, it all just works.

7.  Integration with Oracle Managed Files, Flash Recovery Area, and ASM.

This one is almost an extension of #6.  If you haven’t felt the nerdy euphoria that comes from duplicating a database while using OMF or ASM and flash recovery area, you just don’t know what you’re missing.  Talk about simple – almost automatic.

8.  Backup recovery area.

This is another command I love because it simplifies one of the most underused backup strategies out there:  Backup to disk first, then back the disk up to offline media.  Use cheap disk for a flash recovery area, back everything up using the uber-simple “backup database” command, then send it all to tape or VTL or offline disk, or whatever with “backup recovery area.”  You have online copies available for quick recovery, offline copies for disaster recovery, and you did it with less scripting than I needed to write this paragraph.

9.  Integrity checking.

RMAN doesn’t just back up your blocks, it will tell you if they’re recoverable.  RMAN will check them as you’re backing them up and it will check them in place with a simple command.  Schedule a validate backup routine on a monthly basis and mail the output to your friendly neighborhood SOX auditor – they’ll love it, and best of all, they won’t call you asking “how you know” the backups are OK.

10.  It just keeps improving.

Hot duplicate database was just released with 11g.  Greater integration with RAC, Data Guard, ASM, OMF; performance improvements, simpler commands, and increasing sophistication comes with every new release, but the product seems to remain stable.  RMAN is flat-out one of the best things about Oracle because

1.  We all need to back up the database, and
2.  we just don’t have to worry about it.