Tag Archives: Training

The Juice Box

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

PASS Treasure Hunt

Ok, so the MidnightDBAs are off to PASS next week and we’ll be giving away some of our recently designed swag.  The way this will work is we’ll be twittering our position from time to time and the 1st one to come up and find us will get a shirt, book, or something. 

So if you don’t already follow us in twitter, get yourself setup and have them delivered to your phone and just look for us out and about.

Good luck.

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

Head in the Clouds

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

The Performance Dilemma

OK, so yesterday I was talking about how servers can take a long time to finally be brought to their knees with poor processes, and that you want to get to the point where your server is on a strict diet and you control every morsel that goes into it.

Today I want to talk about how that can play into a real performance strategy because unfortunately you have more to consider than just raw performance.  I know, I know, it sounded yesterday like I was advocating that performance was the most important thing.  And it is… but at the same time it isn’t.  So let me explain a little.

Performance is extremely important and some might even say it’s the most important thing on the server, but you also have to consider management et al.

See, quite often the code that leeches out the absolute best performance on the server isn’t as easy to manage as other solutions.  Something like this isn’t very concrete without an example so I’ll give you one.

Let’s look at what I call moving schema.  The guys in my shop are sick to death of hearing that term but it’s an important one.  Moving schema is where you drop and recreate objects all the time that should be permanent.  A good example of this is doing ‘select into’ instead of ‘insert into’.  Sure, the ‘select into’ performs better than the ‘insert into’, but it’s also harder to manage from a couple different perspectives.  For starters, even during your load you can’t specify a filegroup for the object so you’re stuck with the default.  Now for performance or growth reasons you may find it better in general if you put it on a different set of disks, but you can’t because ‘select into’ doesn’t allow it.  So from a space management aspect ‘select into’ traps you in a corner.  Also, if you have specific permissions granted on the table you have to keep track of them somewhere and reapply them every day when you recreate the table.  And you also have to remember to update your permission repository every time you change the perms on that table during the course of your other admin functions.  As well, most performance stats are gathered by objectID.  And if you’re recreating the object every day then your objectIDs are invalid tomorrow.  So you either have to keep track of what the objectID is every day so you can track performance and other issues (like fragmentation) from day to day, or you have to store the objectName in your repository as well which leads to an inefficient and larger schema to track production issues.  It also makes the timing of other processes more critical because with ‘insert into’ they’ll be blocked until the current load finishes, but with ‘select into’ they’ll fail because the object doesn’t even exist. 

So ok, I’ve shown you a few reasons why something as simple as moving schema can be a problem.  And like I said, it’s really one of my diatribes because of those issues mainly, and a couple out-lying ones.  And the guys at my shop have been hearing this battle cry for about 3yrs now and I’m sure they’re quite tired of it.  But when it comes right down to it, it’s good DB practice. 

There are some instances where the moving schema rule can be broken though.  Let’s look at a really large data load for instance.  If for some reason you can’t do any kind of incremental load and you have to do a full snapshot every night (those instances are becoming fewer and fewer with Katmai) on a HUGE table (several hundred million rows), then you may be better off doing a ‘select into’ because you don’t incur the logging and it can it can decrease your load time significantly.  It of course can also help control how big your log grows.  So this is a decision you have to make at the time, right? 

However, I will say that quite often, if you take the size of the log out of the picture, the ‘select into’ doesn’t out-perform the ‘insert into’ by all that much.  I recently tested the 2 methods against 30mill rows and the ‘insert into’ only took about 40secs longer.  That’s really not enough to worry about in the course of a full ETL load.  And for all the extra benefits you get from having a stable object, that 40secs is more than worth it.  So this would be a case where choosing the absolutely best performing process wouldn’t be the best way to go.  In the case above where I talked about loading several hundred million rows, the ‘insert into’ may increase the load time by as many as 30mins and that’s hard to ignore.  So depending on your requirements you may decide that dropping the object every day is worth it.  But in the instance where the difference is only a handful of minutes, you’d typically choose to keep your schema in tact and gain the other benefits.

So OK, you’ve got a process and you’ve decided to drop the schema every day to do your load.  And your process performs as well as it possibly could because of the lack of logging.  The problem is that people tend to think of performance in terms of the single piece they’re writing and nothing else.  Performance includes more than just the load.  Performance also includes up-time, and number of errors, and manageability, etc.  The load is just one part of the process for any given object.  Examples of different parts of an object’s process would be the load process, the reporting process, the troubleshooting process, the triage process, security process, the space management process, etc.  I’m sure there are others, but you guys get the point.  So all of these are all part of the process of managing this object and if they all don’t play well then the process for that object doesn’t work well.  So be careful in throwing all the other processes away and making them extremely more complicated just to appease a single piece.

So I’ve been in several shops and it’s always different everywhere.  Some shops are really big into management and others are really big into performance.  I’ve been in shops where the management of the objects was just a pain because the systems really were so busy that every last CPU cycle was counted and every last I/O had to be justified.  So they were willing to put up with the management headache of that kind of performance cost because they needed it to stay alive.  And again you have to decide what’s best for your place and your processes.  But whatever you decide, don’t rest on that decision.  Keep making it again and again.  I’ll talk about that tomorrow.

I guess that’s all I’ve got to say for now.

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

Diabetic Servers

One question I get a lot is about performance and how systems can run well for years and then suddenly just stop performing well.  That’s an understandable question and one that’s both easy and complicated to answer.

The short answer is that there’s a huge margin for error in these types of things.  However, the margin is only huge if you’re not doing anything about it.  Let me explain.

It’s like being on a diet.  When you’re watching what you eat every little bit matters.  That extra helping of fries, that bowl of ice cream, and that soda are all death to a strict diet.  Even little things can be harmful when you’re on a diet and the more strict the diet the more the little things matter.  That’s why professional athletes of all kinds watch their intake like hawks.  So in their case that extra ounce of potatoes, or that extra ounce of meat can really make a difference.  And that’s not even to mention diabetics and other people on strict medical diets.  Think about someone with severely high blood pressure.  Their diet is extremely important and the slightest wrong food can have serious blowback on their system.

Now look at someone who’s already grossly overweight.  This guy eats whatever he likes up to thousands of extra calories a day.  He eats only fried and fatty foods and eats as much of it as he likes.  So that extra helping of ice cream or that extra few fries really doesn’t matter much on top of everything else.  That’s not to say that it doesn’t have a cumulative effect, just that day to day it doesn’t matter much.  Eventually though, it will take its toll as he get heavier and heavier and starts to feel health effects from it.  So while those extra fries do eventually catch up with him, they don’t cause any real immediate effect on top of all the other stuff he’s eating.

Well, that’s much the way it is with servers too.  If you have a bunch of stuff that runs kinda poorly or just not as well as it could, it’s not really that important on a daily basis because the server itself runs slow and what’s one more mediocre process going to hurt?  So a server can run for quite a while like that and nobody will ever really notice the difference.  Part of the problem is that so few people bother to investigate better ways to do things so they get used to their DB performing slowly.  It’s not necessarily their fault and these things can sneak up on them.  Even a fairly good DBA can have wrong decisions go undiagnosed for a long time and the poor performance can sneak up on him and next thing he knows his system is just dragging.  And it’s hard to go back and find that one thing that started the whole thing.  I find typically that performance problems are systemic.  By that I mean that whatever mistake is made, is made throughout the whole system.  It’s quite often not an isolated incident unless someone new comes into a shop where things are already running smoothly.

So anyway, a server can put up with a good deal of abuse before it goes belly-up, but it will eventually happen.  What you want to try to get to is a point where you can treat your server like it’s got diabetes.  You want it on a very strict code diet where you watch every single I/O, every single MB going into RAM, every CPU cycle, etc.  On servers like this, one single process that doesn’t behave can have a noticeable effect on many other processes and you’ll know you did something wrong right away.  But if you’ve got a system that’s slow to begin with, who’s really going to notice if it’s running a little slower or if the CPU is hitting 81% instead of 76%?

This is why I’m not only stressing performance considerations on servers, but also why I’m always answering this question.

This of course has to play hand in hand with tomorrow’s post on reasonable performance.

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

Powershell Webcast by O’Reilly

Hey guys… I’m starting a webcast series next week on Beginning Powershell for SQL Server DBAs.

This is an excellent chance for those of you who have always wanted to get started with powershell to do so.

It’ll be a ground zero course so if you don’t know anything at all about powershell I’ll attempt to bring you up.

I hope to see you all there.

Here’s a link to the webcast and I hope all of you can join me.

Signup and tell all your friends.  If we get enough people signup we’ll be able to keep this series alive.

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

Get Away from the GUI

I had a comment on one of my last posts that suggested that I talk about a few things and this is the first thing that struck my interest because it’s a topic that’s close to my heart.  And of course, I’m talking about getting away from the GUI and learning to do things at the command line.

And I know that SQL Server was built around the cmdline and a lot of you cling to it for all of your daily tasks, but you’ve just got to get past it and start doing things in the GUI.  No wait, reverse that.

So why do I want you to get off the GUI?  Well for starters you never really know a system until you code in it.  You can go your entire life not knowing what goes on under the covers if you’re just clicking around and now you’re never learning anything.  So when problems come up you have no idea how to fix them because you’ve never bothered learning how anything works.

OK, I could sit here and write everything out in anecdotes but since time’s of the essence and my boys are going crazy this morning, I’ll just put it in a list with comments.

1.  GUI is limited – quite often the GUI won’t do everything you need it to do.  This comes up quite often working with security, but also things like CDC and data compression.  The GUI just doesn’t have all the features the cmdline does.  Backup/restore is another good example because you can’t do page-level restores in the GUI.

2.  GUI isn’t scalable – You can’t save GUI actions and reproduce them for several boxes.  If you code a solution you can code in parameters that allow you to run the same code against different objects.  I think user accts are a good example.  What if you have to add a user to all 200 DBs on your server, or on 10 servers?  What are you gonna do?  Click through those perms on all 2000 DBs?  It’ll take you days.  Meanwhile at the cmdline you can run it against all boxes at once and be done in just a couple mins.  Seriously, you can’t beat that.  So everything you do at the GUI you have to reproduce every time you need to perform that task.

3.  Gui provides no knowledge – Like I said already, if you always use the GUI then you never learn much because you don’t ever have any exposure to the inner workings.

4.  GUI is single-task based – Everything you do in the GUI is a single action.  You can’t do too multiple tasks as once and you can’t set them up in transactions so they all pass or fail together.  What if you needed to add a user to SQL and to Windows?  You can do it in powershell at the same time, but in the GUI you have to physically click through and do them yourself.  And what if you wanted to make it so that if one of them failed they both did?  You can’t do that in the GUI.

5.  GUI is typically longer – Even though the GUI is more friendly sometimes, it often takes longer to click through the screens than it does to type the cmds… at least for those of us who can type.

6.  GUI is slower – Many times the GUI has been slower to accomplish a task.  I’ve had the GUI take quite a bit of time or even freeze up on me while trying to do something when the cmdline finished in just a couple secs.  So the GUI isn’t nearly as efficient.

7.  GUIs don’t multitask well – While Yukon brought us the ability to have GUI tasks running in the background while we work in SSMS, you can still only do so many things that way.  You can multitask much better at the cmdline because you can offload it easier to other boxes or just schedule scripts to kick off.  Again, you can’t schedule a GUI operation.

Look… GUIs are fine when you’re a beginner.  They ease the burden of learning something new and when a new technology comes out I quite often start with the GUI just to get my feet wet.  But then I switch to the cmdline pretty quickly and do it in there the rest of the time. 

And there’s not much excuse for not learning the cmdline anymore since Yukon brought us the ability to generate the code for our actions and Katmai has improved on that.  Now if you do something in the GUI  you’re not sure how to do in the cmdline, you just script it from the GUI and learn something.  Now you can just modify it for your purposes.  I do that sometimes still.

I was really lucky when I started learning SQL in that the guy teaching me was a huge cmdline buff and insisted that I did everything that way.  Also, I emulated the MVPs who all touted the cmdline so I figured if it was good enough for them then I should be doing it too.  So in that respect I was lucky to learn that lesson early.

I hope some of you now learn that lesson here and start trying to do your jobs at the cmdline.  It’ll be tough at first, but in a yr you’ll be really glad you took the pains.

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

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

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

SQL Server Done Right

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.