Instead of working, I blog.

One of the hardest things to manage as a DBA is all the different sources we receive requests through. We get walk-ups, emails, calls, tickets, rumors, pigeons, and sometimes even smoke signals. And while it's easy for the boss to say 'no ticket, no problem', as a DBA in the trenches you can't exactly be a dick to your users. You have to take the request in whatever form it manifests itself. Sure, you can try to push everyone to a ticketing system, but it's just not worth it in the long run. Too many times the request is just something small like can I have access to this table or can I get a backup real quick so I can push this new code. Using a ticketing system just isn't always practical or even conducive to good relations.

So what can you do then? I mean, you can't exactly just have people shouting requests at you from down the hall assuming you heard them. What I tend to do is push everyone to email. After all, I get email on my hip and it's easy enough to not get in the way of even the simplest requests. When I'm in a shop that insists on having tickets for everything, I'll take requests through email, and just create the ticket myself. And once I get all these requests coming in, I keep them organized in a master list of some kind. I used to use Excel which has its advantages with sorting, etc. Currently, I use OneNote and I'm liking it just fine. In the past I've also written small web apps to manage my task list too.

The point is though it really doesn't matter what you use. Use whatever is easiest for you and that won't hold you back. Just make sure that whatever you use, you use all the time. If you want to manage tasks in Outlook, then do so. Like I said though, I like OneNote these days. That's mainly because it's easy to copy emails from Outlook. That makes it really easy to reply once the task is done, and it gives me a record of exactly what was requested.

I was watching this guy in the bathroom the other day (no, not like that… be nice!). And something struck me as a bit useless. So what this guy did was he had one of those large PDA phones and he didn’t have any where to put it, so he laid it on top of the urinal while he was doing his business. When he was done, he took it out and went to the sink and washed his hands. Then he took his phone and left. Since he actually laid his phone on the urinal and didn’t wash it, I was wondering why he bothered washing his hands at all. Doesn’t he know that unless he actually pees directly on his hands that they’re not in any more danger than his phone is, and it’s actually highly likely that his phone has whatever his hands do? And where do you think all that yuckiness will go next time he uses his phone?

I saw this episode of MythBusters where they tested this theory with toothbrushes. They had a control brush under glass down the hall, and they had a couple more sitting in the bathroom, etc. At the end, what they found was that there was just as much fecal matter on the brush under glass down the hall as there was on the one in the bathroom itself. Pretty gross, huh? The point is that there’s a lot of conjecture that goes on when it comes to bathroom habits and the like. The MythBusters however, pulled hard numbers and proved that your toothbrush is going to get nasty stuff on it regardless.

In DBs we deal with numbers, and not conjecture and not feelings. Numbers don’t lie. So the next time you step into a meeting, or go to your boss and ask for a change to the DB for whatever reason, perhaps it would be best if you pulled some numbers so you have something solid to back you up. Otherwise, despite all your trouble, you might just end up with piss on your face.

OK, I've been promising this for a long time now, but I finally got the RSS ready for IT Bookworm. So you guys go on and subscribe and I'll update it with book and video reviews as well as press releases for new books and videos. I may even put some training discounts up there if they come my way.

I'm actually double posting this here and at Underground just to help get the word out.

OK, from time to time this topic comes up so I thought I'd publish this info in the hopes that someone will find it useful.

The problem is with getting non-admins the ability to admin jobs in SQL2K. It's widely known that only SAs can do this, but there's a special DB role in msdb that lets you do this w/o having to be an admin. Rather than give you a big explanation, here's the code so you can test it yourself. This will let anyone in this group admin SQL jobs just like they were SA.


use msdb
exec master..sp_addlogin 'testme', 'testme', 'msdb'
exec msdb..sp_adduser 'testme', 'testme', 'TargetServersRole'
grant execute on sp_add_job to TargetServersRole
grant execute on sp_add_jobstep to TargetServersRole
grant execute on sp_update_job to TargetServersRole
grant execute on sp_add_jobserver to TargetServersRole
grant execute on sp_add_jobschedule to TargetServersRole
grant execute on sp_delete_jobschedule to TargetServersRole
grant execute on sp_delete_job to TargetServersRole
grant execute on sp_start_job to TargetServersRole
grant execute on sp_stop_job to TargetServersRole

I hope this helps somebody. If you want to give the ability to admin only specific jobs though, you'll still have to use one of the intermediate steps you did before, or make the user the owner of the job.
Too bad groups can't own jobs.

Today on SSWUG, Steven talked about the new DB Architect cert from MS. I have no problem with what he said, and in fact, I even agree with most of it. However, it's really going to be hard to make any of us care about it when pretty much every company out there acts like DB work is so easy that pretty much anyone can do it. Companies go through DBAs like candy with this laissez-faire attitude that any DBA is as good as the next.

It's really getting kinda sickening. Somehow they think that their IT staff is so replacable that they can do anything to us they want and they can just go get another one. Well, I don't know about any of you guys, but I don't remember seeing any DBAs standing on the work wall at 7-11.

I really think that most of the problem is that companies still don't see the real benefit to putting the time in on their apps before they hit production. Most companies still just rush things together and test their apps under fire. They have the coders write the DB schema, and architect the entire solution. Well, I'm sure that reading a couple .Net books qualifies you as an expert in networks, storage platforms, DB schemas, indexing, etc. And until companies start to realize that all of these things can't be done by one person, and that they're all a lot harder than they sound, we won't get any real respect. See, once they make that leap, and start to finally see that these things not only matter, but they'd actually start listening to their DBAs and actually treat them like their valued members of the company with something very important to contribute.

Now, nothing has really spawned this post except me thinking about how trivial this new cert is going to be. If companies don't even see the need for this stuff, then our precious new cert certainly isn't going to mean anything to them. So basically, we're getting certs to impress other geeks at conferences. It's almost like we're displaying our Klingon ranks for each other to see.

And I know what you're thinking... I'm complete wrong and companies are really into architecting real solutions. Well, if that were true, then we wouldn't need to be compliance audits for basic IT processes. Hell, we have to fight companies for even an extra week to benchmark a new app, much less for the money to buy the benchmark software. It's pathetic. I realize that it's a pain in the ass to have to hold off on your deployment for something as worthless as benchmarking, but you're just gonna have to start sucking it up.

Anyway, that's all I've got.