Voice of the DBA

Category: Editorial

  • Make It Routine

    The first one is hard. The rest are boring.

    I heard this statement from someone recently, and it sounds like something a technical person would do. It’s been a goal of mine, or maybe a direction to aim for, though I sometimes think that goal is more aspirational than actual. It can be hard to do that for every task.

    The first time I tackle something, it should be hard. It’s new work. It’s a new process/code/thought/action/etc. It’s unfamiliar, and I spend more time on it than I want. After that, I’d hope I could repeat the thing again in much less time. That’s the goal, and that’s what we aim for in a lot of DevOps work. Make the things we think are hard, less hard. Make them boring by codifying things, using automation, and have the computer replicate the task.

    I think the second one is often hard as well. How often have you tried to reproduce something you did and can’t quite get it? Heck, I now depend (and use) SQL History constantly because I will write some code, change it a bunch and then realize that I can’t reproduce the version that did thing thing (or broke the thing) I was working on. I need to rewind things and figure them out again. Usually by the 4th time I’ve done something, it’s starting to become easier. By the 10th its boring.

    Unless I’m playing guitar, in which case, some things take a few more reps than 10.

    I’ve had plenty of developers say never repeat yourself. If you can automate it, you should. In practice, that’s hard. Sometimes I’m unsure of whether I’ll do something again, or often enough to spend the time automating it. There are also times I’m not sure it’s worth the effort. I spent a day once trying to automate a bunch of Outlook appointments, only to realize the whole Office API and deluge of information out there made this much harder than the 15 minutes a year I spend putting in all my Database Weekly reminders.

    I don’t want to discourage you from automating things and making them routine or boring. My database deployments ought to be routine. The daily checks should be so boring and automated that I don’t bother with them because I know the machine is doing the work and will let me know if there is something I should examine. The efforts to refresh dev dbs, or respond to audit requests, or even reset a password ought to be boring and easy. Some of us build ways to smooth these tasks and ease our jobs, and some of us treat every one as an ad hoc thing that we do over and over.

    The stuff you do over and over is going to be handled by AI at some point (maybe soon). Maybe soon, maybe in a few years, but a lot of simple stuff that you keep doing- that mindless, tedious stuff that doesn’t require a lot of thought – is going to be handled by AI agents. Either you’ll direct them, or your boss will ask someone else to do it after you leave. AI can handle things like figuring out when disks are full and cleaning out old log files, shrinking databases, archiving things, and then writing scripts (and scheduling them) to prevent issues. If that’s your job, your days are numbered.

    Make things routine by thinking about the pattern, how we could reduce or eliminate a lot of labor, and how we can use a computer to handle them. Even better, learn how to guide an AI to do that work and prove your worth.

    Steve Jones

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

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

  • Another Model, More Data Loss

    This past week I saw an article on eWeek that the newest OpenAI GPT-5.6 (Sol) model has deleted local files and live data. Files I’m less worried about, but data concerns me. There are lots of file backups, and certainly version control should be enabled for any developer tasks on which an AI works. However, data is harder, since it can change quickly, especially in live environments.

    There are different reports, some of which seem like more human error issues than the model’s, but we should account for human error when we use models. In one report, a model had access to a live production database and cleared tables for integration tests. Database testing is hard, as I’ve learned over the years. Many developers don’t think about how testing works with live data and how it is different from mocks and stubs. It is different, and if you use a lot of testing frameworks on live databases, you run the risk of there being issues. You could have data loss, and almost certainly will have some level of downtime disruption.

    This is a great reason why adding AI coding to database tasks needs governance around what is allowed. It is easy to have success with AI-assisted work and forget that these models can make mistakes. And if you trust them with too much, like you might be tempted with an impressive but junior DBA, you might get burned. These automated tools can get hyper-focused on a certain task, and not consider the ramifications of their actions. The article notes an agent ran “rm -rf” on a dev machine. That’s similar to what happened with Toy Story 2, where a human made the mistake. Both that person and this GPT-5.6 model weren’t thinking widely enough about what tasks they were managing.

    The article notes that this model can be overly persistent and assume actions are permitted unless explicitly prohibited. Not unlike a lot of humans who assume if someone has given them rights, they can do the task. OpenAI noted in an internal case that a user approved the removal of three VMs. When the coding agent didn’t find these, it looked for other machines and chose three other VMs. Crazy, but I’ve seen humans do this in the past.

    I don’t think these models are getting closer to Artificial General Intelligence (AGI) or that they are anywhere close to sentience. However, as they become more capable and handle more complex predictive actions, they are also likely to do the same stupid things humans do by not considering all the possible consequences of their actions. After all, we have plenty of data where humans haven’t considered the effects of their actions, and that data is in the AI model training set.

    Steve Jones

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

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

  • What is CPU Usage?

    I had a request from a customer recently who asked if we could give them a report of their database server instances and include CPU usage. This request was filtered through an account executive, so something was lost in translation, but I was confused and asked for clarification, as asking for CPU usage is kind of like asking how fast you were traveling in your car. There needs to be more context.

    If someone asked you for a report of CPU usage for a database, what would you expect? How would you report this? I’m sure the person asking might make a difference. A fellow DBA, your DBA manager, or maybe an executive could all view this differently. I want to know how things are performing, if there is a trend, or maybe if we are getting value for the hardware we’ve provisioned, depending on my role.

    If you were looking at your monitoring system, what would you look for? Redgate Monitor shows the last 24 hours of CPU with the last two hours in a focus window as the default, though you can easily change this. Perhaps you’d prefer this boiled down to min/max/average values over a time period? If there’s something else you’d consider, let me know. Maybe I can get it added.

    Certainly, the values you expect might depend on what you are trying to measure. Is there an acute performance issue? Then you might worry about the spot values or perhaps the last xx minutes of trending CPU values. If this is capacity planning, then peaks and average values can matter. If you are looking forward, you might even want longer trend lines and future extrapolation.

    Of course, the experienced DBA knows that other metrics need to be taken into account when looking at the CPU. 100% usage isn’t necessarily an issue if the workload isn’t creating unnecessary processes stacking up or too much latency in returning results. Perhaps the amount of memory used should be included to determine if there are CPU or RAM (or other) bottlenecks.

    There are a lot of factors that might go into how you examine the performance or efficiency of a database server, whether SQL Server or any other platform. A well-performing system has to balance lots of factors to meet the demands of a workload. A poor-performing system doesn’t do this well and often there are many more factors than how much of your CPU capacity is being used.

    The other thing this request showed me is how poorly many people communicate, and especially how much can be lost as a message moves from one person to another. This is an area where AI can succeed or fail as well. IF we communicate poorly with AI, we may waste time and money while receiving useless results. If we let AIs provide summaries to us, or from us, the model may choose to emphasize, highlight, reword, or hide things we think are important. After all, the model is predicting what should come next, not understanding the information.

    Communication is crucial and is becoming more important as we become more distributed and allow technology to sit between us.

    Steve Jones

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

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

  • Republish: IT Staffer Fired

    It’s a great title, and it’s one many people have worried about in their careers. I know I have, and I decided to re-run IT Staffer Fired today. Leave me your thoughts as you re-read this in today’s world.

    It’s a vacation day for me. It’s actually my June-teenth holiday day. I had to work that day and do some recordings, so I flexed it to Jul 20. I was at Day of Data Baton Rouge over the weekend, and my wife came with me. We decided to take a few days in New Orleans and get away from the Colorado heat. It’s still hot in NO, but we can relax, hang out by a pool or in the AC.

    Enjoy Monday and see you tomorrow.