Alerting on Database Mirroring Events - by echoScout

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 657230 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 4/4/2011 12:08:28 PM
Access Restriction Public


The following Threshold Alerts, confirmed to be written to the SQL Server Log, need to be defined for the <all databases>** Database Name rather than a single named database:

  • Unsent Log Threshold (Error Message 32042)
  • Oldest Unsent Transaction Threshold (Error Message 32040)
  • Unrestored Log Threshold (Error Message 32043)
  • Mirror Commit Overhead Threshold (Error Message 32044)

This is in contrast to the documentation provided by Microsoft:

  • Technet: "Alerting on Database Mirroring Events" (

With the thresholds already defined, when one of the thresholds (e.g. Unsent Log: is exceeded for an extended period of time, the event is written to the log, however no email is sent to the Operator. I think that this is because this event (32042) is being logged as a server-level event and not a database-level event.

** When defined with <all databases>, an email is sent without specifying the database that exceeded its threshold.

See also:
Sign in to post a comment.
Posted by John Chantha on 10/13/2011 at 8:40 AM

I ran into the same issue.
I am wondering if the issue will be fixed in the next patch/release.

John Chantha

Posted by Microsoft on 8/2/2011 at 3:55 PM

We have been discussing this fix and the risk for breaking existing functionality by changing the output format (the message format) is fairly high. We decided therefore that we cannot make this change.
A workaround is to create your own alert that includes the complete message. See also

Kind regards,
Michiel Wories
SQL Server Development Lead
Posted by Microsoft on 6/28/2011 at 10:43 AM
Hey David,

Sorry for the delay, the underlined issue was identified as a core Engine issue and I'm working with corresponding team to obtain the fix.

The issue will not be classified as a hotfix required for the SQL 2008 or SQL 2008 R2. We will try to address this issue in our current release for SQL 2011.

Currently we can't recommend the workaround for this issue, hopefully when I get a response back from the Engine team we could suggest a workaround.


Posted by echoScout on 6/28/2011 at 6:25 AM
Hello Sethu & Alex,

It's been 45 days since my reply to your last response.

(1) Will this be classified as a bug and addressed in hotfixes for SQL Server 2008, 2008 R2 and 2011?
(2) What workaround will Microsoft officially recommend for this issue?

Thank you.

David Wing
Posted by echoScout on 5/24/2011 at 5:18 AM
Hello Sethu & Alex,

What is the Microsoft-recommended workaround for this issue?

Will this be classified as a bug and addressed in hotfixes for SQL Server 2008, 2008 R2 and 2011?

Thank you.

David Wing
Posted by echoScout on 5/14/2011 at 10:59 AM
Hi Sethu,

In the BYTES, the DB name is 'msdb', specifically:


, where S.E.R.V.E.R.X.X. is the SQL Server instance name.

Posted by Sethu Srinivasan on 5/13/2011 at 3:35 PM
Hello David,
When database mirroring events are generated and logged to eventlog,
db mirroring event payload does not seem to have a database context in binary blob. due to this issue, SQL Agent could not read the database context from that event log entry

on your scenario, can you check the following,
Open up Event viewer -> Application log
Double click on event logged by database mirroring
In Event Properties -> click on Details tab
scroll down and inspect Binary data "in bytes"
check if your DB name is there in those bytes

Sethu Srinivasan
SQL Server
Posted by echoScout on 5/13/2011 at 12:25 PM
Hi Alex,

It's been one month. What have you discovered/confirmed about this bug?

Posted by Microsoft on 4/14/2011 at 11:28 AM
Thank you for reporting this issue - we are investigating and we will get back to you shortly.


Alex Grach