Alta E / S de disco tempdb durante la replicación de combinación de BLOB

Al tener una publicación de combinación para replicar BLOB (tipo image), obtuve E / S de disco tempdb muy altas para mi tamaño de datos. La publicación es de solo descarga y no tiene filtros.

La alta E / S del disco es causada por la sincronización (cuando no hay suscriptores sincronizados, todo está bien), fuertemente correlacionado con el número de suscriptores. Sucede incluso cuando no se cambian datos en Publisher entre sincronizaciones, y eso me molesta.

• Tamaño de la tabla replicada: 7 MB (el recuento total de filas es de aproximadamente 100)
• tempdb I / O: ~ 30 MB / seg para escritura (archivos de registro y datos)
• Número de suscriptores: un poco más de 100, cada uno sincronizándose cada 30 minutos (más o menos uniformemente).
• Período de retención establecido en 14 días.

Usando SQL Server 2008 en Publisher, SQL Server 2005-2008R2 en suscriptores. Todos los suscriptores usan la sincronización web.

Además, la sincronización en el suscriptor lleva mucho tiempo, con múltiples ocurrencias replmerg.logcomo estas:

DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload     

DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload

Intento de @stream_blob_columnsencendido y apagado sin efecto.

La pregunta es: ¿es una buena idea usar la replicación de mezcla para enviar estos blobs a los suscriptores? Tenemos otras publicaciones (aunque no tienen columnas BLOB) con muchos datos sin problema de tempdb. ¿Es una falla de SQL Server o una mala configuración?

El editor y el distribuidor están en la misma instancia, SQL Server 2008 SP4, no pueden estar seguros acerca de los suscriptores, algunos de ellos tal vez no estén actualizados. De todos modos, puedo preparar un entorno de prueba con pocos suscriptores que tengan versiones controladas, si parece que ayuda.

Confirmado, ese uso excesivo de tempdb causado por la ejecución de sys.sp_MSenumgenerations90. MSMerge_genhistoryTabla marcada , encontrada más de 1.2 millones de registros donde pubides nulo.

Encontré esta conversación con el gurú de la replicación:

Ejecutado sp_mergemetadataretentioncleanupsin efecto.

Encontré un comentario en un caso como este (demasiadas filas MSmerge_genhistory) donde eliminar filas donde pubides nulo y genstatus= 1 ayudó a corregir la replicación.

Las filas eliminadas donde pubides nulo (lo que implica que todos los suscriptores están sincronizados, y que no lo están, se reinicializarán en "modo manual") y el disco IO vuelve a la normalidad de nuevo.

Tengo la sensación de que esta situación podría ser causada por el hecho de que todos mis suscriptores son anónimos a través de WebSync y la mayoría de ellos tienen el mismo nombre de host. Intentaré verificar si la -hostnameclave ayuda a no multiplicar registros MSmerge_genhistory.

Hay un blog de TechNet que analiza algunos problemas de replicación de fusión con blobs en un servidor SQL Server 2008 o superior.

http://blogs.technet.com/b/claudia_silva/archive/2011/10/31/replication-watch-out-for-stream-blob-columns-when-setting-up-replication-on-your-sql- 2008-server.aspx

Tenga en cuenta que el autor advierte sobre qué configuración usar cuando hay clientes de SQL Server 2005, como usted.

Tuve un problema similar con un servidor de clientes que no pudo solucionarse. La gran cantidad de E / S ralentizó el almacenamiento y afectó a varios sistemas. No puedo proporcionar una solución para resolver la causa en sí, pero podría ser una opción (temporal) que resuelva el problema resultante y le brinde más tiempo para identificar y resolver la causa.

Hemos resuelto el problema IO al mover tempdb a un ramdisk. En nuestro caso, tuvimos que actuar rápido, ya que otros sistemas se volvieron temporales sin responder debido a problemas de rendimiento. En lugar de cambiar la configuración del servidor, copiamos los archivos tempdb al ramdisk, creamos una copia de seguridad de los archivos originales y los reemplazamos por enlaces simbólicos. El ramdisk carga una imagen que contiene los archivos tempdb. Los servicios sql se han retrasado para asegurarse de que el disco RAM se haya iniciado y cargado la imagen antes de que comience el servicio sql. El tiempo de inactividad efectivo para cambiar de disco a ram tardó menos de un minuto.

En nuestro caso, mejoramos el rendimiento de forma masiva y resolvimos el problema con el almacenamiento. La solución funciona muy bien para nuestros clientes y al final se ha convertido en una solución permanente.

Brent define por qué necesitamos aumentar el archivo de datos tempDb. Puede consultar el siguiente enlace

https://www.brentozar.com/blitz/tempdb-data-files/