Registro de espejo vacío en el primario pero bien en el espejo

Tenemos docenas de servidores principales y espejos correspondientes, la mayoría funciona bien, sin embargo, 1 de ellos está actuando de manera extraña. Específicamente, el sp_dbmmonitorresultsproceso devuelve todas las columnas como NULL para una base de datos de principio dada, mientras que sp_dbmmonitorresultsen el espejo devuelve información válida:

Ahora, tengo una idea aproximada de cuál fue la causa; cuando el principio y los servidores espejo estaban configurados, la configuración regional era incorrecta en la primaria (la hora era correcta pero estaba usando una región +4 (América, etc.), la región horaria se corrigió a GMT +0 DESPUÉS de la configuración espejo (escuela error de chico, lo sé, pero c'est la vie!)

Editar: 19/12/2012

Hoy eliminé la duplicación, eliminé las copias en la duplicación y volví a configurar la duplicación, sin embargo, ¡esto no resolvió el problema! Voy a hacer una recompensa por esta pregunta para tratar de llegar al fondo de esto.

Para confirmar, si ejecuto EXEC sp_dbmmonitorresults @database_name = 'ProScript'manualmente en cada servidor, devuelve NULL para la mayoría de los valores en el primario, pero devuelve bien en el espejo, como se muestra:

Cuando se ejecutó en primaria:

Zoom: haga clic para ver la versión completa

Cuando corrió en el espejo:

Zoom: haga clic para ver la versión completa

Como puede ver, los tiempos son actuales y la base de datos está sincronizada, pero ¿log_generation_rate, unsent_log, send_rate, etc vare todo NULL en el primario?

Ambos servidores tienen el trabajo de montior ejecutándose cada minuto exec sys.sp_dbmmonitorupdatecomo un paso de trabajo, etc.

Mirando la fuente de sys.sp_dbmmonitorupdate, toma estos valores sys.dm_os_performance_counters, así que si ejecuto lo siguiente en el espejo:

SELECT  counter_name ,
        cntr_value
FROM    sys.dm_os_performance_counters
WHERE   instance_name = 'ProScript'
        AND counter_name IN ( N'Log Send Queue KB', N'Log Bytes Sent/sec', N'Redo Queue KB', N'Redo Bytes/sec', N'Transaction Delay', N'Log Bytes Flushed/sec', N'Transactions/sec' )

Obtengo buenos resultados:

Sin embargo, si ejecuto el mismo SQL en el primario, ¡no hay filas!

¿Esto sugeriría que la sys.dm_os_performance_counterstabla no se está rellenando para la duplicación? ¿Qué causaría eso?

Bueno, tomó meses, ¡pero finalmente encontré el problema!

Los sys.dm_os_performance_counters no se poblaron en absoluto en el servidor primario.

Resulta que los contadores no estaban instalados, pude hacer esto manualmente de la siguiente manera:

C:\Windows\system32>lodctr "D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSS
QLSERVER\MSSQL\Binn\perf-MSSQLSERVERsqlctr.ini"

Reinicié SQL, y boom, la tabla ahora se está completando, incluidas mis estadísticas de reflejo.

¿Ha intentado eliminar el trabajo de supervisión de duplicación de la base de datos en la instancia principal y volver a crearlo?

Esto no implica reiniciar la sesión de creación de reflejo de la base de datos, simplemente abandonar y volver a crear el trabajo utilizando los mismos procedimientos almacenados utilizados por SSMS para administrar el monitor de creación de reflejo de la base de datos.

Aquí están los enlaces a las entradas de Libros en línea:

• sp_dbmmonitordropmonitoring
• sp_dbmmonitoraddmonitoring

Y un breve script de muestra:

    -- you'll need to be connected to the instance as a member
    -- of the sysadmin fixed server role, of course.

    -- delete the database mirroring monitoring job

    exec msdb.dbo.sp_dbmmonitordropmonitoring;
    go

    -- rebuild the database mirroring monitoring job
    -- the procedure accepts an optional parameter
    -- specifying the number of minutes between updates.
    -- the default is 1 minute.

    exec msdb.dbo.sp_dbmmonitoraddmonitoring;
    go