Instead of working, I blog.

I find myself multitasking again with my little one.

Today I'm testing some HA scenarios with replication while simultaneously being a pirate.

Enjoy.

Watch my free SQL Server Tutorials at:
http://midnightdba.itbookworm.com/

Read my book reviews at:
http://www.itbookworm.com/

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

Follow my Twitter:

http://twitter.com/MidnightDBA

I had a very typical conversation with my 2yr old yesterday.  It went something like this…

The Juice Box

Benji:  More juice daddy.

me:  Ok, go throw the box away and bring me another one.

so he goes and throws it away then looks at me.

me:  Ok baby, now bring me another box.

about a minute later he shows up with a brown box that some books came in.

me:  No baby, bring me a juice box.  The small one.

so then he shows up with a smaller shipping box.

me:  No baby, a juice box.  Bring me a juice box. A juice box.

(Benji looking around all over)

me:  it’s in the cabinet right there honey.

(keeps looking around)

me:  open the cabinet door and take out a juice box.

(looks at the fridge door.)

me:  No baby, the cabinet door.  Right there by the broom.

(goes to the other side of the fridge and looks at the wrong broom instead of the one right in front of him)

me:  no sweetie, the other broom.  Open the door by the other broom.

(opens the fridge door)

me:  no sugar, the cabinet door.  close the fridge.

(looks all around)

me:  the green door right in front of you. 

(Looks at fridge again)

me:  no no, the green door by the broom.

(goes to the other side of the fridge again and looks at the wrong broom)

me:  honey, bring me a juice box.

(looks at ceiling, floor, dog food, etc.  everything but the door right in front of him)

me:  sweetie, bring me some juice and I’ll open it for you.

(opens right door and brings the juice box.)

Now I ask you, how many of us have had conversations very similar to that with our end users or even our devs?  I know some of the devs I’ve worked with have been exactly like that.

So it really got me thinking about the skills a good DBA needs.  So as it turns out if you’re looking to make a switch to being a DBA, here’s what you should do. If you really wanna be successful as a DBA, then while you’re studying SQL and learning your job, open up a daycare and run it for about 5yrs.  Don’t only open it and run it, but actually get in there and work with the kids.  I’d say a good mix of 2 and 4yr olds should do it.  I’ve got 3 kids myself and I did it in reverse.  I became a DBA first and then had my kids, but I’m convinced that having kids has made me a better DBA because I honestly do have a lot of very similar conversations with my kids and my devs.

And this may piss of some devs, but any DBA out there who’s had to deal with a group of devs who thinks they know what they’re doing when you’re trying to show them how to do something, you know exactly what I’m talking about.

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

Job security is a really big concern for most DBAs because we tend to automate ourselves out of a job.  It doesn’t have to be though.

First I’d like to talk about the worst way possible to ensure you keep your job.  I’m talking about those guys who write impossible processes that nobody else can support.  They think that if they’re the only ones who can support it then the company will keep them around.  And unfortunately that’s not the case.  A company is gonna do what they’re gonna do no matter how much you hold their processes hostage.

Then there are the guys who do something similar.  They just refuse to document anything and they hold all of the tribal knowledge and keep it to themselves.  This isn’t exactly the same as the guy above because this guy could just have info that nobody else does and refuses to show anyone.  And again, while it seems like holding information hostage in exchange for your job would be effective, it’s not.  Companies are gonna do what they’re gonna do no matter what you do to prevent it.  So if they’re looking to get rid of someone, you may be safe for a while, but not for long.  Your boss may recognize that you’re the keeper of the processes, but if they get rid of him then the next guy in charge of you may not see your brilliance. 

So ok, taking hostages isn’t the way to go, so what is?  That’s not a really easy question to answer because the specifics change from company to company.  However, the overall method goes something like this.  Be a knowledge expert.  Don’t just be a DBA.  DBAs can be automated.  What you have to do is be more than that.  Be a data expert.  Be a process expert.  Be a troubleshooting expert.  You have to actually prove to everyone that you’re the one who’s solving problems, or preventing them.  It’s not enough to just be a DBA anymore.  Buck Woody is fond of telling people to not be DBAs.  He wants them to be DB professionals.  And while he’s right to a degree, he’s splitting hairs.  Instead of changing the name of the position, we should work on changing the meaning of the position.  Show the world what DBA really means.

And it’s not just about being an expert.  It’s about solving problems that nobody even knows are problems.Talk to users and find out what they do every day, or every month.  Find out what their pain points are.  Not only that, but also look at existing processes and try to find out where you can improve things. And by improve, I mean greatly improve.  Don’t just take a single SSIS package and improve its performance by a few mins.  What you need to do is something major.  Really increase the performance or the reliability of something.  Make something easier for your group like building a management portal.  Put your mind to it and be useful.  But don’t just manage backups and automated processes.

Unfortunately, all this is just fodder.  Again, companies are gonna do what they’re gonna do.  So there’s really no way to save your job if it’s really in peril.  Layoffs are unfortunately a part of being in the workforce.  And it always seems that no matter what you do or how good you are, or how useful and incredible you are, the lazy, stupid guy in your group is the one your company keeps instead of you.  That’s another fact of being in the workforce.  Companies have no concept of who their best people are.  I could almost guarantee you that if you poled 50 companies who their best people were, and then had the ability to magically look into the workings themselves and see who’s actually making things happen, the two lists would be completely different.  Or better yet, ask the big bosses at any company who their best people are and then ask the employees themselves.  Again, the lists will be different.  All of this is just a windy way of saying that companies have no idea who their key people are and sometimes no matter what you do you can’t secure your position.  Sometimes companies just insist on being blind and there’s nothing you can do about it.

But if you’re going to have any chance at all, then follow my (and Buck’s) advice.

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

Have you ever heard something so stupid or been asked such a stupid question that it actually made your brain flatline?  And I mean truly flatline in the way that you actually can’t form a complete thought well enough to respond.  I suppose to a large degree you have to decide whether they’re being serious or not. 

One of the things I used to get flatlined on all the time was baselines.  In a gig I had a few years ago I was constantly being asked why the CPU was so high on the server, or why there were so many active connections in the DB.  Here’s how the scenario typically went… I would get a call from someone saying that the CPU was at 87% and why is it so high.  I would then ask what it normally is and to that they would reply, I don’t know.  That’s when my brain would just flatline.  I couldn’t think of anything to say.

Another one that used to kill me is when someone would call me very concerned because they were in perfmon and noticed that the disk queue was 15%.  I literally went blank and couldn’t think of any way to respond.  For those of you who aren’t up on perfmon, disk queues aren’t measured in %. 

Of course I’ve been flatlined enough over the years that I’m better equipped to handle the extreme stupidity that falls on DBAs sometimes… or so I thought.

It was actually earlier this year when one of my devs came up to me and said that he had a problem with one of his SQL boxes.  He then handed me a stack of papers like an inch thick.  This is the problem he says.  What he had given me was a bunch of printouts he’d taken from various websites that came up in his google search.  Now, these weren’t really a fix for a single issue.  No no… what these were, were a bunch of different possible issues to the problem he was seeing.  So he had gone into google and typed something like “SQL Server running slow”, and then printed out the top 50 results or so.  He didn’t read any of them;  he just handed them to me as a collective solution to his specific problem. 

And I, the experienced DBA and MVP… flatlined.

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

The longer I stay in IT, the more I realize I just don’t know what’s common sense and what isn’t.  I used to think all kinds of things were common sense but I’m having to change my opinion on them.  Keeping in mind that common sense changes with each industry, but there are some large overlaps.

For instance, I used to think it was common sense to actually test code before you put it into prod.  I no longer think that.  Apparently it’s something that has to be taught, drilled, practiced, and re-taught.  I’m just awed at how hard it is to get devs to test code, and quite often, how much harder it is to get companies to see the value of testing.

As well, I used to think that it was common sense to test the same scenario that you want to go into prod.  This sounds like the same one above but it’s not.  Here, the testing is happening, but they’re testing something different than is going to be in prod.  I saw this last year actually.  A company was testing a repl scenario to send their prod data to their reporting server.  They tested 25 tables and latency was excellent so they pushed forward with putting it into prod.  And of course the scenario crashed and burned in prod because they published over 200 tables in that DB, and the same number in like 10 other DBs.  So evidently it’s not common sense to test exactly what you’re going to put into prod.  And there are so many more examples of this one I could fill a book.

I used to also think that it was common sense to troubleshoot the same scenario you’re having trouble with, but again, I’m wrong.  I recently saw a scenario where a tech was troubleshooting a data load.  The load process was put on a different server than the one it usually runs on and it took about 4x longer than normal.  And of course that’s cause for alarm especially since both source and destination servers are in the same data center.  At least it would be alarming if he were comparing the same processes.  In prod he was running an incremental process and on his test box he was running a full load process.  So let me see if I’ve got this straight, you went from an incremental process to a full load and you’re surprised it’s taking longer.  I’m actually speechless.  Hopefully you at least now know why we have the incremental to begin with.

Again, I could go on forever, but I think you get the point.  Common sense isn’t so common anymore.  I’m not sure we can say that about anything anymore, much less IT stuff.

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

A couple pieces of code came across my desk yesterday and they’re definitely the kind of thing you read about… if nowhere else, then here for sure.  This was code that a dev sent me that is to be deployed next week.

The first one could actually cause a problem so I’ll talk about it first.

I’ll write the pseudo-code because I don’t have the actual code in front of me right now.  It goes like this:

1.  Check if the Whale schema exists.

2.  If it does exist then drop it.

3.  Create the Whale schema.

Ok, so that’s exactly what the script does. Here, I’ll go ahead and attempt the code.  I didn’t look it up so it may have a slight error in it, but you get the idea.

If exists (select name from sys.schemas where name = ‘Whale’)

BEGIN

drop schema Whale

END;

Create schema Whale with authorization = ‘dbo’;

So what’s wrong with this code you ask?  It’s simple, here’s the logic.

First, if it exists and you drop it then why just turn around and recreate it in the next step?  What’s the point of that?  So if your goal is to create the schema then everything above the ‘create’ line is useless.  And I know what you’re thinking… so what?  What’s the big deal if a tiny query gets run during a deployment?  It’s not like it’s going to drag the system down.  Well, you’re right about that, but it could kill the deployment.  If that schema did exist and it actually contained objects, then the drop statement would fail until you put those objects somewhere else.  So with there being no code to check that objects exist inside, you could be dooming the deployment to an unnecessary error.  You could also say that you know that the schema doesn’t exist so there’s nothing to worry about.  That’s fine, then take out the check and the drop.  If you know it’s not there, then take it out.  It’s called having concise code and it’s something that we lack in this industry these days.  Let me illustrate this with something completely ridiculous that also doesn’t really effect performance.

Create table #t1 (col1 int)

truncate table #t1

truncate table #t1

truncate table #t1

truncate table #t1

truncate table #t1

Insert #t1 Select 1

Ok, so look at that code above.  I created a temp table and then truncated it 5x.  That’s not going to effect performance at all because there’s no data in it since it was just created and there are no pages.  Then I go ahead and insert a row.  I can’t think of anyone who would let this kind of thing go on in an SP, or in deployment code, but we’re expected to let useless checks stay in our scripts. 

This code was clearly scripted in the wizard so it’s not like the dev went out of his way to do this by hand, but it’s the mark of a fairly inexperience coder to let the wizard create scripts and not inspect what it’s giving you.

The other piece of code doesn’t really do any damage as much as it’s just annoying.  In fact, it’s really 2 different scripts.  They’re create view scripts and the first one reads something like this:

create view MyView

as

Select MyFavoriteTable.col1,

MyFavoriteTable.col2,

MyFavoriteTable.col3,

MyFavoriteTable.col4,

MyFavoriteTable.col5,

MyFavoriteTable.col6,

MyFavoriteTable.col7,

MyFavoriteTable.col8,

MyFavoriteTable.col9,

MyFavoriteTable.col10

from MyFavoriteTable as MyFavoriteTable

Ok, so even typing this in the blog pisses me off.  And again, it’s just a style thing, but this just drives me crazy.  What drives me crazy the most is that this dev doesn’t understand what aliases are for.  To alias a table with the same name as the table itself defeats the purpose of having the alias in the first place.  Here a much better alias would have been mft or mt or m.  Hell, you could even go as far as MyFT or something like that.  Here, I’ll play one of those out for you and you tell me which one you’d rather read.

Select mft.col1,

mft.col2,

mft.col3,

mft.col4,

mft.col5,

mft.col6,

mft.col7,

mft.col8,

mft.col9,

mft.col10

from MyFavoriteTable as mft

Forget reading, which one of those would you rather type?  It’s just more concise and easier to read.  I happen to know the dev who wrote this and his opinion is that the full table name makes it easier to read when you’ve got larger joins.  Personally, I’ve never known anyone to complain about short aliases before, and again, I honestly think this boils down to inexperience.  When I first started coding well over a decade ago, I used to need things to be presented to me in very specific ways too.  It was the only way I could read the code.  That kind of thing is much less important to me now that I have been doing it for a long time.  Why?  Because I know how to code.

So the second thing about this script that bugs me is the fact that he saw the need to alias a query with a single table in it.  Now you’re just being obstinate for no reason.  I know the argument though.  He probably would say that he did it for consistency.  The only problem with that is the other create view script he submitted didn’t have the same stupid aliasing structure, so where’s the argument now?

Ok, so this code was clearly brought to us as part of a code review so the next logical question is why don’t we just reject the code if it bothers us so badly?  Well, the answer is simple.  Like so many places, our code reviews are merely perfunctory process placeholders.  Our lead dev has made it very clear that he’s going to do whatever he likes no matter what we say.  We’ve rejected code plenty of times for really valid process or performance reasons and he always thumbs his nose up at us and pushes it into prod anyway.  I really don’t understand how he’s gotten such a superior attitude towards the DBAs, but it’s completely unwarranted.  He acts like we’re in this just to piss on his parade and make him look bad, but we’re really only trying to help.  But we don’t even bother anymore.  What’s the point?  He knows more than the rest of us put together so we don’t even bring stuff up anymore.

So that’s my rant for tonight.  Remember, use aliases wisely and be as consistent as you can.  And for everyone’s sake listen to what your DBAs are telling you for a change.  They’re really only trying to help.

I’m just getting sick of dealing with LIteSpeed problems.  My big DW was using a lower version of LS and it was fine for a long time.  Then I upgraded to the new version and my backups went from 30mins to like 10hrs.  So I went back to the previous version.  Then I upgraded my DB from yukon to katmai and i upgraded LS at the same time hoping that the even newer version would work better with katmai on my big DW system.  That hasn’t happened.  It’s been ridiculous trying to get backups to even complete.

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

So I’m sitting here at the blogger table at the 2nd PASS keynote by Tom Casey and he brings up a good point.  Now this is something I’ve blogged about in the past, but it’s about that guy in your org who goes off and does his own thing and puts a small DB on his desktop and starts doing data loads, and crunching things on his own.  That can be a problem because IT isn’t involved and IT doesn’t even know it exists.  That’s why slammer was so devastating because of all those “unauthorized” DBs out there.  And everyone should be going through IT for these types of projects… or should they?

Tom actually brings up a good point that every piece of data, or every query doesn’t have to go through IT.  Some things aren’t big enough or are only for short-lived times and there’s no reason for it to be spun up as a project.  And again this is a fine line because as a DBA I really do have to know where my data’s going and if I let everyone just pull whatever they wanted, then server performance would be crap.  So it’s a tough line to walk because while we need to have some kind of decent control over where our server resources are going, we also don’t need to be involved in every little thing that crosses someone’s mind.

IT quite often also isn’t very responsive because we do have to plan things better than the users do and I think they lose sight of that.  The trick is for us to make it a real project while at the same time not slowing them down too much.

So I’m gonna go ahead and say that office users are free to keep things under our radar, but know that comes at a price.  If you lose the data or the code or it starts performing badly, then don’t come crying to us.  These are the things that IT brings to the table.  We bring recoverability, stability, accountability, etc.  And it’s quite possible that you start something on your own and then get IT involved when it gets too big or too important for you to manage yourself.  I really like this scenario because it’s often times easier for us to take over a project than it is to build it from scratch.  Sometimes it’s not because you have to re-write it to actually make it stable, but even that’s often times easier because you’ve already got the business logic and the GUI defined for you. 

So anyway, I like what I see in the demos on their new excel plugin (PowerPivot), but personally I’m waiting to see if it’ll actually work as well as they expect.  Because the data they’re using is highly specialized and I have to wonder how well my data will work with the product.  PowerPivot is a new BI plugin for excel 2010 but I really expect that it won’t really take hold for a couple yrs because the requirements to duplicate the scenario they outlined in the keynote are office 2010, sql server R2, and sharepoint 2010, and I just don’t see many people converting all of these that fast.

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

I’m sitting here at the bloggers’ table here at PASS listening to the announcements.  So far it’s just housecleaning, but Wayne is a good speaker. 

There’s been a lot of twitting this year and it really changes the face of the summit because you can find people and events just by pinging the group.  I didn’t think I’d like something like that, but it actually is pretty cool. 

I’m horrible at this live social blogging thing though so I’ll shut up now.

Ok we arrived in Seattle for PASS only I found out tonight that I’m not supposed to call it PASS.  Apparently the PC name for PASS is the PASS Summit.  Oh well…

So we started at the Tap House wtih Allen White and his wife and then went to the convention center (I can still call it that, right?) to register.  There we met up with tons of other MVPs and a few people that Jen follows on twitter.  Would that be her fellow twits?

I was talking to Allen about how things appear to be getting better because there are a lot more MVPs here than there have been the past couple yrs.  I think this is going to be a good week.

We also did our first DBAs@Midnight with Allen.  It was really fun.  We got to talk about Oracle and making mistakes, and powershell, etc.  It was a fun talk.  I’ll upload it soon so check back and I’ll let you know when it’s up.

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