Best Practice

OK, I bent the truth slightly. Lied, if you like. Mis-spoke if you’re a politician. I was going to go for a positive spin this time, but I’ve got one more grumpy negative subject to get off my chest first.

And this one is going to be harder to justify. If it ain’t broke, don’t fix it and We’re Risk Averse are both expressions that carry an implicitly negative connotation, but Best Practice? Come on…. What can possibly be wrong with that?

DB2 is a massively feature rich software product these days. When I started with V2.1 back in the late Cretaceous, we got pretty excited about innovations like “indexes” and the concept of a stored Procedure seemed rather far-fetched. Nowadays, V10.5 and V11.1 offer vast arrays (no pun intended) of options for tackling any given problem or requirement. Commonality with other database products is bumping along at over 99%, so anything you can do with your non-DB2 database can probably be invoked directly on DB2 without having to find different syntax to do it. If you aren’t trying to mimic another database and are just formulating a solution directly in DB2, you find a large number of different means of achieving the same end or, in the rather unpleasant and archaic proverbial, that “there are more ways than one to skin a cat”.

Many of us have attended IDUG or local DB2 User Group meetings where there will be a panel of experts to whom you can address thorny questions about the features and behavior of DB2 and to which the answer, almost always, will include the phrase “it depends”. That’s because DB2 now offers so many options and ways of approaching a problem.

Hence, my issue with Best Practice. There rarely is a Best Practice. There’s a range of options and some might be appropriate for you, your company and your application but many might not. Consider this (a genuine question): We don’t have a backup strategy for our DB2 database; what’s the Best Practice?

Well, I guess Best Practice would include

• Full backups, augmented by Delta and/or Incremental images at appropriate intervals
• Automated backup scheduling, managed by an Auto Backup policy defined with an XML configuration file
• TSA/ HADR configurations to ensure a ‘warm’ Standby and Disaster Recovery version of the database so that we’re not dealing with the outage of a full RECOVER or RESTORE procedure in the event of a primary database failure
• An auxiliary HADR standby with a time delay set in its configuration, so that a dropped or corrupted table doesn’t necessarily mean a full RECOVER or RESTORE
• Data encryption (so that your backup images don’t contain sensitive data that could be easily stolen)
• Compression (of both log and transaction images)

And more besides. But, at about this point, my customer will interrupt and say “Whoa; this sounds like a lot of work. And maintenance. And complex expertise that we don’t have in house. And it’s only the marketing customer database; it only gets updated once a week. Do we really need all this?”

Well, no you don’t. You asked what was Best Practice and that means providing a cast-iron, copper-bottomed, bulletproof, industry standard solution. What you want is not Best Practice but “what’s the best (and maybe, cheapest) set of options to accomplish the limited requirements I have”. In the case we’re discussing here, the eventual solution was a modest cron job that ran a full backup once a week and a delta every night (the database did get updated more than once a week, but that wasn’t something that the high-level management knew about). Far from Best Practice; even, to some purists, a bit of a ropey solution. But cheap, reliable and simple to set up and run.

That’s quite a long way from Best Practice but it’s what the customer really wants and, after all, the Customer is always right (don’t start me).

• Share