sql-server - habilitar - service broker example

Los mensajes de Service Broker no se envían si se reinició el objetivo

Question

En un nivel alto, esto es lo que está sucediendo:

1. Tenemos dos sistemas SQL Server 2008 R2 SP1 (Standard Edition en Windows NT 6.1 (Build 7601: Service Pack 1)) Están funcionando muy bien, comunicándose bidireccionalmente sin errores ni problemas.
2. Reiniciamos el sistema n. ° 2, esperando que cualquier mensaje de Service Broker que se le envíe mientras no esté disponible se ponga en cola en el sistema n. ° 1, hasta que el sistema n. ° 2 vuelva a funcionar.
3. El sistema # 2 vuelve a subir y todo comienza normalmente sin errores.
4. Los mensajes que se pusieron en cola en el sistema n. ° 1 para el sistema n. ° 2 permanecen en cola; ellos nunca son enviados Además, los mensajes nuevos en esa conversación también hacen cola y nunca se envían.
5. Los mensajes enviados en nuevas conversaciones se transmiten muy bien.

Detalles sobre los mensajes que nunca se envían:

R. Mientras que el sistema # 2 está inactivo, el estado de transmisión para los mensajes en la cola muestra varios errores que indican que no se puede comunicar con el sistema n. ° 2, como se esperaba.

B. Poco después de que el sistema # 2 vuelve a subir, el status_transmisión para esos mensajes queda en blanco. El estado en blanco nunca cambia después de este punto.

C. La conversación donde los mensajes se acumulan está en el estado CONVERSING / CO. Ninguna columna en la vista del sistema indica que algo sea diferente de otras colas que funcionan bien. (Si pudiera encontrar banderas configuradas de forma diferente, sabría terminar la mala conversación, pero el sistema no ofrece pistas, aparte de la profundidad de cola cada vez mayor).

D. Los mensajes nunca se reciben en el sistema n. ° 2, en el sentido de que mi procedimiento de activación nunca se llama para estos mensajes.

E. En Profiler (con todos los tipos de rastreo de Broker activados), una buena conversación muestra que estas cosas se registran:

Broker:Conversation CONVERSING 1 - SEND Message Initiator
Broker:Message Classify 2 - Remote Initiator
[SQL Batch complete; SQL that caused the SEND to occur]
Broker:Remote Message Acknowledgement 1 - Message with Acknowledgement Sent Initiator
Broker:Message Classify 1 - Local Initiator
Broker:Conversation CONVERSING 6 - Received Sequenced Message Target
Broker:Remote Message Acknowledgement 3 - Message with Acknowledgement Received Initiator
Broker:Activation Microsoft SQL Server Service Broker Activation 1 - Start

Un mensaje enviado que está destinado a atascarse muestra solo los primeros dos de esos eventos:

Broker:Conversation CONVERSING 1 - SEND Message Initiator
Broker:Message Classify 2 - Remote Initiator

Por lo que puedo decir, esto es lo más lejos que llegan esos mensajes. No hay indicación de que SQL Server intente transmitirlos nunca más. El sistema n. ° 1 cree que la conversación sigue siendo buena, pero el sistema n. ° 2 la ha olvidado por completo. El sistema n. ° 1 nunca parece resolver esto. Si posteriormente reiniciamos el sistema n. ° 1, todo vuelve a la normalidad y todos los mensajes fluyen según lo previsto.

He considerado que estos mensajes se han enviado realmente, pero que el acuse de recibo no regresa al sistema n. ° 1. Pero no veo ninguna evidencia de colas respaldadas de agradecimientos.

Hemos verificado numerosos problemas típicos en ambos lados:

Broker está habilitado en ambos lados. 2. Todas las colas están activadas, con todas las cosas apropiadas habilitadas (en cola, recibir). Las colas no están envenenadas. 3. No existen problemas de permisos que sepamos. 4. No estamos usando fuego y olvidar. 5. Reutilizamos las conversaciones, como lo recomiendan varias personas. (¡De hecho, la reutilización de la conversación es el problema aquí!) 6. Estamos atrapando excepciones de SQL, usando transacciones tal como se indica, etc. 7. ssbdiagnose no devuelve ningún error.

Cuando se reinicia un host de SQL Server, esperamos que eventualmente se envíe cualquier mensaje en cola, pero no es así. ¿¿Que esta pasando aqui??

Answer 1

Entiendo que este es un hilo bastante antiguo, pero he combatido exactamente la misma situación anteriormente, y en mi caso la configuración de red fue la culpable.

Por alguna razón, el iniciador ha enviado sus mensajes desde una dirección IP, pero se ha abierto otra IP para aceptar las respuestas entrantes (y esta segunda IP se ha especificado en la ruta del objetivo).

Lo he detectado por accidente, realmente. Cuando traté de finalizar la conversación en el lado de destino, no se ha cerrado, pero el mensaje EndDialog apareció en sys.transmission_queue con el estado:

Falló el intento de conexión con error: ''10060 (Falló el intento de conexión porque la parte conectada no respondió correctamente después de un período de tiempo, o la conexión establecida falló porque el host conectado no ha respondido)''.

No tengo idea de por qué el reinicio del objetivo ha desencadenado la avería, pero cuando los ingenieros de la red arreglaron el problema y cambié la ruta del objetivo, todo voló a sus destinos como se suponía desde el principio.