On call support experience

  • Can anyone share their on-call support experience. Problem u might have faced and steps for resolution and how long it took. Want to gather some BP or lesson learned.

  • There is plenty of information out there with regards to troubleshooting scenarios and each person's on-call experience will differ from another based on the environment, SLA's, business stake holder relationship, processes, company politics, etc. to name a few factors.

  • Can you plz point out few links.

    Thanks

  • Not so much a how to, but I recently posted this article on how to prepare[/url] for being the on call person.

    For what it's worth, there is no average on-call response. I've had calls that took me about 30 seconds to fix (after waking up and logging on and connecting to the server) to calls that took 3 days. You have to expect them all.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • I'm on call right now!

    Nothing can replace experience and documentation of the environment you are working in. Its also essential to have an escalation protocol and list of "points of contact".

    Never panic, keep a cool head, and if its something you dont think you can tackle on your own or complete within SLA admit it to yourself and escalate straight away. Doing this wrong can and does cost people their jobs and their employers money.

  • {EDIT} Terrible post from a seriously caffeine deprived day removed. My apologies.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • searching is that you learn!!!!!


    [font="Times New Roman"]rfr.ferrari[/font]
    DBA - SQL Server 2008
    MCITP | MCTS

    remember is live or suffer twice!
    the period you fastest growing is the most difficult period of your life!
  • there's no way anyone could answer such a question because all our experiences would be different. You do the same stuff on call as you do in your working day with regard to issues ( except perhaps remotely ) if a server crashes the process is the same regardless.

    I might suggest you keep a "when it goes wrong" manual, I keep a record of every issue I've ever encountered as a DBA, this includes issues with switches, hba's sans, storage, firewalls, app and web tier etc. etc. If something affected the availability of the application my database(s)/server(s) support I need to know so in the future if it happens again I might save myself ( and maybe client ) a "headless chicken" period!!

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • I hate being on call! :w00t:

    When I'm on call, I want to retire early.

    When not on call, I feel I want to work with SQL to the grave.

    But, aside from the silliness, to me on call-support experience is something you get immersed in; there is no way to prepare for it.

    However, a good documentation ethic in the team really helps;

    having some sort of knowledgebase on how to tackle common issues can especially help team members who may not be as senior or experienced in the day-to-day work or even those of us who may not have had experience with a certain issue. After all, no one knows everything...

    In the vast number of cases, call issues will be simple. It's those once-in-a-blue-moon crises though that raise the hair at the back of my neck.

    It's no fun having to call Microsoft in the middle of the night because of a server crash. :w00t:

    __________________________________________________________________________________
    SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
    Persisting SQL Server Index-Usage Statistics with MERGE[/url]
    Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]

  • You may want to sit with a Senior DBA and discuss all issues (SQL related) that used to happened before you in this organization. And how they were resolved. Make sure to document them. It is very important especially if you are new to that place, don't have much of the experience and especially, if issue happens in the middle of the night.

  • You have already entered a house full of information. Most of the questions asked here are the problems faced or thinking ahead of a problem. Please browse through the posts and you 'll get a lot of information.

  • never worried about being on call, done that on and off for around 16 odd years. Generally there are not many calls, if there are then you fix the problems so you don't get called .. works well for me < grin >

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply