Instead of working, I blog.

OK, so a while back I wrote a post about how Oracle doensn’t build as much of a community as MS.  And not only do I stand by it, but I’ve seen quite a few of the replies around the internet and those Oracle guys amaze me even to this day.

They spend an awful lot of time talking about how much better Oracle is than mssql and how much more stable it is and how much more Oracle users expect from their DBs because they tend to be more important than mssql DBs.  Also, Oracle DBs have more users going against them than mssql DBs so more people are affected when they do go down so Oracle DBAs have to be more on the ball because their users expect more uptime.  Whereas mssql DBAs’ users expect more downtime so the DBAs don’t have to hurry as much to get the system back up because that downtime is expected. 

Man, talk about having your head in the clouds.  I can’t believe that in this day and age that people are still so incredibly blind.  Do they really think that mssql has taken the market by storm because there are so many people with little insignificant DBs and they just don’t wanna pay for Oracle on these tiny little things.  It’s not under dispute that Oracle outshines mssql in some areas.  They’ve been around longer and they’ve had more time to bake their product.  But that doesn’t make mssql a slouch either.  I know you guys know this all too well.  Some of the biggest and most important DBs on the planet are on mssql and they require just as much uptime as those super-important Oracle DBs.

To make such statements is not only ludicrous, it’s just childish.  It’s like saying that linux apps are more important than windows apps.  Grow up guys.

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

This post was particularly inspired while cleaning my house today.  It’s easy, if you think you’ve got a clean house then just stand up on a ladder some time and change your perspective.  I think you’ll find there are lots of things about your clean house you don’t know.  And while nobody’s officially complaining about the condition of the house (and in fact, everyone thinks it’s in great shape), it clearly is in disarray when you shift to that new bird’s eye view.

The same is true for your DB.  I honestly can’t count the number of times I’ve been told that there was no reason to look at DB performance because nobody was complaining about it.  Then when I dig into it and look at things from a DBA angle, the system is actually abysmal.  So if performance is so bad then why isn’t anyone complaining?  Well there can be a couple reasons for that.  First of all the DB could just not be very busy comparatively so the users won’t notice the issues.  And second, they may have just gotten used to things running slower so again they don’t notice it.  I’ve actually seen that several times.  Things get slower and slower, or better yet, they just start out slow and nobody ever knows the difference.  And what’s even WORSE is that more often than not there’s some cornhole in the background telling them that Oracle would solve all their problems.  Listen, if you can’t write a simple process against mssql and make it run right do you really think you’ll be able to hit Oracle ok?

So I’ve gotten off topic a little… back on track.  The point of all this is that just because nobody’s complaining about performance that doesn’t mean that your system is performing.  I quite often find that companies have no idea what their systems can scale to and they just assume that they’ll be able to handle whatever they throw at them.  And it typically takes more forethought than most companies have to look at a system objectively and proactively fix problems.

So the next time you’re considering your system performance, stand on a ladder or crawl down on the floor and see how things look from there.

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

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

 

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

 

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.

This is the perfect topic to go along with what I wrote on my other blog today in The real difference between SQL Server and Oracle.

I just got an email from the producer of the new Kalen Delaney series on SQL Server giving me my press pass into the online content for this series. I've only watched the 1st 9mins so far and already it's exactly what I'm talking about in my other blog. Here's Kalen Delaney who writes one of the most successful series on SQL Server (the other one is by the late Ken Henderson. I still have a hard time saying that), and she's going the extra mile to put her book into a video training series where she explains the concepts herself.
I, like many other people learn better when things are explained to me than I do from a lifeless page. And Kalen's an experienced teacher so she has a way of explaining things that make you just get it. Already in this video she's already covered security of metadata and the sys schema. She's actually explaining how this stuff fits together from the ground up. That's how it's done. I have no doubt that the rest of the series will contain the same deep-level understanding.

I think I'm going to enjoy this series and I'll try to write-up a full report when I'm done. Or maybe I'll just do it as I go along.

OK, so here's the link to the site. You can order the DVD or you can watch it online. It's good stuff. Seriously, go check it out if you haven't.
I was recently chatting with Kalen in email and she told me that this is basically the course she teaches when she's brought into a company to teach a class.

Actually, I didn't mean this to be an official interview, but I'm going to go ahead and paste her email here. I'm sure she won't mind (at least I hope not) and she explains it better than I would anyway. I typically don't post emails without asking first, but she knows who I am and she answered my questions like she was being interviewed, so this one time I'm going to do it. But you'll almost never see me take this liberty.

1. What material will this first DVD cover…

You can get information about my course here: http://www.insidesqlserver.com/Course%20Description%20and%20Outline.htm
The first DVD covers most of what is in Module 1.

2. What format will it take… will be be a group of slides and whitepapers, or screencast instruction by you…

The DVD will be a mixture of live capture of me talking, and screen captures of my slides and my demos.


3. Who all is involved in the project…

I am recording the class that I have been presenting all over the world for the last several years. Chuck Boyce, of AskaSQLGuru.com is doing the filming and editing. The business side is being managed by Peter Ward of www.WardyIT.com in Brisbane, Australia


4. How often can we expect to see a new DVD come out…

Since I have to fly to New York for filming, we are only able to do about one a month. In fact, I am just about to leave for the airport for the second round of filming.


5. What advantage will one have in ordering these over just getting the books…

Different people learn in different ways. If you like to hear and see someone explaining concepts, this can add to the benefit of the books. People pay a lot of money to attend my classes, but since I’m only one person, I can’t offer them that often. The DVDs are a chance to for anyone, anywhere to get to take my class. If you can read and absorb everything in the books on your own, the DVDs might not offer anything more.

So again, here's the link to SQLServerDVD.com.