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.)
8 Comments. Leave new
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.
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?
This is something Kendra covered here: Rebuild or Reorganize: Index Maintenance Can Save Your Job
It’s probably more of a red herring, but one that you can eliminate. I’d suggest following her advice and setting up the best index maintenance solution for your environment so this doesn’t have a chance to be a red herring, or, worse yet, an issue that is written off as a red herring.
They also have a free webinar on this subject next week: Why Index Fragmentation Doesn’t Matter. They’re putting everything in place for me to have disagreements with them, but they also tend to make valid points that make me rethink my position.
We covered buffer cache hit ratio being a garbage metric that you should ignore over in On Bobcats per 100 Orders and Other Spurious Metrics. BCHR doesn’t tell you much of anything apart from “This counter is still working.”
When was the last time you, the DBA, shipped something that end users asked for?
Just yesterday actually.
Got it! No Excuses, Find a Better Way. Memo received. Thanks for the reminder.
Guids are evil. When you want to type one in as part of a search query, you can’t store it in your short term memory like an integer key. When you’re looking for a certain record in a list of records, it takes more time to match them up visually. There are three kinds of sort: Ascending, Descending and Demonic. Demonic sorting is when you use a guid as a primary key and your records have a random order. If the guid is a primary key that’s clustered, adding a new record causes many rows to have to be physically moved instead of just adding a new row at the end of the table like with an integer auto-number key. Also, when you use it as a primary key, the new record that you just added using the application isn’t at the bottom of the table, it’s at some random place. You can’t see where that new record is when you list the table and you can’t guess what the new guid is that was just added by the program so you can query for it. You can’t select top 5 * from customers order by customerid desc to find it either. A guid takes up more space than an integer. This causes your indexes to be larger and store fewer rows per page. But otherwise, I like your article. It was well written. http://csharptest.net/1250/why-guid-primary-keys-are-a-databases-worst-nightmare/
Russell – a lot of what you said is theoretically correct, but reread the blog post: we’re talking about excuses that don’t hold up. We know plenty of databases with GUIDs as clustering keys that still perform just fine.
As a DBA, you can’t just say, “I’m not gonna fix your database because you’re using GUIDs.” It’s time to cowboy up, as we say at Dell DBA Days this week, and figure out ways to fix the problem. You can make tables perform even with GUIDs as PK/CLs.