Укажите service_broker_guid вместо случайного получения от NEW_BROKER

Question

В SQL 2008 есть способ указать service_broker_guid вместо того, чтобы просто брать любой GUID, который вам дают:

ALTER DATABASE MyDB SET NEW_BROKER

Наша текущая (на мой взгляд, нарушенная) методология выпуска заключается в восстановлении двух баз данных, которые имеют взаимосвязь, зависящую от кода. Одна из них является «исходной» базой данных, а другая - базой данных BI со звездообразной схемой. Частью плана регрессионного тестирования является восстановление резервных копий обеих баз данных в «золотом» состоянии на разных серверах и даже на одном и том же сервере.

Как правило, мы не включаем переменные BROKER_INSTANCE в наши маршруты, потому что в большинстве мест они нам не нужны (т.е. для гарантированной доставки достаточно сочетания SERVICE_NAME и ADDRESS). Однако, когда у нас есть 2 базы данных, работающие на одном экземпляре, и с включенным брокером, для одной из них потребуется новый BROKER_ID. Кроме того, для всех маршрутов к этим базам данных теперь потребуется спецификатор BROKER_INSTANCE, поскольку на одном АДРЕСЕ есть 2 SERVICE_NAME.

Мы используем Visual Studio Database Professional для генерации наших выходных сценариев сборки, и просто не существует простого способа включить BROKER_INSTANCE в состав метода замены переменных SQLCMD, если вы не знаете его заранее.

Answer 1

Нет. NEW_BROKER создаст новый гид.

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

После вашего редактирования.

Broker_instance, а также информация о маршрутизации, рассматривается как среда выполнения, информация, специфичная для развертывания. Как таковой, он не был разработан, чтобы принимать фиксированные, предопределенные значения, которые хотел бы использовать проект VS GDR или набор сценариев SQLCMD. Кроме того, broker_instance_id действительно предназначен для того, чтобы быть уникальным, специфичным для экземпляра базы данных значением, и разрешение пользователям указывать свои собственные значения быстро приведет к дублированию, что может привести к путанице в конечных точках диалога при попытке обмена сообщениями.

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

Давным-давно я создал инструмент ssbslm.exe, который автоматизировал весь этот процесс и был разработан для использования в сценариях. Этот инструмент сделал все, чтобы настроить маршруты, сертификаты и конечные точки между двумя произвольными сервисами. Хотя этот инструмент больше не доступен (длинная и скучная история, почему это так), суть этой истории состоит в том, что не 1013 *, что трудно написать. Взял меня несколько дней назад в тот же день.