Cómo identificar cuellos de botella en la base de datos de cuadro de mensajes
Para identificar cuellos de botella en la base de datos de cuadro de mensajes, en primer lugar debe asegurarse de que se haya iniciado el servicio del Agente de SQL Server. Cambie el estado de inicio del servicio de Manual a Automático para que, si se reinicia el servidor, el servicio se reiniciará automáticamente.
De forma predeterminada, el servicio de BizTalk limitará si crecen las tablas Spool, TrackingData o ApplicationQ. Estas tablas se eliminan mediante trabajos de SQL-Agent, lo que, si no se ejecuta, provocará que la cola de Spool crezca, lo que provocará que la limitación se inicie y proteja la base de datos frente a una presión adicional. Compruebe el estado de los siguientes contadores de rendimiento:
BizTalk:Agente de mensaje (nombre de host) Estado de limitación de entrega de mensajes
BizTalk:Agente de mensaje (nombre de host) Estado de limitació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 está limitando debido al crecimiento de la base de datos. Para obtener información sobre cómo interpretar los valores de estos contadores, consulte ¿Qué es la limitación de host? (https://go.microsoft.com/fwlink/?LinkID=154694) y contadores de rendimiento de limitación de host (https://go.microsoft.com/fwlink/?LinkID=155285) en la documentación de BizTalk Server 2010.
Crecimiento de la tabla de cola
La tabla Spool puede empezar a crecer por distintos motivos. Una razón para el crecimiento del grupo de servidores es si las colas de aplicaciones están creciendo. Podrían crecer debido a razones como cuellos de botella descendentes o contención de recursos.
Si las colas de aplicaciones son pequeñas y el grupo de servidores sigue siendo grande, compruebe que los trabajos de purga se mantienen al día. Asegúrese de que el servicio de Agente de SQL Server esté en ejecución y, a continuación, compruebe que los siguientes trabajos se estén realizando correctamente:
MessageBox_Message_Cleanup_BizTalkMessageBoxDb
MessageBox_Parts_Cleanup_BizTalkMessageBoxDb
Si la tabla MessageZeroSum es grande, indica que se han procesado los mensajes. Esto significa que 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 la velocidad necesaria. Esto puede ocurrir si el equipo que ejecuta SQL Server está experimentando una contención grave de la CPU, lo que afecta a la capacidad de los trabajos de purga para mantenerse al día debido al colapso de la CPU.
Crecimiento de la tabla de colas de aplicaciones
Las colas de aplicaciones hospedan datos de transición en curso que, una vez procesados, se limpian mediante DeQueue.
Una vez procesados estos mensajes, se puede limpiar la tabla Spool (que contiene referencias a estas filas).
Por ejemplo, RxHostQ publica datos en la orquestación PxHostQ. Esta cola publica datos en el objeto TxHostQ que envía cada una de las cuales hace referencia a una fila de la tabla Spool. Después de que los mensajes de un hostQ determinado se hayan procesado correctamente a través del sistema, DeQueue elimina estas filas. Una vez eliminadas las filas, los trabajos de purga pueden borrar el contenido de la tabla Spool (a la que estas filas ya no hacen referencia).
El crecimiento de la cola de aplicaciones indica que las instancias de host responsables de purgar la cola de aplicaciones no pueden mantenerse al día con la tasa de entrada.
Por ejemplo, la cola de aplicación de orquestación (PxHostQ) puede aumentar de tamaño porque el servidor responsable de procesar las orquestaciones está enlazado a la CPU y no puede procesar más rápidamente. Sin embargo, si el servidor receptor es rápido, puede publicarse más rápido que lo que el servidor de orquestación puede procesar, lo que conduce al crecimiento de la cola de aplicaciones.
Otra razón para el crecimiento de la cola de orquestación podría deberse a la contención de memoria. Cuando muchas instancias de orquestación de larga duración se crean instancias simultáneamente en la memoria, el sobredimensionamiento de memoria provoca indirectamente la limitación para reducir el grupo de subprocesos hasta que se alivia la presión de memoria.
Un motivo por el que puede crecer la cola de la aplicación de envío es si el sistema de bajada no puede recibir mensajes (salientes de BizTalk Server) lo suficientemente rápido. Por lo tanto, los mensajes seguirán residiendo en el sistema de BizTalk, lo que provocará el crecimiento de la cola de aplicaciones. Esto puede hacer que la limitación se inicie y reduzca la tasa de recepción que afecta al rendimiento general del sistema.
TrackingData table growth
La tabla TrackingData de la base de datos MessageBox es una tabla de transición en la que los interceptores escriben datos de seguimiento para el seguimiento de mantenimiento y actividad (HAT) y de supervisión de actividad empresarial (BAM). Si el seguimiento está deshabilitado, esta tabla debe estar vacía. De forma predeterminada, el seguimiento de HAT está habilitado para las canalizaciones y orquestaciones eventos De entrada y salida.
Si el seguimiento del cuerpo del mensaje está habilitado, asegúrese de que el servidor de base de datos messageBox (es decir, el host con "permitir el seguimiento del host") se está ejecutando. Asegurarse de que el host con "permitir el seguimiento de host" se está ejecutando reducirá la posibilidad de que se produzca un cuello de botella a medida que el host mueve los datos de la tabla TrackingData de la base de datos de cuadro de mensajes a las tablas de base de datos de seguimiento de BizTalk.
Es posible realizar un seguimiento de eventos personalizados habilitando el seguimiento personalizado de HAT, por ejemplo, en propiedades promocionadas y seguimiento del cuerpo del mensaje. Además de los datos de seguimiento de HAT, los datos de BAM también se escriben en la tabla TrackingData. El servicio de descodificación de datos de seguimiento (TDDS, que se ejecuta en la instancia de host en la que está habilitado el seguimiento) es responsable de mover estos datos de la base de datos de cuadro de mensajes a las bases de datos de seguimiento de BizTalk y importación principal de BAM. Después de mover correctamente los datos, TDDS elimina estos datos. Los datos de seguimiento de partes de mensaje los mueve por separado el trabajo TrackedMessages_Copy_BizTalkMsgBoxDb del Agente de SQL Server.
Si TDDS no puede mantenerse al día con la velocidad a la que los interceptores escriben datos en la tabla TrackingData, esta tabla aumentará, lo que hará que se inicie la limitación. Esto afecta al rendimiento sostenible. Para reducir este problema, asegúrese de que al menos un host se ejecuta con el seguimiento habilitado.
Si los datos se siguen acumulando, asegúrese de que la base de datos de seguimiento de BizTalk no está creciendo fuera de control. Además, asegúrese de que el trabajo de archivado y purga se está ejecutando y puede mantenerse al día con la velocidad a la que llegan los datos.
Nota
De forma predeterminada, el trabajo de purga no puede eliminar datos de las tablas de base de datos de seguimiento de BizTalk hasta que se hayan archivado estos datos. Si no necesita archivar los datos de seguimiento, puede modificar el trabajo para purgar la base de datos de seguimiento de BizTalk sin archivar siguiendo los pasos descritos en Cómo purgar datos de la base de datos de seguimiento de BizTalk (https://go.microsoft.com/fwlink/?LinkID=153817).