I have twenty+ years experience in IT. That time was spent in technical support, development and database administration. I work forRed Gate Software as a Product Evangelist. I write articles for publication at SQL Server Central, Simple-Talk, PASS Book Reviews and SQL Server Standard. I have published two books, ”Understanding SQL Server Execution Plans” and “SQL Server 2008 Query Performance Tuning Distilled.” I’m one of the founding officers of the Southern New England SQL Server Users Group and its current president. I also work on part-time, short-term, off-site consulting contracts.
In 2009 and 2010 I was awarded as a Microsoft SQL Server MVP.
In the past I’ve been called rough, intimidating and scary. To which I usually reply, “Good.”
You can contact me through grant -at- scarydba dot kom (unobfuscate as necessary).

My adult years started with a pretty thorough education in physics thanks to Uncle Sugar and the Navy Nuclear Power School. The laws of thermodynamics were carved into our brains (along with Baumgart’s Law*). Experience has taught me that all these other statements are more or less riffs on the concepts put forward by the fundamentals of the laws of thermodynamics. They’re just applications of the same within social spheres. In short, if you have a physical engineering background, you tend to be a realist. But note, I’m not a pessimist. I just recognize a simple thing. No matter how positive my thoughts are, no matter my belief in the righteousness of our application or business, no matter the utterly sublime nature of our offerings, I can’t make an electron travel more than about 18 inches in one millisecond.

Sorry.

What am I talking about? I’m talking about trade-offs. I’m talking about the fact that you really can’t get a free lunch, that you have to be prepared to pay the piper, that water is wet and fire does burn, that preparations for winter are not crazy. I’m talking about dealing with physical reality as it is, not how we’d wish it to be.

I was talking to a group of people about checking the consistency of your database. I made the suggestion that you should be checking that consistency as frequently as is practical within your system. If it wasn’t problematic for a whole slew of reasons, I’d probably run the check 3-5 times a day. Why? Because, when you get database inconsistencies, it almost always leads to data loss. So, the more frequently you can check, the better. I acknowledge, for most of us, that means we’re probably only checking once a day or once a week. Some of us are checking even less than that, for, debatable, but, probably, sound reasons relating to the nature of the business, the size of the database and the type of data. And, it’s worth noting, I’ve only had about five instances of corrupt databases over a long career.

But, one person from the audience disagreed. This person had systems that required up-time above everything. While he did run consistency checks, he would try to fix errors by deleting & modifying data rather than going to a restore. Up-time was everything. And, while he had more frequent inconsistencies in his databases, by and large he worked around the problems rather than taking the system offline and he saw zero problem with that.

You know what, I’m not going to argue. That may be an acceptable approach for that person, their data and the business they support. But, you need to make that kind of decision with all those sayings above in your mind. Because if you leave a corrupted page in your database, you’re right, it’s no big deal. Until that page gets split or rearranged or something else happens that your corruption suddenly grows. And now it’s not one page (remember, up to 8k worth of rows) but several (all with 8k worth of rows) and the likelihood of additional splits along with additional corruption grows. You can take risks, but you better be prepared for what might follow on to those risks.

You don’t think you’ll ever need to recover to a point in time, so you think log backups are crazy. Cool. Until you need it. Winter is coming. Doing data loads to your system is taking too long, so you turn off automated statistics updates. Saves you time, but you might notice a change in how queries run. TANSTAAFL. No need to run backups because your system is running a on a RAID 5 set of disks. Excellent until your database is corrupted. All magic comes with a price. You think all this crazy talk about storing relational data in a relational fashion is just job insurance for the lazy and incompetent you can force any kind of behavior you need into your SQL Server instance. And it works great with one row:

And that after this is accomplished, and the brave new world begins
When all men are paid for existing and no man must pay for his sins,
As surely as Water will wet us, as surely as Fire will burn,
The Gods of the Copybook Headings with terror and slaughter return!

In short, you can ignore stuff only so long. Sooner or later, entropy wins. Because of that, you need to make active decisions that bring order out of chaos, not lead to more and more chaos. And, no matter what, you can’t wish stuff into being. You have to do the work to prepare your systems, repair your systems, or maintain your systems.

* Lt. Baumgart was one of our instructors (Heat Transfer and Fluid Flow) and a total geek on horror films. Time permitting, we could get a good horror film conversation started. During those conversations, Baumgart’s Law was created. Baumgart’s Law states: In every horror film, there’s at least one incredibly stupid person. To explain, they usually announce themselves, “I don’t want to go up into the attic where I’ve heard all those horrific noises,” just before they do their incredibly stupid maneuver. This doesn’t always lead to their demise, but they are always there. It holds fairly true.