Policies/Procedures on preventing after hours calls

  • I'm curious as to what policies/procedures other DBAs have in place at your various companies to try and cut down after hours calls and ensure that when you do get a call, it's more than likely an actual SQL issue.

    What do you advise your Service Desks, Level 2 Support, etc?

    Comments appreciated 🙂

  • I wouldn't adivse them of anything. They should be following a written procedure that helps them make better decisions. Ask to see the written procedure so that you can see what's going on there and perhaps suggest a change.

    If they don't have such a written procedure, then they need to make one. It should also contain an "FLD" (Fault Location Diagram) which is a flow chart that they should follow to help isolate a problem to the correct area of expertise.

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

  • After a call an RCA (root cause analysis) should be done to avoid repitition of calls. At our shop this is handled by the Incident management team.

    ---------------------------------------------------------------------

  • Thanks guys, I know for a fact there's no written procedure. At the moment it's let's ring everyone and get them to verify their side.

Viewing 4 posts - 1 through 3 (of 3 total)

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