Microsoft DTC плохо играет с транзакцией в sproc

Question

Я сталкиваюсь с проблемой, когда код неисправности мне не нравится.У меня есть два сервера, которые мы будем называть Сервером A и Сервером B (разные версии, разные физические машины, один и тот же домен и одна и та же сеть).

У меня есть два спрока на сервере A, которые делают что-то идентичноеа именно, получить данные из API (того же API) и в конечном итоге вставить их в таблицу на сервере B. Один sproc имеет все функциональные возможности, заключенные в блок try / catch, и все работает хорошо.Второй sproc делает то же самое с добавлением всего содержимого «try», заключенного в транзакцию (чтобы я мог откатиться, если что-то не так).Это приводит к ошибке - показано ниже.

OLE DB provider "SQLNCLI11" for linked server "[Server B]" returned message "The partner transaction manager has disabled its support for remote/network transactions.".
Msg 7391, Level 16, State 2, Line 105
The operation could not be performed because OLE DB provider "SQLNCLI11" for linked server "[Server B]" was unable to begin a distributed transaction.

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

ссылка на статью : https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-serveroption-transact-sql?view=sql-server-2017
параметр, о котором идет речь : продвижение транзакции удаленного процесса

Iнастройте его как следующий фрагмент кода, который я переверну в положение «выключено» перед запуском межсерверной вставки, и включу его (что по умолчанию), как только я закончу.

EXEC sp_serveroption 
     @server = '[Server B]'
    ,@optname = 'remote proc transaction promotion'
    ,@optvalue = 'false';

Это правильный способ решения проблемы?

Answer 1

КЛЮЧЕВАЯ причина, по которой существуют связанные серверы, заключается в том, чтобы администраторы баз данных / администраторы могли явно ОГРАНИЧИТЬ, какие виды соединений и действий возможны между данным SQL Server и любым другим ящиком / службой, с которым он может взаимодействовать (учитывая некоторые из библиотеки и встроенные возможности, которые поставляются вместе с SQL Server для поддержки «кросс-платформенной» и межхостовой связи).

Для получения дополнительной информации об этом обратите внимание на НАМЕРЕНИЕ того, что делает DISABLING ad hoc распределенные запросы: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/ad-hoc-distributed-queries-server-configuration-option?view=sql-server-2017

По умолчанию это поставляется так, что специальные распределенные запросы НЕ разрешены (что мешает кому-либо эффективно запустить «SELECT * INTO OPENDATASOURCE» («моя удаленная таблица на коробке в моем гараже», переключается здесь) ОТ dbo.SuperSensitiveInfo «и« потоковая передача »конфиденциальных данных на конечную точку AD HOC).

Или, другими словами, связанные серверы не «просто», чтобы упростить / упростить соединения (определяя их 1х как обычно отображаемую конечную точку, что намного проще запрашивать операции OPEN * ()), но так, чтобы администраторы баз данных / Администраторы могут «сигнализировать», что эти конечные точки имеют достаточную степень доверия, связанную с ними, чтобы администратор БЫСТРО создал соединение.

Все это говорит о том, что ключевая причина существования связанных серверов заключается в том, чтобы помочь «определить» защищенные конечные точки, с которыми данный SQL Server может общаться, и точно при каких условиях (т. Е. Что разрешено и что не разрешено). ). Таким образом, в этом смысле связанные серверы похожи на передачу ребенку смартфона, где ВСЕ, что они могут использовать, это приложение для телефона, и им НЕ разрешается набирать любые номера - но они могут вызывать ТОЛЬКО КОНТАКТЫ, которые вы ' мы определили - чтобы они могли разговаривать с друзьями и звонить вам, но не делать никаких специальных звонков.

При таком «образе мышления» в качестве фона продвижение транзакции удаленной процедуры представляет собой «СВОБОДНОЕ» разрешение, которое может быть включено (хорошо, ОТКЛЮЧЕНО или НЕ ОТКЛЮЧЕНО) для связанного сервера ЕСЛИ там 'достаточно' верь там.

Или, другими словами, если вы доверяете отношениям между ServerA и ServerB и с вами все в порядке, когда они вместе играют в DTC, то я бы УСТАНОВИЛ (и «забыл») настройку этого связанного сервера, чтобы ВМЕСТО переключить его до / после того, как этот конкретный sproc был включен.

В противном случае, я ПОНИМАЮ, что вы можете / могли бы просто обойти дополнительные ограничения SQL Server здесь (против включения DTC в качестве DEFAULT), включив сетевой DTC на уровне ОС / сервера, как описано ниже: https://support.resolver.com/hc/en-ca/articles/207161116-Configure-Microsoft-Distributed-Transaction-Coordinator-MSDTC-

Answer 2

Это сработало для меня сегодня, надеюсь, это сработает и для вас:)