Error log history in DBHealthHistory

What this check looks for

Rows written to DBHealthHistory.dbo.ErrorLog in the last three hours. The check only runs when a DBHealthHistory database exists.

Each finding carries the time, the SQL error number, the message and the name of the procedure that raised it.

Why it matters

This one is different from every other check in the report. It is not about your SQL Server. It is about ours.

DBHealthHistory.dbo.ErrorLog is where Database Health Monitor’s own collection code records errors it hit while gathering history. A row here means a collector procedure raised an error, and the consequences are on the monitoring side rather than the database side:

  • A collection may have been skipped, so there is a gap in the history for that period. The history reports will draw a line across the gap rather than showing one, which is why a missed collection is easy not to notice.
  • A gap is invisible in exactly the way that matters. A missing sample looks like a quiet period. If the collector failed during an incident, the record of the incident is what is missing.

The three hour window is deliberate. This is a live signal about whether collection is working now, not an audit of everything that has ever gone wrong.

The most useful thing to do with these is send them to us. The error number and the procedure name identify the collector, and that is usually enough for us to fix it. Several of these are things only reproducible against a particular version, edition or configuration that we do not have here.

How to confirm it yourself

USE [DBHealthHistory];

SELECT TOP (200)
       [logTime],
       [ErrorNumber],
       [ErrorMessage],
       [ProcName]
  FROM [dbo].[ErrorLog] WITH (NOLOCK)
 ORDER BY [logTime] DESC;

Is this a one off or a pattern?

USE [DBHealthHistory];

SELECT [ProcName],
       [ErrorNumber],
       COUNT(*)       AS [occurrences],
       MIN([logTime]) AS [first_seen],
       MAX([logTime]) AS [last_seen]
  FROM [dbo].[ErrorLog] WITH (NOLOCK)
 GROUP BY [ProcName], [ErrorNumber]
 ORDER BY [occurrences] DESC;

A single row from three hours ago is a blip. The same procedure and error number appearing every hour for a month is a collection that has never worked on this instance.

How to fix it

Send them to us. That is the honest answer for most of these, and the Quick Scan has a built in way to do it: the Send to Steve action in the scan report packages the findings up. Otherwise, the output of the grouping query above is exactly what we need, and databasehealth.com has the contact details.

Before you do, there are two things worth checking on your side, because they cause a large share of these:

  1. Permissions. Several collectors read DMVs and catalog views that need VIEW SERVER STATE, VIEW DATABASE STATE or membership in a role the collection account may not have. The error number usually says so directly: 297 and 300 are permission errors.
  2. Version and edition. A collector reading a DMV that does not exist on an older version, or on Azure SQL or Amazon RDS, raises an error rather than returning nothing. Error 208, invalid object name, on a DMV name is the signature.

Both of those we would rather fix in the product than have you work around, so please report them either way.

Do not clear the table as a way of making the finding go away. It is the record we would need, and the check only reads the last three hours anyway, so it clears itself.

How long it takes

About an hour, most of it gathering the detail to send.

Report Why you would go there
Historic Overview Whether the history has gaps where collection failed.
Data Collector The collector’s own state and schedule.
Historic Options What is configured to be collected, and how often.
Agent Security The account the collection runs as, for permission errors.
Job History Whether the collection job itself is failing.
Check
DBHealthHistory data file is too large The same database, a different symptom.
Large tables in DBHealthHistory database One collection writing far more than the others.
Stedman jobs failing The monitoring jobs failing outright rather than logging an error.

Frequently asked questions

Is this a problem with my SQL Server? Usually not. It is the monitoring reporting its own trouble. The exception is a permission or availability error, where the collector is correctly reporting that it could not read something.

Why only three hours? So it tells you whether collection is working now. The grouping query above gives you the whole history when you want it.

Can I stop this check? It only fires when there are recent errors, so fixing or reporting them is what stops it. Clearing the table stops it too, and loses the evidence.

What should I send? The output of the grouping query: procedure name, error number, count, first and last seen. That identifies the collector and tells us whether it ever worked here.