Service Broker to fantastyczne rozwiązanie na pokładzie platformy SQL, o ile działa….
W moim przypadku wysłanie komunikatu ze instancji A do B kończyło się tym, że w sys.transmission_queue na „A” nie był logowany żaden bład, ale wiadomość nie była wysyłana.
No cóż – trzeba było włączyć profiler (najlepiej po obu stronach i analizować).
Na instancji B nie było tak źle. Widać było, że komunikaty chodzą, ale… się dublują i generalnie wszystkie były odrzucane jako duplikaty:
This message could not be delivered because it is a duplicate.
Ten komunikat mówi mniej więcej tyle, że taka wiadomość już raz do instancji B dotarła, ale z jakiegoś powodu nie udało się jej potwierdzić. Najczęściej jest to związane z niepoprawnie ustawionym routingiem. Dla przypomnienia:
- należy zdefiniować w bieżącej bazie danych route do zdalnego serwisu
- oraz w bazie msdb lokalny routing dla lokalnego serwisu
Jednak dlaczego nie można potwierdzić otrzymania komunikatu? Mój routing był ustawiony dobrze! Odpowiedź udało się znaleźć w profilerze na instancji A. Pełny komunikat o błedzie to:
The message could not be delivered because it could not be classified. Enable broker message classification trace to see the reason for the failure.
O jaką klasyfikację chodzi? To się udało odczytać w kolejnej pozycji wyłapanej przez profilera:
Event Class „Broker:Message Classify”
Lokalnego routingu nie można było przeczytać, bo service broker w bazie danych msdb był wyłączony…. rzeczywiśce parę godzin wcześniej musiałem na tej instancji odtworzyć bazę msdb i przy tej okacji flaga BROKER_ENABLED została wygaszona. Wystrczyło włączyć brokera na bazie msdb na instancji A i komunikacja Service Brokera ruszyła z kopyta!
