Voice of the DBA

Tag: administration

  • Never is Not the Policy

    Years ago I worked with a few developers and DBAs that were temp-table happy. As in they defaulted to using temp tables everywhere. This was in SQL Server 6.5, and tempdb was an issue with contention, sizing, and performance. I rewrote so many queries to remove temp tables for our clients that I banned them. I told other developers they could never use temp tables in their SQL code. They, of course, would try to submit code with temp tables in our VCS (Visual SourceSafe at the time), but an early, pre-automated CI/CD would notify me and I’d have the developer rewrite their code.

    There were situations that didn’t perform well with a single query, and we did allow some temp tables. The point wasn’t the ban them entirely, but stop them from being a crutch for developers or a first choice. I wanted them to think about the problem first and try to solve it with SQL. If performance was an issue, then we’d look at a temp table.

    Recently, I saw a post from Jeff Iannucci that noted there are settings you should never change. These were database-level or instance-level settings that he suggests you leave the defaults, or leave a specific setting chosen. An example of the latter is Page_verify set to checksum. The default in older databases, upgraded through different versions, can be none or torn page detection enabled. Fix that if you see it.

    Examples of other settings are things like Auto Shrink and Auto Close, which shouldn’t be enabled. These types of settings should be left off, well, with a caveat from me. There are narrow places where you might want certain things turned on. For example, Auto Close isn’t the worst thing in the world, and there places where it makes sense. Dev servers with a large number of databases that aren’t often used might get help here in conserving resources. Same for production instances where a lot of older databases are kept around for archival, but we don’t want them open and consuming any resources without an explicit connection.

    I don’t mind DBAs or developers having “never” as a policy for certain things, with the caveat that this isn’t a forever rule, but one that strongly sets a guideline that we don’t create exceptions for without a very good reason. Staffs change, internal knowledge is lost or narrowly shared, and often inexperience can creep into your environment. These strongly worded guidelines, even with “never” in them, help to keep everyone on the same path.

    Strong opinions, loosely held. We change our minds and grant exceptions when there is evidence to do so.

    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.

  • 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 Slow Growing Problems

    Both as a DBA and developer, I’ve had plenty of immediate, this-is-broken, fix-it-quickly issues. Usually, I, or someone else, wrote some bad code and somehow got it deployed. I mean, I do test things, and I would (probably) never change code after I’d tested it to fix that one little annoying thing, like the formatting. I’d (almost) never do that, and I’m sure you wouldn’t either.

    Yet somehow bugs slip in at times.

    Those are the acute issues, and they can be hard to fix at times, but often we can reproduce the problem in development and build a fix. Sometimes we even spot the issue quickly and just fix it in production. I’m sure you never do that, but I have had that experience myself a few times.

    However, in the database world, we can have other, slow-growing problems. I saw this post from Jacob Sebastian about production issues that don’t trigger alarms. There are just slowdowns that trickle across multiple systems and cause issues for clients. These aren’t things you instrument for, as a slowdown isn’t necessarily an issue. These things can resolve themselves, or they can develop into a major issue.

    I think about this like vehicle traffic. A minor fender bender on a highway might not be a problem, but it can become one. Cars don’t get out of traffic quickly enough, or traffic police don’t arrive soon and move the cars. Traffic starts to back up, which slows down the response, including that important tow truck that might keep things moving. Suddenly, it’s not a few people inconvenienced by an accident, but thousands.

    There are likely signals in your environment that would let you know about a potential issue coming soon. These are subtle and not always indicative of a problem individually, but taken together, they indicate a production issue is going to occur. To me, this is a place AI can eagerly be taught to look for these signals and then happily keep looking for them every day.

    The future of monitoring is the active examination of correlated data that precede an issue, hopefully giving humans, or other AIs, enough time to respond and prevent customers from experiencing a slowdown.

    I’d certainly welcome this in both traffic motorways and database systems.

    Steve Jones

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

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