Асинхронные триггеры в SQL Server 2005/2008

эти статьи показывают, как использовать брокер служб для асинхронного аудита, и должны быть полезны:

Централизованный асинхронный аудит со службой Broker

Полезности Service Broker: кросс-серверный сценарий «многие к одному (один ко многим)» и способы его устранения

Интересно, можно ли пометить запись для отслеживания изменений, вставив ее в таблицу «слишком процесс», включая информацию о том, кто это сделал? изменения и т. д. и т. д.

Затем может появиться другой процесс и регулярно копировать оставшиеся данные.

Существует очевидный конфликт между «хорошо выполняет свою работу» и «неприемлемо», очевидно.

Звучит мне, что вы пытаетесь использовать триггеры так же, как вы использовали бы события в процедурном приложении ОО, которое IMHO не отображает.

Я бы назвал любую логику триггера, которая занимает 30 секунд - нет, больше, чем 0,1 секунды - как неисправный. Я думаю, что вам действительно нужно изменить свою функциональность и сделать это другим способом. Я бы сказал «если вы хотите сделать его асинхронным», но я не думаю, что этот дизайн имеет смысл в любой форме.

Что касается «асинхронных триггеров», основной фундаментальный конфликт состоит в том, что вы никогда не сможете включить такие что-то среднее между инструкциями BEGIN TRAN и COMMIT TRAN, потому что вы потеряли представление о том, успешно это выполнено или нет.

Создать таблицу истории. При обновлении (/ удалении / вставке) основной таблицы вставьте старые значения записи (удаленная псевдотаблица в триггере) в таблицу истории; нужна также некоторая дополнительная информация (метка времени, тип операции, может быть, пользовательский контекст). В любом случае новые значения сохраняются в оперативной таблице.

Таким образом, триггеры запускаются быстро (er), и вы можете переключать медленные операции в средство просмотра журнала (процедура).

Не знаю, но вставляете ли вы значения в таблицу аудита, которые также существуют в базовой таблице? Если это так, вы можете отслеживать только изменения. Следовательно, вставка будет отслеживать время изменения, пользователя, extra и группу значений NULL (в действительности это значение before). Обновление будет содержать только время изменения, пользователя и т. Д., А также значение перед измененным столбцом. У удаления есть изменение в и т. Д. И все значения.

Кроме того, у вас есть таблица аудита для каждой базовой таблицы или одна таблица аудита для БД? Конечно, последующее может более легко привести к ожиданиям, поскольку каждая транзакция пытается записать в одну таблицу.

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

Если бы вы могли работать асинхронно (что все равно потребовало бы сохранения данных где-нибудь для повторной регистрации позже), то вы не проводите аудит и не имеете использовать историю.

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

Можете ли вы изменить, например, аудит для таблицы? Вы можете разделить текущие данные журнала в соответствующие таблицы.