Drop sys.dm_os_schedulers from memory_stats on Azure SQL DB (#857)

[erikdarlingdata]

Summary

Fourth follow-up to #857. Reproduced @TrudAX's environment by provisioning a standard Azure SQL Database elastic pool and adding a contained DB user with just VIEW DATABASE STATE + VIEW DATABASE PERFORMANCE STATE. That reproduces his failure pattern exactly:

DMV	Standalone Azure SQL DB	Elastic pool	TrudAX
sys.dm_os_sys_info	✓	✓	✓
sys.dm_os_performance_counters	✓	✓	✓
sys.dm_exec_requests WHERE database_id = DB_ID()	✓	✓	✓
sys.dm_os_memory_clerks	✓	FAIL 300	FAIL 300
sys.dm_os_schedulers	✓	FAIL 300	(not probed, but inferred)
sys.dm_os_waiting_tasks	✓	FAIL 300	FAIL 300
tempdb.sys.dm_db_file_space_usage	FAIL 262	FAIL 300	FAIL 300

So D365FO customer tenants really do live in elastic pools, and pools enforce VIEW SERVER PERFORMANCE STATE on those DMVs regardless of DB-scoped grants. Microsoft docs currently say VIEW DATABASE PERFORMANCE STATE should suffice for these DMVs on non-Basic tiers — the docs are wrong for elastic pool.

memory_stats is the one collector we can partially recover: the sys.dm_os_schedulers CROSS JOIN is the only piece that hits the permission wall. Dropping it and reporting current_workers_count = NULL lets the collector succeed with all the memory metrics populated.

• Azure branch of memory_stats now emits current_workers_count = CONVERT(int, NULL) and drops the sys.dm_os_schedulers CROSS JOIN
• Reader (Memory.cs:164) already coerces IsDBNull(11) to 0, so DuckDB gets 0 instead of NULL — no schema change needed, and the existing on-prem / Azure MI path is untouched
• Verified against the elastic pool repro: all remaining fields populate, query runs clean

memory_clerks, waiting_tasks, and tempdb_stats stay permission-denied for elastic pool users — no DB-scoped alternative exists. They'll remain skip-gated by #870 (silent, no log churn).

Test plan

• Build: dotnet build Lite/PerformanceMonitorLite.csproj -c Debug — 0 errors
• Elastic pool repro: full query succeeds as d365pool user (only VIEW DATABASE STATE + VIEW DATABASE PERFORMANCE STATE)
• Boxed SQL Server path (isAzureSqlDb = false): unchanged, still populates current_workers_count
• D365FO confirmation (deferred to @TrudAX on next nightly): memory_stats collector goes green, current_workers_count reported as 0

🤖 Generated with Claude Code

[erikdarlingdata]

Summary

Drops the sys.dm_os_schedulers CROSS JOIN from the Azure SQL DB branch of memory_stats so contained DB users in an elastic pool (D365FO repro) can collect the rest of the row. On-prem / Azure MI path (!isAzureSqlDb) is untouched.

Checks

• Base branch: targets dev ✓
• PlanAnalyzer sync: not touched ✓
• Schema upgrades: no SQL schema churn; current_workers_count column already exists and is nullable in DuckDB (Lite/Database/Schema.cs:180, DuckDbInitializer.cs:563) ✓
• Lite-first: Lite-only change. The Dashboard SQL Agent equivalent (install/14_collect_memory_stats.sql) does not reference dm_os_schedulers, and elastic pool isn't a Dashboard deployment target — no port required ✓
• build.yml / SignPath: not changed ✓
• SQL style: query stays in the house style — aliased sources, N'...' literals, OPTION(RECOMPILE) terminator ✓
• C# hygiene: reader at Memory.cs:164 already coerces IsDBNull(11) ? 0; using blocks intact; no async-void or swallowed exceptions introduced ✓
• Tests: no Memory collector unit tests exist (consistent with the rest of RemoteCollectorService.*, which require a live SQL Server). Not a blocker.

Needs attention (non-blocking)

1. Memory.cs:33-40 — comment says current_workers_count is reported as NULL, but it lands in DuckDB as 0 due to the reader coercion at Memory.cs:164. Clarify in the comment or make the storage path actually null.
2. FinOpsTab.xaml.cs:271 — Worker Threads will render as 0 / 12288 for elastic-pool users, which reads as "zero active workers" rather than "unavailable." Consider a render guard or a nullable end-to-end path. Separate commit is fine.

Otherwise looks good to go — diff is tight and the repro story in the description is convincing.

---

Generated by Claude Code

[erikdarlingdata]

Nit: comment says "report current_workers_count as NULL", but the reader at Memory.cs:164 coerces IsDBNull(11) ? 0 : reader.GetInt32(11), so the value landing in DuckDB memory_stats.current_workers_count is 0, not NULL. A maintainer who reads only this block will be misled about what downstream consumers see. Consider tightening to something like "…SQL returns NULL; the reader coerces it to 0 before the appender, so DuckDB sees 0."

---

Generated by Claude Code

[erikdarlingdata]

Downstream UX consequence worth noting (not a blocker for this PR): FinOpsTab.xaml.cs:271 renders WorkerThreadsText.Text = $"{data.CurrentWorkersCount:N0} / {data.MaxWorkersCount:N0}". After this change, elastic-pool users will see 0 / 12288, which reads as "zero active workers" rather than "unavailable on this tier." A follow-up render guard in FinOpsTab (e.g. show — / 12288 or N/A when CurrentWorkersCount == 0 and engine edition is 5) would close the loop — or keep the DuckDB value nullable end-to-end. Your call; flagging so it doesn't get lost.

---

Generated by Claude Code