Voice of the DBA

Category: Editorial

  • A Full Shutdown

    I have the opportunity to work with a variety of customers on their database systems, often with the focus on how they can build and deploy changes to their databases. Often, they have a process around how and when they make changes. Some have maintenance windows, though often these are approved times for changes rather than a true window during which a system is shut down.

    I ran into a customer recently who scheduled a system shutdown for their deployments. This was a surprise to me in 2026, as I thought most people would have learned to deploy changes to live systems. However, I know that many teams make changes that would render portions of the database inaccessible for a period of time, so maybe that’s not true. Maybe they just make changes and deal with the impact on clients.

    I wanted to ask this question today: Do you shut down your system completely for a deployment? Not all systems, but the one you’re patching and possibly a few related ones, while preventing client access?

    Or do you have to make changes while the system is still in use?

    A lot of DevOps analogies revolve around the idea of cars and performing maintenance or improving them. One that I like is learning to replace all the parts of the car while it’s still running and in use. That can be hard in the real world, but we can often find ways to do this in software, including with databases. A little creativity can go a long way.

    I love watching the evolution of Formula 1 Pit Stops as a way of visualizing the problem. This video is kind of amazing, but it shows the power of thinking about a problem and finding ways to improve it. In the 50s, pit stops could take 45-60 seconds or longer. If you look at the video, in 1990, they dropped this to less than 9 seconds. That seems amazing, but the power of continuous improvement shows this dropping to 7s in 2000. In 2010, 4 seconds. Then in 2020, 1.82 seconds for 4 tires changed.

    This is still a full shutdown, albeit a few short one.

    I constantly deal with people who think that they cannot find a way to make deployments easier, faster, or less impactful. I know that car racing teams used to feel that way about their pit stops. Once they tried to creatively work on their challenges, they found solutions that are truly amazing. Using new ideas and tools, they reached speeds no one could have imagined a decade ago.

    I bet many of you can do the same thing to your databases with an open mind and a little tooling.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Not Just an Upgrade

    Upgrading my database server and moving from version 6 to version 7 because of a support cycle has always felt a little funny to me. In many cases, I’ve had systems that were running smoothly and performing as needed. If people were complaining, often this was because of a lack of resources, where we needed more hardware. In other cases, this was a lack of quality code, often from other developers who were unwilling to change their approach. In neither case was an upgrade likely to change anything.

    However, an upgrade can be more than just buying new license and accessing new features. I was reminded up this by John Sterrett, with a post on how he talks to CEOs about upgrades. The upgrade isn’t just a new database server. It’s a chance to re-evaluate the system and consider something besides the application.

    In the list, John looks at this as a cost, security, and compliance decision. These days, Standard might be a better fit than Enterprise and can save on licensing. Better security can lower risk and potentially prevent issues. Being out of support, which is going to happen 3 times in the next 3 years, can be an issue for some companies. New features might reduce the costs of maintaining existing systems.

    I don’t know that this list would have made a lot of sense in the 2000-2005 timeframe, or even in the 2008-2014 range, but it might now. There are considerations beyond just the license cost. Certainly I’d be re-examining my Standard v Enterprise choice in many situations and perhaps using this argument as a reason to press developers to learn to better structure their data models and write better queries. Lowering the resource usage can lower costs. Even archival might be something I’d press on, as less data is less data to query, and honestly, are those old records in tables truly adding value?

    Or are they muddying the waters of analysis?

    Better security matters, and I do think modern auth systems are better, but often this might require a security change in other parts of the org, and still might require application redesign to account for a directory authenticating users. That might be entail its own costs and not be worth effort.

    I don’t think upgrades should be automatic, and I am a fan of running a database server for ten years, but I also think that running one for 20 years might be a bad idea. Upgrades ought to be approached with the rational, logical view that this is an opportunity for us, but one that we might choose to take advantage of or pass on.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Writing as an Art and a Job

    I remember listening to an interview with Rick Reilly in the mid 2000s. He was the back page columnist for Sports Illustrated for years as well as a writer in various pieces. He talked about how he would lay on the couch in his office sometimes, trying to think of what to write. His kids would come in looking for attention, but couldn’t understand that Dad was “working”.

    I had been writing the editorials at SQL Server Central and I could relate. Moving from 2 to 5 (eventually 6) editorials a week was a lot of work. It was stressful in a way I couldn’t imagine when I started writing them. I quickly realized that if I had to produce a new one every day, I was in trouble. There would be days I’d struggle. I needed to have a queue of pieces at least partially ready if I were going to manage this job and find balance with my family.

    Recently I was listening to an interview with Lee Child, who writes the Jack Reacher series. He said that writing is both a creative endeavor and a job. It requires some inspiration and time, but it also requires you to buckle down and get to work. This is an area where delays are inevitable (everyone gets writer’s block) and if you aren’t thinking ahead delays will occur. Delays aren’t great for newspapers or other scheduled events.

    SQL Server Central became a newspaper.

    One of the things I did early on was start to enhance my powers of observation. There’s no magic here; it’s really a habit to look at things in your life in a different way. For me, this meant considering each question posted on the forums, each bug reported in SQL Server, each complaint/criticism/success through the lens of both telling a story and generalizing the wider issue.

    I learned to write about what I experienced by seeing the experience as a source of inspiration.

    I started keeping notes. First in a text file, then OneNote, then Evernote, and today, Joplin. As I would see something interesting in the world, I’d make a note, copy a URL, write a sentence or two. I then regularly go back and flesh out these ideas and add to them. It’s similar to the recommendations I make for blogging: make notes, expand those later.

    The job part of this was making time to write on a regular basis. I used to try and write every day. I had some success, but I also learned some days I struggle to articulate my thoughts. Rather than struggle, I learned to just abandon the effort and go do other work, or sometimes, go to the gym or get away.

    The flip side of that is that when I feel the writing is flowing, I write more. I don’t stop after one editorial (or blog) and I’ll try to tackle another one or two. If I struggle with one topic, I may find another easier, so I flip through notes and keep trying to get another one when I am in the mood to write. I sometimes find I can write 3 or 4 in a day and then not do much writing for another few days.

    Many of you reading this do technical work. You work on systems, or in code, or both. However, the world is changing. I started this piece with the 25th anniversary of SQL Server Central in mind, but really, AI is front of mind. I’ve had 3 conversations today about AI stuff, and the one thing that stands out is communication and clearly expressing yourself if crucial to getting AI to work well for you.

    Learn to write better. It helps in your communications with humans and with AI LLMs.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Rollback vs. Roll Forward

    The Advocates at Redgate Software had an interesting discussion about deployments in databases and how you go forward or back from the point at which you discover a problem. You can watch the episode, but a few things occurred to me while we were having our discussion.

    The first thing is we all agree data makes things hard. A database is a stateful object, and dealing with stateful objects is hard. That is one of the things I’ve internalized the last few years that has tremendously changed how I work with Redgate customers. The more I consider state, the more I am able to work with the challenges that databases bring.

    The second interesting thing from the episode for me was that each of us had a tendency for what to do. Do you tend to aim to get to a previous state or move to a new state? Each of us had a preference.

    I think lots of us aim for a new state, mostly because we’re optimistic about our ability to “fix” the broken thing. I also don’t think this is a DBA, engineer, or technology thing. I find lots of people in the real world making mistakes and thinking they can do a new thing to fix the situation. Mechanics, lawyers, doctors, plumbers, they all think they can roll forward to a new state.

    What’s occurred to me is that the people I know who are very much in demand for their skills and expertise are often the ones with a tendency to roll back to the previous state. They acknowledge the mistake and undo it. I’ve seen people in construction and other professionals also try to go back to the previous state when they realize they are in a situation where their fix didn’t work, and they abandon that plan.

    In the DBA world, we might prefer this even when our deployment caused data changes. We often will save data, roll back, and then decide what to do. This often means reconciling data, which isn’t a fun task, but a necessary one.

    Watch the episode and decide what your tendency is for adjusting for changes. Do you think about patching the issue and rolling forward? Or do you want to roll back to a known state and re-test our changes in a lower environment.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.