Параметры для неблокирующих сообщений из транзакции SQL Server

Question

Я поддерживаю приложение на базе SQL Server, которое требует, чтобы мы отправляли уведомления об определенных изменениях базы данных подключенным клиентам. Эти клиенты являются приложениями C ++ для толстых клиентов с высокоскоростным подключением к серверу.

До этого момента мы использовали выделенную таблицу сообщений в SQL Server, которая обновляется с помощью триггеров в соответствующих таблицах. Огромный недостаток этого заключается в том, что если кто-то оставляет транзакцию, которая приводит к открытию вставки сообщения в течение длительных периодов времени, то блокировка этой общей таблицы сообщений приводит к тому, что другие клиенты (и сообщения в целом) останавливаются.

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

---

Что я действительно ищу, так это хороший механизм внутри SQL Server (в идеале SQL Server 2000 и выше, но SQL Server 2008-only также будет в порядке) для запуска какого-либо сообщения. Сообщение должно:

1. Быть доступным для чтения произвольной клиентской программой из транзакции базы данных,
2. Не добавляет дополнительной нагрузки на блокировку базы данных, а
3. Будь быстрым.

Постоянство / гарантированная доставка была бы очень хорошей, но не абсолютно необходимой.

---

Я смотрел на MSMQ , но я не до конца понимаю документацию. Я понимаю, что в MSMQ существует такая вещь, как «транзакция сообщения», и что возможно отключить сообщения от расширенной хранимой процедуры или процедуры CLR, но насколько пуленепробиваемой и быстрой она является в этом контекст?

Любой совет, который вы можете дать, будет очень признателен.

---

Редактировать: Чтобы уточнить, мне нужен способ отправить хотя бы одно приложение, кроме вызывающего приложения. Это требование уведомления / трансляции, поэтому приведенное ниже предложение RAISERROR не подходит.

Answer 1

MSMQ поддерживает транзакции, правда, но использование MSMQ означает, что вы регистрируете локальную транзакцию SQL в распределенной транзакции с менеджером MSQM. Это будет полноценная распределенная транзакция с участием MSDTC и двухфазной фиксацией. Ваша транзакционная пропускная способность очень серьезно скажется на производительности.

Я буду вторым Сунгом здесь и рекомендую Service Broker.

Компонент Service Broker надежно доставит сообщение, асинхронно и с очень высокой пропускной способностью, в очередь в той же базе данных, том же экземпляре или другом экземпляре SQL Server. Компонент Service Broker нельзя использовать для доставки уведомлений прямо в клиентское приложение (т. Е. Обратный вызов сокета-соединения), но вместо этого сообщение доставляется в очередь (объект SQL Server), и клиент подключается через обычное соединение и выдает инструкцию RECEIVE для удаления из очереди. ожидающие уведомления. API Service Broker - это полностью Transact-SQL, поэтому вы легко можете добавить его к триггерам. Его транзакция полностью содержится в базе данных SQL Server и не переводит локальные транзакции в распределенные транзакции, что позволяет достигать пропускной способности тысяч сообщений в секунду . Самый большой недостаток в том, что у него очень крутая кривая обучения.

Компонент Service Broker будет блокировать базу данных для работы, но при правильном использовании не вызовет конфликт. Когда Forgetful Fred оставляет свою транзакцию открытой и отправляется на ланч, это не приведет к блокировке очереди. Он заблокирует используемый им канал от повторного использования (т. Е. «Разговор» в терминах компонента Service Broker), но другие каналы, используемые другими пользователями, остаются открытыми. Принимающая сторона (где приложение ожидает доставки) не блокируется вообще. Точно так же, если Forgetful Fred запускает приложение и отправляется на ланч, когда у него есть незафиксированная транзакция, которая исключила уведомление, это не заблокирует возможность других приложений получать уведомления, а также возможность ставить в очередь другие уведомления, в том числе на канале, с которого Fred снял очередь. Таким образом, приложения не могут блокировать уведомления (триггеры не могут быть приостановлены медленными приложениями), и наоборот. Разработка и внедрение компонента Service Broker отделена.

[Полное раскрытие: я бывший член команды Service Broker.]

Answer 2

SQL Server 2005 и 2008 предлагает Service Broker , который представляет собой систему очередей сообщений.

Вы можете использовать Активация компонента Service Broker , чтобы сообщение могло быть «прочитано произвольной клиентской программой из транзакции базы данных».

А также, поскольку Service Broker является частью ядра базы данных SQL-сервера, он будет «не добавлять дополнительную нагрузку на блокировку базы данных» и должен «быть быстрым» (хотя это полностью зависит от того, как реализован Service Broker)

«Стойкость / гарантированная доставка была бы очень хорошей, но не абсолютно необходимой.»

Гарантируется сервисным брокером.

Answer 3

Как насчет RAISERROR?

http://technet.microsoft.com/en-us/library/ms178592.aspx

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

Я полагаю, что именно так SQL Management Studio прослушивает такие сообщения, как операции DBCC.