Асинхронный триггер против триггера

Question

У меня есть таблица table1. Я хочу создать аудит этой таблицы с помощью триггера для каждой вставки, обновления и изменения событий.

В этой таблице мы обычно не выполняем массовое обновление, удаление или вставку. Но иногда тысячи записей меняются. Я просто хочу знать, какой подход эффективен здесь.

1. простые спусковые
2. асинхронные триггеры с использованием услуг брокера

асинхронные триггеры с использованием услуг брокера не работают хорошо для менее нет вставок, обновлений и удалений ли?

Answer 1

SQL Server на самом деле не предлагает асинхронные триггеры. Все, что вы можете сделать, это иметь обычный синхронный триггер и в этом триггере использовать SEND, чтобы отправить сообщение службе Service Broker, размещенной в очереди, с подключенной активированной процедурой и инициировать эту активированную процедуру для запуска после транзакции, которая вызвала оригинальный синхронный триггер совершает. Это имеет смысл, если действие триггера является дорогостоящим, и его следует отложить, или если действие делает что-то вроде запроса веб-службы HTTP, и оно должно гарантировать, что запрос будет выполняться только после коммита. Но поскольку исходный SEND, который запускает все в движении, должен происходить в синхронном триггере, асинхронный триггер на основе Service Broker по-прежнему зависит от первоначальных ограничений, которые имеет триггер синхронизации (например, may not fire on bulk insert).

Вторая вещь, которую следует учитывать, заключается в том, что переход на «асинхронный» сервисный брокер с поддержкой триггера имеет стоимость. Чтобы отправить сообщение уведомления и ПОЛУЧИТЬ его, вы должны запустить как минимум 1 вставку, 2 обновления и 1 удаление (базовые операции, которые представляют SEND и RECEIVE). Вам также придется иметь дело с асинхронными аномалиями: к моменту запуска вашего триггера «асинхронный» данные могут быть хорошо изменены.

Лично для проверки данных я бы посмотрел больше на Change Tracking и Change Data Capture.