Voice of the DBA

Author: way0utwest

  • Another Day, Another City

    After a few days in Copenhagen for SQL Nexus, I traveled to London late last night, and am now making my way to Liverpool for SQL Bits. A hectic schedule, leaving one city, flying to another, a few hours sleep and moving again today.

    It’s exciting to be heading back to SQL Bits again, as it’s my favorite conference, and I am looking forward to seeing people from all over the world that I’ve become friends with across the years. Plus it will be fun to see all the costumes at Friday night’s space themed party.

    I’ve got two sessions to deliver. A lunchtime session on version control Friday and then a testing talk Saturday.

    Between now and then, some final rehearsals, and hopefully an hour or two at the Beatles museum.

  • Off to SQL Nexus

    This week begins my two city, two conference journey across the Atlantic. I arrive in Copenhagen today, after traveling overnight from Denver. I wrote this before leaving, knowing that I’ll likely be a bit worn out as I make my way from Denver to Washington D.C. to London to Copenhagen.

    This is the most relaxing part of my trip, with a day to adjust in a new country before the SQL Nexus conference starts tomorrow. I’m looking forward to getting some coffee and exploring the city.

    Tomorrow is a conference day, hanging out and learning a bit before I speak on Wednesday morning. I’ll be talking about SQL Server 2016 Encryption, and I expect that if SQL Server 2016 hasn’t RTM’d by this time, it will either Tuesday am at SQL Nexus or Friday am at SQL Bits. I could be wrong, but as I write this, I expect those are the likely dates.

    I’m looking forward to Nexus, which has lots of SQL 2016 content scheduled. I just hope all the sessions are in English Winking smile

  • Install Cumulative Updates

    For years I haven’t recommended installing Cumulative Updates (CU) as they are released. The main reason is that Microsoft has had language associated with their CUs that say customers should not install a particular CU unless they are experiencing the specific issues the CU corrects. Each CU has (in the past) also noted that you should stick with the latest Service Pack otherwise. That disclaimer has been enough for me to be concerned about CUs in a general sense, despite the insistence that the CUs were tested as well as SPs. My thought was that if the testing was the same, that disclaimer wouldn’t exist.
    Well, things have changed. The latest CUs have this language in the section where a KB says that Microsoft recommends CUs as they are release:
    • SQL Server CUs are certified to the same levels as Service Packs, and should be installed at the same level of confidence.
    • Historical data shows that a significant number of support cases involve an issue that has already been addressed in a released CU.
    • CUs may contain added value over and above hotfixes. This includes supportability, manageability, and reliability updates.
    That’s good news, though as Kendra Little notes, you still need to test. Bugs will still exist in patches, and really all software, so it’s important that you test in your own environment. That means you need a test plan that can easily run, preferably an automated test plan. If nothing else, this is a good reason to use tSQLt and have tests written for your system. At least you can verify important queries and systems are working. Kendra has a good list, so read her post.
    While I think the quality of CUs is up and they are probably as safe as most of the Windows patches we get every month (and are often installed no matter our individual feelings), I’d still be wary. If you can’t test, if you’re busy, if this is a month you can’t afford for things to fail, then don’t install the CU. This is like throwing your own developers’ code into production without any testing. Make sure you know what is being changed, and you look for obvious problems. No one will be too upset of an obscure issue, but if your scheduled jobs start failing, you’ll dramatically reduce the confidence people have in you.
    I am still wary of all patches. They’re disruptions, to both your routine, and potentially to availability as well. Make sure you test, but if you have the time, I’d say keeping up with patches is worth doing. Microsoft is constantly fixing issues, and you want to take advantage of their hard work, if you can verify the patches don’t degrade your system.
    Steve Jones

  • Stress Testing

    Many of the DBAs that manage production systems will at some point determine what level of hardware is needed to support a workload. Whether this is a physical server purchase or a cloud “rental”, someone has to decide what hardware is needed. How many cores, the amount of RAM, the number of disks, which hopefully correspond to some level of IOPs, and more. Even in the Azure SQL Database world, you must decide what database capacity you will pay for.

    Since this is a big decision, and changes can be hard to make, many DBAs overbuy hardware. After all, no one wants to have a slow server. This is true for Azure as well, at least for many people I know. While changing from an S3 to a P2 is quick and easy in the Azure portal, it’s not such an easy sell to management. If they’ve budgeted $150/month and you tell them we want to go to $900/month, the technical change is the easiest part of this.

    As a result, I’m surprised that we don’t really have better ways to determine if hardware will support our workload. I see this question asked all the time, and although there are tools and techniques suggested, I’ve yet to see many people have a set, known standard way of evaluating hardware and a particular workload.

    One one hand, I think there should be better tools to do this, whether from Microsoft or someone else. I suspect since this is such a rare activity and businesses have been willing to overbuy hardware (or deal with substandard performance), that there isn’t any large impetus to solve this issue.

    However I wanted to ask if any of you actually stress test hardware? Either your current hardware or new purchases. If you don’t know what your level your current hardware performs at, how do you compare that to new hardware?

    Do you have a way to replay and measure a workload? Do you have the time to do so when new hardware arrives? Is there a documented method you use? Apart from discussing this today, I’d love to see some articles that detail exactly how you test hardware from a technical tool perspective, and then a followup that examines and evaluates the results.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.2MB) podcast or subscribe to the feed at iTunes and LibSyn.