SQL Server bietet nicht wirklich asynchrone Trigger. Sie können nur einen normalen, synchronen Trigger verwenden und in diesem Trigger SEND verwenden, um eine Nachricht an einen Service Broker-Service zu senden, der in einer Warteschlange mit einer angehängten aktivierten Prozedur gehostet wird und diese aktivierte Prozedur auslöst, nachdem die Transaktion ausgelöst wurde ursprüngliche synchrone Trigger-Commits. Dies ist sinnvoll, wenn die 'Aktion' des Triggers kostspielig ist und aufgeschoben werden sollte oder wenn die Aktion eine HTTP-Webdienstanforderung ausführt und sicherstellen soll, dass die Anforderung nur nach dem Commit erfolgt. Aber da das Original SEND, das alles in Bewegung versetzt, in einem synchronen Trigger auftreten muss, unterliegt ein async-Trigger basierend auf Service Broker immer noch den ursprünglichen Einschränkungen, die der Sync-Trigger hatte (z. B. may not fire on bulk insert).
Eine zweite Sache zu berücksichtigen ist, dass die Umstellung auf einen 'asynchronen' Service Broker-basierten Trigger Kosten verursacht. Um die Benachrichtigung zu senden und sie zu EMPFANGEN, müssen Sie mindestens 1 Einfügung, 2 Aktualisierungen und 1 Löschung (die zugrunde liegenden Vorgänge, die die SEND und die RECEIVE darstellen) ausführen. Sie müssen sich auch mit den asynchronen Anomalien befassen: Zu dem Zeitpunkt, an dem Ihr 'async' Trigger ausgeführt wird, haben sich die Daten möglicherweise geändert.
Persönlich für Daten-Audit würde ich mehr in Richtung Change Tracking und Change Data Capture aussehen.
Sobald ich die Nachricht sende, muss ich nicht auf die Antwort warten, und meine Transaktion wird nicht blockiert – gkarya42