sp_IndexCleanup: fix NULL database_name on Azure SQL DB

[erikdarlingdata]

Summary

• On Azure SQL DB, sys.databases.database_id is logical-server-scoped while DB_ID()/DB_NAME() and every DMV database_id column are database/elastic-pool-scoped, and the two id spaces need not agree. sp_IndexCleanup carried the sys.databases id and round-tripped it through DB_NAME(), which returns NULL for a foreign-space id — Msg 515 on the NOT NULL database_name columns of the analysis temp tables on Hyperscale.
• Same mismatch silently emptied #operational_stats: fo.database_id = os.database_id compared server-space to DMV local-space ids.
• Fix is direction-proof: ids are resolved locally, and names are never derived from ids.

Changes

• sp_IndexCleanup/sp_IndexCleanup.sql
  • #databases (single- and multi-database inserts) stores ISNULL(DB_ID(d.name), d.database_id) — the local-space id, identical values on box product — aligning dm_db_index_operational_stats, dm_db_index_usage_stats, and the operational-stats join predicates within one id space.
  • Every DB_NAME(@database_id) / DB_NAME(os.database_id) / QUOTENAME(DB_NAME(@current_database_id)) site (#filtered_objects, #operational_stats, #index_details, #partition_stats, #index_analysis inserts, generated DDL) now uses @current_database_name, parameterized into the dynamic SQL.

Test Plan

• Compiles clean on SQL 2017, 2022, 2025
• Local harness on SQL2022: adversarial 32/32, fixture-cases 31/31 (executes all generated scripts), rule-coverage 40/40 (covers @get_all_databases multi-db path), no-access 4/4
• Re-run on the Azure Hyperscale elastic pool database that reproduced the Msg 515 errors

Closes #839

Generated with Claude Code