views:

19

answers:

1

Hi,

We have mirroring set up between 2 SQL Server 2005 standard editions. There are also mirroring alerts set up as follows: DB Mirroring (Connection with Mirror Lost) DB Mirroring (Connection with Principal Lost) DB Mirroring (Principal Running Exposed) DB Mirroring (Synchronizing Mirror) DB Mirroring (Synchronizing Principal) Mirror commit overhead exceeds the threshold (MIRROR) Oldest unsent transaction exceeds the threshold (PRINCIPAL) Unrestored log exceeds the threshold (MIRROR) Unsent log exceeds the threshold (PRINCIPAL)

"Oldest unsent transaction exceeds the threshold" alert was generated a lot of times in last coupld of days. But this alert wasn't specifically for a database. It was just average value.

I thought that this information should be in a table and I found that it was msdb.dbo.dbm_monitor_data table. It holds data like log_flush_rate ,send_queue_size,send_rate,redo_queue_size,redo_rate,transaction_delay and transactions_per_sec with database names. Then i wondered how is this table populated. For this i found that the mirroring monitoring job that SQL server creates "Database Mirroring Monitor Job" runs an sp sp_dbmmonitorupdate which populated this table from Mirroring perfmon counters. This job runs every minute.

The alert was generated for example at 11:23:52. The jobs only runs once a minute, still it managed to capture data at 11:23:00 and then at 11:23:52 (when the alert was generated) that is twice in the minute.

I thought that may be, when the alert is generated, it also runs this stored procedure. If it updated the table, then I can just run a select statement. But how can I be sure?

Problem: how can I find out why this table was updated without schedule? what triggered its population? Does anyone know which table holds alerts history data?

NOTE:No rebuild index jobs were running and the mirroring thresholds have been set as in the following screenshot: alt text

Can anyone help please?

thanks in advance

A: 

Answer: sp_dbmmonitorupdate raises errors which in turn raises alerts and hence populates table. I digged in all mirroring stored procedures and tables to find this. :-)

Manjot