Using Data Domain with Oracle RMAN and an FRA

Referenced white paper can be found here.

We use DD, but management is done via backup application so everything is pretty much automated.  I'm not big fan of having DBAs dump data on their own as silo approach to backup is nightmare when it comes to DR situations.

NetWorker 8.1 addresses precisely the problem you mentioned as follows:

The DBA does her RMAN backups to FRA and her RMAN restores fromFRA, without worrying about FRA getting full, without knowing or learning anything about NetWorker, and with zero impact on her FRA functionality.

A NetWorker Backup Admin, who knows nothing about Oracle, fills in one page in the NetWorker Wizard, once, and he does nothing else Oracle-specific for configuration, backup, or recovery of Oracle.  To clarify: he is not involved at all at recovery time.

If the DBA and NetWorker Backup Admin do the above, NetWorker 8.1 does its magic, putting everything together: DBA’s backups to FRA are moved “automatically” from FRA to a DD (or any NetWorker backup device) and catalogued as backups in the RMAN catalog,  it reports on protected Oracle *objects* (and not on the DBA’s dumps to the FRA), and it even backups logs not in the FRA if the databases themselves are backed in the FRA.

To clarify: when I wrote above that the “DBA does her RMAN restores from FRA”, I really meant exactly that: no matter whether the backups are in the FRA or not, the DBA writes her RMAN recovery scripts as if herbackups were in the FRA.  Networker will intervene if needed (i.e. if the backups are not in the FRA), and will pull them out of the DD.  Oh, and when I wrote above that the “DBA does her RMAN restores from FRA”, I really meant exactly that: the DBA doesn’t even have to specify the NetWorker Server or Client name; Networker has done its magic.

If you want to learn more,  you may read the White Paper https://support.emc.com/docu48097_White-Paper:-EMC-NetWorker-and-Oracle-Backup-and-Recovery.pdf, or Chapter 8 in the NMDA 1.6 Admin Guide  https://support.emc.com/docu50645_NetWorker_Module_for_Databases_and_Applications_1.6_Administration_Guide.pdf,
or contact me directly.

Thank you for the reply, however this answer does not address the question, and I've removed the Correct Answer status.

We are removing NetBackup and writing directly to our Data Domain for budget reasons; Networker is another product, another cost. 

It seems as though you know the Networker product well, but I'd like details and not "magic".  I'm working on getting a support account so that I can review the document for my own edification, but as I said, additional dollars are not going to happen.

To restate the question -

Oracle RMAN fully integrates the use of an FRA.  It's a "Fast Recovery Area". With each new release of Oracle, the management is more refined.  The FRA is a container of all backup -related files:  backup pieces, backup sets, archived redo logs, flashback logs, etc.  A pre-defined sizes lets Oracle know how to manage expiring and deleting these pieces, when there is enough space, these objects can hang around so that they don't have to be brought from a backup.  If there's not enough space, Oracle knows what to do about it.

I've been working with Oracle since version 7.3.4. At that time I did cold backups with scripts.  The technology has evolved immensely, we now have database in the terabytes that never need to come down, while at the same time having point-in-time recovery.  A key learning point with each new release is to allow Oracle to do its own management. Its database information and recovery catalog, and control file are finely interwoven. 

When writing my backup and recovery documentation to reflect using the DD directly, I need to detail what I am losing by not having all files in an FRA, and what I am gaining by directly writing to DD.  Technical information.  Do you have any information.  BTW, we've had EMC sales in an out of our office, we are making use of its technology, so sales information is not what I'm looking for.

Please don't mark your answers as "correct" when the initiator has not even reviewed it.  I'm a little offended by that.  Your information is marked as private so I can't call you or email you directly. 

Thank you.  This is in fact the same white paper that I referenced in my post, the basis for the question.  It does not speak of EMC's integration with an FRA.  DD becomes a disk location.

One question; do you use NetBackup for other backups in the company?  Or do you plan to switch to "everyone-for-themselves" model and use common target like Data Domain?  I ask this because usually you wish to keep all backups under same umbrella and operation wise this is much easier. I'm not sure about current licensing model by NB, but usually one would expect that you have combo deal or storage based license nowadays (where you license target storage only and this can be used by unlimited number of agents or database plug-ins).

As for Oracle alone and DD, I would say DD is just another target where only benefit would be usage of DD Boost which should make things a bit faster.

As for the rest, I will leave you and the other guy fight

SKDBA wrote: Thank you for the reply. Of course we have a fully automated scripted system, however what this means is that Oracle RMAN no longer handles the full integration and management of all of its backup and recovery files, the automated scripts do.  DD becomes nothing more than a disk location and we are back to the old method of backups. I have the white paper Oracle RMAN Design Best Practices with EMC Data Domain, my starting point.  Never does EMC address an FRA and its benefits, and what EMC can do to replace that.

Oracle RMAN is still involved if you use backup agent - it simply calls your RMAN script. Your restore is totally RMAN based.

As for FRA integration, for that one you should refer to NW 8.1SP1 docs.

Thank you for the reply.

Of course we have a fully automated scripted system, however what this means is that Oracle RMAN no longer handles the full integration and management of all of its backup and recovery files, the automated scripts do.  DD becomes nothing more than a disk location and we are back to the old method of backups.

I have the white paper Oracle RMAN Design Best Practices with EMC Data Domain, my starting point.  Never does EMC address an FRA and its benefits, and what EMC can do to replace that.

NetbackUp is only used by Oracle Databases, so that me.  DD Boost is another paid-for product. 

I'm aware of the compression issue, our EMC sales and the documentation talks about this.  Have you done testing to split out the archived redo logs from the backupset and compared its compression? 

I did a simple test a while back in which I used DD as a FRA target, and performed RMAN backups to it over an NFS mount. It worked great. Using a similar approach you could use a DD / NFS backup target for just about anything.

In terms of Oracle, avoid RMAN compression when dumping to a DD (it defeats deduplication, kind of eliminating the whole point of DD). Also, DD dedupe typically saves you more space than RMAN compression does, and does not drive up CPU cost while running a backup. So that makes perfect sense.

Agreed, this was stated originally. 

DD is now my disk target while my FRA resides in ASM, so what Oracle manages automatically for me I now have to include in my RMAN scripts.

I think I got my answer, which is "go ahead and write to DD directly, you give up the FRA management Oracle provides. We can help you with that if you purchase another product."

I knew this coming into the question, also know I have to script a system, and the answers to "what am I giving up" (I wanted another opinion in case I forgot something; more heads are better than one). 

In that case it is easy, you could use DD only as "just another target" and nothing more.  I believe general idea is that FRA storage is outside DD of course so you would need to use RMAN to dump data there directly.

Of course, unless you change the ARCH_DUMP_DEST, if you have a FRA, and that FRA is on a DD, the archived logs are going to end up there anyway. That's the primary copy, though. You should back them up to a second set of physical devices, for sure.