May 25, 2012 at 11:07 pm
JamesMorrison (5/25/2012)
Chuck Norris can gargle peanut butter.Chuck Norris can slam a revolving door.
Chuck Norris can design databases so amazing that they don't even need indexes.
He learned those first two things because of me...
His code didn't pass a peer review because, in order to get around having to know much about indexes, he put all of the data in a "One true lookup table" as an EAV. It made him so angry that when he stormed out of the building, he left so fast that it looked like he slammed the revolving door. He was so disgusted with the code review that it left a really bad taste in his mouth. When he got to his car, the only thing he could find to remove that taste was a jar of peanut butter that his wife asked him to pick up. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2012 at 6:39 am
Lynn Pettis (5/25/2012)
Oliiii (5/25/2012)
Ah, here is why you don't seem to get what i say 🙂I'm not talking about any failure or incident. I'm only talking about mistake.
When things go right (failure is handled correctly and so on...) it doesn't reach us, when something reach us that mean something went wrong and it wasn't handled correctly (in other word, someone made a mistake).
So we don't really care if a disk crashes, that happen all the time, we care if it crashes and it was not protected by a raid when it should have been (specifically requested or by default), and in this case that is a mistake by the storage team so they are the one to be blamed for the issue.
The result of that blame might not be some guy being shouted at by his manager, it might simply end up by the team being reinforced by 2 more peoples because their management found out they made the mistake because they were simply overworked.
With the amount of applications we have for SQL Server alone, even if an application has an avg of 1 big issue every 10 years (that's being massively optimistic), that's still over 2 per day for us. So i might seem a bit hard on some issue or ways to work, but once you start managing a lot of servers and DB there are things you can't do anymore and everyone needs to do their work correctly.
By applying that way of working to our team first we managed to get from hundreds of incidents a week to only 1 or 2 and we expect to reach 1 or 2 a month by the end of the year.
By starting to assign blame to the right team we went from having a bunch of monkey in the staging dept to a system that can stage physical and VM in minutes.
That may not seem like something incredible for some but heck, a year ago they gave us a few clusters with one windows 2008 node and one Windows 2003, a few month ago we were happy if we had to spend less than a day fixing configuration issues on brand new clusters, so by keeping pointing fingers in the same direction for valid reasons they finally got the budget, formations and manpower required to deliver a good quality service...
We explain to people as nicely as possible as often as we can, but that doesn't work for everyone or is not always possible. Assigning blame to some team can be done by just letting them know something should have been done differently and letting the business know exactly what happened without trying to cover things up.
We are seeing very good and very real improvement only because we started to blame the right people.
Each blame we made always ended up with an overall improvement. We may have bruised a few ego but things always ends up better for everyone.
I get what you are saying, I just disagree with how you are saying it. I personally have a problem with finding who is "to blame" for a problem/mistake/error. There is too much negative connotation with the phrase "to blame" because it is used more often than not when trying to deflect responsibility.
I don't care how nicely you may put it, but once you use the phrase "you are to blame" with me, I am already on the defensive, even when I know I may have made the mistake or error.
I am all for identifying the who, what, why, where, how of a problem, error or mistake, and for identifying policies or procedures that will prevent or mitigate such problems, errors or mistakes from happening again. It is necessary for improvement of individuals, groups, and organizations.
My suggestion, move away from using the phrase "to blame." In my opinion there is just too much of a negative connotation to this phrase.
To misquote The Bard, "A cesspool by any other name..."
Not calling it "blame" is just too PC for me. Yeah, the word has negative connotations, because of connections to punishment. But unless you have a real semantic difference, calling it something else is just coddling, and is, to me, insulting.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 29, 2012 at 10:04 am
Oliiii (5/23/2012)
Lynn Pettis (5/10/2012)
Oliiii (10/15/2010)
Anyone tuning the query by not looking at IO and Time statistics and query plan would immediately fail.Guess I'd fail here. First things I look at are the code, the indexes, and the data. Amazing what you can learn from just looking at those before you even look at IO and Time statistics or the query plan.
I'm not giving a super easy query where you can spot right on what's wrong and I'm giving some big hint that i would like to know by how much the query has been improved (without specifically asking for the statistics).
If the guy can tell right away what's missing that's all good, but I'll still ask him what he would do to give me the situation before and after or I'll ask him to optimize another query a bit harder.
Where i work, when you fix something you have to usually show why it was like that, what you did to fix it and why the dude developing it (or the company that sold it) made the mistake, and to do that there is nothing more efficient than having statistics time & io and sometime the query plan.
If the guy I'm interviewing has not clue what is the query plan, the statistics io, time or how to use it's info quickly and efficiently, i don't really have any use for him here (that doesn't mean he's bad, just that he doesn't fit).
I guess some people here see that i would make them fail just because they can't answer a question the way i want and freak out but that's not at all how it work 🙂
When I'm doing this I'm sitting right next to the guy in front of the computer, it's all part of a conversation where i ask a bunch of small question and steer the interview the way i want it to go if the guy seems a bit lost.
The interview looks more like a regular day of work summarized in a few minutes, that way the guy can see how we work, what kind of skill he's expected to have and i can see how he react and how he would fit.
I found out doing interview this way was much better than a regular conversation since I've met some folks that could BS their way into any job, and only found out about it after asking some simple technical questions and looking how they would resolve it.
You do realize how wrong durations in SET STATISTICS can be, right?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2012 at 10:08 am
Jeff Moden (5/29/2012)
You do realize how wrong durations in SET STATISTICS can be, right?
The durations show by statistics time are 'correct'. They may not show what people think, but they are correct. 😉
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 10, 2013 at 2:47 pm
It is always important to learn as much as possible. If you feel very comfortable/senior in your current position, then you may have stopped growing/developing and need to push yourself harder. No matter how senior you are there is still so much to learn.
I would like to share a humorous YouTube rap video describing Super DBA
He uses SQL powers to save the day and make all the children happy:-D. I hope you enjoy. Thanks
May 10, 2013 at 3:23 pm
GilaMonster (5/29/2012)
Jeff Moden (5/29/2012)
You do realize how wrong durations in SET STATISTICS can be, right?The durations show by statistics time are 'correct'. They may not show what people think, but they are correct. 😉
Wow. Sorry I missed a response by a year. You've stated it more correctly than I. I should have said that having SET STATISTICS ON can seriously change what those durations are especially if scalar UDFs appear in the code.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2013 at 2:55 am
In regards to the OP: labels are OK but aren't always the most accurate. I hate when companies specify a minimum number of years doing the role though. We have around 400 oracle databases and 800-900 sql server databases (although these arent being monitored or anything). With so many databases you have the chance (at least with Oracle) to get experience much quicker than a team with < 10 databases so that 2 years those 2 possibilties are not really comparable. The team with a lower number might be more IT well-rounded (if their role requires them to mess around with storage etc) but with less DB related issues during the same timeframe.
I class a good senior of being knowledgeable & still having enthusiasm to improve. I've only been studying SQL Server for 2 months now & I feel I've surpassed 1, if not both of the "SQL Server guys" at our work. One of them also does Oracle & it's clear that's where his passion lies so the SQL has been neglected (as evidenced by the fact that during DR last week he said that we didnt have to recover MSDB because it was just a template for future databases :-D; I corrected him). He's awesome at oracle though (although he gets caught blagging a little too much for my liking) & pushing for promotion to senior if he tweaks his attitude a little.
Bad senior: The other guy is solely MSSQL though & has definitely rested on his laurels. Was taking like 3 weeks out of 4 on call (maybe 1 call out per month) and playing with his phone all day at work. Didn't know about CPU affinity when someone suggested it to him. This is not a good senior.
Bad senior 2: On the oracle side there's a guy who's been doing DBAing for 20 years! He's been a contractor; he was a pretty high flier in the 90s (friends in the oaktable for you oracle people) but after a 2 year breakdown his knowledge has massively depleted (I didn't know him before; just assume it was better) & he has no real interest of improving. He's labelled a senior but one of the juniors is better than him & I could probably give him a run for his money in oracle.
Good senior: On the other hand we have a newish colleague for Oracle who is OCP (equivalent of MCSE); very knowledgeable on oracle related facts (the previous guy always goes to him with questions) and still eager to learn. At home he's using VMware to experiment with clusters & other tech and hes aiming to get his OCM (MCM equivalent) this year maybe.
Try to find one like the third one; if they don't have great knowledge in performance tuning or clustering (not just general concepts; anyone can know that) then keep looking. As a senior I'd expect you to be pretty boss on one of the two & able to hold your own on the other. But if your preference is perf tuning then focus on that.
Dird
September 23, 2013 at 7:15 pm
I have been a DBA for over 14 years and as a DBA that worked on Tons of projects, interview tons of DBA's and train developers that want to be a DBA. I have interview with some young geeks that just became a DBA a year or so ago and if you don't answer the question like they expect you to they thing something is wrong. When I interview a DBA I'm interest in their problem solving skills and how they go about trouble shooting an issue then how quick they can do a join.
Microsoft Quote un quote supposed to have senior DBA's on staff to help you resolve issue I can tell you without a shadow of a doubt I may talk with 1 our of 20 that is qualify for that position. I need for you beginner DBA's that think you know what you are doing please understand it's more then two or three ways to resolve an issue.
It took over 300 men to develop SQL SERVER in my 28 YEARS in IT If someone told me he was an expert I wouldn't hire him.
Derrick McNeill
Viewing 8 posts - 181 through 187 (of 187 total)
You must be logged in to reply to this topic. Login to reply