Friday, July 31, 2009

10yrs Experience

I’ve interviewed many DBAs and one thing holds true more often than not.  Almost everyone has 10+yrs experience, and almost none of them can show the most basic knowledge of SQL.  So I have to ask myself again and again how it is that such experienced people can manage to not have any knowledge about their field.  I think the answer is that these people don’t really have 10yrs of experience.  What they have is 1yr 10 times.  They never bother learning anything new or pushing their skills so they never get any advanced knowledge.  This is why the big conference speakers can give the same sessions year after year and always pack the big rooms.  Because there are more people out there who need the basics and they don’t even study the session material.  So they’re able to come back year after year and still learn something from the content.  And that’s not to say that the session isn’t fabulous.  It’s just to say that people should be getting tired of it and they’re not.

So you’ve got the bulk of our profession out there doing the bare minimum to survive.  It’s honestly like they’re potty training.  When you’re a kid and you start potty training you have a hard time at first, but once you get it, that’s it.  Once you’re potty trained there are no extra levels.  You either pee in your pants or you don’t.  And that’s how so many DBAs treat their jobs.  They’re learned a very small core of DBs and they think that’s it.  They can stop learning because they’ve potty trained in SQL.  Come on guys… that’s now how it works.  Learning SQL is more like chess.  There’s much more to it than just the basic moves of the pieces.  You eventually have to push yourself and learn to think in different ways. 

So all I wanted to tell all you guys is now that you’ve learned to not pee in your pants, start pushing yourself for more and actually get 10yrs experience, and stop repeating the same basic level of knowledge again and again.

 

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Tuesday, July 28, 2009

Landing that job

You’ve been on a couple interviews and you’re finally getting offers coming in.  But a mistake that gets made quite often is that someone takes the first gig that makes them an offer because they can’t afford to turn it down.  That’s an evil in our society that we have to be forced to something we don’t want just to make a living.  If more companies considered retention in their plans we would be more stable as a workforce and you wouldn’t be forced to make decisions you don’t want to make.  Of course, if companies gave even a single thought to retention a lot of us wouldn’t find ourselves out of a job to begin with.

But leaving that behind, let me just advise you against taking the first job you come across.  If you have a family to support I certainly understand it and you’ve gotta do what you’ve gotta do.  But if you’ve got more than one offer coming in, there’s no reason why the other guys can’t wait a day or 2 for your answer.  Most companies take forever to get you through the process and then expect you to make your decision on the spot.  Try not to fall into that trap if you can help it.  It’s not going to kill them if you take an extra day or 2 to consider all your offers.  Some recruiters like to put pressure on you by getting offended at your audacity for considering a different offer, but that’s just childish and don’t fall for it.  Their only concern is their own paycheck and it has nothing to do with you.  You gotta do what you gotta do.  Take the gig you want not the one the losing recruiter wants you to take. 

Recruiters will play games with you to get you to take gigs too.  I recently witnessed a recruiter telling someone they had to accept the company’s offer right now or it would be rescinded.  Whatever dude.  So if something like that happens to you you have 3 choices.  You can capitulate in which case you get what’s coming to you.  You can also tell them up front that if the deal’s only good right this second that you pass.  That usually changes their tune and fast.  Or you can accept the offer and then entertain other opportunities as they come up.  That may leave you accepting the offer and then rescinding it a few days later, but that’s the cost of doing business.  And if they ask what happened and why you’re backing out, just tell them that you don’t like being blackmailed so you took it to appease them but did your own thing.  Then if at all possible, make sure the company finds out how the recruiters who are representing them are doing business.  You’ll probably find that they knew nothing about the threat and would be pretty upset to hear about it.  I’ve personally ratted out a couple recruiters for similar behavior.  Seriously, don’t let them bully you.

I don’t really like the idea of having to accept a gig and then turn it down a couple days later, but if the recruiter is going to be a child about it then you have to play the game.  My job is to get the best deal for me and my family.  So I’m going to make sure that happens.

So unless you’re about to lose your house, don’t marry the first guy who holds your hand.  There may be better out there.  Personally I don’t like shortterm gigs if I can help it.  I like to get somewhere and stay there.  So when I accept a gig it’s because I think it’s something I want to do for more than 3yrs.  That’s the goal anyway.

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Thursday, July 23, 2009

Decimal(18,2)?!?

I just reviewed a script that had 3 major problems.

1.  It created a #table and then immediately truncated it.

2.  It passed in a var into the sp and then hardcoded the value a few lines later.  The passed-in value will never be read.

3.  It did the following operation.

Declare @var decimal(18,2)

Set @var = select count(*) from table

Really?  Come on people let’s think about what we’re doing.

 

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Wednesday, July 22, 2009

Murphy’s Law of Vacation

We’ve got this situation at work where we’ve just run across this very well-known law. 

The law states that that code you just put into production will always break right before you go on vacation.

The law also states that if the only resource for an application goes on vacation, no matter how long the app has been running without issue, it will break as soon as he goes on vacation and you’ll have nobody there with knowledge to fix it.

Help us all.

Is there a connection between Oprah and Michael Jackson that caused his death?

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Monday, July 20, 2009

DBA Requests

Here’s just a little advice when sending your DBAs a work request. 

Keep the request as succinct as possible.  If you can get away without giving tons of extra info in paragraph form it’s easier to get exactly what you want.

For instance… if you need a DB restored to a different box the perfect request that will be understood by your DBAs will be this:

I’d like you to restore the latest full backup of Server1.CustomerDB to Server7.CustomerDBtest.  I don’t need the logs restored.

Here’s another good one that will get you something specific that you need as well. 

I need you to take an immediate backup of Server1.CustomerDB and restore it to Server7.CustomerDBtest.  I’m trying to solve a data issue.

That’s it.  You really don’t need any more than that.

Here’s an example of a bad request I received:

Can you please copy some data for me?  I had one of our field agents call and tell me that he accidentally deleted some data and he needs me to investigate it and get it back.  And can you let me know when it’s done because he’s waiting for it.  The problem is that he was trying to delete an order he just entered but he deleted more data than he needed and now someone else’s orders aren’t showing up.  So if you could take care of this for me as soon as possible it would be appreciated.  If you could also give him permissions to the development server so he could inspect it before I make the change that would be fabulous.  I need the data copied from the OrdersPending view on Server17 to Server 58.

Thanks.

 

So, ok… here are the problems with this request.

1.  Way too much extra crap.  I don’t need the story, just the request.

2.  The request doesn’t come until after the big story so you’re wasting my time by making me read all that stuff before I even find out what you want me to do.

3.  As a DBA I’m having a hard time figuring out how copying the current production data to a dev box will recover the lost data.  This request doesn’t even make sense.

4.  As it turns out, it’s not that data that was needed.  He needed the view itself to be placed on the dev box so he could investigate which orders were missing.  Then he was going to request that the data be recovered.

Here’s how this request should have gone…

A field agent has deleted needed orders.  Can you create the Server17.OrdersPending view to Server58.ThisDB so I can investigate which ones are missing?  Also, do you know of a way we could just roll the entire operation back or otherwise get those missing orders?  Thanks and any help you can provide will be appreciated.

It’s not the most succinct, but it allows the DBA to understand the situation and respond accordingly as the view may not even be necessary.  We may be able to get a log reader and just rollback the entire thing.  So this is where the DBA can make a decision.  This request gives just enough info to get the problem across, but not so much that it’s unwieldy. 

The elements that a DBA request should have are:

1.  Brevity

2.  Concision.

3.  Explanation of specialized circumstances (but remember #1 above).

Anyway, this is just to help those of you who may have trouble getting what you want from your DBAs.  Speak a little of their language and you’ll get things faster and more easily.

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Wednesday, July 15, 2009

Fairy Repellent

One of my big peeves is devs writing code to protect themselves against things that never happen.

You really see it all the time don’t you?  And it always sounds so reasonable at the time, but it really isn’t if you put any thought into it at all.  Here are a couple examples.

We had a dev a while back to introduced a redesign for a job where he put everything pretty much into the same step.  He had a long SP written that combined xp_cmdshell steps and reindexing steps, etc.  It was all just one long strip of code.  And of course his logic sounded logical on the surface, but not once I started asking the right kinds of questions.  See, his reasoning was that since there’s no way in SQL to run a job step by itself and not the steps that come after it, he needed the ability to be able to run any section of that SP he needed.  Ok, that sounds alright because he’s right.  While you can start a job at any step, you can’t tell it to only run a single step unless you play with the workflow in the steps. 

But one simple question killed the whole thing… when’s the last time you needed to run just a single step in this job?  I assume that the steps that follow are there for a reason, right?  So give me a scenario that this would cover.  And of course it’s always the ethereal… I can’t think of anything right now, but I’m trying to cover all the contingencies.  I get that dude, but you’re coding for issues you can’t even state. 

What about when the job fails?  How often does the job fail? 

He said, oh it probably fails a couple times a week for one reason or another. 

Ok, now how easy is it going to be to troubleshoot the failure if everything’s in just in one huge pile?  Shouldn’t you be coding for the case that happens the most?  And of those times it fails say at step 2, do you ever need to run step 2 and nothing after it? 

He said, No. 

, then why are you coding for it? 

He says, well there might be a time when I need to run a single piece of the code for some reason say redoing something in the middle of the day or something.  It hasn’t happened yet, but it could. 

Yeah sure, that could happen.  And if it ever does what’s stopping you from copying the code from the job step you need to run and just running it manually in SSMS? 

To which he replied… Ummmm….

So ok, this is getting long so I’ll leave this at one example, but you get the point.  It’s a lot like buying fairy repellent for your house, and setting fairy traps everywhere.  When’s the last time you had a fairy problem?

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

 

Technorati Tags: ,
Tuesday, July 14, 2009

No More Select *

Ok, not ‘no more’, but you guys should seriously limit your usage of select * for everything.  I realize that it’s easier to support when you change the data requirement, but it pushes a lot more data than you need and that could really impact network and server performance. 

Let’s say you’re running a web app and you need 3 cols on your page.  And you pull all 37 because it’s just easier to type a * than each column.  That’s fine from your end, but you could seriously impact the server and the network because if one of those cols is really wide, say varchar(200) (or even 400, right…) then you’re taking up that much extra bandwidth and server memory.  Sure it probably won’t effect your session that much now, but when you’ve got 500 people on your site at the same time you’ll start to feel the pain then for sure.

So just code for performance and stop being so lazy about having to type a few chars.  And if you really don’t like typing that much then get yourself a nice code completer like the one from Red-Gate and you won’t have to type nearly as much.  But I’m getting sick of laziness being an excuse for bad coding.

There are some exceptions though.  It is ok to use select * for some things but you have to choose those individually and judiciously.  Let’s say that you’ve got an SP that pulls 65 cols from a complicated set of logic that you don’t wanna have to re-create or maintain separately.  And let’s also say that you only need to query it every now and then, or maybe just 2-3 times a day.  In a case like that, it’s probably ok to go ahead and use the SP even though you’re only using a handful of the resultset.  However, in that same scenario, if you were using that data several times a minute, or even a second, then you’re really better off from a performance perspective to go ahead and create your own SP that returns less data.

Another excuse that gets used is people often tell me that they used select * to make it easier to make changes to the app.  And that is logical to a degree.  But people protect themselves all the time from issues that aren’t issues.  For instance, I had this just a while back where someone gave me that excuse and when I probed, the app had been up for 2yrs and had only ever had one minor change.  So what are you protecting yourself from then?  If the app is fairly static, then grow up and do the right thing.

OK, that’s actually stepping on the toes of another post so I’ll stop here.

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

 

Technorati Tags: ,
Monday, July 13, 2009

Just NO

No you can’t have a generic acct to share with all the devs in your dept so stop asking.

And Oprah.

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Thursday, July 09, 2009

Midnight Twits

OK, like the rest of the world I have felt pressure to start twittering… so here’s my twitter addr, and feel free to follow me.  It’ll be mostly (if not completely) DB-related stuff so I’ll keep the personal stuff out.

http://twitter.com/MidnightDBA

 

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground -- http://www.infoworld.com/blogs/sean-mccown

There is no “I” in SHUT UP!

We’ve all had him… that manager who thinks he’s a wonderful team player but who is more like a Nazi than anything.

He thinks it’s teamwork to override everyone’s advice.

He thinks it’s teamwork to force people to work the way he wants to work that doesn’t make sense to anyone else.

He thinks it’s teamwork to have the minority opinion and force it on the group.

And of course he thinks it’s teamwork to monopolize every meeting with his own agenda(even someone else’s meeting).

So what do you do with someone when you can’t just tell them to shut up?  That’s a tough one and something we’ve all had to face.  At my last big gig there was a guy that none of us liked.  He literally sabotaged projects and he even swung a real sword around the office one day.  And for some reason the bosses wouldn’t get rid of him.  This guy was like the teflon don and nothing we did could get rid of him.  And that’s what I don’t understand.  What is it about these guys that the managers like so much?  Why do they consistently get rid of qualified techs and keep the morons?  Why does the guy with 3 kids who takes on every project in the place and produces more code than anybody get fired for an honest mistake when the little asshole who lives with his parents and is 4mos behind on his only project keeps his job?

I’m telling you, there’s something wrong with the American job marketplace.  Companies don’t know how to retain employees and they don’t care.  I really can’t tell you how many times I’ve been told by some HR tool that a DBA is a DBA and they can replace someone just like that.  Well you guys are probably all DBAs… does it really work like that?  Are we really all the same?  Can you just replace any DBA with any other DBA?  I really hope not because if that’s true then why did I even bother trying to get my MVP?  Or get my certs? 

OK, that was kind of a little jaunt there for a min… I was talking about dealing with that guy at work.

The truth is I don’t really have any of those answers.  It’s so hard to deal with someone like that because if you’re rude to him he’s the first one to go running to daddy to tell him you aren’t being a good soldier.  And now you look like the asshole.  And you can’t go to daddy yourself because now you look like a baby who can’t solve his own problems. 

Here are a couple ideas though.  These guys rarely act like themselves around the bosses so the bosses don’t know how they really are.  So you can start recording your interaction with them.  That’s a little underhanded and some companies don’t like that, but you can do it if it’s bad enough to prove a point and you need to prove to your boss that he’s unworkable.  Another thing you can do is to always make sure you talk to him with someone else present.  If you can, make it the boss.  Explain to the boss what this guy is like and that you want to hold all official meetings with him in the room to make sure you get heard and the right issues come out.  If you can’t always have your boss there, then whenever you have a meeting, send out meeting notes to him, the others involved and the boss.  In that email state that it was advised that he do this for these reasons and that he declined for this reason.  This way maybe the boss will read it and ask what happened, and at the very least you have a record so that when it all crashes, you’re covered.

Look, there is no real solution.  You just have to feel out the situation for yourself and see what it’s going to take.  It’s a shame that an inability to effectively deal with someone like that often times drives good people away.  I’ve worked in one company where they did regular 360 reviews and the managers looked through them and if someone got a low score from their peers they dug deeper.  And they often got rid of people based on those scores.  You have to be careful with something like that though.  Sometimes an entire group can hate someone just for doing the job he was hired to do.  So like an entire dev group can really hate a DBA coming in and locking down production when they’ve been allowed to do whatever they like for a long time.  And in a case like that they can use the 360 to get their power back… but I’m not bitter, I swear.

Technorati Tags: ,
Thursday, July 02, 2009

A Learning Plan

I realize it’s hard to find time to study with work pushing at you all the time and with family pulling on you after that, but you’ve gotta try to find some time or you’ll get left behind.

I’m certainly not perfect, but I am pretty good at making time every day to study something.  It’s not that hard really.  Just take 15mins out of your lunch break.  Or take 15mins at the end of the work day before you leave, or in the morning before you get started.  I used to spend the first 30mins every day going through newsletters, or reading a few pages in a book and going through an example.  It’s slow going to just do 15mins a day, but at the end of a month you’re further along than you would be had you not done anything at all.  Slow going is better than no going.

And I’ve interviewed guys before who were just pathetic.  You could tell that they hadn’t bothered learning anything new in a long time and even what they knew wasn’t all that.  And once I even got the opportunity to interview the same guy again like 2-3yrs later and you know what… he hadn’t changed a bit.  I don’t think he’d picked up a book in all that time.  And there’s just no excuse for not learning more these days.  There are so many free resources it’s staggering.  There are free sites with plenty of tech articles, there are free video sites, there are newsletters, forums, etc.  There’s just no excuse.

So really, don’t get left behind.  Dedicate yourself to 15mins a day.  Make it the same time every day.  It’s only hard to get started.  Once you’ve got the habit you’ll begin to love making even slow progress. 

Technorati Tags: ,

I Warned You

I managed to take the 70-450 exam for Katmai a couple weeks ago and I was surprised to find that I got a powershell question.

As well, I was looking through some practice questions for the Katmai Dev exam (don’t remember the number)and there were a couple powershell questions on there as well. 

So I’ve been saying to people for 2yrs now that they’d better start learning powershell and now it’s starting to creep into exams even.  So you guys get boned up on your powershell and feel free to write me if you don’t know where to even get started.  I’ll be glad to help.

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