Voice of the DBA

Category: Editorial

  • Better Comments

    I assume most of your comment your code.

    Well, you probably comment code most of the time.

    I’d bet your comments have quite a bit of detail.

    And you do this completely inconsistently.

    That’s what I’d think, or maybe just what I want. Even the best developers I know will not consistently comment code. You can drift through any project on Github and see this. Those projects on GitHub might even be better documented because people know they are public. In most corporate environments I have worked in, I’ll find that when people get busy, or distracted, or even when they’re experimenting to find a solution, and they don’t write detailed comments. Usually only when someone fixes a bug, with a solution found quickly, do I get a really useful comment.

    There are all sorts of ways that people think about commenting their code. I ran across a post from Annette Allen about adding comments. She noted that she has headers in her stored procedures and other comments. However, after a few months, she wasn’t sure that the comments actually helped her. I’ve had that same feeling at times when looking back at comments, both mine and others.

    Do you have a method for choosing the words you use to comment code? Jeff Atwood says to comment on why you did something, not what. I’ve seen that before, especially with version control commit comments. We often can look at code to determine what it does, and if you use a VCS extensively, then you can always see the changes that were made between versions. The comments typically give me some rationale for the work I did. Over time, I find that if I think about how I’d explain my reasoning to myself in the future, I come up with a good comment.

    You might feel differently, and if so, please let me know. Perhaps there are some good ideas you have about choosing comments, and perhaps you have examples. Some might include a bug or Jira number, which I like, but others may hate. These could be comments inline in code or those you use when comimtting to a VCS.

    Share some thoughts today, and if you have any entries for the best code comment, drop them here.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Get What You Pay For?

    Many items that we choose to buy have some relation between the price and the quality of the item. We often find that a more expensive appliance or automobile has better quality than a cheaper one. There’s certainly a point at which spending more doesn’t necessarily get you better quality or even value. This seems especially true today with many “over the top” products that have added features or design that don’t seem to be worth the additional cost. At the other end, there are times many of us pay less for less quality, consciously making that tradeoff. I also think that the base level of quality has risen for so many products that it might not be worth spending more than some amount for an item. They’re all close in value and performance.

    I ran across a piece that looks at the value of consumer and enterprise SSDs. This isn’t a scientific analysis, but rather a short discussion of why enterprise SSDs might be more than twice as expensive as consumer ones. There are some details, such as the architecture and spare capacity, but ultimately the author notes that people purchasing drives also worry about the perception that they might have saved money with a cheaper drive, but lost data because the warranty and support are lower. Even if the same hardware were being sold by the vendor, which I’m sure happens, having enterprise support is a crutch that can provide the employee some protection if there are issues.

    There certainly are hardware differences for most devices, though the buyer should beware and verify that they are actually buying enterprise level gear. The big difference for me is that the large over provisioning of enterprise devices offers more predictable performance sustained over longer periods of time. This is important, especially for databases that might get quite a bit of transaction log or tempdb activity. In those cases, we need sustained high rates of I/O.

    There are no shortage of white papers, articles, reviews, and vendor claims about their particular hardware. This is a very competitive and also highly profitably space. If you’ve had to purchase a new SAN device at any point, you know these are expensive and complex. Making the decision is stressful as it can take lots of time ot evalute, lots of resources to get things installed, and so it’s not easy to go back on the purchase. In addition, many of us that have to make a recommendation are usually asking management to spend 6 or 7 figures on a device. If it doesn’t perform, we will take the blame and may find our choice to be career limiting.

    I don’t envy anyone that needs to make hardware decisions for their database or organization. There are so many companies in the storage space now that it’s a large project just to evaluate the various products and try to make a decision. It’s complex enough these days that I can see why moving to the cloud is attractive for some. While we can’t control everything and we may have large monthly bills, we typically don’t ever have to face that extremely large capital purchase decision.

    Steve Jones

    The Voice of the DBA Podcast

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

  • SQL Server Tuning Skills

    Performance tuning a SQL Server instance, database, or even query is a skill that most of us could improve. In fact, I see that the query performance presentations are often the most popular learning items at any event. I’ve seen quite a few people asking for more tuning talks in different areas, which is a good thing. I think most SQL Saturdays could schedule a different tuning session every hour, or even repeat the same one a few times, and the room would be mostly full each time.

    Learning to look at the various possible problems in a SQL Server is both a science and an art. There are good methods, such as waits and queues, for examining where an issue occurs. There are basic techniques for looking at execution plans and then making changes to indexes or T-SQL. There are different options for queries, SET values, and more that will affect your query or even all your queries.

    Sometimes it seems there might be too many options for a beginner to decide how to begin examining a system, especially one that is having issues. I can’t cover all of the issues in this short piece, but I can give you some guidance that might help. First, make sure that you know how to gather information about your issue. We have forums at SQLServerCentral to answer your questions, but you have to do some work. Gail Shaw wrote a great piece on how to post performance problems.

    Ultimately, you need to understand the recommendations that we may give. It’s helpful to learn about indexes, and the differences in the various types (including Columnstore). You should also have a baseline so that you can measure the impact of your changes. How do you know the problem is fixed? Maybe the user gets lucky with a quicker experience when you tell them you’ve changed the system, but will they call again soon? That second call might be worse than the first one. Even getting a baseline of the poor performance now will help you understand (and prove) that the system is running better.

    You also need to understand what not to tune, and which items to ignore. I thought quite a bit about this after reading Paul Randal’s post on wait types to ignore. This is part of his 101 series, which are a good way to start improving your skills. Performance tuning takes practice and knowledge, which takes time to acquire. Even if you’re fighting a problem today, try and learn a little something about how you get your system to run better.

    I’d also recommend that you look to continue your education over time. Take advantage of those sessions at local events, like user groups, virtual groups, and SQL Saturdays. Take advantage of pre-cons at larger events, which pack lots of learning into a few hours. If you go, take a paper pad, not a laptop, and take lots of notes. If you can’t get away, maybe you can lobby for some tuning classes from sqlSkills, Brent Ozar Unlimited, or even self-paced courses on Pluralsight.

    Learning to become better at tuning is an ongoing process, and one that requires some investment. Perhaps some money, but definitely some time and practice are necessary. Don’t let this be a daunting task, but one that’s a journey. Your goal is to get a little better each time you work on this skill, not to be an expert that knows it all. I’m not sure anyone gets to that point, but you can become as good at this skill as any of the presenters you watch. It might take you longer than it took them, but you’re also able to build on their work and learn from their knowledge. Take advantage of that opportunity.

    Steve Jones

     

  • The Journey to DevOps

    Netflix is one of those companies that I find amazing. I was an early subscriber to their mail DVD service, and thought it was amazing how they processed both orders and physical objects with technology. As they pivoted to streaming, I continued to be impressed with their technology growth, from the chaos monkey to their DevOps deployments. They have been an organization often looked to as a model for other technology companies.

    I certainly think there are things to learn from Netflix, as they’ve scaled and build quite a resilient system. They aren’t necessarily worth copying, however, as the problem domain they solve is both narrow and also quite different than that many of us work in. If someone can’t watch a movie, it’s annoying, but they can pick another one. If a customer can’t transfer money, communicate with another user in an app, or schedule a ride, it’s a bigger deal for other problem domains.

    Still, Netflix didn’t build this system overnight. They didn’t come up with amazing DevOps techniques for building and deploying their software from the beginning. It’s been a journey, and they talk about some of the full cycle developer challenges in a recent blog post. This looks at one team’s journey across 6 years, from 2012 to this year. The piece is an interesting read, and it’s not advocating for their particular approach, but rather trying to explain the value that they received from moving to a DevOps model, where they have a group that must run what they build.

    As I try to help customers and clients move to Database DevOps models, I see lots of similarities to what’s in this post. As we look to optimize the entire software development life cycle, this requires a changing of roles and closer cooperation between groups. As I look at the evolution of Netflix, using a centralized group to build tools and then ensuring you have a better staffed development team that works to both build and support their software, ensuring clients get the value (or features) they need quickly.

    I’ve worked in orgs that did this in groups, and for the developers to be involved in operations is an eye opening experience. Developers will learn ensure they think about their design and test more because they don’t like getting woken up. They listen Operations and learn about the ways in which they can better build a system that works. They start to realize “works” is a feature, perhaps the most important one.

    I’ve also found my role as a DBA can facilitate DevOps. I’m often between development and Operations, with a foot in both camps. I help developers build better tools and techniques to work with databases. I understand the impact on production databases, meaning I can help ensure that deployments are smoother, and we avoid risky changes. We build indexes early, install primary keys, test queries for performance, and more. The DBA is the one of the ways in which DevOps can grow in an organization, if they work with the developers instead of against them.

    Steve Jones

    The Voice of the DBA Podcast

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