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 StackOverflow.com, 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.)