Just Blame The Database

Enough already.

How has it come to be acceptable that whenever issues arise with any computerized system it is okay to use the phrase “there was a problem with the database” and everyone just accepts that and moves on with their lives but not before kicking their DBA around? For the record, as a DBA we always blame the network. They will always blame management, and management will blame the budget, and the budget is the result of a bad economy, which most people will say is the fault of Bush the Younger. So there you go, George Bush is responsible for all your database problems.

So, Microsoft themselves had a glitch with the download of Windows 7 last week, which prompted some members of their brain trust to leak a wonderful testament to their own product. I have not seen a more disastrous product endorsement since the Cartoon Network decided to promote Adult Swim. They might as well have mentioned a few competitors in their statements, it was that stupid.

Can you imagine anyone else talking about their own products this way? “Stop by [restaurant_name] for a bacon cheeseburger where we are now 100% pesticide free and you have no chance of getting the Swine Flu.” As silly as the thought is of contracting Swine Flu from bacon, it would be even more silly to think of ever mentioning something negative about your own company product, on or off the record.

Back to my first thought. When the hell did blaming the database become acceptable anyway? Granted, none of the links I have provided here (or seen elsewhere) ever states as a fact that someone from Microsoft made an official statement that they were blaming the database, each account I have read only cites “a source”. I suspect that this may simply be a case of a communication breakdown. Perhaps this source tried to explain the technical details involved with the application design that resulted in the excessive fragmentation, and these details were just summarized by the authors who felt that either all the details were not necessary or that it was okay to just blame the database. It would not be the first time that I have seen someone that is not very technically savvy simply gloss over necessary details and just focus their ire on the database server or the people responsible for administering the server, as opposed to the people that designed the application or system.

Well, let me tell you a little secret: Computers do what we tell them to do.

I swear to Turing it is true. They are simply tools. They are not sentient, at least not yet, and I am not aware of any working at Microsoft (maybe at Google, or the NSA, not sure about that) although Paul Randal may come close. So, computers do as they are told, or in this case programmed. Guess what else that means? They work as well as they are told to do. Anyone see where this is going?

If you put a bad design on top of a good database platform, you still have a bad design on top of a good database platform. Stop blaming the database for problems that arise due to inefficient application design and code.

I think most people blame the database because they have no idea how things work. This is like me blaming my engine for seizing up because there is no oil, only I am the one responsible for knowing if there is enough oil in the engine. When people do not understand how things work, they tend to blame those things because it is easier than taking responsibility for their own actions and/or their lack of knowledge. You can read more about this issue from Paul Randal and Greg Low.

I have seen databases and database servers get blamed for lots of things over the years. It is just an easy thing to do, especially when nothing has changed on the application side. How many of you have seen the emails that say “we haven’t changed any code in months, so it must be a change you made recently that is causing the problem”. Apparently people think that DBA’s or server admins are making changes all day long on systems (false), as opposed to never touching them at all because we don’t want anything to break (very true). Well, if we did not make any changes, and the application code has not been changed, then what could it be? Could it? Well? Could it be…the data?

And there it is. The real culprit. In the Windows 7 case it appears that the increase in traffic resulted in an increase in fragmentation brought about by the design. Take all of that and throw in a touch of inadequate testing and you have a slight bump in download times. Hey, things happen. But let’s be clear. The code did not change. And the DBA’s did not change anything on their end. Nope, the database server was just doing what it was told, mostly by the application code and design. I am sure if it could think for itself there would not have been any issue, but since it cannot do that (yet), then a human had to step in and fix things.

I see this all the time. Data inserts, updates, deletes, and selects happening at all times, from a variety of systems. Some planned, some scheduled, and always a handful that are ad-hoc. After a while, despite the best laid maintenance plans of mice and men, performance can degrade. This is going to be true of any database system at some point in time. But bad performance does not mean there is a problem with the database engine itself necessarily. What it does mean is that there is a problem with the system as a whole.

What is needed is more understanding of the overall systems that people are being asked to develop and support. And when something goes amiss we need to focus on the details, to understand the root causes and effects, and a lot less finger pointing. Passing blame around does not do anyone any good.

But, if you need to blame something, just blame the network. That’s what we always do.