Voice of the DBA

Tag: administration

  • You Need a DBA Pipeline

    I work regularly with a number of customers on improving their database change processes. This has been the goal of Redgate’s Database Change Management over the years, helping database systems work more like application software with DevOps principles. The idea is to move quicker and respond better to demands, while providing safety and governance. A database is a stateful machine, which is a challenge to evolve and maintain, but with good data modeling, testing, code analysis, and automation, your database change process can coexist with your application software.

    That being said, most of the solutions for managing database change focus on the database itself and everything inside it. After all, that’s where the data is. I understand people wanting to solve that problem, but there are plenty of things that need to be managed for a database server (or an instance for MSSQL) outside of the database. We have security, configuration, and, in the case of SQL Server, jobs. That might be the number one request is a way to manage jobs across systems.

    Regardless of any tooling you might use, the important thing that you need is a way to easily manage and deploy the scripts you generate. These might be adding users or logins, perhaps rotating certificates, or something else. Clicking through SSMS or manually running things might seem like it’s quick, but that’s a governed way to manage tasks. You might update a Jira ticket when you’re done, but do you always capture the code you ran in the ticket? The results?

    For many tasks, this might not seem like it matters. If we make a mistake, we correct it, and no one needs to know. However, this doesn’t help you work more efficiently, nor does it help your team work closer together. If there are records of the code and results in a pipeline, then you have a trail of who, what, when, and how. The ticket should tell you why.

    This helps hold you accountable. It ensures you test more carefully. It gives teammates a place to go grab a script that worked and re-run it, perhaps changing the name of something in the script; this allows the reuse of work. This ensures that the work is routine.

    Many of us have made a career out of doing work manually, and we’ve gotten good at it. However, the future will require us to work in a team, one that may include an AI, and learning to build patterns of work that flow easily across humans and agents will be a skill that lets us both be productive and provide value to our employers.

    Steve Jones

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

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

  • Make It Routine

    The first one is hard. The rest are boring.

    I hear this statement from someone recently, and it sounds like something a technical person would do with a task. It’s often been a goal of mine, or maybe a direction to aim, that I want to make things easier with some script or automation. Sometimes I think it’s more aspirational than actual. I might want to make most things routine and automated, but that doesn’t always work out.

    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, have the computer replicate the things.

    I think the second time I tackle a task 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 the 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 over and over stuff is going to be taken over by AI. 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 disks are full and cleaning out old log files, shrinking disks, 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 to your employer.

    Steve Jones

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

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

  • Differences Between xp_readerrolog and sp_readerrorlog: #SQLNewBlogger

    I was creating a question on sp_readerrorlog and realized that this procedure is different from the one it wraps: xp_readerrorlog. This post digs into a few differences.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    The New System Stored Procedure

    For most of my SQL Server career, it’s been a habit to use xp_readerrorlog to query the log. This was code I learned a lot time ago, and it’s worked in every version of SQL Server. Despite being undocumented, as you can see below:

    2026-08_0381

    xp_readerrorlog has been written up by a few people at SQL Server Central, including Nagaraj Venkatesan and Ken Fisher, as well as in some forum posts (one, two). However, it’s not well documented. I usually end up Googling for the parameters as I need them.

    Until now.

    Here are a few differences I’m documenting, so I will hopefully remember them.

    Note: I got a few different results from AI, which were at best incomplete, and sometimes wrong.

    sp_readerrorlog has different permissions. This proc works with anyone that has VIEW SERVER STATE, which is sysadmin, serveradmin, and security admin.  Or with the permission granted.

    xp_readerrlog has extra parameters. Both of them have these parameters:

    1. error log number (0 based)
    2. error log type, 1 – SQL Server, 2 Agent
    3. search value – needs to be NVARCHAR
    4. second search value, NVARCHAR as well

    xp_errorlog adds 5 and 6, and 7.

    1. start time (datetime)
    2. end time (datetime)
    3. sort order (ASC,DESC)

    Those are the main differences I see, and if you want to filter or sort, you need the extended stored procedure, not the wrapper.

    I also learned to be careful of AI, as some of the data wasn’t correct from Google or Claude, so I need to verify what I get back and test how things work.

    SQL New Blogger

    I was investigating something and noticed a difference. This post was about 15 minutes to write, along with some testing of the parameters to verify what worked and what didn’t. That testing will make future posts quicker, as I’ll reuse some code.

    This is a quick example of showing some knowledge, and including the warnings about AI. You can write this post and give someone confidence you’re a good choice for the next person to manage their database servers.

  • The Cost of Multiple Platforms

    I ran into an interesting post that noted the modern data platform can have a bunch of different systems underlying it. The example might be that your “software” could use PostgreSQL, MongoDB, Cassandra, Clickhouse, and something NewSQL (Spanner, CockroachDB, etc,). Some of you might think that’s not reality, but keep in mind that for a lot of your organizations, the “software” is what the customer uses. I’m sure my bank has multiple systems behind the mobile app I use to pay for things, move money, check balances, etc. I would guess there is some DB/2, SQL Server, and some analytics or No/NewSQL stuff in there. Hidden as different applications that make up the “app”, but they are still in there from my perspective as a user of the app.

    No one intentionally designs software like this, but we still see it. They might not even have 5 or 6 platforms in their organization, but almost none of the customers I work with have less than 3. Somehow, somewhere, someone added a PostgreSQL server to an Oracle/SQL Server environment. MongoDB crept in when someone thought it was a better store than DB/2 or MySQL. An article written about how Facebook or Spotify or some other high tech company used Cassanda or Snowflake inspired a developer to add that to their toolbelt and build it into their application.

    And the ease with which the cloud makes experimentation quick and cheap causes a spread of your database estate.

    There’s a cost to having all these systems. Either an organization hires separate sets of experts to manage Ops, or they try and train lots of individuals to run multiple systems. It can be done, but those lightly trained people who have to focus on remembering the differences between SQL Server, PostgreSQL, and MongoDB will work slower. They’ll solve problems with a higher MTTR. Even if they have a single pain of glass, like Redgate Monitor, they still won’t be as effective as the number of platforms grow. It’s just human nature. And if you hire separate teams, that’s a cost as well.

    Heck, I’m a pretty good DBA and a good volleyball coach, but I get confused. When I got voluntold to manage DB/2 systems in addition to SQL Server, I got less done every day. When I coached two volleyball teams at the same time, I was less effective with each. It’s hard to keep focused on multiple similar things. Add in the complexity of not only separate paradigms, but different ways to manage things in the cloud or on-premises and the operational cost is high.

    I’m not sure it exceeds any licensing cost or the cost of limiting what platforms developers can use. I would argue only allowing 1-2 platforms just makes you more efficient and your staff more effective.

    However.

    That’s not the world. Even if I mandated that, often some external even changes my world. Companies get bought and integrated. New COTS software is needed, and it will, of course, run only on a database platform we don’t run.

    There’s a serious operational cost to adding new platforms that few consider. Even if they did, I’m not sure anything would change.

    Steve Jones

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

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