Voice of the DBA

Category: Editorial

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

  • The SQL Server 2016 Plan

    SQL Server 2016 went out of support this week, on Jul 14, 2026. This is the end of the Extended support, according to the Support Lifecycle page. Microsoft posted an article on next steps for SQL Server 2016, which looks like the AI read of an article at the top. There’s a lot of header info, so scroll down. I’m sure none of you want to listen to 10 minutes of an AI voice reading an article.

    I know some of you still run SQL Server 2016. In fact, I still run into some companies on older versions, and the last (ever) update from Brent also showed 6% on 2014 and older. There are probably still plenty, albeit a minority, of systems on older versions. I know when I worked in a non-regulated industry, we weren’t in a hurry to upgrade as many of our applications ran fine on older versions. Especially with VMs these days, I could see people sticking with 2016 for a while if it’s running well. Just be sure your server is well protected by firewalls.

    The blog gives 3 upgrade paths: Azure (IaaS or PaaS), SQL Server 2025, or Extended Security Updates. That latter one goes until 2029 if you want to pay for it. This is certainly a marketing post more than a technical one. Moving to Azure PaaS isn’t necessarily easy or quick. IaaS doesn’t help you here, so I’m sure whoever wrote this post (or whatever AI) isn’t thinking this through. An Azure VM isn’t going to get me any support.

    SQL Server 2025 is likely the easiest if you want to upgrade, as you could continue to use an older compatibility level in your database on SQL Server 2025. It will cost something, but it does give you 9-ish years of support and updates. I’d certainly prefer this over paying for ESU. It might not be a seamless upgrade, but I’d give it a quick go and see if my application worked on a restored 2016-on-2025 database. That’s an easy test and helps me make a decision.

    I suspect some in regulated industries need support for their compliance goals, and they might pay for ESU if their staff is busy and they need to mitigate an audit finding. I think this option is there, and it’s expensive, as a carrot/stick combo for organizations to upgrade. I can’t be upset about this, as I think there should be a plan in organizations to keep their software up to date. Either deliberately plan to remain on an older version and accept the risk, or ensure you have plans (and time) in place to regularly upgrade systems.

    If you’re on SQL Server 2016, what are your plans? Upgrading soon? Sticking with the platform? And if you’re on 2017 or 2019, you ought to be thinking forward and be ready to handle the end of support for those versions.

    Steve Jones

  • The Mythical Bus Accident

    What if I got hit by a bus?

    I’m sure many of you have heard some variation of this, or used it, or maybe your boss told you to be ready in case you (or someone more important) gets hit by that vehicle. This is the “bus factor,” and it’s often used in reference to preparation for unforeseen events. Not literally someone getting hit by a bus, but perhaps a sudden accident that takes someone away from work (hopefully not fatal). Perhaps it’s someone leaving for a new job. Maybe it’s retirement, which is something my boss and I at Redgate chat about periodically.

    Don’t worry, I’m not planning on retiring anytime soon. I expect to work until at least 2033 and possibly longer. Likely longer, I’m a weird work-a-holic in some ways, and I love my job.

    Recently, Rob Sewell wrote about a DR plan for his life, and specifically about his setup in case his wife needs to understand what’s running. I certainly don’t have the automation or complex computer setup he does. In fact, none of my computers really need to be running for anything on the ranch to function.

    However, there is a lot of important data.

    If you think about how embedded your life is with digital assets, you’ll realize quickly that if you were to get hit by the mythical bus, a lot of stuff might disappear. Most won’t matter, but your partner/spouse/children/parents might care about some. They might really care about a few items.

    There will be passwords to banks, the locations of photos, videos, and other memories. There will be documents you’ve kept on maintenance, or manuals on how something works, or maybe it’s just the various email (and social) accounts you have. You might not care, but the person behind you might feel the need, and want to, notify your friends and coworkers that you’re gone. Maybe your family wants to know how to keep your site alive (I still miss Tom and re-read his work occasionally).

    This isn’t to be morbid or worry you, but the planning you might undertake for your life is a lot like the planning that you should be doing at work for your job. Others should be able to take over for you (especially on vacations), and a guide to how you’ve solved problems, patched over issues, and built scripts that run rarely but reliably for some forgotten reason. Those items should be available to others. Certainly, your IT staff can give someone else access, but will those others know what to do with that access?

    I’ve documented a bunch of processes for SQL Server Central. Mostly so I can go on sabbatical and not worry, but also so that others can share the load. I’ve given away some of my work to others, I’ve been lucky to have others volunteer (volun-told) to help, and I realize as I write this, I likely need to update some docs. Not a fun task, but my buddy Claude can likely help me. And he will.

    Planning for the future is prudent, it’s respectful to others, and it’s a common courtesy. I used to think the future was a long way off, but as I age, I realize it’s closer than I think. Planning for the future is a good idea, and it’s something I need to ensure I update every so often, to help the others in my life.

    Steve Jones

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

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