Database Health Monitor 4.1869: 33 New Reports That Put Your History to Work, Plus Printing and PDF
Database Health Monitor version 4.1869 is the release where the history database stops being a place we store numbers and becomes the source of answers. It adds 33 new reports, most of them built on the monitoring history the collector has been saving, plus printing and PDF output from every page, a much larger set of Dashboards tiles that stays quick with dozens of servers, high availability and SQL Agent job history that now outlives msdb, and 973 fixes.
This post walks through the release in the order you are most likely to use it. If you only want the headline, read the sections on the history reports and on printing, then come back for the rest once the installer is running.
The theme: making the history database earn its keep
A live DMV report answers the question “what is happening right now?” That is the right tool when something is on fire. It is the wrong tool for the questions that come the next morning: when did this start, who changed it, is it getting worse, and when will it run out? Those questions need a record, and Database Health Monitor has kept one for years in its history database. Version 4.1869 adds a large group of reports that read that record directly.
Each of the new reports takes one question that a team asks again and again and answers it from history. Reports that depend on history also show where the history begins and where the collector was not running, so a gap is never mistaken for a quiet period. Instance reports run from the instance node in the tree and Database reports run from a database node.
Collection health and coverage
Before you trust a trend, you want to know the data behind it is complete. Monitoring Coverage shows which collectors ran, the gaps in each history table, any collector errors, and how the resolution of the data drops as it ages. If a graph looks flat because the collector was stopped for a weekend, this is the report that says so.
CHECKDB Cadence answers a question that the last CHECKDB date cannot: how often each database really got a clean check. It reports the longest unchecked stretch and every miss, built from history, so a database that was checked last night but went six weeks unchecked before that is not hidden by a recent success.
Estate Health Scorecard puts every monitored instance side by side, week by week, for CPU, waits, page life expectancy, connections and blocking. The instance that is drifting stands out because the others are next to it. Monthly Health Summary then produces one printable page per instance per month covering uptime, backups, CHECKDB, growth and peaks, written so it can be handed to a manager or an auditor without a meeting to explain it.
Waits, blocking and workload
Blocking Culprits looks at 30 days of blocking and ranks the head blockers by the number of sessions they held up and the seconds they held them. Blocking is usually blamed on whoever was waiting. This report names the sessions at the front of the line.
Wait Profile Shift by Query finds statements whose dominant wait changed from one week to the next. A statement that used to wait on CPU and now waits on disk has lost its data from memory or moved to a scan. One that moved to locks has a new concurrency problem. The report shows the change and what it usually means, so the conversation starts at the cause.
Wait Anomaly Calendar compares every hour of a database’s waits with that database’s own normal for that hour of the week, over 30, 60 or 90 days. What Changed compares one window with the previous four weeks, but you have to know when to look. This page does the looking and marks the hours that were not normal.
Noisy Neighbor Databases shows each database’s share of the instance waits by day and which database’s spikes line up with slowdowns in the others. On an instance that hosts many databases, this is how you find the one that is hurting the rest.
Long Running Query Trends groups recurring long runners by query hash and shows which are getting slower, when they start, and whether they are working or waiting. New and Vanished Queries lists statements first seen recently and statements that stopped appearing, with what each costs in waits, which is a quick way to see the effect of a deployment. Memory Grant Waits History shows when queries queued for workspace memory, for how long, which statements and how often. Connection Leak Detector spots session counts that climb between restarts without any rise in work, and names the applications behind them.
Memory, storage and capacity
Buffer Pool Share Over Time shows each database’s memory residency by hour: who grew, who was pushed out, and when. PLE Drop Forensics goes after every page life expectancy collapse and lists the queries, reads and memory events around it, so a sudden drop has a suspect list instead of a shrug.
Storage Saturation Curve plots disk latency against I/O load for each drive. If latency stays flat as load rises, the storage is fine. If latency climbs steeply at modest load, the storage is the problem. File Latency Trend shows read and write latency for each database file by day for 90 days and flags the regressions. Autogrowth and Shrink Events lists every file growth and shrink from the size history and calls out tiny growth storms and shrink then grow loops. Log Growth and Log Backups lines up log file growth with late log backups, open transactions and big jobs.
Database Space Runway looks at the free space inside the data files, the growth of the tables, the next autogrowth and the date the drive fills. CPU Capacity Forecast takes the peak hour CPU trend by month and projects the date the busiest hour reaches the limit. These two turn “we should watch that” into a date you can put on a calendar.
TempDB Consumer Trends adds up the recurring tempdb users over weeks, by statement and login, with the drivers of version store growth. The existing live tempdb pages show a single moment. This one shows who is responsible week after week. Restart Recovery Profile measures, after each restart or failover, how long page life expectancy, CPU, compiles and waits took to settle back to normal, which is the number you want before promising anyone how long a patch window really lasts.
Tables, indexes and schema
Index Adoption and Abandonment lists new indexes and whether they ever got used, and indexes that were used and then stopped. Cold Data Finder lists large tables that are rarely read, sized against their activity, as candidates for archiving or compression. Table Shrink and Purge Watch looks for tables that lose rows, purge jobs that stopped running, sudden drops, and space that was never given back.
Database Activity Calendar shows every database’s days of reads, writes and sessions from history and names the idle ones. Schema Change Analytics shows who changes what, finds deployments in the DDL log, and highlights out of hours changes and their impact.
People, logins and Agent jobs
Who Uses This Database lists the logins, hosts and programs seen over time, newcomers, ones that have gone quiet, and the days each was active. Dormant Logins and Applications turns the same history into a cleanup list of logins, hosts and programs that have not been seen working for months.
Agent Job Resource Cost reports CPU, reads and writes for each SQL Agent job per run and per day, trending over time, and shows what each job overlaps with. Job Duration Trends shows each job’s run durations over time with the runs that took longer than usual picked out. Job Timeline draws a cross server timeline of Agent job runs so overlapping jobs and the long ones are visible at a glance.
High availability gets a history
Until now the Availability Groups, Log Shipping and Replication reports showed the current state. Version 4.1869 begins keeping that state over time. The collector samples Availability Group RPO and RTO, failovers, log shipping latency and replication latency into new history tables, and the new HA/DR History report draws them with the events marked. The three existing reports link to it.
There are four new alerts to go with it: 5031 for Availability Group data loss exposure, 5032 for an Availability Group that is not healthy or has failed over, 5033 for log shipping that is behind and 5034 for replication latency. The history database upgrades itself to add the tables the first time the new version runs.
Agent job history that outlives msdb
The msdb database keeps job history only as long as its retention settings allow, and busy servers often keep very little. Version 4.1869 stores job runs in the history database past msdb’s own retention, with a baseline for each job and a threshold dialog for deciding what counts as unusual. Alert 5023 covers the case no run time threshold can: a job that has stopped running when it should have run.
Print any page, save any page as a PDF
Reports have always been easy to read on screen and awkward to hand to someone else. Version 4.1869 adds printing and PDF output across the product. Ctrl+P prints the page you are looking at and Ctrl+Shift+P saves it as a PDF, with Print Options on the Database menu. Every grid menu gains Print Grid and Save Grid as PDF, and every chart menu gains Print Chart and Save Chart as PDF.
A few details matter in practice. Printouts are drawn in light colors on white whatever the screen theme, so a dark mode screen does not produce a page of ink. A historic time window is written into the header, so a printout says which period it covers. Pages that know better supply their own printout, and HTML pages print through the browser. The Dashboards page prints a board through the same shared print shell. A new help page, Printing and Saving as PDF, covers the details.
Dashboards: more tiles, faster, and easier to share
Version 4.1818 introduced Custom Dashboards, and this release extends them in four directions.
More report tiles
Another 15 instance reports get a tile that shows the report’s own headline instead of a link. Connections Over Time shows the hour of day profile of peak connections. Memory Grants and Spills shows queued, granted and used grants, timeouts and forced grants. Deadlocks By Hour and Long Running by Hour draw week by hour heat grids. Others cover deadlocks by database, deadlock objects, tempdb metadata contention, the email alert log, the logins behind schema changes, memory pressure events on a timeline, chargeback by database, Backup SLA, linked servers, session waits and host hardware.
Database page tiles
A new tile family covers the pages under a database and is driven by the Database variable in the board header. The tiles are Database Overview, Files, Backup Size, Backup Time Frames, Recovery Exposure, VLFs, Table Size, Unused Indexes, Missing Indexes, Index Fragmentation (with a Scan now button), Statistics, File Size Over Time, Query Store Health and Untrusted Constraints. Each one uses the same bands and verdicts as the page it summarizes, so a tile and its page agree.
Sizing, shapes and readability
Report tiles take a default size from their shape, and category boards pack them by shape and importance. One big number size rule, small, medium or large, is shared by KPI, report, gauge and stat strip tiles, with the state arrow on all of them. Healthy items are drawn green like the status list, color blind mode is honored, and heat tiles get unique day labels, regional hour labels, a scale legend and a cell tooltip. Items in a report tile show a tooltip with the full name and value, a click opens the report on that item and that database, and the arrow keys walk the items.
Menus, sharing and scale
The 33 item Board menu is split into Board and View menus, with Board settings as the one home for every option. A built in board offers Customize, which copies it and opens the copy in Edit mode in one step. Add to dashboard on reports and Server Overview cards places the matching tile on a board you choose. Copy link on a published board opens that shared board for a teammate with its range, server and variables.
Underneath, refreshes now cancel superseded and abandoned queries, pause while the window is minimized, and load off screen tiles as you scroll. Live tiles read all of a board’s live metrics in one pooled, named connection per server per poll, and estate tiles scale to 50 or more servers without thread pool starvation or false “did not answer” rows. Event metrics such as blocking, deadlocks and errors count a quiet period as zero rather than showing the last event as current.
Help, documentation and the monitoring service
Every new report has a help page, and there are new pages for Printing and Saving as PDF, Connection Problems, Patch Currency, Pop Out Windows and the Monitoring Service and Tray Application, which now documents the service only secrets file used for SQL and SMTP passwords. The new reports and more than 25 existing query tuning and storage reports have real screenshots captured from the sample database.
973 fixes
This release also includes 973 bug fixes across Database Health Monitor, Azure SQL Health Monitor, Schema Drift, Data Compare, Query Loading Ramp, the monitoring service and the tray application, including 15 crash reports. The largest group came from the code review sweeps of the 33 new reports and the new Dashboards tiles. The rest cover the Badge of Shame and plan analysis checks, Quick Scan security checks, Availability Group and Agent job pages, grids that were wider than the window at 1280 by 900, and reports that gave wrong results on older versions of SQL Server and in non US cultures.
Getting version 4.1869
The release notes for version 4.1869 are included with the installer and appear after installation. Install it, let the collector run for a few days if you have not been collecting history, and open Monitoring Coverage first. Once you can see that the history is complete, the other 32 reports have something to work with.
The history reports do not need extra configuration beyond the collector and the history database you already use. The first report to try on any history database is Monitoring Coverage, because it shows how much history exists.
Three ways to start using the history reports
With 33 new reports it helps to have a plan for where to begin. Here are three routes that match the way teams usually work.
The weekly review. Open Estate Health Scorecard and look for the instance that has moved against its neighbors. Then open Wait Anomaly Calendar and Noisy Neighbor Databases for that instance, and Long Running Query Trends for the busiest database. In a few minutes you have a list of what changed this week, with the hours and the databases named. Finish with Monthly Health Summary at month end and save it as a PDF for the file.
The capacity conversation. When someone asks whether the server can take next year’s growth, open CPU Capacity Forecast, Database Space Runway and Storage Saturation Curve. CPU gives you a projected date, space gives you a drive full date, and the saturation curve tells you whether the disks have room left before latency climbs. Add File Latency Trend and Autogrowth and Shrink Events to see whether the files are behaving. The answer is then a set of dates and charts rather than an opinion.
The cleanup project. Before you retire a database, remove a login or archive a table, use Who Uses This Database, Dormant Logins and Applications, Database Activity Calendar and Cold Data Finder. They show who touched the database, when it was last busy and which tables nobody reads. Because the evidence comes from weeks of history, you can show it to the people who own the application and agree on the change with the facts in front of you.
In every case the reports link to one another and to the existing pages, so you can move from a finding to the page that explains it without hunting through the tree. Pair that with Print This Page and Save This Page as PDF and each of these routes ends with something you can attach to a ticket or send to a colleague.
Database Health Monitor version 4.1869 is available from DatabaseHealth.com.