Генерация событий из SQL-сервера

Question

Я ищу наилучшую практику или пример того, как я могу генерировать события для всех событий обновления на заданной базе данных SQL Server 2008 R2. Чтобы быть более наглядным, я работаю над POC, где я, по сути, опубликую события обновления в очередь (в моем случае RabbitMq), которая затем может использоваться различными потребителями. Это было бы первой частью реализации модели данных CQRS только для запросов через источник событий. Поместив в очередь, любой может подписаться на эти события для репликации в любое количество моделей данных только для запросов. Эта часть ясна и довольно четко определена. проблема, с которой я сталкиваюсь, заключается в определении наилучшего подхода для генерации событий с сервера SQL. Мне дали несколько идей, таких как мониторинг журнала транзакций и служб SSIS. Однако я не совсем уверен, целесообразны ли эти варианты или даже осуществимы.

Есть ли у кого-нибудь опыт такого рода вещей или есть идеи о том, как устроить такое приключение? любая помощь или руководство будет принята с благодарностью.

Answer 1

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

SSIS - это очень широкое понятие, и выражение «использование SSIS для обнаружения изменений» сродни высказыванию «Я буду использовать язык программирования для решения своей проблемы».Подробности как вы бы использовали SSIS?С SSIS или без нее невозможно надежно обнаружить изменения данных в произвольной схеме.Даже модели данных, специально разработанные для обнаружения изменений, имеют проблемы, особенно при обнаружении удалений.

Однако существуют жизнеспособные альтернативы.Вы можете развернуть Change Data Capture и делегировать его самому движку для отслеживания изменений.Поглощая эти обнаруженные изменения и публикуя их для потребителей (через RabbitMQ, если вам интересно), - это , что-то, что SSIS было бы хорошо.Но вы должны понимать, что SSIS плохо справляется с непрерывными задачами в реальном времени.Он предназначен для периодической работы в пакетном режиме, поэтому ваши потребители уведомлений об изменениях будут получать уведомления с пиками, с большими задержками (минутами), когда выполняются задания SSIS.

Для подхода в реальном времени лучшим решением является Сервисный брокер .Одна возможность - SEND Сообщения Service Broker от триггеров, но я бы не рекомендовал это.Лучшим вариантом было бы, чтобы приложение само опубликовало изменения, явно указав SEND сообщение, когда оно выполняет изменение данных.С SQL Server 2012 возможно многоадресных сообщений компонента Service Broker другим пользователям SQL Server (включая SQL Server Express).Доставка сообщений SSB полностью транзакционна (при откате транзакции сообщение не отправляется) и не требует двухфазной фиксации с менеджером ресурсов хранилища сообщений.Но для трансляции через RabbitMQ вам нужно будет соединить связь, т.е.RECEIVE сообщения SSB и преобразование их в уведомления RabbitMQ.