Executives: Are You Doing This Wrong With Your Data?

When offered this topic for a blog, I responded, “I’ve written books about this… where do I stop?”

I’m going to hit some highlights for executives who may spend more time running their business than managing your data, in a Letterman-esque list. If you’re not old enough to know who Letterman is, look him up on YouTube or Google when you need a chuckle.

1)?????Are you certain you can restore your data? Has this been tested?

We’ve acquired more than one new client because a corruption was backed up (testing for corruption is part of your backup process, and verifying a lack of corruption is part of your restore test).

We’ve also acquired new customers because databases have gotten so large that standard backups take too long, or a real-time restore would drastically blow up their SLA.

Finally, air-gapped backups (i.e. backups NOT on your SAN) are a critical component of Ransomware protection. Whether you decide to pay a ransom or not, you will want the ability to perform a bare-metal restore. As a DBA-at-heart, I sometimes forget to remind folks that software & middleware also needs to be backed up, but usually somebody is around to remind me.

2)?????If you haven’t cleared a ransomware plan with your own board, your company and you are at risk

Ransomware happens. Chances are that at some point in your career it will happen to you. Sometimes this occurs because of an external hacker, but more often these days it is caused but a malicious employee or by a careless employee clicking on a malicious link in an email.

Make sure that you have a plan that you’ve run by your board. If your board clears your plan and you follow it, you are golden. IF you do not have a plan, you are a target, and all of the fingers will point at you. If you have a plan, you were prepared. If you don’t, not so much.

3)?????Is preventive maintenance being run correctly?

I’ve personally performed hundreds of health checks / performance reviews at hundreds of client sites. I can count on one hand the number of times a complete preventive maintenance plan has been set up and followed and monitored. If your data is being managed by a developer or a network administrator, your changes are even worse.

Regardless of DBMS, your data needs to be backed up, maintained, indexes balanced, and tuning reviewed. You need to have a positive mechanism for identifying that a) it ran correctly or b) it failed or c) it didn’t run.

Many shops come close but lose it when it comes to knowing that a failure occurred, or that a job (like a backup!) didn’t run.

(This is a good place to do a health check with an external resource, who will also test your backup regimen against your SLA)

4)?????Is your data archiving happening? Does it meet all contractual and legally-mandated requirements?

If your company has been around for 20 years, there’s a good chance you have 20 years’ worth of data in your databases. There’s also a good chance that your backups are taking longer, your storage is increasing, and your restores are taking longer.

We have a lot of companies implementing archiving projects right now, and it never ceases to amaze how many people need to be involved in deciding how long data needs to stay online or recorded in an archive database. This requires knowledge of business needs, contractual needs, and regulatory needs.

Get everybody into a room, take notes, and make sure it’s signed off by all parties (because it WILL change mid project).

Finally, make sure that somebody is responsible for making sure the jobs run periodically.

5)?????Using the data for all it could be

Sometimes you don’t even know what questions you can ask.

And answers to those questions can be worth money, or more.

Recently one of the Blues created a Mongo project to examine treatments for diseases in different parts of the country for efficacy. This strikes me as a great use for data that might not otherwise have been used; insurance companies keep information on what the diseases are, how much it costs to treat, and how long the treatment lasts. I’d have thought that it ended at underwriting. But no, not only does understanding what treatment is better help their bottom line, it saves pain, suffering, and perhaps extends or saves lives.

Sometimes you don’t even know what data you have until somebody chooses to look at it a bit differently.

6)?????Are you throwing hardware at a software problem?

I won’t got to a full Letterman-top-10, and will end my list here.

I’ve lost track of the number of calls I’ve received that went something like this: “Jeff, I’ve just spent $10 million upgrading my hardware and the performance hasn’t improved. Got any ideas?”

It seems self-evident to me that you identify a problem before throwing resources at it, but sometimes when the users are screaming loud enough & offering to fund it, faster hardware seems to be just the right choice until it shows up and it wasn’t.

There are plenty of tools today that will help you identify both resource and software bottlenecks. I strongly recommend tuning the software first, then identifying a specific hardware bottleneck, then solving for that bottleneck.

May DBAs do not have tuning skills; borrow one.