Verwendet jemand den Service Broker in SQL Server?

Question

Als ich an einer Präsentation von SQL Server 2008 bei Microsoft teilnahm, wurde eine kurze Umfrage durchgeführt, um zu sehen, welche Funktionen wir verwenden. Es stellte sich heraus, dass mein Unternehmen im gesamten Vortragssaal das einzige war, das den Service Broker verwendete. Das hat mich sehr überrascht, da ich dachte, dass ihn mehr Leute nutzen würden.

Meine Erfahrung mit SB ist, dass es seine Aufgabe gut erfüllt, aber ziemlich schwer zu verwalten ist und es schwer ist, einen Überblick zu bekommen.

Haben Sie schon einmal daran gedacht, den Service Broker einzusetzen? Wenn nicht, warum nicht? Haben Sie sich stattdessen für MSMQ entschieden? Gibt es irgendetwas in SQL Server 2008, das Sie dazu bewegen würde, den Service Broker zu verwenden?

Answer 1

Ich verwende SQL Service Broker seit ein paar Monaten nach der Veröffentlichung von SQL 2005. Wir verwenden ihn hier ununterbrochen und senden täglich Hunderttausende von Nachrichten über ihn.

Wir verwenden es, um Daten aus Staging-Tabellen in Produktionstabellen zu laden, so dass der Dienst, der die Staging-Tabelle lädt, nicht warten muss, bis die Daten tatsächlich verarbeitet sind, sondern zurückgehen und weitere Daten zum Laden holen kann.

Wir verwenden es, um das Löschen von Dateien aus dem Dateisystem in eine Warteschlange zu stellen. (Wenn die Zeile gelöscht wird, muss auch die Datei gelöscht werden).

Bei früheren Unternehmen habe ich damit Darlehensdokumente und die Schecks gedruckt, die an die Kunden verschickt wurden.

Ich habe Service Broker sogar für ETL von einer OLTP-Datenbank zu einer OLAP-Datenbank für Echtzeitberichte verwendet.

Die meisten Leute (insbesondere DBAs) mögen den Service Broker nicht, weil es keine Benutzeroberfläche dafür gibt. Wenn Sie den Service Broker verwenden oder sehen wollen, was er tut, müssen Sie tatsächlich T/SQL schreiben und ausführen.

Answer 2

Ich verwende SB im Jahr 2005 seit etwa zwei Jahren mit einer Implementierung, die mehrere hunderttausend Nachrichten pro Tag verarbeitet. Ich würde sagen, die größte Herausforderung lag nicht so sehr in der Architektur, sondern im Verständnis aller damit verbundenen Nuancen. Die Dokumentation von Microsoft ist dürftig und es gibt nur sehr wenige praktische Beispiele. Remus Rusanu's Blogs waren wirklich hilfreich bei Dingen wie der Wiederverwendung von Dialogen und der Abstimmung von gespeicherten Aktivierungsverfahren. Ich habe festgestellt, dass es WIRKLICH wichtig ist, Dialoge so oft wie möglich wiederzuverwenden (und alle damit verbundenen Sperren zu bearbeiten) sowie mehrere empfangene Nachrichten als Satz und nicht einzeln zu behandeln.

Die Überwachung von SB kann mühsam sein. Man ist im Grunde auf eine Reihe von Systemansichten angewiesen, um zu erfahren, was vor sich geht. Verwaiste Nachrichten sind ein Problem. Es gibt einfach eine Menge kleiner Probleme, die, nun ja, einen erwischen können.

Abgesehen von den Problemen, und davon gibt es nicht so viele, denke ich, dass es wirklich besser funktioniert hat, als ich es erwartet hatte. Da SB in die Datenbank integriert ist, gibt es keine separaten Nachrichtenwarteschlangen, die außerhalb der Datenbank gesichert werden müssen. Es ist alles transaktional konsistent. Die Leistung ist gut. Es ist eine großartige Lösung.

Ich würde es wieder verwenden und werde es auch weiterhin nutzen.

Answer 3

In meinem derzeitigen Unternehmen ist die Verwendung von SB etwas anders als bei den anderen Postern. Wir verwenden SB in SQL2005 hauptsächlich als Verwaltungstool. Wir verwenden es z. B. zur Verwaltung von Aktualisierungen in einer kleinen Gruppe veränderlicher Tabellen, die in einer großen Anzahl ansonsten unveränderlicher Datenbanken vorhanden sind. Alle Nachrichten werden zwischen Diensten ausgetauscht, die auf derselben Instanz laufen, und das Nachrichtenaufkommen ist sehr gering.

Meine Erfahrung mit SB ist, dass es etwas "fummelig" sein kann, es korrekt einzurichten, und wie Sie in Ihrer Frage erwähnten, ist es schwierig, einen Überblick über den Zustand von SB zu bekommen, da es kein einziges Überwachungsinstrument gibt.

Nichtsdestotrotz haben wir festgestellt, dass es sehr wertvoll ist, um viele Aufgaben der Datenbankverwaltung auf nachvollziehbare und zuverlässige Weise zu automatisieren.

Answer 4

Ich habe vor kurzem in Erwägung gezogen, Service Broker für ein Projekt zu verwenden, habe mich dann aber doch für MSMQ entschieden.

Unsere Architektur bestand aus einer Reihe von (geclusterten) Servern, von denen jeder zuverlässig Informationen in eine einzige Instanz von SQL schreiben musste.

Soweit ich weiß, funktioniert SB nur für die SQL-zu-SQL-Kommunikation, so dass wir auf jeder Clusterbox eine Instanz von SQL benötigt hätten. Wir hielten das für unnötig und haben daher MSMQ verwendet.

Um ehrlich zu sein, fällt mir kein Szenario ein, in dem ich SB verwenden würde - ich bin daran interessiert, etwas mehr über Ihr Szenario zu erfahren, um zu sehen, ob ich etwas Entscheidendes übersehe.

Answer 5

Service Broker kann in verschiedenen Fällen eingesetzt werden, in denen eine Automatisierung in der verteilten Architektur erforderlich ist. Solche Anwendungen empfangen Ereignisse von verschiedenen Geräten und müssen zuverlässig verarbeitet werden. Wo Ereignisse von Geräten (Erkennung) oder Sensoren für die Verarbeitung der Automatisierungslogik verwendet werden. Zum Austausch von Daten zwischen mehreren Datenbanken oder Anwendungen.

Ich hoffe, dass die Umsetzung besser sein kann gesichert y zuverlässig mit SB