Voice of the DBA

Tag: DevOps

  • Finding Bad Queries

    T-SQL Tuesday #200 was in July, hosted by Brent Ozar, and it was a great topic: How do you recognize a bad query? In the age of AI, when lots of people will get queries written by others (people or AIs), how can you easily and quickly review code? Review is already a challenge in the software world, and I am sure it’s going to be even more challenging as people let machines author more database code.

    Lots of you might hope that an AI agent will write better code than your average developer, but I don’t know if I’d count on that. There is a ton of poor query examples on the Internet and that’s where AI models are trained. You need some sort of feedback loop, good testing, and strong guidance if you want better query code. I think it’s as likely as not that AIs will produce poor queries just like humans.

    Just faster.

    How can you recognize poor queries? How do you judge if there are issues? Brent’s roundup shows what a number of people think, and there are some good “quick checks” to use to evaluate your code. The things that people wrote in their blog posts are the types of things that I’d want added to Flyway’s Code Analysis rules to catch problems before they get deployed to production. After all, anything that gets to production usually lives for 10 years (my rule of thumb).

    Getting feedback early in the development process is critical. We know from over 50 years of software development that finding problems early is less expansive than finding them later. Whether we use humans or AI agents, we don’t want unnecessary time spent on simple bad code things that we know cause issues. Shift-left is still a challenge, even in the automated era of DevOps and guided AI agent skills. We need reliable, repeatable ways to analyze code and limit the downstream effects of poor quality.

    Especially these days, where the volume of changes is overwhelming CI/CD systems. This was a problem already in organizations with too many teams in one codebase. It’s a growing problem in more organizations as users use AI and submit more changes.

    Plus wasting time gets expensive. Human labor is slow and spending time on more tokens for rework gets expensive.

    Don’t let bad queries flow through to CI/CD systems if you can avoid it. Learn to provide quick feedback early to whoever, or whatever, writes your SQL.

    Steve Jones

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

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

  • Working Better Under Pressure

    One of my colleagues wrote a great post about DBAs and developers, about how a DBA’s pushback on bad code isn’t to be difficult, it’s because they can see the future. I never thought of myself as a modern-day Nostradamus, predicting the future of system performance. Apparently I had another title besides DBA.

    Working under pressure and with short deadlines often leads to short cuts. I’ve made them. I’ve implemented quick hot fixes. I’ve forgotten to port changes back to development databases. I’ve increased our tech debt load, just to solve a more immediate problem.

    The challenge is cleaning things up later, when we have more deadlines and things to fix. It seems that we never have enough time to do the job the way we would like, and there’s certainly no time to go back later and fix things. Most management won’t make this a priority until things get so bad that we have to rewrite a lot of code (which we should never do).

    DevOps, pipelines, automations, and yes, AI, helping can reduce some of the tech debt we create if we use those tools appropriately. Which is a big IF. Often we have more immediate pressures that prevent us from finding time to invest in our systems or in ourselves.

    Getting a handle on bad code, checking it early, and doing so every time with automation can help prevent some of these issues, even when we are in a hurry. That’s why it pays to adapt our work and learn from others. Listen to that DBA that keeps your systems alive. Listen to the DevOps engineers that want you to automate things. Certainly, make them prove their suggestions work, but adopt those patterns. Learn to work with them, rather than against them.

    They can see the future.

    Steve Jones

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

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

  • Multiple Deployment Processes

    We had a Simple Talks podcast recently where we discussed roll forward vs roll back. You can watch the episode and listen to our thoughts, but one interesting place was when we talked about deployments. Grant mentioned that he deployed from version control/source control at a previous employer. I asked him whether he did that for every system.

    His response: “Well, …”

    He admitted that most, but not all, databases came from a controlled source. There were some systems that had a more ad hoc change process. I wonder how many of you have consistent processes throughout your organization. I suspect not many of you do, especially if an organization isn’t small. Often, different groups and applications are in a constant state of flux, with lots of different processes and protocols.

    Some groups are more mature and have stable staff who expect to deploy changes in a certain way. This might be on a known cadence, with documents or processes in place already. Others applications might have been developed quickly; perhaps they are newer and use more automation to deploy changes. Some might even use things like packages from an ORM or a vendor that takes control of database changes away from anyone managing the database. Does anyone deal with Spring Boot and very optimistic developers?

    I wonder how many of you have a consistent process for promoting database code to production across all your teams. Maybe 80% is a better metric, as this accounts for those groups severely limited by legacy technology or those that might be experimenting with new ways of working.

    Even those companies that have platform engineering groups in place to ease the flow for both developers and operations often aren’t consistent throughout the organization. Often, getting everyone to adopt a standard is hard and takes time.

    That might be the biggest challenge with standardizing database deployments: time. Organizations grow and change, new technologies come, and by the time we think we’ve gotten everyone to agree to change, who everyone is has changed. We have someone or something new, and we’re forever chasing standardization. Even when we might have a great DevOps process or a platform engineering team for software, we don’t do this for databases.

    I believe having a consistent, standardized process is a worthwhile goal, but one where 80% success is probably good enough in most organizations. If you can get most teams to follow the same process, you’ll increase efficiencies and ensure a better software development life cycle.

    Steve Jones

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

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

  • 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.