[QUESTION] - Application database size and uninstaller?

[StanYan]

Which component is your question about?

Full Dashboard

Performance Monitor Version

2.0.0

Is your question about how it works, or the results?

Results / data interpretation

What's your question?

Hi,
I installed Performance Monitoring v.2.0.0 on a server with two production databases. Each has a size of 3-4 GB of data. The application's database has grown to over 155 GB in 5 days. What is the reason for this and how can it be reduced - automatically/scheduled or manually?
I did not find an official way (script) for uninstall Performance Monitoring, is there one?! I apologize in advance if I am wrong.

Thank you!

Additional Context

No response

[erikdarlingdata]

Hi! Thanks for trying Performance Monitor.

The installer creates a Data Retention agent job that runs daily at 2:00 AM and purges data older than the configured retention period (default: 30 days). You can shorten that per collector via the retention_days column in config.collection_schedule, or adjust it from the Dashboard's settings UI to help control database size. You can also disable query text and execution plan capture per-collector (collect_query and collect_plan columns in the same table, also editable from the Dashboard settings), which are typically the largest data contributors.

I'd be curious what's driving the size that high — if you're willing to share the table and index sizes for your PerformanceMonitor database, that would help me understand what's going on.

As for uninstalling — there isn't an official uninstall process yet, but I'm working on adding that as a flag to both the CLI and GUI installers. For now, the cleanest approach is:

1. Delete these three SQL Agent jobs:
   • PerformanceMonitor - Collection
   • PerformanceMonitor - Data Retention
   • PerformanceMonitor - Hung Job Monitor
2. Drop the PerformanceMonitor database

That will remove everything cleanly.

[jirish-hcs]

@erikdarlingdata, had the same issue. Database getting quite large and actually caused the data drive on one Server to run out of space due to growth. I figured it was related to the fact that these Servers are highly transactional.

I went looking for the config.retention_settings table to check what the settings were and I did not find one. I found the column retention_days in config.collection_schedule most of which are set to 30, except "Currently running SQL Agent jobs with historical duration comparison".

I have a backup of the Database before I dropped it. Data file was 196 GB and Log was 384 MB.

I ran the following query to pull the information I think you asked about for table sizes.
SELECT SCHEMA_NAME(t.schema_id) AS SchemaName, t.NAME AS TableName, i.name as indexName, FORMAT(sum(p.rows),'N0') as RowCounts, FORMAT(sum(a.total_pages), 'N0') as TotalPages, sum(a.used_pages) as UsedPages, sum(a.data_pages) as DataPages, (sum(a.total_pages) * 8) / 1024 as TotalSpaceMB, (sum(a.used_pages) * 8) / 1024 as UsedSpaceMB, (sum(a.data_pages) * 8) / 1024 as DataSpaceMB FROM sys.tables t INNER JOIN sys.indexes i ON t.OBJECT_ID = i.object_id INNER JOIN sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id WHERE t.NAME NOT LIKE 'dt%' AND i.OBJECT_ID > 255 AND i.index_id <= 1 GROUP BY SCHEMA_NAME(t.schema_id),t.NAME, i.object_id, i.index_id, i.name ORDER BY -- object_name(i.object_id) --DataSpaceMB DESC; sum(p.rows) DESC;

DataPages	DataSpaceMB	HasErrors	indexName	ItemArray	RowCounts	RowError	RowState	SchemaName	Table	TableName	TotalPages	TotalSpaceMB	UsedPages	UsedSpaceMB
550387	4299	False	PK_query_stats	{collect, query_stats, PK_query_stats, 6,825,309, 9,271,880, 9268711, 550387, 72436, 72411, 4299}	6,825,309		Unchanged	collect	Table	query_stats	9,271,880	72436	9268711	72411
459324	3588	False	PK_query_store_data	{collect, query_store_data, PK_query_store_data, 6,466,113, 10,552,344, 10550823, 459324, 82440, 82428, 3588}	6,466,113		Unchanged	collect	Table	query_store_data	10,552,344	82440	10550823	82428
20306	158	False	PK_procedure_stats	{collect, procedure_stats, PK_procedure_stats, 1,113,975, 4,512,332, 4511644, 20306, 35252, 35247, 158}	1,113,975		Unchanged	collect	Table	procedure_stats	4,512,332	35252	4511644	35247
3182	24	False	PK_wait_stats	{collect, wait_stats, PK_wait_stats, 487,360, 3,256, 3250, 3182, 25, 25, 24}	487,360		Unchanged	collect	Table	wait_stats	3,256	25	3250	25
3304	25	False	PK_spinlock_stats	{collect, spinlock_stats, PK_spinlock_stats, 478,616, 3,373, 3360, 3304, 26, 26, 25}	478,616		Unchanged	collect	Table	spinlock_stats	3,373	26	3360	26
2274	17	False	PK_perfmon_stats	{collect, perfmon_stats, PK_perfmon_stats, 396,495, 2,344, 2336, 2274, 18, 18, 17}	396,495		Unchanged	collect	Table	perfmon_stats	2,344	18	2336	18
467	3	False	PK_collection_log	{config, collection_log, PK_collection_log, 302,172, 510, 498, 467, 3, 3, 3}	302,172		Unchanged	config	Table	collection_log	510	3	498	3
4153	32	False	PK_file_io_stats	{collect, file_io_stats, PK_file_io_stats, 248,215, 4,228, 4213, 4153, 33, 32, 32}	248,215		Unchanged	collect	Table	file_io_stats	4,228	33	4213	32
9290	72	False	PK_trace_analysis	{collect, trace_analysis, PK_trace_analysis, 238,797, 13,864, 13854, 9290, 108, 108, 72}	238,797		Unchanged	collect	Table	trace_analysis	13,864	108	13854	108
704	5	False	PK_memory_clerks_stats	{collect, memory_clerks_stats, PK_memory_clerks_stats, 120,518, 760, 749, 704, 5, 5, 5}	120,518		Unchanged	collect	Table	memory_clerks_stats	760	5	749	5
326	2	False	PK_latch_stats	{collect, latch_stats, PK_latch_stats, 72,706, 362, 353, 326, 2, 2, 2}	72,706		Unchanged	collect	Table	latch_stats	362	2	353	2
5291	41	False		{collect, query_snapshots_20260227, , 33,786, 8,012, 8000, 5291, 62, 62, 41}	33,786		Unchanged	collect	Table	query_snapshots_20260227	8,012	62	8000	62
4950	38	False		{collect, query_snapshots_20260303, , 32,499, 7,586, 7580, 4950, 59, 59, 38}	32,499		Unchanged	collect	Table	query_snapshots_20260303	7,586	59	7580	59
4703	36	False		{collect, query_snapshots_20260228, , 30,939, 5,727, 5715, 4703, 44, 44, 36}	30,939		Unchanged	collect	Table	query_snapshots_20260228	5,727	44	5715	44
3563	27	False		{collect, query_snapshots_20260302, , 23,208, 6,110, 6104, 3563, 47, 47, 27}	23,208		Unchanged	collect	Table	query_snapshots_20260302	6,110	47	6104	47
3049	23	False		{collect, query_snapshots_20260304, , 19,143, 5,386, 5379, 3049, 42, 42, 23}	19,143		Unchanged	collect	Table	query_snapshots_20260304	5,386	42	5379	42
18	0	False	PK_waiting_tasks	{collect, waiting_tasks, PK_waiting_tasks, 17,982, 27, 22, 18, 0, 0, 0}	17,982		Unchanged	collect	Table	waiting_tasks	27	0	22	0
57	0	False	PK_plan_cache_stats	{collect, plan_cache_stats, PK_plan_cache_stats, 17,025, 79, 65, 57, 0, 0, 0}	17,025		Unchanged	collect	Table	plan_cache_stats	79	0	65	0
2553	19	False		{collect, query_snapshots_20260226, , 16,611, 3,804, 3792, 2553, 29, 29, 19}	16,611		Unchanged	collect	Table	query_snapshots_20260226	3,804	29	3792	29
35	0	False	PK_cpu_utilization_stats	{collect, cpu_utilization_stats, PK_cpu_utilization_stats, 11,281, 45, 41, 35, 0, 0, 0}	11,281		Unchanged	collect	Table	cpu_utilization_stats	45	0	41	0
41	0	False	PK_running_jobs	{collect, running_jobs, PK_running_jobs, 10,438, 63, 49, 41, 0, 0, 0}	10,438		Unchanged	collect	Table	running_jobs	63	0	49	0
39	0	False	PK_memory_grant_stats	{collect, memory_grant_stats, PK_memory_grant_stats, 9,026, 54, 46, 39, 0, 0, 0}	9,026		Unchanged	collect	Table	memory_grant_stats	54	0	46	0
31	0	False	PK_cpu_scheduler_stats	{collect, cpu_scheduler_stats, PK_cpu_scheduler_stats, 7,609, 53, 37, 31, 0, 0, 0}	7,609		Unchanged	collect	Table	cpu_scheduler_stats	53	0	37	0
9	0	False	PK_default_trace_events	{collect, default_trace_events, PK_default_trace_events, 6,783, 35, 13, 9, 0, 0, 0}	6,783		Unchanged	collect	Table	default_trace_events	35	0	13	0
1036	8	False		{collect, query_snapshots_20260301, , 6,288, 1,860, 1851, 1036, 14, 14, 8}	6,288		Unchanged	collect	Table	query_snapshots_20260301	1,860	14	1851	14
26	0	False	PK_memory_stats	{collect, memory_stats, PK_memory_stats, 4,513, 44, 31, 26, 0, 0, 0}	4,513		Unchanged	collect	Table	memory_stats	44	0	31	0
16	0	False	PK_session_stats	{collect, session_stats, PK_session_stats, 4,511, 27, 20, 16, 0, 0, 0}	4,511		Unchanged	collect	Table	session_stats	27	0	20	0
19	0	False	PK_tempdb_stats	{collect, tempdb_stats, PK_tempdb_stats, 4,511, 27, 23, 19, 0, 0, 0}	4,511		Unchanged	collect	Table	tempdb_stats	27	0	23	0
4	0	False	PK_database_configuration_history	{config, database_configuration_history, PK_database_configuration_history, 3,462, 25, 6, 4, 0, 0, 0}	3,462		Unchanged	config	Table	database_configuration_history	25	0	6	0
58	0	False		{collect, BlitzLockFindings, , 2,520, 68, 62, 58, 0, 0, 0}	2,520		Unchanged	collect	Table	BlitzLockFindings	68	0	62	0
5	0	False	PK_memory_pressure_events	{collect, memory_pressure_events, PK_memory_pressure_events, 1,596, 9, 7, 5, 0, 0, 0}	1,596		Unchanged	collect	Table	memory_pressure_events	9	0	7	0
5	0	False	PK_blocking_deadlock_stats	{collect, blocking_deadlock_stats, PK_blocking_deadlock_stats, 1,504, 9, 7, 5, 0, 0, 0}	1,504		Unchanged	collect	Table	blocking_deadlock_stats	9	0	7	0
8	0	False	PK_SqlServerVersions	{dbo, SqlServerVersions, PK_SqlServerVersions, 452, 17, 10, 8, 0, 0, 0}	452		Unchanged	dbo	Table	SqlServerVersions	17	0	10	0
2	0	False	PK_collect_deadlocks	{collect, deadlocks, PK_collect_deadlocks, 378, 165, 160, 2, 1, 1, 0}	378		Unchanged	collect	Table	deadlocks	165	1	160	1
94	0	False	PK_blocked_process_xml	{collect, blocked_process_xml, PK_blocked_process_xml, 218, 111, 102, 94, 0, 0, 0}	218		Unchanged	collect	Table	blocked_process_xml	111	0	102	0
1	0	False	PK_server_configuration_history	{config, server_configuration_history, PK_server_configuration_history, 172, 9, 2, 1, 0, 0, 0}	172		Unchanged	config	Table	server_configuration_history	9	0	2	0
1	0	False	PK_ignored_wait_types	{config, ignored_wait_types, PK_ignored_wait_types, 124, 9, 2, 1, 0, 0, 0}	124		Unchanged	config	Table	ignored_wait_types	9	0	2	0
1	0	False	PK__HealthPa__40D1892482FF1E90	{collect, HealthParser_SevereErrors, PK__HealthPa__40D1892482FF1E90, 84, 9, 2, 1, 0, 0, 0}	84		Unchanged	collect	Table	HealthParser_SevereErrors	9	0	2	0
3	0	False	PK_critical_issues	{config, critical_issues, PK_critical_issues, 69, 9, 5, 3, 0, 0, 0}	69		Unchanged	config	Table	critical_issues	9	0	5	0
11	0	False	PK_collect_blocking_BlockedProcessReport	{collect, blocking_BlockedProcessReport, PK_collect_blocking_BlockedProcessReport, 39, 27, 20, 11, 0, 0, 0}	39		Unchanged	collect	Table	blocking_BlockedProcessReport	27	0	20	0
1	0	False	PK_collection_schedule	{config, collection_schedule, PK_collection_schedule, 32, 9, 2, 1, 0, 0, 0}	32		Unchanged	config	Table	collection_schedule	9	0	2	0
1	0	False	PK__HealthPa__40D18924D5985191	{collect, HealthParser_PendingTasks, PK__HealthPa__40D18924D5985191, 19, 9, 2, 1, 0, 0, 0}	19		Unchanged	collect	Table	HealthParser_PendingTasks	9	0	2	0
1	0	False	PK_server_info_history	{config, server_info_history, PK_server_info_history, 3, 9, 2, 1, 0, 0, 0}	3		Unchanged	config	Table	server_info_history	9	0	2	0
1	0	False	PK_deadlock_xml	{collect, deadlock_xml, PK_deadlock_xml, 2, 18, 5, 1, 0, 0, 0}	2		Unchanged	collect	Table	deadlock_xml	18	0	5	0
1	0	False	PK_trace_flags_history	{config, trace_flags_history, PK_trace_flags_history, 1, 9, 2, 1, 0, 0, 0}	1		Unchanged	config	Table	trace_flags_history	9	0	2	0
0	0	False	PK__HealthPa__40D189240B4A838E	{collect, HealthParser_SignificantWaits, PK__HealthPa__40D189240B4A838E, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_SignificantWaits	0	0	0	0
0	0	False	PK__HealthPa__40D18924E04DD8D6	{collect, HealthParser_SchedulerIssues, PK__HealthPa__40D18924E04DD8D6, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_SchedulerIssues	0	0	0	0
0	0	False	PK__HealthPa__40D18924BA11BFAD	{collect, HealthParser_MemoryNodeOOM, PK__HealthPa__40D18924BA11BFAD, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_MemoryNodeOOM	0	0	0	0
0	0	False	PK__HealthPa__40D189244817DFA2	{collect, HealthParser_MemoryBroker, PK__HealthPa__40D189244817DFA2, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_MemoryBroker	0	0	0	0
0	0	False	PK__HealthPa__40D18924829C28C8	{collect, HealthParser_MemoryConditions, PK__HealthPa__40D18924829C28C8, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_MemoryConditions	0	0	0	0
0	0	False	PK_installation_history	{config, installation_history, PK_installation_history, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	config	Table	installation_history	0	0	0	0
0	0	False	PK__HealthPa__40D18924704BDB2B	{collect, HealthParser_IOIssues, PK__HealthPa__40D18924704BDB2B, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_IOIssues	0	0	0	0
0	0	False	PK__HealthPa__40D18924534ED5C8	{collect, HealthParser_CPUTasks, PK__HealthPa__40D18924534ED5C8, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_CPUTasks	0	0	0	0
0	0	False	PK__HealthPa__40D18924AB5DD324	{collect, HealthParser_Blocking, PK__HealthPa__40D18924AB5DD324, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_Blocking	0	0	0	0
0	0	False	PK__HealthPa__40D189247DB03CF3	{collect, HealthParser_Deadlocks, PK__HealthPa__40D189247DB03CF3, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_Deadlocks	0	0	0	0
0	0	False	PK__HealthPa__40D189249342E274	{collect, HealthParser_WaitsByCount, PK__HealthPa__40D189249342E274, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_WaitsByCount	0	0	0	0
0	0	False	PK__HealthPa__40D18924D9CDFC15	{collect, HealthParser_SystemHealth, PK__HealthPa__40D18924D9CDFC15, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_SystemHealth	0	0	0	0
0	0	False	PK__HealthPa__40D189241FC08CA8	{collect, HealthParser_WaitsByDuration, PK__HealthPa__40D189241FC08CA8, 0, 0, 0, 0, 0, 0, 0}	0		Unchanged	collect	Table	HealthParser_WaitsByDuration	0	0	0	0

[erikdarlingdata]

@jirish-hcs interesting. When was that from? At some point I stopped collecting query plans for query stats and procedure stats (and added an option to skip that and query text for query store), then changed the dashboard to just try to fetch from the server on demand. I'd have to look to see when precisely that was, though the query store change was recent.

Anyway, I'm looking at two approaches for this:

1. Deduplication logic on insert, to only log changed rows
2. Column compression (COMPRESS/DECOMPRESS)

The column compression is quite promising:

Summarized:

2016:

2017:

2019:

2022:

2025:

[jirish-hcs]

@erikdarlingdata, that was from minutes before I posted the message. It was right after the release of 2.0.0. I had installed 1.3.0 and then went through and upgraded the dashboard and databases to 2.0.0. I have not yet upgraded any of the later 2.0.0 sub-releases.

Compression is a good plan, I think. I was testing this out as a long-term collection to get a baseline, but when we started getting space alerts on disk the easiest and fasted way to resolve that was to drop the database. Especially since it was growing so rapidly, albeit unexpectedly.

I was headed out here to see if anyone else had run into this and found the thread and added my rusty 2 cents.

I don't know if the databases that I'm watching are that much more transactional than what you're expecting, but I can say that I did not adjust any settings on retention or collection frequency. All base install.

[erikdarlingdata]

@jirish-hcs gotcha, thanks! I'll try to have a dev build with some fixes in this area in the next couple of days if you're willing to try it again. There's a little complexity on schema migration (upgrade path) and then decompressing dashboard-side to work through.

What I'm quite surprised by is the log file size you posted. The database is in simple recovery and the log growth increments are 64MB. Maybe it got picked up by an index maintenance job or something?

[erikdarlingdata]

@StanYan @jirish-hcs — this has been addressed in PR #433 (merged to dev).

The fix applies COMPRESS()/DECOMPRESS() to all LOB columns (query_text, query_plan_text, query_sql_text, compilation_metrics) plus row-hash deduplication so unchanged rows aren't re-inserted each collection cycle.

Storage reduction on a busy test server (sql2022):

• query_stats: 2,480 MB → 219 MB (91% reduction)
• query_store_data: 2,449 MB → 236 MB (90% reduction)
• procedure_stats: 11 MB → 1 MB (91% reduction)

This will be in the next nightly build (v2.2.0). Existing installations will auto-migrate data via the upgrade scripts — the migration compresses historical data in batches so it doesn't require downtime.

[erikdarlingdata]

Hey @StanYan — we just merged an uninstall option into dev (PR #432). When the next release goes out, you'll have three ways to fully remove Performance Monitor:

1. CLI: PerformanceMonitorInstaller.exe <server> <user> <pass> --uninstall
2. GUI installer: Connect to the server → click the Uninstall button
3. SSMS: Run install/00_uninstall.sql directly

This cleans up everything: all 3 Agent jobs, both Extended Events sessions, server-side traces, and the PerformanceMonitor database.

[jirish-hcs]

@jirish-hcs gotcha, thanks! I'll try to have a dev build with some fixes in this area in the next couple of days if you're willing to try it again. There's a little complexity on schema migration (upgrade path) and then decompressing dashboard-side to work through.

What I'm quite surprised by is the log file size you posted. The database is in simple recovery and the log growth increments are 64MB. Maybe it got picked up by an index maintenance job or something?

@erikdarlingdata, the Database was set to a Full Recovery Model. That was not on purpose, it was just how it was created. I suspect that was caused by the Model DB being set to a Full Recovery Model. Any DB that is set to a Full Recovery Model has the log backed up every 15 minutes, that may attribute to the small Log size (maybe). The log growth on that Server is much smaller, both in initial size and allocation, than I would like but that is another story for another time.

Of course I am willing to try again! I want this excellent tool to improve not be abandoned! I just will watch it more closely and I will be checking the retention settings right away. Though maybe that could be a future feature in the Dashboard or the PerformanceMonitorInstallerGui.exe? Yes, it is fine to have it in the DB, but for a Freshman DBA sometimes it is good to have to UI tooling.

[erikdarlingdata]

@jirish-hcs that shouldn't be the case. The database gets created, and then set to simple. Unless you're on a PaaS offering where I can't control that part, or someone did something to it after the fact. Perhaps some automated process? Hard to say.

Just as a heads up, the collector schedule and retention duration are both visible and editable from the Dashboard already:

[erikdarlingdata]

Fixed in PR #433 (merged to dev). COMPRESS()/DECOMPRESS() on all LOB columns achieves 90-91% storage reduction, plus row-hash deduplication to skip unchanged rows between collection cycles. Will be in v2.2.0.