InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 22 May 2013 15:13:40 GMT20http://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxIn 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.[b]Bad senior[/b]: 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.[b]Bad senior 2[/b]: 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.[b]Good senior[/b]: 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.DirdMon, 20 May 2013 02:55:23 GMTDirdhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]GilaMonster (5/29/2012)[/b][hr][quote][b]Jeff Moden (5/29/2012)[/b][hr]You do realize how wrong durations in SET STATISTICS can be, right?[/quote]The durations show by statistics time are 'correct'. They may not show what people think, but they are correct. ;-)[/quote]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.Fri, 10 May 2013 15:23:56 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxIt 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 [b][size="4"][url]Super DBA[/url][/size][/b]He uses SQL powers to save the day and make all the children happy:-D. I hope you enjoy. Thanks[url]http://www.youtube.com/watch?v=UZuZkhbNPjs[/url]Fri, 10 May 2013 14:47:21 GMTwaveryhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Jeff Moden (5/29/2012)[/b][hr]You do realize how wrong durations in SET STATISTICS can be, right?[/quote]The durations show by statistics time are 'correct'. They may not show what people think, but they are correct. ;-)Tue, 29 May 2012 10:08:33 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Oliiii (5/23/2012)[/b][hr][quote][b]Lynn Pettis (5/10/2012)[/b][hr][quote][b]Oliiii (10/15/2010)[/b][hr]Anyone tuning the query by not looking at IO and Time statistics and query plan would immediately fail.[/quote]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.[/quote]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.[/quote]You do realize how wrong durations in SET STATISTICS can be, right?Tue, 29 May 2012 10:04:49 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/25/2012)[/b][hr][quote][b]Oliiii (5/25/2012)[/b][hr]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.[/quote]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.[/quote]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.Tue, 29 May 2012 06:39:51 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]JamesMorrison (5/25/2012)[/b][hr]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.[/quote]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. :-DFri, 25 May 2012 23:07:49 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxChuck 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.Fri, 25 May 2012 22:57:21 GMTJamesMorrisonhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/25/2012)[/b][hr][quote][b]JamesMorrison (5/25/2012)[/b][hr]I always blame Chuck Norris when anything goes wrong. He is unstoppable.Chuck Norris was born on May 6th, 1945Nazi Germany surrendered on May 7th, 1945.[/quote]Nice joke, but, he was born March 10, 1940 .[/quote]That also means that he didn't start it. :-PFri, 25 May 2012 22:08:45 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]JamesMorrison (5/25/2012)[/b][hr]I always blame Chuck Norris when anything goes wrong. He is unstoppable.Chuck Norris was born on May 6th, 1945Nazi Germany surrendered on May 7th, 1945.[/quote]Nice joke, but, he was born March 10, 1940 .Fri, 25 May 2012 20:24:10 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxI always blame Chuck Norris when anything goes wrong. He is unstoppable.Chuck Norris was born on May 6th, 1945Nazi Germany surrendered on May 7th, 1945.Fri, 25 May 2012 18:01:44 GMTJamesMorrisonhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxHeh... I just call it a "post mortem review"... that way everyone is equally insulted. :-DFri, 25 May 2012 17:55:23 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]herladygeekedness (5/25/2012)[/b][hr]I'm with you. Blame is absolutely a negative word."Who is responsible" is nicer but still smacks of my mother being mad about something and demanding to know "who is responsible for this??"[/quote]I tend to agree here. The best way I've seen to handle this in the past is a review of "what went wrong" and "what could we have done to prevent this?" without any discussion of who missed something.Focus on the future, building better DR planning. If management doesn't every single out people and only events, it becomes easier to accept mistakes and improve for the future.Fri, 25 May 2012 09:46:24 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxI'm with you. Blame is absolutely a negative word."Who is responsible" is nicer but still smacks of my mother being mad about something and demanding to know "who is responsible for this??"If staffed with mature individuals that know their responsibilities and accept consequences of actions in areas for which they are responsible, there can be good change. But "blame" sounds a lot like sitting around pointing fingers and shaming people. not an environment I could stay in long (been in them, left them). On the job I have now, we all work closely together and each is responsible for certain aspects. If something goes wrong, we each look through our own areas to determine the Cause, vs blame.Happily, we each readily admit our errors when we find them because we know that others have work intertwined with our own and impacts are rarely isolated to "just my stuff" and we don't have time to do anything but fix the problem. we don't have time nor room for egos and accept that each of us is imperfect and will make mistakes.We do post-mortems later to see what we have learned by what went right, what went wrong, and what we had to abandon because we just couldn't make it happen correctly. It sounds like the Blame scenario doesn't get personal so maybe it's just how it was phrased. But based on some jobs I have had, the word Blame is absolutely negative to me.Fri, 25 May 2012 08:59:58 GMTherladygeekednesshttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote]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.[/quote]Very well said, Lynn.Fri, 25 May 2012 08:52:17 GMTtgarlandhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Oliiii (5/25/2012)[/b][hr]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.[/quote]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.Fri, 25 May 2012 08:41:58 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxThe kind of "blame"/"responsibility" being proposed here is the healthy kind. Find out who messed up and why, and educate them on the right way to do it. That's a good thing.Fri, 25 May 2012 06:33:16 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/25/2012)[/b][hr][quote][b]Oliiii (5/25/2012)[/b][hr]Everyone seem to understand the opposite of what i say, i guess i suck at English :-).We blame the application if it doesn't do it's task.We blame the user if he makes the application do thing it's not supposed to do (including overloading the application).We blame us if the server is not doing what it's supposed to do.We don't blame people that are not responsible for the issue at hand.We don't send them to the corner if they've been bad.We only shout at them if they are total *** and there is no other way to get the message across.[/quote]Here is the problem:[quote]We [b]blame[/b] the application if it doesn't do it's task.We [b]blame[/b] the user if he makes the application do thing it's not supposed to do (including overloading the application).We [b]blame[/b] us if the server is not doing what it's supposed to do.[/quote]You are playing a blame game. Let's blame the sys admin for a hard drive failure, or the network admin for a switch failing. Let's blame the users for overloading the system when the business has changed processes or workload has simply increased. Let's blame the developer because the system doesn't do what the user wants, but does what they requested.Things happen, and you can't always blame someone or something.You have a failure, you do a root cause analysis, not to assess blame, but to determine what happened, why it happened (not assigning blame), and what needs to be done to keep it from occuring again.[/quote]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.Fri, 25 May 2012 02:54:36 GMTOliiiihttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Oliiii (5/25/2012)[/b][hr]Everyone seem to understand the opposite of what i say, i guess i suck at English :-).We blame the application if it doesn't do it's task.We blame the user if he makes the application do thing it's not supposed to do (including overloading the application).We blame us if the server is not doing what it's supposed to do.We don't blame people that are not responsible for the issue at hand.We don't send them to the corner if they've been bad.We only shout at them if they are total *** and there is no other way to get the message across.[/quote]Here is the problem:[quote]We [b]blame[/b] the application if it doesn't do it's task.We [b]blame[/b] the user if he makes the application do thing it's not supposed to do (including overloading the application).We [b]blame[/b] us if the server is not doing what it's supposed to do.[/quote]You are playing a blame game. Let's blame the sys admin for a hard drive failure, or the network admin for a switch failing. Let's blame the users for overloading the system when the business has changed processes or workload has simply increased. Let's blame the developer because the system doesn't do what the user wants, but does what they requested.Things happen, and you can't always blame someone or something.You have a failure, you do a root cause analysis, not to assess blame, but to determine what happened, why it happened (not assigning blame), and what needs to be done to keep it from occuring again.Fri, 25 May 2012 00:46:43 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/24/2012)[/b][hr][quote]The mistake can come from poor development or wrong way to use the application.By experience the mistakes comes from the way the application has been developed, they simply didn't plan or didn't have the skill to make an application that can handle the kind of load it's been sold to do (it doesn't matter if the problem comes from the dev or the commercial selling the application).In some very rare case the business is pushing the application beyond the limit specified in the sla/contract.[/quote]This part scares me too. You pay for a 3rd party application to accomplish a task, and it accomplishes this task. Then you use it in a way that was not anticipated by the vendor and now you are telling the vendor they didn't know what they were doing? That is arrogance. Most times, what I have found is that the users push the system to the limits, and when it doesn't do exactly what they want, they find ways around the system. This usually works for a while but it usually catches up with them and the system starts to fail. Are you still going to blame the vendor and their developers for not anticipating what the users might do?[/quote]Everyone seem to understand the opposite of what i say, i guess i suck at English :-).We blame the application if it doesn't do it's task.We blame the user if he makes the application do thing it's not supposed to do (including overloading the application).We blame us if the server is not doing what it's supposed to do.We don't blame people that are not responsible for the issue at hand.We don't send them to the corner if they've been bad.We only shout at them if they are total *** and there is no other way to get the message across.Fri, 25 May 2012 00:20:33 GMTOliiiihttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]tgarland (5/24/2012)[/b][hr][quote]So assigning blame and making sure it's handled correctly is paramount in a big company.[/quote]This may be one of the scariest statements I have seen in a while. I would hate to work for a company that fosters this kind of attitude. I work for a big company and we focus on fixing the issue and if we can educate someone in the process then it was a success. I feel that companies that play the blame game promote a culture where individuals feel that they cannot make mistakes causing the individual to try and hide mistakes. By focusing on fixing the issue and education, we promote an open culture where people freely admit mistakes because they are not worried about getting blamed.[/quote]I said "pointing finger in a constructive way" for a very good reason. If it's constructive then they don't hide, they don't get shouted at but they do have to take responsibility for what happened and make sure it doesn't happen anymore.You said you try to educate someone when you can, here we do the same thing, but we just do it every single time to save time.We learned that just fixing things or "covering" for other is just a poisoned gift, it help them in the short time but does nothing for the long term.Thu, 24 May 2012 23:45:31 GMTOliiiihttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspxBWAAA-HAAAA!!!! I found a simple and easy way to handle all of this. I wake up in the morning hating everyone and make exceptions from there. :-P By the 3rd cup of coffee, the list has usually dwindled to only repeat offenders. :-DThu, 24 May 2012 15:52:30 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote]The mistake can come from poor development or wrong way to use the application.By experience the mistakes comes from the way the application has been developed, they simply didn't plan or didn't have the skill to make an application that can handle the kind of load it's been sold to do (it doesn't matter if the problem comes from the dev or the commercial selling the application).In some very rare case the business is pushing the application beyond the limit specified in the sla/contract.[/quote]This part scares me too. You pay for a 3rd party application to accomplish a task, and it accomplishes this task. Then you use it in a way that was not anticipated by the vendor and now you are telling the vendor they didn't know what they were doing? That is arrogance. Most times, what I have found is that the users push the system to the limits, and when it doesn't do exactly what they want, they find ways around the system. This usually works for a while but it usually catches up with them and the system starts to fail. Are you still going to blame the vendor and their developers for not anticipating what the users might do?Thu, 24 May 2012 14:02:50 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote]So assigning blame and making sure it's handled correctly is paramount in a big company.[/quote]This may be one of the scariest statements I have seen in a while. I would hate to work for a company that fosters this kind of attitude. I work for a big company and we focus on fixing the issue and if we can educate someone in the process then it was a success. I feel that companies that play the blame game promote a culture where individuals feel that they cannot make mistakes causing the individual to try and hide mistakes. By focusing on fixing the issue and education, we promote an open culture where people freely admit mistakes because they are not worried about getting blamed.Thu, 24 May 2012 12:47:02 GMTtgarlandhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/23/2012)[/b][hr][quote][b]michael vessey (5/23/2012)[/b][hr][quote]The person who wrote the original code or the tester that allowed it to make it into production? [/quote]ahem.... the tester didn't put the defect there (the developer did) :-P[/quote]The tester may not have put it there, but they let it get by. ;-)Plus, is it really a defect? Isn't it possible that it met the requirements at the time?[/quote]it wasn't just the tester that let it go by, it was the developer, the tester and the SME that did UAT.testers are like goal keepers, a defect has to get past midfield, the defence, the offside trap and cross the line inside the posts before it's an issue..... in this analagy the deveopers are the opposition strikers and the extremely wooly business requirements are the opposition midfield , making the pass to the forwards :-)Thu, 24 May 2012 02:36:29 GMTMVDBAhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]GSquared (5/23/2012)[/b][hr][quote][b]Oliiii (5/23/2012)[/b][hr]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.[/quote]To add to the discussion on this point:What do you do if the "dude" who made the original mistake is not available? Q. Why it was like that?A. Who knows?Q. Why the dude developing it made the mistake?A. Humanity is prone towards imperfection?Honestly, you often won't know why something was coded a particular way, and stats and query plans won't discover it for you. You may not get as flippant as I do about answering silly questions like that, but you're going to be confronted by questions you actually can't honestly answer on those points.What do you do if the code, as originally written, was error-free at that time and for forseeable events, but the query became slow because of unforseeable changes in data distributions? Is that an error? If so, the answer to the question about why the mistake was made in the first place has to be, "Nostradamus wasn't involved in the design/testing of the code."On the point about the QA personnel not being the ones who made the original mistake, all that says is you don't use test-driven development, or, if you do, you're doing it wrong.[/quote]Most of the DB here comes from application bought or licenced, we don't have that much internal development for SQL and they very rarely have issues that requires our input.We only work on issues that are threatening the servers stability/availability/performance or if someone specifically asks us to, so by definition when we are involved it is because a mistake has been made somewhere.The mistake can come from poor development or wrong way to use the application.By experience the mistakes comes from the way the application has been developed, they simply didn't plan or didn't have the skill to make an application that can handle the kind of load it's been sold to do (it doesn't matter if the problem comes from the dev or the commercial selling the application).In some very rare case the business is pushing the application beyond the limit specified in the sla/contract.I don't know anything about the way you need to work, but here if you fix an issue and simply say "it's fixed" is not good enough. The question that will come back 2 secs later is "what happened?".And by that they mean what happened exactly, how did you fix it and what has to be done so we never have the problem anymore.It's pretty easy to explain what you did to fix it or what need to be done to fix it, it's usually not hard at all to find out why it happened and it requires some experience to explain what need to be done to avoid the issue in the future.Most of the time fixing the issue or avoiding it in the future requires the involvement of the company developing it and that's when you need rock solid proofs (yes, you always have to prove it's their fault).There is no better proof than statistics before/after, sometime with query plan and observations with a couple of server performance stats/history.With these proofs we can show the business the issue is not with the server or the way we manage it but with way the application is used or has been designed.Once the business understand that, they can contact the application provider and see either if it can be fixed or if they have to either accept the issue and keep working, pressure the provider more, send their army of lawyer or simply start planing a migration to another application if there is one.If the issue came from one of our mistake then we explain what happened, what we did to fix it and what we've put in place to avoid it in the future.To answer the questions: What happen if the dude who made the mistake is not available?That's actually way easier than you think, the business nearly always have the answer, if they have not then we make an educated guess.While i agree the human is prone to imperfection that's not an excuse for not fixing mistakes and that's exactly why you need to have all the infos on the issue.While we are at it i totally disagree with the fact that time spent assigning blame would be better used fixing the issue.First thing is you can do both at the same time so time is not really lost and i would go as far as saying pointing fingers in a constructive way is more important than the fix itself.Any DBA can fix an issue or resolve an incident, but the only way permanently fix an issue is to know where it comes from and why it happened and that's not something any DBA can do.So assigning blame and making sure it's handled correctly is paramount in a big company.Thu, 24 May 2012 01:26:56 GMTOliiiihttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Elliott Whitlow (5/23/2012)[/b][hr]Seriously, the problem in my mind seems to be trying to place blame and that is not something that I really care about.[/quote]+100Time spend trying to assign blame will be far better spent fixing the problem and learning from it to ensure it doesn't happen again.Wed, 23 May 2012 11:48:48 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/23/2012)[/b][hr][quote][b]michael vessey (5/23/2012)[/b][hr][quote]The person who wrote the original code or the tester that allowed it to make it into production? [/quote]ahem.... the tester didn't put the defect there (the developer did) :-P[/quote]The tester may not have put it there, but they let it get by. ;-)Plus, is it really a defect? Isn't it possible that it met the requirements at the time?[/quote]Random feature?Seriously, the problem in my mind seems to be trying to place blame and that is not something that I really care about. If we need better test cases say that, if the requirements were weak say that. As Lynn said, code I wrote years ago is not up to MY standards today, but does that make it wrong? If it all of a sudden breaks was it wrong or did something else change?I take the hard line that if you are more worried about who screwed up and not more worried about getting it fixed you have your priorities wrong. I worked for a fella years ago that was always concerned about who was to blame and it really irked me because I didn't care. If there was clear blame I would often just talk to the "offender" privately about it so they knew and we could work for better outcomes. Because in the end thats all I really wanted anyway..CEWIIWed, 23 May 2012 11:37:54 GMTElliott Whitlowhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Oliiii (5/23/2012)[/b][hr]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.[/quote]To add to the discussion on this point:What do you do if the "dude" who made the original mistake is not available? Q. Why it was like that?A. Who knows?Q. Why the dude developing it made the mistake?A. Humanity is prone towards imperfection?Honestly, you often won't know why something was coded a particular way, and stats and query plans won't discover it for you. You may not get as flippant as I do about answering silly questions like that, but you're going to be confronted by questions you actually can't honestly answer on those points.What do you do if the code, as originally written, was error-free at that time and for forseeable events, but the query became slow because of unforseeable changes in data distributions? Is that an error? If so, the answer to the question about why the mistake was made in the first place has to be, "Nostradamus wasn't involved in the design/testing of the code."On the point about the QA personnel not being the ones who made the original mistake, all that says is you don't use test-driven development, or, if you do, you're doing it wrong.Wed, 23 May 2012 11:34:26 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]michael vessey (5/23/2012)[/b][hr][quote]The person who wrote the original code or the tester that allowed it to make it into production? [/quote]ahem.... the tester didn't put the defect there (the developer did) :-P[/quote]The tester may not have put it there, but they let it get by. ;-)Plus, is it really a defect? Isn't it possible that it met the requirements at the time?Wed, 23 May 2012 10:08:13 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]michael vessey (5/23/2012)[/b][hr][quote]The person who wrote the original code or the tester that allowed it to make it into production? [/quote]ahem.... the tester didn't put the defect there (the developer did) :-P[/quote]Bad assumption: maybe the analyst who wrote the requirement spec made the mistake, so that neither development (who wrote code that met the stated requirement and unit tested it thoroughly) nor QA (who did system tests that demonstrated that the code did indeed meet the stated requirement and behave ensibly in edge/stree conditions of the data, and performed even better than the stated performance requirement) made any mistake (except perhaps trusting management not to saddle them with responsability for someone else's mistakes).Wed, 23 May 2012 10:07:25 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/23/2012)[/b][hr][quote][b]Elliott Whitlow (5/23/2012)[/b][hr][quote][b]Oliiii (5/23/2012)[/b][hr]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.[/quote]I have to question this methodology. Or at least this part "made the mistake". This assumes that a mistake was made instead of a change in process that perhaps queried on a column that would not typcially be indexed. Is that a mistake?This requirement seems overly complex, YOU need to understand why it is acting the way it is acting otherwise you probably can't enhance performance.Perhaps I am over thinking this, but this doesn't "feel" right to me and I can't quite quantify why..CEWII[/quote]My problem with the "made the mistake" really comes down to this, who made the mistake. The person who wrote the original code or the tester that allowed it to make it into production? Or perhaps the people that reviewed the code?Maybe it wasn't a mistake but the best effort of the individual developing the code based on their knowledge (SQL< application, data) at the time it was written. Sorry, I just think that the wording is wrong. I'm not going to critisize the work of others because I know that work I did years ago could now be done better. I will look at code and tell you if it can be improved, but I won't say that the original developer made a mistake.[/quote]Or maybe it wasn't a mistake but was the best query for the requirement as it was at the time the query was written. So the guy who wrote it did what was best for teh company and got it absolutely right. Then, to Oliii's way of thinking, when later on the requirement changed so that that query was no longer optimal the guy who wrote it ceased to have got it right and started to have made a mistake. Anyone who assumes that whenever something nneds fixing that means that a deveoper made a mistake gets a big down-tick from me.Wed, 23 May 2012 10:03:36 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote]The person who wrote the original code or the tester that allowed it to make it into production? [/quote]ahem.... the tester didn't put the defect there (the developer did) :-PWed, 23 May 2012 09:59:38 GMTMVDBAhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Elliott Whitlow (5/23/2012)[/b][hr][quote][b]Oliiii (5/23/2012)[/b][hr]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.[/quote]I have to question this methodology. Or at least this part "made the mistake". This assumes that a mistake was made instead of a change in process that perhaps queried on a column that would not typcially be indexed. Is that a mistake?This requirement seems overly complex, YOU need to understand why it is acting the way it is acting otherwise you probably can't enhance performance.Perhaps I am over thinking this, but this doesn't "feel" right to me and I can't quite quantify why..CEWII[/quote]My problem with the "made the mistake" really comes down to this, who made the mistake. The person who wrote the original code or the tester that allowed it to make it into production? Or perhaps the people that reviewed the code?Maybe it wasn't a mistake but the best effort of the individual developing the code based on their knowledge (SQL< application, data) at the time it was written. Sorry, I just think that the wording is wrong. I'm not going to critisize the work of others because I know that work I did years ago could now be done better. I will look at code and tell you if it can be improved, but I won't say that the original developer made a mistake.Wed, 23 May 2012 09:52:22 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Oliiii (5/23/2012)[/b][hr]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.[/quote]I have to question this methodology. Or at least this part "made the mistake". This assumes that a mistake was made instead of a change in process that perhaps queried on a column that would not typcially be indexed. Is that a mistake?This requirement seems overly complex, YOU need to understand why it is acting the way it is acting otherwise you probably can't enhance performance.Perhaps I am over thinking this, but this doesn't "feel" right to me and I can't quite quantify why..CEWIIWed, 23 May 2012 09:27:17 GMTElliott Whitlowhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Oliiii (5/23/2012)[/b][hr][quote][b]Lynn Pettis (5/10/2012)[/b][hr][quote][b]Oliiii (10/15/2010)[/b][hr]Anyone tuning the query by not looking at IO and Time statistics and query plan would immediately fail.[/quote]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.[/quote]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.[/quote]I would say that some leading questions that point at stats for time and io are a valid part of a DBA interview. If the job will include any sort of tuning/optimization/code-review duties, of course. Those stats are important tools and I've been using them religiously in my query tuning ever since I found out about them.Wed, 23 May 2012 06:25:45 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Lynn Pettis (5/10/2012)[/b][hr][quote][b]Oliiii (10/15/2010)[/b][hr]Anyone tuning the query by not looking at IO and Time statistics and query plan would immediately fail.[/quote]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.[/quote]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.Wed, 23 May 2012 06:19:51 GMTOliiiihttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Jeff Moden (5/17/2012)[/b][hr][quote][b]Elliott Whitlow (5/15/2012)[/b][hr]Jeff, You gotta give 'em cred for calling back that takes some stones.CEWII[/quote]Heh... gotta give me some credit, as well. It took some stones of my own to tell them "no" a second time while being out of a job. :-P[/quote]I'll give you that..CEWIIThu, 17 May 2012 11:48:49 GMTElliott Whitlowhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]GSquared (5/17/2012)[/b][hr][quote][b]Michael Valentine Jones (5/15/2012)[/b][hr]I had an interesting experience recently where I was being interviewed by someone without the technical experience to be able to evaluate my skills at a company where I would be the first database guy.The question that the interviewer asked me was "What questions would you ask someone like yourself to determine if they had the technical skills for this job?" I was caught a bit by surprise by this, but I realized that it was actually a very good question. I gave some questions that I would ask in an interview and explained what I would want to hear as an answer. It was a bit different, kind of like I was interviewing myself.I think the question was good, because it enabled me to both answer technical questions and to demonstrate that I had the communication skills to be able to explain the subject to someone who was not deeply technical in the subject.[/quote]Good interview technique for a skillset you can't screen yourself. Shows an ability to think outside the box.[/quote]It's an excellent technique for a skillset you can screen yourself too; you can follow up by asking one or two of the questions suggested, or change it slightly to be "what questions would you ask and what answers would you expect a good candidate to provide?"Thu, 17 May 2012 06:43:31 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1005193-334-1.aspx[quote][b]Elliott Whitlow (5/15/2012)[/b][hr]Jeff, You gotta give 'em cred for calling back that takes some stones.CEWII[/quote]Heh... gotta give me some credit, as well. It took some stones of my own to tell them "no" a second time while being out of a job. :-PThu, 17 May 2012 06:43:14 GMTJeff Moden