Voice of the DBA

Category: Editorial

  • Very Hot Patches

    “At best it would crash” is not a phrase I’d like to have to use as a data professional. That’s a quote from an article that the Azure team wrote about hot patching SQL Server. While this sounds very scary, it’s actually something being used now to patch the SQL Server code running Azure SQL Database.

    Years ago I read a book where the hero was a programmer that had to alter and hack into live code on a mainframe, making changes to thwart the villains. It was a neat concept, and certainly daunting. As someone that had to write assembly code at one point, I had trouble keeping track of instructions when I could map them out on paper. Doing this on live code would be very scary.

    The SQL Server code is not being changed live by a human, but code is being patched without stopping the sqlsrvr.exe process in Azure. There is a blog on the hot patching process, which I appreciate, though I’m not completely sure I get the minute technical details. Still, it’s an impressive feat of engineering to me, and this does make me wonder to what extent platform engineers might structure their code to allow more of this in the future.

    Deploying changes is already a challenge for many of us with database code. Making changes, evolving our schema and adding functionality without downtime or excessive blocking is a challenge. Many customers that look to move to a database DevOps software development process often assume that our tools will just do this for them. They won’t, because any DevOps tools that help with automation don’t magically get around the limitations and restrictions that Microsoft has built into the platform.

    Making changes in real time, without interrupting workloads involve some engineering challenges, but whether at the SQL Server platform level or the database code level, they are possible. It takes some work, some flexibility, and more importantly, some understanding of how changes can be made and the patterns that enable uninterrupted changes. There is often a space and time trade-off, and certainly no magic, though to our customers, it might appear that way if we do our jobs well.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • T-SQL Context Switching

    Studies have shown that reading someone else’s code can be both stressful and time consuming. Developers that pick up unfamiliar code find themselves spending much more time comprehending the code than with more familiar projects. I think this might be one of the reasons that so many developers want to build things themselves from scratch, or in least build new things in their team. They find their own code easier to understand.

    This might be less of an issue with SQL code, which is often more straightforward for simple queries, but I  do find that complex queries can be confusing to many developers if they didn’t write the code. This can especially true when another developer has used some rather uncommon trick. I’m also sure that plenty of people will cut and paste solutions, from places like SQLServerCentral, without understanding how the code works, but even decoding the answer to a question you’ve asked can be hard, even if another poster tries to explain how the code works. Hopefully most developers make an effort rather than coding a poorer solution or deploying code they don’t understand, but I’m sure some don’t when facing their own pressures to get work done.

    With staff turnover and the need for developers to work on multiple projects, time spent interpreting code can be a drain on the efficiency of all developers. In addition, since individuals often find code easier to read in certain formats, tools like SQL Prompt can help, but there are plenty of easy ways to keep your codebase readable for staff. Dr. Greg Low has written a nice post on standards, which I think outlines some of the things I like to implement in a team. Having a known way to structure our code can help us communicate intuitively in a group, rather than require extra communication.

    Actually, I don’t care what standards exist in a company. I don’t have strong feelings about any particular way to structure code. I prefer spaces, but if we decide on tabs, I think that’s fine. I’ll work within the framework we’ve built. What I do think is very important is that you have some standards. They don’t have to be perfect or exhaustive, but they do need to be followed.

    If you don’t have standards, I suggest you start creating them. Add them as needed, when a developer finds a reason to make a decision, get consensus from the rest of the group and document the standard. Like other things in DevOps software development, we can grow these over time as we need them.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Republish: Documenting with Tests

    I’m at SQL in the City Summit – Sydney today, likely loaded on coffee to get through 2 days down under. In any case, you get Documenting with Tests

  • Live and Learn

    I love this quote from Randolph West: ” Listen to people. Have strong opinions, but loosely held. If you are wrong, admit it and move on. Learn from those around you.”

    This is from his blog on diversity, which I support and agree with. He has some great thoughts and the post is worth reading. Maybe you appreciate diversity, maybe you don’t, maybe advocate for or against it, but in all those cases, I think his message is worth reading.

    I am not going to talk about minorities or ethnic groups here, but rather diversity of thought. That first quote could apply to software development in general, and certainly the idea of a DevOps process for building applications. It’s good to have strong opinions, and good to be able to debate and argue them, but it’s also good to keep those strong opinions loose. Many of us find as we get older and more experienced that we often have a huge gap in the things we don’t know that we don’t know.

    These are the unknown unknowns, as opposed to the known unknowns, which are things I know I don’t really understand. I’ve remarked to a few people that learn new things every week, and I feel stupider every week. Why? I learn things I never knew existed, so I constantly expand the knowledge of my own ignorance. It feels like I learn two things and then realize there are nine more new things I don’t know anything about.

    Today’s software requires a team. Maybe more importantly, today’s software requires a team of both application and database developers, as well as infrastructure staff, that can help put together an entire system. We need to work together, not independently with hopes of efficient integration of our ideas later. We want to shift left, and coordinate and communicate earlier. That needs strong opinions on how to best do a job, but a loose grasp on those as we might need to adapt to work with others.

    Read Randolph’s blog twice. Once thinking about the topic of human rights, and then once more thinking about teams and our opinions on building software. It’s thought provoking and worth a few minutes of your time.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.