Add typed blocker-side columns to blocking_BlockedProcessReport

[erikdarlingdata]

Summary

Schema-only PR (1 of 2) for the SQL-side blocked-process pair extraction work. Moves blocked-process-report XML parsing from analysis time to collection time so the Dashboard analysis path can read structured columns instead of re-parsing blocked_process_report_xml on every BLOCKING_CHAIN fact (up to 5000 XElement.Parse calls per cycle).

Adds five typed columns to collect.blocking_BlockedProcessReport:

• blocking_spid integer
• blocking_last_tran_started datetime2(7)
• blocking_status nvarchar(10)
• blocked_sql_text nvarchar(max)
• blocking_sql_text nvarchar(max)

Names match the equivalent Lite DuckDB columns so the Dashboard and Lite analysis SQL can read identically-named columns.

What's in this PR

• install/02_create_tables.sql — new columns added inside the existing IF OBJECT_ID(...) IS NULL table-creation guard (fresh-install path).
• upgrades/2.11.0-to-2.12.0/01_extend_blocked_process_report_columns.sql — new upgrade script. Five idempotent IF NOT EXISTS / ALTER TABLE ADD blocks plus a one-pass backfill of existing activity='blocked' rows.
• upgrades/2.11.0-to-2.12.0/upgrade.txt — manifest.
• install/23_process_blocked_process_xml.sql — collect.process_blocked_process_xml now populates the new typed columns at insert time from the XQuery (//blocked-process-report/blocking-process/process/@…)[1] shape, scoped to the freshly-parsed window. Runs before the is_processed=1 mark so a crash rolls everything back and the raw XML rows stay unmarked for retry.

Wire-format notes

The stored XML is <event>-rooted with the report nested two levels deep at /event/data[@name="blocked_process"]/value/blocked-process-report. Both insertion paths (the raw collector in install/22 and sp_HumanEventsBlockViewer's named-XE path) preserve this wrap. All XQuery in this PR uses the descendant axis //blocked-process-report/... to sidestep the two-level wrap; this was empirically validated against sql2022.PerformanceMonitor (a leading-slash root path returns NULL on every row, descendant axis returns the expected attributes).

Defense-in-depth

If sp_HumanEventsBlockViewer writes rows but the XQuery extraction populates zero typed columns, a TYPED_COLUMNS_EMPTY row is written to config.collection_log so any future wire-format regression surfaces in telemetry instead of silently producing garbage chains in the analysis path.

What's NOT in this PR

C# read-path simplification ships in a follow-up PR — deletion of BlockedProcessXmlParser.cs and switching SqlServerFactCollector.CollectBlockingChainFactsAsync / SqlServerDrillDownCollector.CollectReconstructedBlockingChains to read the new typed columns directly. That PR is gated on this one being on dev.

Test plan

• Upgrade script applied cleanly on sql2022.PerformanceMonitor (5 ALTERs + 126-row backfill)
• collect.process_blocked_process_xml ALTER applied cleanly
• Verification gate (§10 step 8, tightened) returns 0:
  sql SELECT COUNT_BIG(*) FROM collect.blocking_BlockedProcessReport WHERE activity='blocked' AND blocked_process_report_xml IS NOT NULL AND blocking_spid IS NULL AND blocked_process_report_xml.exist(N'//blocked-process-report/blocking-process/process[@spid][1]') = 1;
• Spot-checked populated rows have plausible blocker-side values (spid, status, last_tran_started, SQL text)
• tsql-style-enforcer agent — pass (one minor alias-qualification fix applied)
• upgrade-path-validator agent — pass
• Live-server validation by maintainer before merge
• Repeat upgrade script on a server that hasn't yet seen any blocked-process rows (should ALTER cleanly and backfill UPDATE 0 rows)
• Verify upgrade script is re-runnable (re-running on already-upgraded server should ALTER 0 columns and UPDATE 0 rows)

🤖 Generated with Claude Code