Press "Enter" to skip to content

Category: Administration

Local Admin and SQL Server

Rebecca Lewis follows Betteridge’s Law of Headlines:

“Does a DBA need local administrator membership to manage SQL Server?”

The answer is simple: Local admin group membership is not required. In fact, best practices dictate that Database Administrators (DBAs) and SQL service accounts should not have local administrator rights on the host server.  This change was introduced as far back as SQL Server 2008 with a ‘secure by design, secure by default, and secure in deployment’ strategy.

Read on for the caveat of what happens when you don’t provide local admin access to your DBAs.

Comments closed

SQL Server and January 2026 Patch Tuesday

Rebecca Lewis takes a look at a recent security vulnerability:

Microsoft’s January 2026 Patch Tuesday included a security fix for SQL Server: CVE-2026-20803, an elevation of privilege vulnerability with CVSS score 7.2 (Important).

The vulnerability is classified as CWE-306: Missing Authentication for Critical Function. An attacker who already has high-level privileges on the SQL Server instance could exploit this flaw to escalate further — gaining debugging privileges, dumping system memory, and potentially extracting sensitive data or credentials.

Read on for more information about the CVE, what it requires to exploit, and how you can patch SQL Server to prevent it from being an issue. It’s interesting that this only affects SQL Server 2022 and 2025.

Comments closed

Deciding Whether to Use Clustering or Availability Groups

Brent Ozar has a take:

Sandra Delany (LinkedIn) wrote a well-thought-out blog post called, “Should a SQL Server DBA Know Windows Clustering?” She’s got about 20 years of DBA experience, and she works for Straight Path (a firm I respect) as a consultant. You can probably guess based on her background that yes, she believes you should know how to set up, configure, and troubleshoot Windows clustering. It’s a good post, and you should read it.

But… I don’t agree.

Read on for Brent’s opinion. I do agree that there are companies that don’t need high availability, and that there are plenty of problems you can run into if you don’t understand how it all works. I also think that, if you’re a DBA responsible for maintaining servers, and your company isn’t using any kind of high availability option, it’s important at least to learn how the mechanisms work so that, if HA does become important, you aren’t pushing back because of ignorance in the product.

But on the flip side, where does that rank in importance? It’s probably closer to the middle (or lower) than the top of the list. And I definitely agree that disaster recovery is generally the more important of the two if you can only have one. But even there, we have exceptions in things like stock trading systems or data warehouses, where you can rebuild the system from external sources.

Comments closed

Tracking Unused Indexes in PostgreSQL

Semab Tariq wants to see which indexes are in use:

Indexes exist to speed up data access. They allow PostgreSQL to avoid full table scans, significantly reducing query execution time for read-heavy workloads.

From real production experience, we have observed that well-designed, targeted indexes can improve query performance by 5× or more, especially on large transactional tables.

However, indexes are not free.

The reasons for why are very similar to what we have in SQL Server. The way to track utilization is a bit different, however.

Comments closed

Removing a Supersized tempdb File

Jeff Iannucci wants to smooth things out:

While reviewing the configuration of a client’s SQL Server instance recently, I noticed that they had a very curious tempdb configuration. Although it had multiple files for the eight CPU cores as Microsoft recommends for tempdb configuration, it also had another MUCH larger file with a MUCH larger growth rate.

And it turns out that when this happens, there are some knock-on effects that make it a challenge to remove such a file later. But read on for the solution.

Comments closed

ALTER TABLE and Partitioned Tables in PostgreSQL

Chao Li classifies a series of commands:

Does an operation propagate to partitions? Does it affect future partitions? Does ONLY do what it claims? Why do some commands work on parents but not on partitions—or vice versa?

Today, PostgreSQL documentation describes individual ALTER TABLE sub-commands well, but it rarely explains their interaction with partitioned tables as a whole. As a result, users often discover the real behavior only through trial and error.

This post summarizes a systematic investigation of ALTER TABLE behavior on partitioned tables, turning scattered rules into a consistent classification model.

Click through for 15 buckets of commands relating to ALTER TABLE in PostgreSQL and see how they handle dealing with partitioned tables.

Comments closed

Running PostgreSQL on Kubernetes

Umair Shahid digs into the arguments for and against:

“Should PostgreSQL run on Kubernetes too?”

The worst answers are the confident ones:

  • “Yes, because everything else is on Kubernetes.”
  • “No, because databases are special.”

Both are lazy. The right answer depends on what you’re optimizing for: delivery velocity, platform consistency, latency predictability, operational risk, compliance constraints, and, most importantly, who is on-call when things go sideways.

Click through for a detailed analysis. It’s a similar story in SQL Server:

Comments closed

Dealing with a Full Transaction Log

Rebecca Lewis performs some troubleshooting:

It’s 2am. Your phone wakes you. Rub your eyes, check your email, and there it is:

Error: 9002, Severity: 17, State: 4
The transaction log for database 'trading' is full due to 'LOG_BACKUP'.

The database is still online. Looks ok. You can read from it. But every INSERT, UPDATE, and DELETE fails. Production night-trading is effectively down.

The good news: It’s fixable — but, that fix depends entirely on what’s preventing log truncation.

Click through for a choose-your-own-adventure story.

Comments closed

Thoughts on the Death of the DBA

Rebecca Lewis presses X to doubt:

Every few years, something comes along that’s definitively, no-questions-asked going to replace us.

Let’s review the historical record.

Rebecca points out a half-dozen instances in which people have decried the end of the DBA role, and yet it’s still there somehow… And honestly, you could probably find a half-dozen more examples without searching too hard, like how SQL Server 2000 was going to render DBAs obsolete because of its self-management capabilities. Which, admittedly, is very similar to the 1996 Oracle announcement.

Comments closed