Voice of the DBA

Category: Blog

  • Working with SQL Server Third Party Vendors

    I ran across Denny Cherry’s (@MrDenny) blog on Fixing Vendor Performance Problems in which he outlines three methods of dealing with the. His list is basically

    1. Work with the vendor
    2. Do nothing
    3. Fix it yourself

    Denny recommends that you do #3, and add indexes, statistics, etc., and script them so that you can drop them if the vendor needs to access the database, and add them back afterwards. This is done to avoid voiding a service contract.

    I’ve done that in the past, but I try to avoid it. My first inclination is always to choose #1. I have had great success with this in the past, with a number of vendors, and it’s the item I recommend. Try to work within the system and make change, rather than just go "cowboy” right away and make the changes you think need to be made. I’ll give you the how and why I recommend this.

    How

    How do you get the vendor to make changes? The same way you get the best support you can from a vendor: you have a logical and rational discussion, explaining your thoughts with backing documentation.

    I have had vendors insist that the “sa” login was needed, and avoided it. I have fixed performance problems by getting vendors to add and drop indexes. I have convinced vendors that they application could run, and be supported, on an instance with other databases.

    All of this has been done with tracing the calls, analyzing performance, and then explaining where I saw issues with the vendor’s application. lt wasn’t done to prove I’m right, it wasn’t done to tell the vendor their code was sh*t, It was always done with me in the middle, along with the support person, between my boss, and their boss.

    Talk to the vendor like he’s a friend coding in the next office, and he’s doing his best, but perhaps doesn’t understand why something isn’t working well. Give them supporting documentation, show them execution plans, show them before and after views on test systems, give them reasons why a chance is needed. Even offer to be a guinea pig for the tests. I’ve done that before, and we convinced a vendor that they didn’t need to index every column in a few tables based on six months of evidence from our system.

    If they argue with them, perhaps they have good reasons. Get them to prove to you that they have logic and evidence on their side. They might, but if they don’t, then you ask to talk to their manager, or their development lead, and work through the argument there. Most vendors don’t want crappy performance, but as Denny mentioned, they often just don’t have expertise.

    Work with them, not against them.

    Why

    Why should you spend time educating and teaching the vendor about SQL Server performance? Obviously you want to maintain your support contract status. There’s nothing worse than violating this and then having a problem that doesn’t get supported. That’s an ugly conversation to have with your boss.

    You also don’t want issues with upgrades. I have seen more than a few problems with upgrades because someone “touched” the system. Make sure that you not only document the changes, but get the vendor to document them in your account. They might even work with you on upgrade scripts.

    Lastly, you want to be right. There are plenty of people out there that make mistakes, or make a decision based on an incomplete picture. You might be sure that an index is needed for this query that runs every day, but maybe the vendor tested it and found a better index, or they found it caused worse performance for some other queries. Maybe you’re misreading the evidence yourself.

    If you are forced to explain yourself, and can do so in a way to convince someone else, you should have more confidence that you are making the correct decision.

    Plus it gives you something to blog about and put on your resume. Winking smile

  • PASS Speaking Results

    I got the PASS speaking results today on the new speaker portal. They posted the top sessions as well, overall and in each track. I did two sessions, and here are my summarized results:

    Branding Yourself for a Dream Job

    67 attendees, 39 surveys.

    Overall, I was mid 4’s (4.59, 4.72, 4.74, 4.56, 4.56) for the various questions. Anything over a 4 means that I was doing a good job overall. I got some great comments, many of them in caps. I hope that means people were excited, but in any case, here are a few:

  • IT IS TIME TO VAN SP_UPDATERESUME
  • GREAT, GREAT PROFESSIONAL DEVELOPMENT TIPS! ESPECIALLY LIKED THE PART ABOUT BLOGGING. WELL DONE!
  • IDEAS FOR FINDING EMPLOYEES AND OWN CAREER
  • THE IMPORTANCE OF MANAGING MY IMAGE
  • STEVE OPENED MY EYES TO THINGS I ALREADY KNEW BUT WASN’T REALLY AWARE OF.
  • LEARNED SOME GREAT TIPS FOR IMPROVING "BRAND" TO HELP IN KEEPING/FINDING JOBS
  • GLAD I CAME. VERY ENJOYABLE AND INFORMATIVE.
  • SUPERB PRESENTATION!
  • I GOT SOME GREAT TIPS TO IMPROVE MY ONLINE PRESENCE.
  • DESIRE TO PROMOTE ONLINE PRESENCE
  • I ALREADY STARTED TO UPDATE MY ONLINE PRESENCE AND I’LL BE UPDATING MY RESUME WHEN I GET HOME.
  • GREAT STUFF! MORE GOOD INFO THAN EXPECTED!

    • Nice comments, and I enjoyed the session. Got some great questions during this presentation.

    In the PD track, I was third, and I regret not going to see Plamen’s talk on great presentations. The slides look good.

    The Top Ten SQL Server Skills You Need

    188 attendees, 80 surveys.

    I was worried about this session a bit because it was near the end of Friday, the last day, and it’s a basic 100 level session. Also, I was in a huge room, the one that Adam Machanic filled up with 500+ people that morning.

    However I was pleasantly surprised to see similar scores here in the mid 4s (4.43, 4.66, 4.6, 4.45, 4.34). I guess that means I do a decent job presenting, even when I’m not at my best. One comment caught my eye:

    • Voice was more monotone than yesterday. Sounded tired.

    Very, very true. I was wiped out, and after this session I left immediately for the airport for a flight. I dislike speaking late in the day, and after being in Seattle for a week, I was definitely tired.

    This is a tough session since it’s basic, and I suspect some people come to see me, expecting something more. I was actually surprised this session was picked by the program committee, though clearly wanted. I was more surprised it was scheduled so late in the week. I had some nice feedback:

    • several of the tips were useful and possibly the links to more information is most helpful
    • go home and use what I learned
    • finally someone at this conference who teaches people new to sql server the basics and not something over my head Thanks Steve!
    • how to train my entry level dba’s

    Glad I met the need. Some not to great feedback, though I’m not sure how I can fix some of these. It’s listed as a 100 level session.

    • Could have said for beginners. This was a very low level presentation of many basics that most dbas do every day.
    • I expected sql server dba function more advanced than types of joins and how to create basic indexes
    • Could use a little more just like most sessions

    I’m not sure what “more” I could do, especially with 10 things. I suppose I could cut it down, but my aim was to point people in a direction, not teach them deep skills.

    I think I’ll retire this one, unless I get a call for it. I don’t love it, and with a mixed skill level audience, I always find people complaining that it’s too basic.

  • Data Usage

    This is somewhat shocking to me. I was reading about ATT’s decision to throttle some high bandwidth users, and there was this quote in the article:

    “But as business rises, so does data usage. J.P. Morgan estimates that the average iPhone user will consume around 800MB of data per month. That’s not far off from the average non-iPhone user projected to grab around 825MB each month.”

    Huh? Much of what has been reported implies, or says, that the iPhone is the culprit for data usage growing so quickly. Perhaps that’s true, but if the non-iPhone users are using more (825MB v 800MB, average) that implies that other platforms are using more data. I’d assume this means Android, but I suppose that Blackberry might be implicated with the constant email traffic, and potential links in those emails driving people to view other data.

    I use about 250MB/month, so I’m not worried about the throttling. As much as I wouldn’t like it, it does make some sense to me. The people that are using 2GB a month are impacting others, and unlimited data, while it’s something I think should be there, I don’t think it should be unlimited MB AND speed. That’s unsustainable for any company as usage grows. Sure the bandwidth will increase, but there are a few people that abuse the plans and impact others.

    Slowing down the top 5%, or even asking for a surcharge seems like the fair thing to me for the good of the digital network. I think we ought to have net neutrality on the Internet, but I also think that for the outliers we ought to institute something. On the high end, I can see some throttling done, even across all kinds of traffic.

    On the low end, I wonder if we ought to have some type of national infrastructure growth like we had for the POTS lines to try and ensure that we can help the entire country access the Internet.

  • The Layman’s View of a DBA

    I wrote this piece as a guest on Bradmcgehee.com for the DBA in Space competition. Republishing here.

    A DBA (Database Administrator) is someone who takes care of your data. When you place an order on Amazon.com, it’s the DBA who ensures the order is permanently recorded in the database. If one of the computers at Amazon fails, and they regularly do, the DBA can recover the data. The DBA should be the person that prevents part of your order from getting lost because it’s incorrectly recorded, and it’s the person that makes sure that if you update your address, the change is recorded so your purchases reach the right destination.

    A DBA makes sure that the transfers between your bank account and other accounts are completed in full, without allowing the deduction from your account to occur without the credit arriving in the destination account. DBAs try to ensure the data that appears on your bill is correct, and that if you change the name on your account, the change is reflected in your statement.

    DBAs are like the local librarians, keeping track of all the various words and numbers in their library and knowing where everything is. They are the custodians of information in databases, trying to keep it all organized, intact, and available for access. DBAs are not perfect and they can make mistakes which result in the mistakes we occasionally find on bills or statements.

    However, DBAs don’t act alone, and in many cases their job is directly affected by other people. The websites you use, or the applications on your computer or mobile phone, are written by developers that decide how you enter or read the information, and how the data moves into or out of the database. These developers sometimes do not have the proper training on how to store data to prevent mistakes, or how to clean data to fix incorrect entries, resulting in bad data outside of the control of the DBA.

    In addition, the connections to databases are often managed by system administrators or network professionals who also deal with failures. When you cannot access your account on a website, it’s entirely possible the database is running and working fine; the problem is in the connection between the website computer and the database computer.

    The DBA’s role is often taken for granted. If everything works as expected, it appears the DBA is not doing any work, or adding any value to their company. This may be why so many companies forgo hiring a DBA and expect their developers and system administrators to manage the databases. That’s not usually the case as the work a DBA does is designed to prevent problems, and be available to fix the inevitable issues that will arise.

    The DBA is a preventative mechanic, working on your car every day and night when you aren’t using it, ensuring that it is working when you do need it. They’re the behind the scenes staffers that coordinate and organize the concert or play you enjoy, unaware of just how much work goes into providing you with an enjoyable experience. The DBA is the glue that binds so much of our technological world together, helping to ensure that all parts of the system know what should be built, sent to who, and when it should arrive.

    Read more: http://www.bradmcgehee.com/#ixzz1fnp9rH1k
    Under Creative Commons License: Attribution