Voice of the DBA

Category: Editorial

  • Another Re-Release

    If you haven’t noticed, SQL Server Release Services dropped an updated CU6 for SQL Server 2014 SP1 this week. This replaces a previous CU6 that had a NOLOCK bug in it, and the old KB article (and patch) have been deprecated. You can install the new CU#6 on top of the old one, and you should. The old patch could cause you some issues, so if you’ve applied CU#6 previously (build 12.0.4449), go download the updated patch, test it, and apply it to your instances.

    However, there’s a couple issues with the process here. First, re-releasing a patch under the same name (with a different build) is confusing. I am sure there are going to be plenty of people, especially accidental DBAs, that think they’ve applied CU 6, and they don’t realize there has been a change. There will be others that apply the patch from an old download that’s shared on their file system. I’d much rather have fixed patches released as a new CU. What does it matter if CU #7 is released now instead of in a few months? There’s no limit I’m aware of for the number of CUs allowed for a particular version, so let’s just increment numbers.

    The second issue, for me, is that this eats up time. Releasing quickly is one of the problems with an agile approach, where you update software quite often. There isn’t necessarily enough time to completely test the the fixes, and as comprehensive as the Microsoft testing suite is, there will be things that are missed. I certainly think Microsoft deserves kudos for finding the issue and releasing a fix so quickly. However, will this patch be distributed as quickly as the original CU #6?

    If you are used to applying these CUs, are you going to notice there is a new version of this CU to apply? The blog entry title doesn’t note this is re-released. If you look for the latest patches and see CU #6, will you realize this fix has been updated? If you know there’s a new patch, will you have time to re-test the update and schedule another release? I know from experience in a large organization, re-applying Service Pack 3a for SQL Server 2000 was a chore, with limited time to re-deploy a patch among all the other work we had scheduled.

    One thing I’ve noticed is that more and more companies are depending on their databases more often, demanding higher uptime and fewer maintenance windows. The more patches we have, the more troublesome it can be to get permission to apply these patches, especially across a large server farm. Microsoft is building a better engineering process, that allowed for more comprehensive (internal) testing and quicker releases, but this process doesn’t necessarily prevent all mistakes. Those mistakes are not only bad press, but they reduce confidence in the entire process.

    I do think these CUs will start to take the place of Service Packs at some point, though I think the pace will become problematic for many organizations, especially those running third party software. I’m guessing that at some point, a good portion of the SQL Server community will start treating these patches like upgrades, and not applying every one. Many people will end up applying only every fourth or fifth patch, much like people seem to be upgrading many instances every 6 or 8 years.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Coffee Routine

    My daughter had a birthday recently, and one of the things she asked for as a present was a French Press. She loves coffee and is willing to wake up 15 minutes early each day to grind beans and make a nice cup of coffee each morning before high school. This has been a routine for her this past year, one that has generated requests for me to return home from my trips with new coffees for her.

    In a chat with Andy Warren recently, he mentioned that his new company has a few different coffee machines, with different choices available for employees. Some simple machines, some French Press, and other ways that employees can get their morning coffee fix. This is a small perk, but one that often goes a long way in the technology world as many developers I know aren’t morning people. They appreciate getting coffee provided by their workplace.

    This is in contrast to the situations I encountered early in my career. Back then there was no Starbucks available during my commutes, in fact, with few choices for coffee shops. I started in a large company where each department was in charge of their own coffee. We pooled money together to buy a cheap Mr. Coffee (replacing it ever year or so) and each of us contributed to fund to buy a large tin of Maxwell House every few weeks. I’m sure quite a few of you couldn’t imagine that scenario: cheap, bad coffee every day. In other companies, the same Mr. Coffee was provided, along with the buckets of ground coffee. After a decade and a half in this business, I finally worked at a company where we had a better machine.

    I was thinking about this on my recent trip to the Redgate office( after a quick stop in Copenhagen where I was instructed to be sure to get a bag of coffee for my daughter). The Redgate coffee machines (4 of them) are all located on the ground floor, in the atrium. This means that anyone wanting a cup gets to leave their desk, or make a trip before a meeting, to the open area. Lots of conversations start here, and certainly there are interactions between departments that might not otherwise occur. Plus, we have great machines, as you can see in my video.

    Despite the hassles, I visit the machines a bit too often while I’m there. At least 4 or 5 times a day, which means it’s probably good I’m not in the office full time. Now if I could only get them to put soy milk in one of the machines…

    Steve Jones

    The Voice of the DBA Podcast

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

  • More Overloads

    I was attending the SQL Nexus and SQL Bits conferences recently in Europe. These were launch events for SQL Server 2016, and the keynotes given by Microsoft included the overload of yet another SQL Server term. This time ACID was taken to be: Algorithms, Computer/Cloud, IoT, and Data. While I appreciate someone trying to be memorable or interesting in a keynote, to me, this creates confusion when we try to discuss the importance and positioning of SQL Server. ACID is a core term for relational databases, having nothing to do with the future. While some marketing people probably enjoyed this, I would have preferred they spent a little more time coming up with a term that describes a creative look at the future.

    There have been plenty of “overloaded” terms from the SQL Server platform. DAC, is that a connection or part of a database schema package? Snapshots? We have a few of them. When we talk about logs, is this meaning transaction logs or logs for the SQL Server process? Or even Agent logs. Are clusters meant to be FCIs or traditional shared storage clusters? At least that last one is close to same meaning for both terms.

    There are others, which creates confusion and could result in problems if two of think we’re discussing the same topic, but we’re not. I’d hope we’d realize there are ambiguity in a few minutes, but what if we’re dealing with a crisis? Clear meaning and understanding are important.

    I don’t mean to be pedantic, but I don’t think it’s too much to ask that new features, new concepts be given new names. While marketing might think there’s a neat sound to an old acronym, for us technical people it’s annoying, and potentially a liability. If we will continue to have marketing people influence the ever growing platform, the least we can have is creative marketing individuals that can come up with new ways to describe the hard work completed by the SQL Server development team.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Great Developers

    This editorial was originally publised on March 12, 2012. It is being re-run as Steve is on vacation.

    Is a great software developer worth 100 average ones? On one hand I think there are some good arguments that it’s not true. One developer certainly can’t write the amount of code that 100 average ones can. However there’s another way to look at things. A great developer can do things that the 100 will never think of, or never consider. He might not write the code that does as many things as 100 people, but I think a great developer could easily write code that performs a hundred times faster than the code 100 developers write.

    That’s why you always have an open position available for a great developer. If one is available, and they rarely are, you hire them if they want to work for you. You can always find things for them to do, and they can make improvements in code that your other 5, 10, or 20 developers will never come up with. I’d make sure they fit in your team and get along with others. You can get less work done if you have someone that is too difficult to deal with or too critical of others. While a great developer can accomplish things that others can’t, or won’t, they can’t do all the work.

    Ultimately I think that managing great developers is hard, and they are unlikely to stay with your company for a long period of time. However they are rarely available, and for a few years, they might jump start the evolution of your software, and potentially build something that makes your software great. I’d always have an open spot in my team for a great developer, and hire them as soon as they came available, if I thought they would fit in well with the rest of the team.

    Steve Jones