• Pingback: SQL Server Performance Tuning Politics | John Sansom - SQL Server DBA in the UK()

  • Pingback: 10 Character Traits of Outstanding DBA’s | John Sansom - SQL Server DBA in the UK()

  • S.E.

    Well, what I did recently in theme response is the following (not quite like you have recommended):

    I had the SP that was (among others) the cause for excessive blocking. The developers rewrote it so it became better (say, initial state was 1 on a 1-10 scale, the modified solution was about 4).
    I analyzed the SP logical block by logical block (there were only 4) and at the end of my mail I proposed a brand new solution which would have no cursors at all, and I proposed a new – covering – index to avoid the table scan.
    I was not unfriendly, nor friendly. I was objective.

    The reposonse was: “you’re right, that SP would be faster with your recommendations, but at this time we are working on rewriting some other SPs that are more frequently used. The SP you analyzed had en execution time of 200ms and it runs only a few times a day”.
    Well, they may be right, but that few times when it ran, in the problematic timeframe it ran not for 200ms but for 576 secs (due to blocking).

    At this point I got angry and replied: “OK, do what you think you must do, I’ll moderate myself with my
    recommendations. Let’s go!”

    Maybe I was wrong.

    What do you think?

  • http://michaeljswart.com Michael J Swart

    I’ve been in that situation too. And I hear you loud and clear. If I listed my top ten frustrations for the year, then unimplemented recommendations would leave them all behind.

    The best I can do is make sure the business maker understands the risk. And at last resort – get them to repeat back to me. “I am choosing deadlines over quality”. I do it tactfully and it’s not always black and white. And I’m lucky that I got co-worker’s that trust me.

    But it sounds like you have people that actually don’t believe you. (Whether it ‘s personal or they’re hiding their heads in the sand) That’s the worst and I wish you luck. I’d shy away from snarky emails, but I don’t have any alternative.

    I am curious about what others think.

  • http://sqlsolace.blogspot.com r5d4

    Have been there too. More recently than I would like.
    A developer I’ve been working with has ignored everything I’ve explained about sql server.

    As a result >

    1) We still have a ton of adhoc sql (stored procs, user defined functions etc are ‘too much work’)

    2) We have little Normalization (the clue is in RELATIONAL database). It is too much effort apparently, meaning –
    a) We have lots of duplicated data.
    b) A lot of it is large text data (meaning the data cache has NO chance and the page life expectancy is very low).
    c) Reporting on the data is painful.

    3) H/A technologies are near impossible. Try implementing replication and a reporting environment when your schema gets repeatedly ‘tweaked’…

    The individual always listens, but then does exactly the opposite.

    The most recent example is implementing Linked Servers for retrieving large results set and putting the code live (against my advice)

    Due to small company politics and the individual’s seniority (8 years loyal service), they frequently ‘work on live’ and retrospectively update dev & uat with db changes.

    My auditing skills have improved no end and I have automated checks of object changes to see ‘ what ‘x’ has done today ‘.

    It’s not a nice way to work though, and is very stressful.

    • http://sqlsolace.blogspot.com r5d4

      I’m moving forward with my feet. right out of there.
      In a few days in fact :)

  • http://kmescha.wordpress.com/ Keith Mescha

    Nice job on this, very good advice and something that I see happening on a regular basis. Sharing with the team here as I think your approach to sharing advice is great.

    Keep up the good work.

  • Pingback: Seven Reasons You Should Attend SQLBits 7()

  • Pingback: TSQL Tuesday 13: Managing Unrealistic Expectations()

  • Pingback: The DBA Ultimate Fitness Workout Plan()

  • Pingback: Stop Asking and Start Making Decisions Today()

  • Pingback: Something for the Weekend - SQL Server Links 31/05/13 • John Sansom()

  • Maria B.

    This is a great artice. Thanks for articulating one of the key skills we need to develop as a DBA – optimal communication. Just as important as optimal queries!

    How our information is received is a different story. But it’s still our responsibility to pass the information on.
    And if that information isn’t valued by the business or development teams, then perhaps it’s not the right business for us??