Database Administration — Sat Jan 31

← Home | ← database-admin

Databases Don’t Shrink. They Betray Patterns.

Sat Jan 31
#sql-server #monitoring #capacity-planning #dba-life

Every DBA Team Gets This

Databases rarely shrink.

They either:

  • Grow fast
  • Grow slowly
  • Expand and contract
  • Or sit at roughly the same size for years

But they almost never get smaller.

Transaction logs?

Exactly the same story.

Now picture this.

You’ve got one SQL Server instance.
Forty databases on it.

Each with its own personality.
Each with its own growth pattern.
And after a while… you get used to them.

You know which one grows 5GB a month.
You know which one spikes at month-end.
You know which one expands during patch windows.

But here’s the problem:

No One Tells You When Behaviour Changes

Something shifts.

  • New app functionality gets deployed
  • A feature suddenly gets heavy adoption
  • A bulk process is introduced
  • A job runs differently
  • Backups stop running
  • Log truncation stops happening

And suddenly, one database breaks its normal pattern.

You don’t get advance warning.

You get a phone call.


What Actually Happens

Disk fills up.

Then:

  • Databases stop growing
  • Writes fail
  • Availability Groups fall behind
  • Replication breaks
  • TempDB screams
  • The whole instance starts grinding

If databases share drives, it’s even worse.

One runaway log file can take out everything.

And when that happens?

The whole company is on the phone asking what went wrong.


The Reality

You can’t prevent every growth event.

But you can:

  • Detect abnormal growth early
  • Spot log files that stopped truncating
  • See disk trends weeks before they become incidents
  • Correlate growth spikes to releases or deployments

If you measure:

  • Data file size
  • Data used
  • Data free space
  • Log file size
  • Log used percentage
  • Disk free space

You turn surprises into conversations.

And when someone asks:

“Why did this database suddenly grow 300GB?”

You don’t guess.

You pull up the history and show exactly when behaviour changed.

That’s the difference between firefighting and engineering.


This Is Why We Monitor

You won’t stop all outages.

But you’ll prevent a lot of them.

More importantly:

You’ll know when normal behaviour stops being normal.

That’s what real DBA work looks like.

Not just reacting —
but watching the patterns before they turn into incidents.


You don’t control growth.
You control visibility.

Active Requests Script

File Sizes and Free Space.sql
    Loading…
  

Gareth Winterman