Voice of the DBA

Tag: AI

  • Are You Working More Hours?

    Recently, I noticed my son was coming home later and going to work earlier. He typically works a 9/80 schedule as a software engineer, but at times he might work extra hours on a deadline. His company tries hard to keep employees working a set schedule without overtime. Unless there is a need, after all, this is software. However, when they are on a deadline, management warns people, and they try to manage overtime to reasonable levels to avoid burning out employees.

    I asked him if he was extra busy or if AI was encouraging extra hours. He told me this was a short-term project with a few more hours, but mostly the team was decompressing a bit after work. I completely understood that as I’ve spent my share of time with co-workers at theend ofday, sometimes sharing a drink or meal nearby, sometimes just chatting in the office or the parking lot.

    There have been a number of studies and reports that AI is making people work more, not less. The time spent on a variety of tasks, especially those where we are reading or interacting with text, has grown. I suspect there is additional pressure from management as well to get more done since everyone has an AI assistant around. There is also the excitement of tackling new projects, which can lead people to spend more time at work. While I appreciate that AI can be exciting, and you might love it, don’t lose yourself in it at work. It’s still just a tool.

    And, of course, there’s the token spend. Some managers are measuring people on the amount of work their AI assistants do, rather than by what gets done. I’ve certainly seen plenty of people using AI to perform busy work just to be seen as using AI tools.

    At times, it seems people are using AI to process more information, which they then use AI to summarize. They post these summaries, which grow in number because the AI can produce more of them. Others use their AIs to read these summaries and produce their own summary of what they should be reading. It certainly seems like AI is producing more copies of information, summarized over and over, giving all of us more things to keep an eye on.

    That seems silly. While I like AI, I fall into that group that uses it lightly for targeted tasks. I certainly try not to create more reports, summaries, or even emails to send to others, especially large groups of people. We have enough to review without AI creating even more tasks to deal with every week.

    Steve Jones

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

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

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

  • Monday Monitor Tips: The MCP Server

    I have been experimenting with MCP servers in a few ways, and pressing on our Redgate Monitor team to add one to their system. They did, started adding tools, and are continuing to work. I’m excited.

    Here’s a quick look at the MCP server for Redgate Monitor (preview in July 2026).

    This is part of a series of posts on Redgate Monitor. Click to see the other posts.

    Getting Started

    I’m not going to bore you with the setup and configuration. You do need to be on a 14.23 or later as the version. Your account rep can get you setup instructions, which are still be worked on and finalized. This is really a work in progress as of this writing (Jul 30) and I’ve found a few things that didn’t quite make sense, so be patient. This is editing the Monitor Webserver config file and enabling this.

    Once that’s done, it’s a little tricky with an AI agent system. This is the high level, and I’ll do some more detailed notes about getting this in VSCode and Claude, where I work. The basic steps are:

    • Enable in Redgate Monitor
    • Create an MCP Access token
    • Add the MCP config to your Agent setup

    It’s not quite as simple as it sounded to me, but it wasn’t that hard. It’s mostly working through some of the steps and ensuring you get your JSON correct.

    Accessing the MCP Server

    I connected with Claude for the demo in the Video Walkthrough below, but I’ll give you a quick look here. I set my token for the prod/staging/dev systems. When I look at the test instance of Redgate Monitor, I see this: lots of servers and alerts.

    2026-07_0120

    Once the MCP server is added, I start Claude and run a /mcp. I see my server get connected.

    2026-07_0121

    There are a number of tools, which have grown since I started testing. I don’t have a complete list and anything I put here will be out of date in a week, so I won’t bother. In any case, I’ll ask for the production servers. I can see the various base monitors being queried. This is slower than almost any customer, since we have more BMs than most people here. Most have 1-2 at most.

    2026-07_0122

    Note: I did get asked for permission a few times before the tools were accessed. Since all MCP stuff is read-only now, I just granted permission for all sessions.

    Here are the results. Note the summary at the bottom.

    2026-07_0123

    I next asked this: which servers are in critical status and why. The Claude LLM interprets this and starts querying the Redgate Monitor server, using the token for security, and the tools, which are really the API of things that can be run.

    The results I got were what you see below. The LLM had to run a bunch of queries to get results and the read in those results and interpret them. In this case, there were a lot of different queries of tools to look for data. This probably took a minute or two, but it feels long while watching the screen.

    2026-07_0124

    I next asked about queries on an instance. I don’t know these servers that well, but I know there are workloads on some to simulate what clients see. I decided to ask about one of the 2019 instances in production. In this case, I got asked for permission for a new tool (I hadn’t run the top queries tool) and then the agent went to work. You can see the tool usage and results. In this case, the system was down when I ran this, and it let me know this was from before the outage.

    2026-07_0126

    At the bottom, there are some observations, which can be useful. I’ve got cursors running, XEvents, etc. Helpful to look at this for a system I don’t spend a lot of time examining.

    2026-07_0127

    Ultimately the MCP server is a way for you to use tools you use already, but allow them to query the data in Redgate Monitor.

    I’m excited to see where this can go, and how it can help customers interpret all the data collected by Redgate Monitor and more easily summarize it. This will be useful to some, though others of you might not like MCP access and instead stick with the internal AI tools.

    It’s up to you, but we are giving you the choice to work as you wish.

    Summary

    The Redgate Monitor MCP server is in preview as of July 2026. I tried to give you a short sense of how you can use this to query Redgate Monitor and keep an eye on your systems. There are lots of ways to work, and I’ll try to give some guidance on specific things over time, but for now this gives you a sense of how MCP works.

    I’ll do future posts that cover the config and help you get testing in your own environment.

    Redgate Monitor continues to grow and advance and MCP capabilities are a great way to start using AI to help manage a large database estate, with your own AI resources.

    Redgate Monitor is a world-class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

    Video Walkthrough

    Watch me use the MCP server live.

  • Building Your Own Software

    Lots of AI usage has been spent inside companies on building new software. Sometimes people are trying to rebuild existing software. I’ve seen more than a few articles say that Slack is dead (it’s changing), or Monday is dead, or some other SaaS isn’t going to survive because people can vibe code their own replacement. I know a few people trying to do this, with very mixed success.

    I saw this post from Jason Friend of Basecamp, where he noted that most products wouldn’t exist if everyone were an entrepreneur. This is because the great products exist precisely because an entrepreneur had a great idea and followed it through. They made mistakes, they learned, and they spent a lot of time getting the product right. The coding was likely a part of this, but the mistakes, the changes of direction, the decisions on what to add or take away, those are time-consuming things not shortcut by AI. The coding isn’t the big delay in lots of products. A great response to the post notes this: there are many decisions that go into a product. Many people don’t think about all those decisions.

    Certainly, some people will use AI and do a great job coding a replacement for some existing product. They’ll make their own version of a product, likely learning a lot from existing software. They will shortcut some design and testing time since they know what they want. It’s the software they already use, and they know how it works. They don’t need to design it.

    However, the software is just part of the process, especially in the SaaS world. Infrastructure and operations are big. While a replacement Slack might not need quite the level of hardware, networking, DR, disks, etc., it needs a lot more than an individual can build and manage. An LLM might help you determine where your bottlenecks are and help you build the systems needed to manage more resources, but it’s going to take time. Especially if you don’t know what sorts of hardware and bottlenecks will occur as more people use your software.

    It’s also going to make mistakes.

    Imagine your LLM gives you a piece of bad code that doesn’t perform. We can refactor and fix that. Now imagine your LLM doesn’t configure DR correctly. Fixing that is a little harder, especially if you don’t realize DR is lacking until an incident occurs.

    Software is hard. One thing I’ve learned over the years in advocating for customers’ requests in Flyway, SQL Prompt, or Redgate Monitor is that the coding takes time and effort, but much less than the decisions on what and how to build something. Those eat up time and focus. Once you solve these, AI definitely helps the rest go quicker, especially if you have AI building tests. However, until you solve the problems around coding, it’s not necessarily faster or better.

    Steve Jones

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

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