Voice of the DBA

Category: Editorial

  • Choosing Your Tasks

    This editorial was originally published on May 13, 2011. It is being re-run as Steve is out of town.

    I have been working for SQLServerCentral for nearly a decade. I started in 2002 and in that time I have had to define my own job most of the time. Early on Andy and Brian had a list of things they thought I should be doing, and there were certain things to get done each week, but it was a general list.

    This Friday I thought this was a topic for a good poll. Answer this question:

    What percentage of your time is self-directed?

    By self-directed I mean the tasks that you choose to do because you think they need to be done for some reason. This is opposed to the specific tasks that someone assigns you and gives you some deadline for finishing. If someone asks you to “tune the server”, I don’t consider that a specific task, and you would have to pick items to work on, and determine how much time you spend on them, that’s a self-directed task.

    Do you have a good amount of self-directed time? When I used to manage a series of production servers, I usually had at least half my time as self-directed time. I could look at poor running queries, contact groups with proactive ideas for improving performance or preventing problems. I even had time to schedule DR testing. That took a lot of investment over time. I had to understand each system, set up monitoring and standards, build in data capture and analysis routines, and of course, plenty of alerting mechanisms.

    I think that a great production DBA will have a lot of self-directed time after 6-12 months on the job. A development DBA, however, will likely be constantly responding to code requests and enhancements, which is one reason I prefer the former job.

    Steve Jones

  • Aging Software

    I wrote The Age of Software awhile back and noted that supporting previous versions of software isn’t necessarily a good use of resources for development teams. I especially think this is true of SQL Server. But does that mean we should abandon aging software platforms?

    It’s a tough question. I’ve certainly talked about the case for upgrading, and the reasons why you might not. For any particular instance, however, I think that each of you has to make the case about whether the software works, or it doesn’t.

    If it works, then it seems many of us will live with the old software and keep it running. As late as a few years ago I knew a company running SQL 6.5 with a piece of software built in 1996 and last patched in 2001. However this software ran a building key card system, and there wasn’t a good case to be made for upgrading.

    For a software developer, however, when you look at aging pieces of software, even those that customers may pay for support on, is it worth maintaining skills and support? If you don’t have staff turnover, then perhaps. If you don’t, I do think that it might be time to let the product die.

    I’m torn on the way we deal with software in our world. On one hand, I’d like to see customers given source code for end of life platforms in order to support themselves if they wish. On the other, I understand the IP concerns, and business case to let software die.

    Ultimately I’m mostly OK with the current way most vendors support software. If it works for a decade and support ends, I can continue to use it. Until it doesn’t work, and then I am glad that most vendors have an upgrade for me.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Querying Yesterday

    One of the new features coming in SQL Server 2016 is the temporal table. It’s an interesting concept, one that many businesses have wanted for years. If you’re not sure what this is, we’ve got a collection of resources on Learning about Temporal Tables (and other features). Check them out and we’ll keep adding content as we find it.

    Temporal tables give us some amazing capabilities, but at a cost. As with anything in computers, there is a cost for capability. In this case, we can look back at the view of our data as of a particular point in time. In many ways, this means that we don’t need to bolt on, or query into, auditing data.

    However there are other costs. As with any auditing system, we potentially have substantial data that we need to manage somehow. Certainly we need to choose which tables to track. Even if we don’t have to build a process, we will have to deal with the cost of storage and provisioning, as well as determining the retention periods. We also need to really depend on the system times for our various instances to be in sync.

    I think that this is a needed, and very useful feature. I’m sure there will be bugs to patch, as well as enhancements to be built. We’ll find those over time, but I think that this is one of those features that we’ll come to see as essential in a decade and wonder how we ever built systems without it.

    Steve Jones

    The Voice of the DBA Podcast

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

  • What’s a Code Smell?

    We all have a variety of code patterns and practices that we follow. Most of them were probably picked up along the path of our career. A suggestion from a colleague. A piece of sample code that solved a problem. A performance tuning trick that stopped our phone from ringing. These methods of learning are the way that most of us actually grow our skills over time.

    However just because we learned something, or because a technique solved a problem doesn’t mean it was a good piece of code. In fact, often the code we may think works well might not be the most efficient way to structure the code. Many developers have learned this over the years, as they read about new techniques that are more efficent, elegant, or just simpler.

    Kent Beck and Massimo Arnoldi coined the term code smell years ago, as a way of noting the development patterns and practices that  lead to poorly written, or difficult to maintain code. There have been other attempts to document practices which are not recommended, though the success is probably limited as many developers continue to build on poorly written code rather than refactoring and cleaning their codebase over time.

    Simple Talk  and Phil Factor published a SQL Code Smells ebook awhile back, trying to document the signs of poorly written T-SQL. The book is good, with guidance about particular patterns that can cause you problems over time. The items aren’t meant to be rules, but rather guidelines that you adhere to unless you have a good, specific reason that you can justify to others.

    I ran into a code smell recently where a developer noted that their application depended on a specific database name in order to work.  That’s not in the ebook, but I think it’s easily one I’d avoid. My connection should determine the database, not the application itself. I know there may be exceptions here, but in general, application code shouldn’t be dependent on a particular name.

    I’d urge you to pick up the ebook (it’s free) and keep it handy. See if any of the items listed are habits you might have picked up over time and not realized that they are, in fact, poor practices. I would also recommend you peruse Aaron Bertrand’s Bad Habits to Kick series, as a way of improving your own code.

    Steve Jones

    The Voice of the DBA Podcast

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