SqlWorkloadProfiler
Profiles SQL Server workloads (query stats, wait types, IO telemetry) and
What it does
Existing infrastructure discovery captures SQL *instances*. This module answers the next question: "what tier do I land each instance on in Azure SQL?". It surfaces the same telemetry Cloudamize SQL Telemetry Toolkit ships with: 1. Query CPU / logical-read / duration distribution (sys.dm_exec_query_stats joined to sys.dm_exec_sql_text). 2. Wait-type breakdown (sys.dm_os_wait_stats) so we can flag CPU-bound, IO-bound, or memory-bound instances. 3. Per-file IO telemetry (sys.dm_io_virtual_file_stats) for read/ write IOPS, latency, and stall ratios. 4. CPU + memory pressure (sys.dm_os_ring_buffers, sys.dm_os_process_memory) sampled at module run time. From those metrics we compute a single recommended Azure SQL tier per instance: - vCore General Purpose (default steady workloads) - vCore Business Critical (high IO / low-latency) - vCore Hyperscale (>4 TB or heavy log IO) - DTU Standard / Premium (sub-100 GB low-CPU instances) Source instance list (priority order): 1. Configuration.SqlInstances (array of "host\instance" or "host,port") 2. SQLInventory.csv produced by infrastructure discovery 3. Local default instance ("(local)") as a fallback Output: SqlWorkloadProfile_Queries.csv top-50 queries per instance (CPU+IO) SqlWorkloadProfile_Waits.csv top-20 wait types per instance SqlWorkloadProfile_IO.csv per-file IO telemetry SqlWorkloadProfile_Summary.csv per-instance roll-up + tier rec
How the app exposes it
The module runs through the ACQI discovery orchestrator and writes its rows into a dedicated results view. From there, conflicts, dependencies, and readiness scores feed the deal-wide consolidation layer.
/discovered/sql-workload-profiler Outputs
Each module emits a normalised CSV keyed by entity ID with readiness and risk scores, evidence-source counts, and last-seen timestamps. The exact column set varies by module — the app's results view shows the live schema.