Collect and surface ADR persistent version store size per database

[erikdarlingdata]

Accelerated Database Recovery keeps its Persistent Version Store INSIDE the user database, and PVS growth is one of the classic silent-disk-eater stories: a long-running or aborted transaction pins version cleanup, the database file grows, and nothing in the product today says why. We should check for it and show it.

What to collect

sys.dm_tran_persistent_version_store_stats (SQL Server 2019+), per database with ADR enabled - the interesting columns are the PVS size, the oldest active transaction holding cleanup back, and the aborted-transaction accounting. Enablement itself comes from sys.databases (is_accelerated_database_recovery_on), which is also worth surfacing as inventory: knowing ADR is ON is context an operator wants even at zero PVS pressure.

Platform and version gates

• Version-gated 2019+ on box SQL Server (the min-supported floor here is 2016, so the collector gates like the other version-gated columns rather than assuming).
• Azure SQL DB has ADR permanently ON and cannot disable it - every Azure database is in scope, which arguably makes this MORE valuable there than on box.
• Managed Instance supports it; verify the DMV binds through the enumeration path like the Query Store replica attribution on Managed Instance: still gated off on an unverified basis after #1872 #1886 probes did.
• Builder verifies every DMV/column claim against MS Learn at build time per the sourced-advice rule; nothing in this issue is exempt from that.

Surfacing

Both apps, catalog-driven collector per the standing pattern (catalog + dispatch + StorageVersion bump + viewer probe sentinel). A natural fit beside the existing database size / tempdb surfaces. Alert consideration (separate decision, not required for v1): PVS size threshold or growth-rate, and the aborted-transaction count as the leading indicator - but collection and visibility come first.

[erikdarlingdata]

Shipped in #1985. One pvs_stats collector in both apps: per-database ADR persistent version store size from sys.dm_tran_persistent_version_store_stats, version-gated 2019+, hourly tier beside database_size_stats, Lite DuckDB v51 + Darling migration V47, surfaced in both apps' size telemetry with Custom Views exposure. The lane survived a mid-build agent death and the continuation caught what the first pass missed: on Azure SQL Database, sys.databases.database_id lives in the LOGICAL SERVER id space while DB_ID() and the DMV's database_id are pool-scoped, so the inherited INNER JOIN silently collected NOTHING per database on Azure - fixed by reading the ADR flag by name (d.name = DB_NAME()), with a regression test pinning each platform path and the id-space behavior itself deferred to a tightly-scoped Azure smoke (#1989, everything testable off-Azure already verified on box). The migration renumber V45 to V47 was proven the hard way: a store migrated to 46 by a dev-base build, then upgraded by this build to 47, hash-identical to a fresh store - because the applier skips anything at or below MAX(version), a late-arriving 45 would have silently never applied. CI cluster worker sizing re-derived for both new hypertables (43/54). Live evidence: 234 MB of off-row PVS from one open transaction on SQL2025, and the join defect was MEASURED (18 DMV rows, 15 surviving the join) rather than assumed.