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