Monday, March 31, 2008

The Untunable Database

There are some DBs that just can't be tuned any more than they already are (or aren't). A good example of this is an application that hits a DB and never qualifies any of its queries. They all hit with select * and no where clause. There's really nothing you can do to increase the performance short of just throwing more spindles at it. But that's not really what I'm thinking about right now. What I've got on my mind now is an application and DB that just can't be tuned no matter what you do because the business owners don't see the benefit of making the changes.

I saw that a lot when I first got to my current gig. We had queries doing horrendous things and taking several hours to return and nobody cared. The end users had been running these queries for years and were happy with them. They didn't care that the server was maxed out all the time and that they had to wait 12hrs for a report to return. Now, I don't have to tell you that as a DBA that just drives me insane. Not to mention that it gives me nothing to do. Why am I even here then?

So with that in mind, I had to go a little cowboy on them and just start making minor changes that proved my point. I really can't stress enough that I'm against going cowboy on any DB and I don't care who you are. But there are some instances where it's warranted. You have to get the ball rolling somehow. And how this DB got in such bad shape was definitely their fault, but their current view wasn't. They had just been so used to things working the way they were that they didn't see the need to change. They got their reports more or less when they expected them and even if they had to wait a couple extra hours for them they didn't really mind because they understood the server was busy.

So what I did was just start by indexing a couple huge #tables. I just picked a couple of the worst SPs and added a couple indexes. Then I went in and started commenting out cursors and replacing them with simple join queries. Both of these made a huge difference. Then I just sat back and waited. You really don't want to go too far with something like this. Then when they started noticing that their 12hr queries were coming back in just a few secs, then I had their attention. I was then able to convince them to let me go even further and start really tearing into some of these SPs.

And now, for the first time ever, we've got a near-realtime reporting effort in our company. They've come a long way from 'I don't care if it takes 12hrs' to 'I have to have it now'. The problem is they still slip back into their old habits now and then. They currently want to implement an encryption solution that will take around 2mins to return for each report when the solution I suggested returns in about 2secs. And sure, 2mins isn't really going to break the bank, but as those of you who have done a lot of query tuning should know, you have to be hungry for resources. You have to treat every single CPU tick as a drop of water in the desert. If you don't, you'll wake up one day and be in the middle of the same shit you were in before. You have to fight over milliseconds and squeeze every last drop of performance out of every query you can find. That's the only way to run a real tuning effort.

But it's amazing how politics and perception find their way into every aspect of your job.
Wednesday, March 26, 2008

Training Site

I just came across a training site I haven't seen before. They've got a couple free vids, but it's hard to really get a feel for the training from just those.
So I'm trying to get a pass to the site so I can review it for you guys and let you know if it's worth it.

I'll keep you posted.
Monday, March 24, 2008

Celebrity DBA Work

I've always had a soft spot for celebrities who have their entire lives spilled out in public. It's gotta be tough to not only have everyone see how good or bad you do you in your job, but also in your personal life as well. And I've often thought for everything I'm not (rich, well-known, etc) at least I don't have all my failures made public.

At least, that's the way it is until you have a disaster with one of your DBs. Then everyone wants to come stand over your shoulder and watch you bring it back online. Now the heat is on because you have to remember every last command and parameter in front of the crowd. And knowing that is like trying to stop laughing in church. The pressure is just too great. Some DBAs fold at this time. Others just do their jobs like nothing's going on. Me, I clear my desk of on-lookers. I had that happen just this morning. I can't stand to have people just standing there watching me work. I like to be able to follow a train of thought without worrying about how I come off to my audience. So I always tell them... the sooner you leave the sooner I can get to work fixing this.
This morning's disaster came in the form of a dev sending me an email telling me his system was down. He then followed up with a trip to my desk. So I asked him... did you come over just to stand over my shoulder and watch me work? Thankfully, he took the hint and left. But it's not always that easy.

I've always been very sensitive about that with other people too. Unless invited, I always try to stay on the backside of the monitor... especially when someone is trying to get something done in a hurry or needs to concentrate.

There are those who don't really mind people watching them. These would be those who present at conferences all the time and are used to it. But I'm not one of them. Anyway though... give your DBAs a break. If you want them to do something for you, don't stand there and watch them. Just leave and they'll call you when it's ready.
Friday, March 21, 2008

Videos Coming Soon

I've started making some SQL Server tutorial videos. I've done like 3 or 4 so far and I'm going to post them soon. I'm starting with a basic topic and building on that. So this time it's backup. I started with the basic backup syntax and am working up to complicated backup procedures. This is meant to be kind of an inclusive tutorial series for someone who doesn't know backups at all to taking them through some decent types of procedures. I'll be branching out too, this is just where I started. I'll post links once they're online.
Thursday, March 20, 2008

Will the Real Idiot Stand-up.

As you know our other DBA just left and he just started his new job. I was IMing him today and asked him how it was going. He said, the last DBA was an idiot. It's funny, cause I can't count the number of times I've said that. I don't thing I've ever started a job where the guy before me knew what he was doing.

The question is though, am I really all that good or do I just have an inflated ego? I'd probably have to say it's a bit of both really. I've seen a lot of DBAs who just don't know the simplest things about SQL. I've talked about this several times in both my blogs so I'm not going to harp on it too much right now, but it holds more true every year I'm in this industry.

There's a difference between just doing things differently than the other guy, and his systems actually being neglected. Not performing backups or index maint. is bad DBAing. It's not just a different way of doing things. I remember talking to a guy who was a very high DBA at a company we all know last year. I was at PASS come to think of it. And he sat there proudly and told me that they NEVER change their sa passwords on any of their systems. I would love to tell you his reasoning, but I just couldn't get into something like that. But to be proud that you never change your sa password is just assinine. You know what they say dude, if you look around the room and you can't find the asshole, it's you. The same goes with idiots.

It's hard to measure skill though. Everyone has such different experiences. Things I've come to know well may be completely foreign to a different DBA who's far better than I at something else. So does it make him an idiot because he doesn't know what I know? Yeah, sometimes. The basics should be covered. Every DBA should know what it is to backup a system and do maint. and basic security. And so often it's these basics that aren't covered.

So now it comes down to simplicity. What makes a really good DBA? I've had several talks with guys all over IT about this same topic, and in almost every session, we've pretty much concluded that you only have to try a little bit to be better than the average guy. The average guy does very very little to further his knowledge or to get really good at his job. Most people just skate by. So if you try just a little bit you can rise above the crowd. That's what I think anyway.

About Me

My Photo
Sean McCown
I am a Contributing Editor for InfoWorld Magazine, and a frequent contributor to SQLServerCentral.com as well as SSWUG.org. I live with my wife and 3 kids, and have practiced and taught Kenpo for 22yrs now.
View my complete profile

Labels

Blogumulus by Roy Tanck and Amanda Fazani

Page Views