You’re making excuses.

The database application is slow, and you’re throwing something under the bus, but we’ve got bad news. Changing it probably isn’t going to make your server faster. Here’s some of our favorite excuses.


Kendra SAYS, “Your Problem Isn’t GUIDs.”

Unique identifiers may or may not be globally unique, but they are one thing: the universal scapegoat for people who aren’t really sure what’s causing their performance problems.

I’ve met a lot of GUID blamers. I’ve had people introduce myself to me and immediately say, “My application is soooo terrible. There are GUIDs everywhere!” 

I’ve got news: GUIDs aren’t evil, and using them isn’t a sign of pure incompetence. The same thing is true of natural keys— using them doesn’t necessarily mean your database is going to perform terribly. If your application is slow, then yeah, you should consider schema design and key choices as part of the landscape, but being dogmatic about “good” and “bad” types isn’t going to help you figure out what the most effective changes are to improve your performance.

I’d just love to get back the three days of my life I once spent deploying a key change to “get rid of the problem GUIDs” in a schema. Especially since afterwards performance wasn’t noticeably any different.


Brent SAYS, “Your Problem Isn’t the SAN.”

You’ve been measuring Perfmon metrics like Average Disk Queue Length and Disk Seconds/Read, and you’ve been comparing the results to the SQLCAT list of OLTP problems. You keep waving the results at the SAN admin, and he keeps shrugging, saying that everything looks okay on his end.

That’s because it probably is.

You’ve gotta stop thinking that your SAN is going to hand-deliver every byte to you within a millisecond of the request. It’s not gonna happen. It takes millions of dollars to build a fast SAN, but it takes one heck of a lot less to build a server with a buttload of memory. If you’re doing online processing, the answer isn’t faster disks, because even the fastest drives can’t hold a candle to memory. If you can’t cache it in memory, users are going to call it slow. Full stop.


Kendra SAYS, “Stop saying nobody listens to you”

When you say: “Nobody listens to me!” People hear something else. They hear you say: “I’m not a leader.” They hear you say: “I don’t know how to communicate.”

The more you say this, the less and less people want to listen to you. And the less you expect anyone to listen, either. 

You can fix this. Take a step back. List out three recent changes that you’ve recommended that you haven’t been able to get traction on. For each of your examples, consider:

1) Is communication the problem? If you’re relying on emails, that’s usually not going to get the job done. Develop a strategy to communicate more effectively: and yes, this means talking to people face-to-face at times and listening to what others have to say, too.

2) Do you lack technical credibility? This is an area where training can help. Students come to our classes to ask questions about how to effectively approach real world problems.

3) Do you need an independent opinion? Sometimes different teams get into fingerpointing standoffs, and nobody’s sure where they stand with anyone else. We get brought in as consultants to take an independent look at bottlenecks, defuse any blame fires, and set people on a path to solve their pain points as a team.

Leadership isn’t something that you’re entitled to because of your job title. Leadership is something we each must earn– and we’ve gotta work to keep on earning it. You can become influential and you can lead people! You’ve just got to build your skills to do it.


Brent SAYS, “Your Problem Isn’t the DEVELOPERS, EITHER.”

Brent says: I know, it’s trendy to complain about how the developers do stupid stuff. I make jokes about this all the time on DBAreactions.

Thing is, though, they’re shipping stuff.

Useful stuff. Valuable stuff. Stuff the end users actually want. You think they’re being sloppy because they don’t know any better, but the truth is that they don’t get unlimited time to build everything perfectly. Your management wants to ship features out the door and keep moving forward.

When was the last time you, the DBA, shipped something that end users asked for? Did you build it absolutely flawlessly, or did you duct tape it together to get it out the door?

I bet you could take the diamond-in-the-rough from the developers, put some work into tuning the server and the indexes, and make it fly. And if you can’t, if you’re only willing to work with flawless code, I’ve got bad news for you. I’ve worked with those kinds of developers, like the ones at, and they don’t need you. (In fact, Stack doesn’t have a full time DBA, and they’re one of the 200 biggest sites on the web. Think about that for a second.)

Brent Ozar
I make Microsoft SQL Server faster and more reliable. I love teaching, travel, and laughing.

I’m mostly a figurehead here at Brent Ozar Unlimited. My true skills are menu advice, interpretive dance, and reading Wikipedia.
Brent Ozar on sabtwitterBrent Ozar on sablinkedinBrent Ozar on sabinstagramBrent Ozar on sabgoogleBrent Ozar on sabfacebook
↑ Back to top
  1. One thing I feel is absolutely necessary to add to Kendra’s portion on leadership is that leadership and management are two completely separate entities. You can be one without the other. Leadership is something you strive for with confidence, communication, trust, and direction, of which none of these rely on job position.

    Also, how this fits in to the rest of the points, a leader isn’t out there to place blame. The real leader is out there to point out an issue (slow app in this case), work with whoever is necessary to find the true root problem (better be an execution plan to back up that GUID claim), and get a plan with direction to it to resolve the issues that others can get behind.

    Finally, Brent, that is a great comment about StackOverflow not having a full time DBA. We need to stop complaining about everyone not being an expert in our job and be grateful that we hold skills that others don’t just as they hold skills we typically don’t.

  2. Would you include ‘indexes are fragmented’ as a red herring, where buffer cache hit ratio is over 99% and there are almost no physical reads?

  3. When was the last time you, the DBA, shipped something that end users asked for?

    Just yesterday actually.

  4. Got it! No Excuses, Find a Better Way. Memo received. Thanks for the reminder.

Leave a Reply

Your email address will not be published. Required fields are marked *