Uncategorized

Easier to Care

We’ve all had companies that didn’t listen to us.  They hire you with the intention of having you make things better and improving their processes.  Then when you come on and start making suggestions, they don’t want to implement any of them.  The reasons can be political, selfish, or just laziness, but the fact remains you’re not doing what you were told you would be.  And the company doesn’t seem to mind.

So what do you do now?  The company doesn’t seem to mind if things run the way they always have been so why should you?  It’s definitely easier to care about the quality of your job when the company does.  But why would any company choose to do things poorly especially when they’ve got to such great lengths to hire someone to fix them?  The answer is I just don’t know.  I’ve seen it too many times under too many companies and it confounds me every time.  I think a lot of time it’s an issue with a boss having too much faith in a guy who’s telling him you don’t know what you’re doing.  And even when you bring solid numbers to him he still doesn’t see the light.  That’s the one that gets me.  When I come to them with solid benchmark results and they still refuse to change the process because there’s a guy they’ve worked with longer who’s lying to them about how it’ll really behave in prod.

OK, so now what to do… well, you’ve really only got a couple choices.  You can quit or you can make your peace with it.  If you’re just not getting anything you need out of the gig then maybe it’s time to move on.  But if you’re getting something else out of it like a good schedule, or work from home, etc then it might be worth it to you to stick around.

If you do stick around then you need to make your peace with it.  And that’s the hard part.  Basically you have to stop caring about the systems and how they run.  Consider yourself more of an internal consultant.  They ask you questions and you advise them.  If they don’t take your advice then it’s not your problem.  It’s really as simple as that.  Of course, if you’re on the hook for support and this is gonna cause a bunch of extra work for you then that’s another story.  But you’ve gotta weigh that against everything else and make a decision.  If they’re really not gonna listen to anything you say then they really don’t understand DBs now do they?  Part of that is education, right?  You have to educate them about how to work with data.  Remember, this data explosion we’re in the middle of is still relatively new and many companies don’t have any idea how to work with it yet.  They have to be taught.  Now if only you can find a way to open them up to listening.

Just remember… numbers don’t lie.  If you keep showing them numbers eventually they may listen.  Of course, for some of these things you could always just do it yourself and say sorry later.  I’d never personally do anything like that(cough-cough), but I know some guys who have.

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

Uncategorized

10yrs Experience

1 Comment

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

Uncategorized

Landing that job

1 Comment

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

Uncategorized

Decimal(18,2)?!?

2 Comments

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

Uncategorized

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

Uncategorized

DBA Requests

2 Comments

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

Uncategorized

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: ,
Uncategorized

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: ,
Uncategorized

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

Instead of working, I blog.