Identificación de cuellos de botella en la base de datos MessageBox

Para identificar cuellos de botella en la base de datos MessageBox, asegúrese primero de que se inicie el servicio SQL-Server-Agent. Cambie el estado de inicio del servicio de Manual a Automático para que, incluso si se reinicia el servidor, el servicio se reiniciará automáticamente.

De forma predeterminada, el servicio de BizTalk controlará si crecen las tablas Spool, TrackingData o ApplicationQ. Estas tablas se eliminan mediante trabajos de SQL-Agent, los cuales, si no se ejecutan, provocarán un aumento del Spool, lo que provocará la activación de la limitación para proteger la base de datos de la presión adicional. Compruebe el estado de los siguientes contadores de rendimiento:

• BizTalk:Message Agent (nombre de host) Estado de limitación de entrega de mensajes

• BizTalk:Message Agent (Nombre del anfitrión) Estado de restricción de publicación de mensajes

  Un valor de 0 indica que no se está produciendo ninguna limitación. Un valor de 6 indica que el sistema se está ralentizando debido al crecimiento de la base de datos. Consulte la documentación sobre cómo interpretar otros valores de estos contadores.

Crecimiento de la tabla de spool

El spool puede empezar a crecer por varias razones. Una razón para el crecimiento de Spool es si las colas de aplicaciones están creciendo. Podrían crecer debido a varias razones, como cuellos de botella aguas abajo o contención de recursos.

Si las colas de aplicaciones son pequeñas y el Spool sigue siendo grande, compruebe que los trabajos de purga se realizan a tiempo. Asegúrese de que el servicio SQL-Agent se está ejecutando y compruebe que los trabajos siguientes se completan correctamente:

• MessageBox_Message_Cleanup_BizTalkMessageBoxDb

• MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

  Si la tabla MessageZeroSum es grande, indica que los mensajes se han procesado (DeQueue ha completado y eliminado correctamente los datos de las tablas de cola de aplicaciones) y las filas se han marcado para su eliminación. Sin embargo, los trabajos de purga no pueden eliminar los datos a tiempo. Una razón para esto es si la máquina SQL-Server está experimentando una contención grave de CPU, afectando la capacidad de los trabajos de purga para mantenerse al día debido a la escasez de CPU.

Crecimiento de la tabla de cola de aplicaciones

Las colas de aplicaciones hospedan datos de transición en proceso que, una vez que son procesados, son depurados por DeQueue.

Una vez procesados estos mensajes, se puede limpiar el depósito (que contiene referencias a estas filas).

Por ejemplo, RxHostQ publica datos a la orquestación PxHostQ, que a su vez publica datos al envío TxHostQ, cada uno referenciando una fila en la tabla Spool. Después de que los mensajes para un HostQ en particular se han procesado correctamente a través del sistema, DeQueue elimina estas filas. Una vez eliminadas estas filas, el Spool (al que ya no hacen referencia estas) puede ser limpiado por los trabajos de purga.

El crecimiento de la cola de aplicaciones indica que las instancias de host responsables de vaciar la cola de aplicaciones no pueden mantenerse al día con la velocidad entrante, es decir, la velocidad a la que se publican los mensajes en la cola de aplicaciones en particular.

Por ejemplo, la cola de aplicaciones de orquestación (PxHostQ) puede crecer porque el servidor responsable de procesar orquestaciones está enlazado a la CPU y no puede procesarlo más rápido. Sin embargo, si el servidor receptor es rápido, puede publicarlo más rápido que lo que puede procesar el servidor de orquestación que conduce al crecimiento de la cola de aplicaciones.

Otro motivo para el crecimiento de la cola de orquestación podría deberse a la contención de memoria, por lo que muchas instancias de orquestación de larga duración se instancian simultáneamente en la memoria, lo que provoca un exceso de memoria que indirectamente causa una reducción del grupo de subprocesos hasta que se alivia la presión sobre la memoria. Una razón por la que la cola de la aplicación de envío puede crecer es si el sistema receptor no puede recibir mensajes que provienen de BizTalk lo suficientemente rápido. Por lo tanto, los mensajes seguirán permaneciendo en el sistema BizTalk, lo que provocará un crecimiento de la cola de aplicaciones que, a su vez, activará la limitación automática, reduciendo la tasa de recepción y afectando al rendimiento general del sistema.

Crecimiento de la Tabla de Datos de Seguimiento

La tabla TrackingData de la base de datos MessageBox es una tabla de transición a la que los interceptores escriben datos de seguimiento para el seguimiento de instancias de mensaje y servicio y el seguimiento de BAM. Si el seguimiento está deshabilitado, esta tabla debe estar vacía. De forma predeterminada, el seguimiento de instancias de servicio y mensajes está habilitado para las canalizaciones y orquestaciones de eventos de entrada y salida.

Si el seguimiento del cuerpo del mensaje está habilitado, asegúrese de que se esté ejecutando el servidor de MessageBox (es decir, el host con "permitir el seguimiento del host"). Reducirá un cuello de botella a medida que mueve datos de la tabla TrackingData de la base de datos MessageBox a las tablas de BizTalkDTADb.

Es posible realizar un seguimiento de eventos personalizados habilitando el seguimiento de mensajes personalizados y de instancias de servicio, por ejemplo, sobre las propiedades promocionadas y el cuerpo del mensaje. Además de realizar el seguimiento de los datos, los datos de BAM también se escriben en esta tabla. Es responsabilidad de TDDS (el host en el que está habilitado el seguimiento) mover estos datos de la base de datos de cuadro de mensajes a las bases de datos BizTalkDTADb y BAMPrimaryImport y, después, una vez movidos correctamente, elimine estos datos. Los datos de seguimiento del cuerpo del mensaje se trasladan por separado mediante un trabajo SQL-Agent llamado TrackedMessages_Copy_BizTalkMsgBoxDb.

Si TDDS no puede mantenerse al día con el ritmo al que los interceptores escriben datos en la tabla TrackingData, esta tabla crecerá, lo que hará que se active la limitación del rendimiento, afectando finalmente al rendimiento sostenible. Para solucionar este problema, asegúrese de que al menos 1 host se está ejecutando con el seguimiento habilitado.

Si los datos se siguen acumulando, compruebe la base de datos BizTalkDTADb para asegurarse de que la base de datos no está creciendo fuera del control. Asegúrese de que el trabajo de archivado y purga se está ejecutando y pueda mantenerse al día con la velocidad a la que llegan los datos.

Nota:

El trabajo de purga no puede eliminar datos de las tablas de BizTalkDTADb hasta que estos datos se hayan archivado.

Compruebe que la tabla TrackingData no está creciendo. Asegúrese de que al menos una instancia de host que se esté ejecutando tenga habilitado el seguimiento (TDDS). Si la base de datos BizTalkDTADb ha crecido demasiado grande, puede tener un impacto negativo en la capacidad de TDDS para mover datos de la base de datos cuadro de mensajes a la base de datos BizTalkDTADb.

El crecimiento en la tabla TrackingData puede provocar que el estrangulamiento comience, afectando el rendimiento sostenible durante el tiempo de ejecución.