SQL Server Changes You Didn’t Approve

If you’ve ever stepped into a performance issue and heard, “I didn’t touch anything,” there’s a good chance something did get touched.

SQL Server is remarkably sensitive to even small changes. A setting that’s flipped “just to test something,” an index added to speed up a report, or a profiler trace during a slowdown - these rarely feel risky at the time. But when they happen without visibility, they can immediately change SQL Server behavior.

When you don’t know something changed, you can’t measure or mitigate the impact. That’s when risks can become outages.

The Real Problem with Quiet Changes

Most unapproved changes are attempts to help. They’re not sabotage. They’re often driven by troubleshooting, curiosity, or something someone picked up at a conference. But production systems shouldn’t be where ideas get tested.

When even minor changes aren’t tracked, you lose control of performance, predictability, and accountability.

Common Sources of Unapproved Changes

• Permissions too broad (developers or sysadmins have ALTER access)

• Automatd “minor” patch or hotfix installs

• Ad hoc tuning while debugging performance

• Someone enables a new index or query hint without proper testing first

• Someone reads a blog post and implements something they think is low-risk

None of these actions feel significant at the time. Until they are.

A Familiar Example

Friday, 5:15 PM. Someone adds a nonclustered index to “help reporting.”
Monday morning:

• Blocking has increased

• Execution plans changed

• Statistics are skewed

• Ticket subject line reads: “URGENT – DATABASE SLOW”

It wasn’t a malicious act. It was a well-meaning change made without documentation or rollback planning.

How to Reduce the Risk

1. Restrict production modification permissions
   If it's production, it requires approval. No exceptions.

2. Baseline regularly
   Capture configuration and performance before and after any change (sp_Blitz, diagnostic snapshots).

3. Document everything that can influence SQL behavior
   “I was just testing something” is not acceptable in production.

4. Monitor for configuration drift
   Knowing what changed and when is often the difference between a long outage and a quick correction.

5. Encourage experimentation in non-production environments
   Curiosity is great. But not on systems that generate revenue.

The Bottom Line

Minor fixes often feel harmless until they introduce instability. If you’re not fully tracking SQL Server changes, you’re reacting to problems rather than managing them. SQL Server will change. Your goal is to make sure those changes are intentional and detectable.

SQL Tidbit

Run sp_Blitz regularly to detect configuration drift. This includes changes after patching, tuning, or manual adjustments. It also flags settings that deviate from best practices. Start building baselines now so future comparisons are meaningful. The ‘Configuration Changes History’ Instance level report in SSMS can be useful as well. Either way, save the results for future comparison.

When SQL Server changes without warning, be confident someone qualified sees it coming.
First month free for new clients

Pocket DBA®

Link Party:

If there’s nothing here, its because I got busy and forgot 😉

Please share this with all of the developers you are about to kick off the prod servers