Ключевое слово здесь, конечно же, ACTIVATION, то есть
активация. Однако если параметр STATUS у нее выставлен в OFF, она не сработает.
Как несложно догадаться, в параметре PROCEDURE_NAME указывается имя процедуры, которая будет вызвана при активации, а в EXECUTE AS – от имени какого пользователя
эта процедура будет вызвана. Параметр MAX_QUEUE_READERS определяет максимальное
количество процедур, которое одновременно может быть запущено для разгребания
очереди. Если во время работы процедуры поступили новые сообщения, то
запускается еще один экземпляр этой процедуры, и так до максимального
разрешенного количества или опустошения очереди.
Теперь все готово для эксперимента, можно приступать.
Сначала обновим нашу «очень_большую_таблицу», и тут же заберем данные из
таблички агрегатов, затем подождем чуть-чуть и снова заберем агрегированные
данные, чтобы увидеть, как они изменились после работы процедуры перерасчета, автоматически запущенной Service Broker-ом.
UPDATE Very_Big_Table SET Data = Data + 10 WHERE ID=1
SELECT * FROM Big_Aggregate
WAITFOR DELAY '00:00:05'
SELECT * FROM Big_Aggregate
-- Результат:
--
Agg Time
--------------------
-----------------------
76577545551 13:44:37.987
76577545561 13:59:24.630
|
Как можно заметить, все отлично сработало, произошло
асинхронное обновление агрегатной таблицы. Вся прелесть в том, что агрегатная
таблица может находиться на совершенно другом сервере в другой стране, надо
только настроить подключение соответствующим образом, что совсем не сложно.
Асинхронные DDL и SQL-Trace триггеры (Event Notification)
Для реализации асинхронных триггеров на DDL-операции и
события профайлера существует специальный механизм, Event Notification
(извещение о событии).
ПРИМЕЧАНИЕ
Надо учитывать, что в связи с
асинхронностью данного механизма породившие это извещение изменения в базе
или на сервере, не отменятся в случае отката извещения, как это было бы в
DDL-триггере. Они – уже свершившийся факт. И еще один нюанс: поскольку
события профайлера работают вне транзакций, то даже если изменение на
сервере, вызвавшее посылку сообщения, не увенчается успехом, то само
сообщение все равно будет доставлено до получателя, однако для DDL-событий
это не работает, так как DDL-операции работают в рамках транзакции и в случае
отмены DDL транзакции сообщение отправлено не будет.
|
Как не сложно догадаться, этот механизм отслеживает
события, на которые есть подписчики, и посылает соответствующее сообщение. Для
того чтобы механизм сообщений заработал, достаточно создать очередь и сервис
получателя с предопределенным контрактом
[http://schemas.microsoft.com/SQL/Notifications/PostEventNotification], все
остальное - и контракт, и диалог, и сервис с очередью отправителя, уже
реализовано. Затем надо создать объект EventNotification, связывающий нужное
событие с сервисом – и готово. На практике, допустим, для асинхронного аудита
подключений к серверу и отключений от оного, это может выглядеть следующим
образом:
-- сначала создадим очередь
получателя, при желании
-- здесь можно назначить
процедуру обработки новых сообщений
--
CREATE QUEUE [LoginQueue]
GO
-- затем необходимо создать
сервис со специальным контрактом,
-- в котором уже есть
необходимые типы сообщений Рекомендуем скачать другие рефераты по теме: рефераты на казахском языке, реферат на тему время.
Предыдущая страница реферата | 3
4
5
6
7
8
9
10
11
12
13 | Следующая страница реферата
|
|