We put all Oracle binaries in subdirectories of /oracle.   We put all Oracle database, archive log etc… in subdirectories (usually submounts) of /database.   We create “hostname-OS” policies that are designed to back up only OS components so always have exclude lists for /oracle and /database for those.   For any “environment” that needs to be backed up we create policies such as “hostname-INST-DB” (for dbfs/archives etc…) and hostname-INST-APP (for binaries) or hostname-INST-DB-APP if we want to backup binaries and dbfs at the same time.

 

So if we had a Production environment with Oracle instance PROD on a server named billybob we’d have policies:

billybob-OS

blllybob-PROD-APP

billybob-PROD-DB

If that server also had another instance (e.g. OLAP) we’d also have policies:

billybob-OLAP-APP

billybob-OLAP-DB

 

Our general rule here is we do NOT backup Test/Dev instances – if one goes down then we do a refresh of it.     Unless DBAs specifically request backups and can justify them we don’t back them up so the onus is on them to be sure we’re backing up what they need.

 

There may be other applications or directories (e.g. those for concurrent manager) for a given environment – if so those filesystems would be backed up in the  APP policy.   If the app is not Oracle related and needs to be backed up it would generally have its own policy in the form hostname-APPNAME-APP.

 

 

I’m hoping I can get a few peoples opinions on using *.dbf (or *.whatever) in exclude lists to avoid backing up Oracle (or whatever) database files.  I’ve always been of the opinion that excluding the directory where the database files are is a better method as it doesn’t require NBU to evaluate each and every file that it attempts to backup so you have less of a load on the client and, in theory, there might be an every so slight increase in backup speeds.  Our database environment, especially on the development/QA side, is very active/transient and new databases are popping up all the time on existing hosts resulting in backing up tons of tons of hot database files which are absolutely worthless.  Putting procedures around creating new databases requiring them to notify us when they create a new database is The Right Way to Do It™ but that’s easier said than done in a dev/qa world.  I’m starting to think that the time required to maintain the exclude lists is becoming more expensive than any performance benefits.

 

So, all ye great NBU minds, what are your experiences with using *.dbf and have you noticed any ill effects on the client?

 

 

_______________________________________________________

Barclays
www.barclaycardus.com
_______________________________________________________

This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on.