InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 18 Jun 2013 17:32:57 GMT20http://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxThat was back in the wild west days of EMS still, wasn't it? :)I like trying to find lessons that are transferable from career to career or life lesson to career, vice-versa. I'm lazy ;-)Sat, 11 Apr 2009 06:59:38 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxGreat Article!My first career was an EMT working on an ambulance (back in 1980), and never thought about how it applies to what I do now... gave me an interesting perspective...MarkMon, 06 Apr 2009 06:33:40 GMTSuperDBA-207096http://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxThank you for the article! I have always been quietly grateful that in my IT line of work I didn't have to be responsible for human lives (not directly anyway). The analogy used here cleverly illustrates the parallels and how we can approach our IT jobs with the same calm and structure as do people in much more critical situations. I think the benefits of planning and keeping cool head are the most important ones.Sun, 05 Apr 2009 12:31:10 GMTmishalubahttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]mike_walsh (4/3/2009)[/b][hr][quote][b]esteban alvino quispe (4/3/2009)[/b][hr]HelloIm from peruvian, and i found interesting the article, but there are some terms that is difficult to understand, like "ShotGun", more or less what it is means.Good Post.Thank You[/quote]Thanks Esteban,I apologize for not being more international friendly in my post. To simplify: a Shotgun is the kind of gun (firearm) that shoots (fires) a series of small pellets or large slugs. It's used in bird hunting with the smaller pellets and multiple pellets loaded at one time. This way when it is fired, there is a better chance of hitting the target. I used the term to say throwing a lot of things at the problem and hoping one of them hits it :)[url=http://en.wikipedia.org/wiki/Shotgun]http://en.wikipedia.org/wiki/Shotgun[/url][/quote]Or this link:[url=http://es.wikipedia.org/wiki/Escopeta]http://es.wikipedia.org/wiki/Escopeta[/url]Fri, 03 Apr 2009 13:41:02 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]esteban alvino quispe (4/3/2009)[/b][hr]HelloIm from peruvian, and i found interesting the article, but there are some terms that is difficult to understand, like "ShotGun", more or less what it is means.Good Post.Thank You[/quote]Thanks Esteban,I apologize for not being more international friendly in my post. To simplify: a Shotgun is the kind of gun (firearm) that shoots (fires) a series of small pellets or large slugs. It's used in bird hunting with the smaller pellets and multiple pellets loaded at one time. This way when it is fired, there is a better chance of hitting the target. I used the term to say throwing a lot of things at the problem and hoping one of them hits it :)[url=http://en.wikipedia.org/wiki/Shotgun]http://en.wikipedia.org/wiki/Shotgun[/url]Fri, 03 Apr 2009 13:36:14 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxHelloIm from peruvian, and i found interesting the article, but there are some terms that is difficult to understand, like "ShotGun", more or less what it is means.Good Post.Thank YouFri, 03 Apr 2009 12:41:16 GMTesteban alvino quispehttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxMike, this was a good article, quite well written and thought out. It's good to think of things differently in this manner, which helps to deliver the sense of urgency as well as empathy for users (patients/family members).Thu, 02 Apr 2009 22:40:05 GMTTim Mitchellhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxThis is a clever article and discussion and fun to participate and read. The analogy and abstraction hits some marks and stimulates thinking. I'm want to say that nothing is final and absolute and that people change, laws change, priorities change but we still need rules and laws and sometimes they fit and sometimes they don't. But some things are universal and never change. And some of those are in this article.Thu, 02 Apr 2009 16:16:12 GMTKen Shapleyhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]DavidMcAfee (4/2/2009)[/b][hr]haha. I wonder how many people got the "Johnny and Roy" reference. :) I loved Emergency.[/quote]:-D First to catch it and comment on it anyway. Desoto and Gage. Never really watched it a whole lot except some reruns (showing my young age ;-) ) but they are still referred to at least once per training class you seem to take (not sure if that's good or bad).Thu, 02 Apr 2009 15:02:01 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxhaha. I wonder how many people got the "Johnny and Roy" reference. :) I loved Emergency.Thu, 02 Apr 2009 14:46:19 GMTDavidMcAfeehttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]ALZDBA (4/2/2009)[/b][hr]and off course there is a difference in Red Cross junior camp first aid, Paramedic first aid and combat first aid :-DAccording to their trained skills, you may have a better chance of:- surviving their actions- surviving the incident- quality of life afterward.[i]In some cases, it is better to call for a paramedic.[/i][/quote]You got that right :) Know when to ask for help and know your own limitations. No matter the situation. You could be on a fire scene and a captain or chief says "Get that ladder up there!" and you've never operated that departments ladder truck... Much better to ask for help than be embarassed and try and figure it out on the fly. You could be trying to figure out a hardware problem and see that something in the SAN "feels wrong" but you aren't trained there, only know casual information about the SAN, etc. Rather than just try and change it blindly, escalate... Get help.Thu, 02 Apr 2009 13:57:42 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]mike_walsh (4/2/2009)[/b] I agree doesn't translate to a fire scene but so far it has worked for me in SQL and the Ambulance.[/quote]I thought about this at lunch and I actually think that while the analogy may not fit a lot of the steps still fit into a "rely on training" type of situation. You may not have time to go to checklists like I blogged about [url=http://www.straightpathsql.com/blog/2009/3/16/checklists-recipes-and-algorithms.html]here comparing doctors,chefs,pilots and DBAs[/url]. You may also end up skipping some steps but the same general pattern works in those look and act type scenarios. I also hope that whoever has incident command is thinking through them, the IC at a fire is supposed to work with the other members of command (Safety, Operations, Medical, etc) and make informed decisions. Even the operations leads in the fire should practice some of the below. For a sturcture fire:1. Gather initial information - What type of structure? What other hazards are around? Live high voltage lines lying in a puddle? People inside or just a structure? Propane tank? Any law enforcement concerns? Traffic safety hazards? Water supply?2. Prepare your mind - En route to the call, what is your job? You are going back to your training but what role are you in, think through it, know it and prepare to do it. 3. Work as a team - So very important in a fire. You don't have to think about this, training has hopefully beaten it into you but you go in as a team and, Lord willing, come out as a team.4. Plan your attack - Victims trapped? You will be more aggressive (but still not stupid). Just property? Is the fire contained enough to send a crew in? Where will you approach from? Where will you put emergency ladders for dumping out of the house in a pinch? How is the structural integrity?5. Don’t be afraid of asking for help - Confirm a command if you aren't sure, bring in mutual aid early, etc.6. Formulate a problem statement and verify it with all parties! - This one is sort of easy.. There's some red stuff that needs wet stuff ;) This is sort of an assumed portion here and probably superflous.a. We also looked at the entire picture and didn’t develop tunnel vision. - Were you so focused on the flames or screams that you missed you were about to kill yourself with that pole to house electrical line flapping in the breeze?7. Remain Calm - Big Plus on the fire scene. Adrenaline is flowing in huge buckets already. Having a chief panic (and I have seen it) and get angry/flustered does no good. The crews will do stupid things and someone risks getting hurt (or worse). Stay in control.8. Understand priority and if the issue is stable or declining - Speaks for itself in a fire, right? At what point do you go from offensive to defensive attack? Do you even skip offensive attack (in spite of reported entrapment) because it is far too dangerous?9. Anticipate changes and plan ahead for worsening – RIT teams (Rapid Intervention Teams) are becoming more and more standard at fire scenes. It's a team all geared up, ready to go in and rescue downed firefighter(s). That is what they train for and they are outside waiting for that purpose. You have ambulances there even if no victims in case a firefighter gets hurt. You continue to monitor the house and surroundings looking for new hazards.10. Use all of the information – You are using everything from the above steps in making your plans.11. Documentation – Even here, insurance companies, training "opportunities", etc.12. Clean up and preparation for next call – You hope there a lot of probationary firefighters around to roll hose. The last thing a bunch of exhausted firefighters want to do is clean up after themselves ;-)I agree, a lot of these steps are look and act type steps but even here you are not just looking only. Yes you are relying on training a LOT more but even still if you train for firecalls with a consistent methodology (which is what Incident Management Systems is for command/control aspects) it really does become just "another problem" to troubleshoot. Decisions come a lot faster and less alternative options are gone through or gone through a lot faster but I think the methodology does work.Thu, 02 Apr 2009 13:53:36 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxand off course there is a difference in Red Cross junior camp first aid, Paramedic first aid and combat first aid :-DAccording to their trained skills, you may have a better chance of:- surviving their actions- surviving the incident- quality of life afterward.[i]In some cases, it is better to call for a paramedic.[/i]Thu, 02 Apr 2009 13:42:39 GMTALZDBAhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxHi MikeNo need to appologize did nothing wrong, I just find that sometimes people look at SQL Server as the little brother and I get very frustrated because of this(not saying you did or the other guy ). It's alsways DB2 this and Oracle that and sometimes I get a bit emotional around those comments and statements.... Microsoft has made excessive footprints in the OLTP\OLAP market ....and according to the latest TCP benchmarks ...SQL is a fantastic product and in some benchmarks even outclass the other one's but DB2 and Oracle are fantastic products as well......so I will calm myself down now :blush:The 10 min an 1 hour comment:I am refering to save time when there is an outage. Good methodology and skillsets can always save time on fixing the problem. And you could use a methodology to also indicate skill shortages(although this is up to the individual sometimes if he\she wants to advance in their career).One of the gents also made a comment about documentation when problems are experienced...so true ...we all feel the pain and sometimes we are also guilty of it ourselfves..It is also dicipline that needs to be applied for documentation and there is no excuse for this .......Once again well written article.Thu, 02 Apr 2009 10:55:48 GMTCoetzeeWhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]aureolin (4/2/2009)[/b][hr]In an emergency you must remember to panic!! Well, not really, but people who *are* panicking often get really angry at your failure to panic along with them. They see your calmness not as competence in the face of an emergency, but as a "failure" on your part to "understand the seriousness" of the situation. If you're not careful (and sometimes even if you are), you can suddenly find yourself defending your actions and your attitude from a frustrated and angry person instead of solving the problem. In my experience, the best bet is to remove the panicky people from the area where you are trying to problem-solve. This can help break the escalation of their panic (and give them a chance to calm down) and remove a fairly serious distraction while you're in an emergency situation.[/quote]I disagree. In almost every case I've been in, as long as people saw that I understood the urgency, they became calmer. I tend to do something to the effect of:- Say, "All right, let's stay calm or become calm because emotion is going to cloud our thinking and we need to solve this as fast as possible. That means we've got to be able to think as clearly as possible."- Then say, "Okay, very quickly, what do we know?"- Then say, "Okay, shortly and succinctly, what have tried and what were the results?"I use words like "very quickly" and "shortly and succinctly" to communicate that I understand the urgency and gravity of the situation but that we're in control of the situation. And if I know that they are the types who need/demand status reports, I then set a schedule. Usually on the hour, of if necessary, every 15 minutes. I make sure that I tell them if we find something significant, they'll get a status report sooner. That seems to stop the pacing outside the cube. Thu, 02 Apr 2009 10:53:23 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]aureolin (4/2/2009)[/b][hr]In an emergency you must remember to panic!! Well, not really, but people who *are* panicking often get really angry at your failure to panic along with them. They see your calmness not as competence in the face of an emergency, but as a "failure" on your part to "understand the seriousness" of the situation. If you're not careful (and sometimes even if you are), you can suddenly find yourself defending your actions and your attitude from a frustrated and angry person instead of solving the problem. In my experience, the best bet is to remove the panicky people from the area where you are trying to problem-solve. This can help break the escalation of their panic (and give them a chance to calm down) and remove a fairly serious distraction while you're in an emergency situation.[/quote]It's sad to say but I know what you mean and have seen that. I have asked management to give me some time and space before. It wasn't rude but I said, "it will be easier for me to get you an update and fix things if I can focus on it". If they are good they'll understand and give you the space. A coworker once tried it in a ruder way... He was being asked every 5-10 minutes for an update and he replied, "if I didn't have to stop thinking to give you an updates every 5 minutes, I could have this solved a lot quicker!". It was effective but not an approach I suggest.[quote][b]mike brockington (4/2/2009)[/b][hr]In that case, I suppose I must retract my earlier criticism of your analogy - I still think that the comparison wasn't very close, but the point of an analogy is to stimulate thought, and in that respect it has worked well![/quote]Fair enough :-) In my experience in both troubleshooting technology issues and people issues it works. I agree doesn't translate to a fire scene but so far it has worked for me in SQL and the Ambulance.Thu, 02 Apr 2009 10:25:57 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]CoetzeeW (4/2/2009)[/b][hr]If any one that think's SQL is less complex then Oracle or DB2 then I would assume you have excessive knowledge in these products to make such a decision. Then if one says that SQL server is not complex then take a minute and dwelve into the SQL server architecture..let's say memory Architecture ..you will be suprised that there are many complex components involved in the SQL server memory arhictecture and then on top of that try mapping those components back to Windows memory architecture ...wow seems simple enought...:hehe:But let's not focus on comments about complexity and focus on the article that was written and the way of thinking that must sometimes change to fix a problem in 10min or spend 1 hour....[/quote]I apologize for my reply about the complexity comments. I didn't convey what I was thinking properly. I completely agree SQL Server is complex inside. It has a simpler user interface (from my experience with the other platforms) but it by no means is a simple product :) Teams of great developers have spent countless hours developing the various versions and it's architecture is complex. Thanks for the reply about that, you said it much better than I did :)As for the second part of your comment, are you saying a methodology would reduce time to 10 minutes or drag it out to 1 hour? I am hoping that it saves time, most of those steps and principles aren't lengthy and they only increase time by a little. In the ambulance call example, if we were to rush through, miss a couple steps we could have maybe saved a couple or few minutes but the outcome wouldn't have been better and could have been worse.Thu, 02 Apr 2009 10:21:53 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxIf any one that think's SQL is less complex then Oracle or DB2 then I would assume you have excessive knowledge in these products to make such a decision. Then if one says that SQL server is not complex then take a minute and dwelve into the SQL server architecture..let's say memory Architecture ..you will be suprised that there are many complex components involved in the SQL server memory arhictecture and then on top of that try mapping those components back to Windows memory architecture ...wow seems simple enought...:hehe:But let's not focus on comments about complexity and focus on the article that was written and the way of thinking that must sometimes change to fix a problem in 10min or spend 1 hour....Thu, 02 Apr 2009 10:03:17 GMTCoetzeeWhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxIn an emergency you must remember to panic!! Well, not really, but people who *are* panicking often get really angry at your failure to panic along with them. They see your calmness not as competence in the face of an emergency, but as a "failure" on your part to "understand the seriousness" of the situation. If you're not careful (and sometimes even if you are), you can suddenly find yourself defending your actions and your attitude from a frustrated and angry person instead of solving the problem. In my experience, the best bet is to remove the panicky people from the area where you are trying to problem-solve. This can help break the escalation of their panic (and give them a chance to calm down) and remove a fairly serious distraction while you're in an emergency situation.Thu, 02 Apr 2009 10:00:33 GMTaureolinhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxIn that case, I suppose I must retract my earlier criticism of your analogy - I still think that the comparison wasn't very close, but the point of an analogy is to stimulate thought, and in that respect it has worked well!Thu, 02 Apr 2009 09:54:27 GMTmike brockingtonhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]mike brockington (4/2/2009)[/b][hr][quote] that is why training and familiarization, disaster drills, etc. come in handy[/quote]Thinking about it further, I think you have stumbled on the biggest difference - both Fire and Ambulance services are primarily there for emergency situations, prevention is largely a different department and/or an activity carried out during quiet periods.For most IT people, the reverse is true: our performance is generally assessed on how _little_ time we spend on emergency care, as prevention is preferred.This leads into the classic dilemma over training: should we put time and effort into learning diagnostic techniques, and purchasing diagnostic tools, or should we concentrate on ensuring that disasters never happen? While many large organisations will be prepared to have a dedicated disaster team, is Google's approach of massive redundancy not an even better idea?[/quote]Exactly, that's where I ended up in that long-winded stream of conscious reply to you :) I think Google has it right in ways and that covers a hardware or even a majority of software errors but there are still troubleshooting scenarios that come up. I think in IT we do need more training (not to the extent of the fire service, that would be a wasteful use of IT budgets), more tool familiarity and we should look at redundancies more. Google still has their failures though, the massive redundancy is great until you introduce a glitch across a massively redundant array of machines (yes I am very much oversimplifying that).Anyway I think your response and this conversation brings up some interesting points.Thu, 02 Apr 2009 09:44:53 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote] that is why training and familiarization, disaster drills, etc. come in handy[/quote]Thinking about it further, I think you have stumbled on the biggest difference - both Fire and Ambulance services are primarily there for emergency situations, prevention is largely a different department and/or an activity carried out during quiet periods.For most IT people, the reverse is true: our performance is generally assessed on how _little_ time we spend on emergency care, as prevention is preferred.This leads into the classic dilemma over training: should we put time and effort into learning diagnostic techniques, and purchasing diagnostic tools, or should we concentrate on ensuring that disasters never happen? While many large organisations will be prepared to have a dedicated disaster team, is Google's approach of massive redundancy not an even better idea?Thu, 02 Apr 2009 09:33:36 GMTmike brockingtonhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxGreat point about documentation! I mentioned it but as an after thought. The post-call documentation on an ambulance call is definitely after the fact but there is a lot of writing that should go on. I will often either write on the back of a glove, a scratch pad or just take the wider medical tape and tape it to my thigh. Vitals, Treatments, Things I checked. Wish I had thought of that and added a blurb about it. It is quite frustrating to find nothing documented, nothing to prevent the next time or at least make it easier to fix next time.Thu, 02 Apr 2009 09:22:59 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxGreat article, Mike. One thing I would add to it is to emphasize in the IT world is that documentation should be occuring throughout the troubleshooting effort. Record what you're doing. Record what the results were. That way if you have to rollback, you know exactly what you did and in what order you did it. In the scenario you've described I'm sure there is documentation continuously going on. When you check vitals, etc., you're probably recording some info, just like you probably did with initial information. A lot of times in troubleshooting what frustrates me is when I get brought on to help find out what is wrong and I ask the folks that have already been working the problem, "What have you done to this point?" and they can't give me a good breakdown of what has already been tried and what they saw when those things were tried. Thu, 02 Apr 2009 09:19:29 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]mike brockington (4/2/2009)[/b][hr]Interesting analogy, but I'm afraid that is simply isn't true. Recent studies have shown that well trained personnel (I think it was Incident Controller, aka Lead Fireman specifically) simply do not run all the possibilities in an emergency situation, they just look and act. The training allows them to adjust procedures as the reality of the situation emerges. The key thing being that they can never have any significant understanding of the problem domain in advance, only of the tools at their disposal. In tech support, the reverse is more often true: people know how to configure devices, but only use the diagnostic tools when they need to, and therefore only ever learn the bits that they have used so far.[/quote]Hey Mike - That is an interesting point and I guess I am slightly confused. You are right, not all possibilities get run through at a structure fire or car accident. I agree about the lack of significant domain knowledge though. In the firefighting/ambulance world, every call is different and we have been trained for a general domain knowledge of the potential problems but each one is a bit different. We apply the same pattern to the problems though. At least I do. I think through all of the potential scenarios when responding to a house fire or medical call or even a more common fire alarm activation call (bells and smells). I think through the potentials that could happen, as I approach I look for signs that lead towards a scenario, I plan for the worst case (throw my air pack on my back even if it's the 17th alarm call there this week, have my gear situated properly). You are right it does come down a lot to training on both the fire and ems side. On the ambulance call though we are thinking of the big picture and trying to proactively use a rule-out methodology to rule things out. I said differential diagnosis and perhaps that is a bit arrogant (we are certainly not doctors or nurses) but it is close to what we do. We go to our training, look at all of the information, make a decision that this is the general area of problem and treat that problem while transporting. If signs and symptoms change we go to our training and knowledge to redirect treatment. That isn't looking and acting though. Show up to a "working code" (a patient unresponsive, not breathing and pulseless) and it is a look and act situation.In technology we have occasions where we may have to do a look and act that relies on training (server is frozen, can't access any tools to gather more information, can't connect easily.. reboot). A lot more situations where we want to analyze, use a methodology and form a "differential diagnosis" of the issue at hand.As for the only using what you know when you troubleshoot technology. Sure that makes a lot of sense but that is why training and familiarization, disaster drills, etc. come in handy. To develop some of that "muscle memory" to learn about the tools you may need to use under stress. The focus in technology on training is far lower than that in the emergency services which I guess makes sense.I like your viewpoint and it makes me think about a lot :) Should we do more training/drilling in technology? I think so but how much more? How much will it cost (time, resources, lack of attention towards reactive tasks and user requests) and what's the likelihood we'll ever need it? In Fire/EMS it's an easy decision, if you don't train lives could be lost, there is a LOT of downtime between calls and you are getting hit with such a variety. I still like my analogy on the medical side as it brings out the steps that work on both an ambulance call (at least it has for me, on both trauma and medical emergencies) and most other areas of life. There are a lot of places (like the fire example) where that methodology is not used and I never really thought of it like that :)Thanks!Thu, 02 Apr 2009 09:04:22 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxNice job, Mike.I fixed the one type on "seen"Thu, 02 Apr 2009 08:42:38 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxInteresting analogy, but I'm afraid that is simply isn't true. Recent studies have shown that well trained personnel (I think it was Incident Controller, aka Lead Fireman specifically) simply do not run all the possibilities in an emergency situation, they just look and act. The training allows them to adjust procedures as the reality of the situation emerges. The key thing being that they can never have any significant understanding of the problem domain in advance, only of the tools at their disposal. In tech support, the reverse is more often true: people know how to configure devices, but only use the diagnostic tools when they need to, and therefore only ever learn the bits that they have used so far.Thu, 02 Apr 2009 08:40:36 GMTmike brockingtonhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxBeautiful article, and well written. It seems, as with so many things in life, the key element in the article can be summed up with a quote from the Hitchhiker's Guide "Don't panic."Thu, 02 Apr 2009 08:39:14 GMTtimothyawisemanhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxSounds like you work at a great place. I have not been doing technology very long. I have worked with SQL Server for 10 years but I have yet to not find folks executing that type of troubleshooting. Anyway, thanks for the comments, gives hope.Thu, 02 Apr 2009 08:37:47 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxThe chicken approach would not be tolerated where I work.Thu, 02 Apr 2009 08:32:46 GMTKen Shapleyhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]Ken Shapley (4/2/2009)[/b][hr]Wow! "SQL Server is less complex"?What kind of production environment are you running. A lab?[/quote]Thanks :) I was confused by that comment as well. My response to them about yeah maybe it's less complex than say an Oracle or DB2 was more about the installation and management options/methods. It is still a very complex DBMS with tons happening under the hood, lots of moving pieces and parts and if you treat it like it's just a simple thing then you end up seeing the kind of troubleshooting I concluded with.Also to your point about everyone following this if they have survived awhile. I think you summed it up best when you said "Then again..." ;-) I work with a lot of folks at the same skillset or much higher who could stand to use a better troubleshooting method. They try the chicken with the head cut off approach far too often :)Thu, 02 Apr 2009 08:23:47 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxWow! "SQL Server is less complex"?What kind of production environment are you running. A lab?Thu, 02 Apr 2009 08:18:03 GMTKen Shapleyhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxJust about any working professional that's been able to survive any length of time in our profession does what this article says. Where I work now we perform it as a necessity. Not sure we've ever wrote it out and followed it. We do have a lot of written antedotes and not all apply. I think I've learned this process from making all the mistakes in the past. This would have been good advise then. Then again....Thu, 02 Apr 2009 08:12:35 GMTKen Shapleyhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]SanjayAttray (4/2/2009)[/b][hr][quote][b]CoetzeeW (4/2/2009)[/b][hr]Great Article, Since most DBA's responsiblity is supporting\troubleshooting such a complex product like SQL server you have highlighted a good methodology and approach to problem solving, Thanks ! ;-)[/quote]Excellent article Mike.I like this part most though from above quote ..........[b]supporting\troubleshooting such a complex product like SQL server[u][/u][/b].:laugh:[/quote]:-P I am not sure if the sarcascm was frustration about troubleshooting SQL or the fact that SQL is less complex than other database management systems. SQL Server is less complex than some but shoddy troubleshooting happens all the time and often causes more problems than solutions (or accidental solutions that can't be recreated). In fact the simpler management interface and installation interface is what causes a lot of the woes with SQL Server. A lot of companies have the theory that since you can just click next, next, next, finish and it's installed you don't need a DBA staff. You don't need to follow best practices and it can't be that complex to fix, you can just fix it with a quick web search. Watch the forums here or the msdn forums and you'll see the results repeat time and time again.No it's not as complex as the human body either but the point is the same principles of problem solving and troubleshooting can be applied anywhere.Thu, 02 Apr 2009 08:12:24 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspx[quote][b]CoetzeeW (4/2/2009)[/b][hr]Great Article, Since most DBA's responsiblity is supporting\troubleshooting such a complex product like SQL server you have highlighted a good methodology and approach to problem solving, Thanks ! ;-)[/quote]Excellent article Mike.I like this part most though from above quote ..........[b]supporting\troubleshooting such a complex product like SQL server[u][/u][/b].:laugh:Thu, 02 Apr 2009 07:55:36 GMTSanjayAttrayhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxExcellent article Mike! I really like your writing style, and you have some cool things to say. Troubleshooting is about as scientific as our jobs get and I appreciate your application of the scientific method.:{> AndyThu, 02 Apr 2009 07:51:55 GMTAndy Leonardhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxGreat Article, Since most DBA's responsiblity is supporting\troubleshooting such a complex product like SQL server you have highlighted a good methodology and approach to problem solving, Thanks ! ;-)Thu, 02 Apr 2009 07:48:53 GMTCoetzeeWhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxFantastic article. All too often we find ourselves thrown into panic mode when a major event happens, especially when it's the busiest part of the day. This is usually exacerbated by the CIO spewing "We're losing 10,000 dollars a minute while this is down!" or something similar, trying to shock the DBA into fast action. I wish more tech managers/leaders understood the point Mike is making with this article.One minor grammatical bug: "You arrive on seen" should read: "You arrive on scene".Thu, 02 Apr 2009 07:46:44 GMTSeñorDBAhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxThanks for the comments thus far :) I have to admit I got scared (but remained calm and handled it in an orderly fahsion ;-) ) when I saw all of the comment alerts pop up on the phone's mail client.To the comments about the importance of remaining calm, a great piece of advice I received and neglected to put into the article fits here. It was a Paramedic class instructor and he said that paramedics need to be like ducks. If you ever watch the duck on the water, they are in control, just sitting there calmly and slowly moving where they need to. Look under the water and they are paddling feverishly. In other words, don't be slow but don't be hustled and rush either. Sometimes when we troubleshoot an issue we need to move quickly but quickly doesn't mean so fast that we lose all control and all appearance of control and start doing stupid things.Thu, 02 Apr 2009 07:15:52 GMTmike_walshhttp://www.sqlservercentral.com/Forums/Topic688548-1521-1.aspxGreat article, thanks very much!Thu, 02 Apr 2009 06:49:15 GMTCarol Wickenheiser