• Artikel

Grundlegendes zur Aktivierung

Der Service Broker-Aktivierungsprozess setzt sich aus zwei Schritten zusammen. Im ersten Schritt bestimmt Service Broker, ob eine Aktivierung notwendig ist. Im zweiten Schritt bestimmt Service Broker, ob die Aktivierung stattfindet. Obwohl sich die Prozesse für die interne und die externe Aktivierung im Detail unterscheiden, sind die Gesamtkonzepte für beide Strategien identisch.

Bestimmen, ob eine Aktivierung notwendig ist

Eine Aktivierung ist immer dann notwendig, wenn sinnvolle Arbeit für einen neuen Warteschlangenleser vorhanden wäre. Ob eine Aktivierung erforderlich ist, wird durch Warteschlangenüberwachungen bestimmt. Service Broker erstellt eine Warteschlangenüberwachung für jede Warteschlange, deren Aktivierungsstatus STATUS = ON lautet, oder für die eine QUEUE_ACTIVATION-Ereignisbenachrichtigung registriert wurde. In der dynamischen Verwaltungssicht unter sys.dm_broker_queue_monitors (Transact-SQL) werden die Warteschlangenüberwachungen aufgelistet, die in der Instanz aktiv sind. Jede Warteschlangenüberwachung verfolgt Folgendes nach:

Enthält die Warteschlange empfangsbereite Nachrichten?

Wann hat eine RECEIVE-Anweisung in der Warteschlange zuletzt ein leeres Resultset zurückgegeben?

Wie viele gespeicherte Aktivierungsprozeduren werden derzeit für die Warteschlange ausgeführt?

Eine Warteschlangenüberwachung überprüft alle paar Sekunden, ob eine Aktivierung erforderlich ist. Auch wenn eines oder mehrere der folgenden Ereignisse auftreten, wird eine Überprüfung durchgeführt:

  • Eine neue Nachricht geht in der Warteschlange ein.

  • SQL Server führt eine RECEIVE-Anweisung für die Warteschlange aus.

  • Für eine Transaktion, die eine RECEIVE-Anweisung enthält, wird ein Rollback ausgeführt.

  • Alle gespeicherten Prozeduren, die durch die Warteschlangenüberwachung gestartet wurden, werden beendet.

  • SQL Server führt eine ALTER-Anweisung für die Warteschlange aus.

Eine Aktivierung ist notwendig, wenn eine der beiden folgenden Bedingungen zutrifft:

  • Eine neue Nachricht geht in einer Warteschlange ein, die keine ungelesenen Nachrichten enthält, und für die Warteschlange werden keine gespeicherten Aktivierungsprozeduren ausgeführt.

  • Die Warteschlange enthält ungelesene Nachrichten, in einer GET CONVERSATION GROUP-Anweisung oder in einer RECEIVE-Anweisung ohne WHERE-Klausel liegt keine wartende Sitzung vor, und für einige Sekunden hat keine GET CONVERSATION GROUP-Anweisung oder RECEIVE-Anweisung ohne WHERE-Klausel ein leeres Resultset zurückgegeben. Es sammeln sich also Nachrichten in der Warteschlange an, weil die aktivierten Prozeduren sie nicht schnell genug lesen können.

Die Warteschlangenüberwachung kann mithilfe dieser Prozedur ermitteln, ob die Anzahl der Warteschlangenleser zur Verarbeitung der Warteschlange den eingehenden Nachrichtenverkehr bewältigen kann. Beachten Sie, dass bei diesem Ansatz eine Konversationsgruppensperre berücksichtigt wird. Da Nachrichten für eine Konversation nur von jeweils einem Warteschlangenleser verarbeitet werden können, werden unter Umständen Ressourcen verschwendet, wenn Warteschlangenleser als Reaktion auf einen einfacheren Ansatz wie der Anzahl der ungelesenen Nachrichten in einer Warteschlange gestartet werden. Stattdessen wird bei der Service Broker-Aktivierung berücksichtigt, ob sinnvolle Arbeit für einen neuen Warteschlangenleser vorliegt.

Zum Beispiel enthält eine Warteschlange möglicherweise eine große Anzahl von nicht verarbeiteten Nachrichten für eine einzelne Konversation. In diesem Fall kann nur ein Warteschlangenleser die Nachrichten verarbeiten. Die Warteschlangenüberwachung aktiviert einen weiteren Warteschlangenleser. Der zweite Warteschlangenleser wartet in der RECEIVE-Anweisung, weil alle Nachrichten zu einer einzelnen Konversation gehören. Solange alle Nachrichten in der Warteschlange zu derselben Konversation gehören und der zweite Warteschlangenleser weiterhin ausgeführt wird, startet die Warteschlangenüberwachung keinen anderen Warteschlangenleser.

Bestimmen, ob die Aktivierung stattfindet

Sobald Service Broker bestimmt, dass eine Aktivierung notwendig ist, muss Service Broker entscheiden, ob die Aktivierung stattfindet.

Zur internen Aktivierung aktiviert die Warteschlangenüberwachung eine neue Instanz der gespeicherten Aktivierungsprozedur, wenn die Anzahl der ausgeführten Programme den für die Warteschlange festgelegten MAX_QUEUE_READERS-Wert unterschreitet. Wenn die Anzahl der ausgeführten Programme gleich oder größer als MAX_QUEUE_READERS ist, startet die Warteschlangenüberwachung keine neue Instanz der gespeicherten Prozedur. Die Verwaltungssicht unter sys.dm_broker_activated_tasks (Transact-SQL) enthält Informationen zu gespeicherten Prozeduren, die von Service Broker gestartet werden.

Für externe Anwendungen verfügt Service Broker über keine Informationen zur Anzahl der unterschiedlichen Warteschlangenleser, die möglicherweise mit der Warteschlange arbeiten. Zudem muss möglicherweise zwischen der Auslösung des Aktivierungsereignisses und der Zeit, zu der ein Leser mit dem Lesen der Warteschlange beginnt, etwas Startzeit berücksichtigt werden. Deshalb veranlasst Service Broker ein Timeout, damit eine externe Anwendung reagiert. Während des Timeouts erzeugt Service Broker keine weitere Benachrichtigung. Sobald eine Anwendung in der Warteschlange RECEIVE aufruft oder das Timeout abläuft, erstellt Service Broker eine weitere Ereignisbenachrichtigung, falls eine Aktivierung erforderlich ist. Eine externe Anwendung überwacht die Ereignisbenachrichtigungen. Das Programm wird dabei ausgeführt, um zu bestimmen, ob weitere Warteschlangenleser zum Lesen von Ereignissen erforderlich sind.