HomeDownloadable ResourcesContact Me
Archive Newer | Older

Monday, August 18, 2008

Essbase Backup Methodologies
I admit it.  I like to keep things simple.  I am also a rather complex person.  Is this a dicotomy or a natural result of one begets the other?  I don't know, but what I do know is that simple cannot be defined from a universal perspective.  What is simple for one person is more often than not very complicated for others.

Take for instance the task of backing up databases.  The simplist approach from an IS perspective is to just throw a tape drive at it and call it done.  Most IS professionals will tell you that they have software than can back up files while they are in use, so this is all that is needed.  While it's tempting to laugh at this concept, it's often hard to convince certain people that this is not the wisest choice of actions to take.  What's worse, the tape access to the machine is often done at the worst possible moment during the day (thank Murphy for that one), in the middle of your key calculation -- despite assurances that the backup window is set in stone and won't be violated.

Do I blame IS for this?  No.  I blame the underlying concept of backing large files up directly in a non-static environment.  This is the issue, and once you understand that, you can free yourself from the problem entirely.  It really is that simple.  No matter how big your database is, the backup must be of high enough priority to justify keeping a static copy of the data.  The backup can access this "dormant" copy at any time, especially if that copy is not on the same drive set as production. 

So how best to do this?  Well, this gets back to the definition of simple.  In my case, I use the archive.cmd file from the downloadable content section here.  It's a simple command script, meaning that you don't need to have additional skill inventories to support it.  What you DO need, is a good understanding of notepad and command scripts though.  This "throwback" technology is a lost art, admitedly, but easily mastered -- at least sufficiently to do the installation and extremely infrequent maintenance for the backup.  Other than reconfiguring the script, I haven't changed it in many years (and I haven't even edited the script in more than two years now).  It's complete, one call and it does the whole thing.

So what else?  Well, how about what and when?  I perform a backup whenever I do the primary data load for any production database.  This way, the downtime is just a part of handling the data load itself, and kept minimal at that.  I also keep three copies of the database, although the script can do up to 9 generations without modification with any number of uniquely named "types".  Why three?  Mostly to allow a Monday recovery of Friday's data -- but this was just a matter of simplicity on the automation side.

What else should be considered here?  How about the server's configuration itself?  I have three drive sets for the production server.  The "C" drive is dedicated to the operating system, as most people would guess.  The "D" drive is for backups ("Data"), and the "E" drive is for essbase.  This simplicity is just a matter of isolating one set from another.  It also allows me to tell IS to backup the C and D drive however they want -- although I recommend a Weekly Full drive C/D backup and Daily Differential backup of D.  Either way, using this configuration keeps things simple from an isolation perspective, even if it seems like three drives are otherwise more complex than one.

Yes, I often make things more complex on the automation/design side to keep them simpler on the maintenance/user side.  In other words, it's not about making it simple for me to design, but simple to use and maintain.  Often, the two are in harmony, but not always.

1:08 pm est

Archive Newer | Older
DougWare was a name given to me by a former boss that kind of stuck.  I purchased the domain back in 1992 and have had it idle almost all the time (except for email).  At first it was because I tended to handle everything that was *not* hardware or software, and dougware was the "in-between" stuff.  Lately though, it's been software only and focussed on tools for Hyperion Essbase developers.

Ask the Expert!

For free email business advice, send your questions, comments or ideas to dougb@dougware.com. For issues that are of particular interest to the Essbase community, we may publish your questions along with our answers on this web site.  Since there are so many forums that deal with general essbase issues, I will specifically be addressing VBA/VB API issues where the code shows no overt signs of problems and needs an indepth review.

Join Our Mailing List!
By joining our mailing list, you will be the first to know about:
  • Breaking news about our business
  • Helpful tips
  • Exclusive special offers
To join, type your email address below and then click the Go button.


This site  The Web