Change Timeline

The Changes page answers the first question asked in any incident: what changed?

Every monitoring tool shows you that CPU jumped at 14:03. This page shows you that IX_Auftrag_Datum was dropped at 13:58.

Why this page exists

SQL Server records DDL changes itself — in the default trace. But that trace rolls over after five files of 20 MB and is then gone for good. On an active instance that can be a matter of hours.

That is precisely where the value is: we continuously harvest what the server subsequently throws away and store it permanently. The harvest interval is therefore the real retention control:

"ChangeTracking": {
  "Enabled": true,
  "IntervalMinutes": 10,
  "RetentionDays": 180
}

On very write-active instances, lower IntervalMinutes.

What is captured

Category Source Attribution?
Schema — tables, procedures, indexes, views Default trace yes
Security — logins, server roles, DB roles Default trace yes
Server config — sp_configure Diff no
Trace flags — global Diff no
DB options — recovery model, compat level, auto-shrink, RCSI, page verify Diff no
Database — created or dropped Diff no

Only the default trace supplies login, host and application. Configuration diffs detect the change but cannot attribute it — those rows deliberately show "—" rather than a guess.

Severity

The bar for Critical is deliberately high. A timeline where half the rows are red is a timeline nobody reads.

Critical covers changes with known outage or data-loss impact:

  • Recovery model set to SIMPLE — breaks the log chain. Point-in-time recovery stops working from that moment while every backup job keeps reporting success. This is the single most valuable find in the category.
  • AUTO_SHRINK or AUTO_CLOSE switched on
  • Page verify moved away from CHECKSUM — torn pages go undetected
  • A database leaving the ONLINE state
  • MAXDOP set to 1, priority boost enabled, memory cap removed
  • A database dropped

Notable is anything that is a plausible cause during a regression hunt: compatibility level, RCSI, trace flags, dropped objects, security changes.

Info is routine movement — altered tables and procedures.

Chart overlay

Under Performance → History, the Show changes switch overlays recorded changes as vertical markers across every chart. Hovering a marker reveals exactly what happened.

Only changes of Notable severity and above are overlaid — Info-level noise would paint the charts solid on any instance with active development.

First run

On first contact with an instance only the baseline is recorded: no events. Otherwise every instance would produce a hundred false entries the moment monitoring is enabled, and would backfill the entire trace buffer — which you did not ask for. From the second run onward, changes are reported.

Requirements

  • The monitoring login needs ALTER TRACE to read the trace file, plus VIEW SERVER STATE for the catalog views.
  • The default trace must be enabled: EXEC sp_configure 'default trace enabled', 1; RECONFIGURE;
  • Trace flags require sysadmin. Without it that part is skipped silently — everything else continues.

Where no default trace is available (disabled, or Azure SQL Database), the page reports this once and falls back to configuration diffing. Schema and security changes are then unavailable; the remaining categories are unaffected.

Time zones

The default trace writes in the monitored server's local time. The offset against UTC is determined during harvest and converted; only UTC is stored. Display is in your local time.