I get the chance to talk to a lot of DBAs in my line of work, and that sometimes gets me thinking about the things that DBAs spend time on and what they feel are the most important aspects of their job. Too often DBAs conflate frequency with importance. In other words, just because you do something a lot does not make it the most important thing that you do!
I think that too little emphasis overall is placed on the integrity and recoverability of the data – and too much is placed on performance. Yes, performance is probably the most visible aspect of database systems, at least from the perspective of the end user. But what good does it do to quickly access the wrong data? By this I mean you better get the integrity of the data correct before you even start to worry about performance. Anyone can give you a wrong answer quickly, but most of us would rather wait a little bit if it means getting the right answer, wouldn’t we? So database design, integrity constraints, and so on need more emphasis in DBA training and in actual database implementations.
Taking this a step further, how sure are you (you meaning the DBA) that every database under you care is recoverable to a useful point-in-time should an error or failure occur? Is there a database backup job running in a timely manner for each and every database structure such that recoverability can be achieved within the agreed service level? What’s that? You don’t have service levels for time to recovery for each database, table space, and/or table? You should! These are commonly known as RTOs — or Recovery Time Objectives — and they are every bit as important as your performance-based SLAs.
Finally, when was the last time you tested the recoverability of your database(s) using the backups you’ve made? Or do you just assume that they are all there and working as planned and will be available as soon as you need to recover? Failing to conduct a periodic, planned testing of all your backup and recovery plans and implementation is a sure-fire way to lose data when you need to recover during a hectic timeframe (after all, aren’t all recovery situations hectic?)…
So DBAs, take a moment away from focusing solely on performance and spend some time on the integrity and recoverability of your databases. You’ll be glad you did.