При каких обстоятельствах репликация SQL частично (и молча) может завершиться неудачей из-за транзакции MSDTC из приложения c #

Question

У нас особенно странная проблема; позвольте мне установить сцену. Решение найдено, см. Ниже

У нас есть три базы данных SQL Server 2005 в качестве аргумента: Альфа , Бета и Гамма .

Существует отношение репликации, определенное между этими базами данных следующим образом:

Все три базы данных имеют таблицу с именем «AnExample» с одинаковой схемой. Репликация настроена таким образом, что Alpha является поставщиком, а две другие базы данных являются подписчиками.

1. Приложение c # .Net 3.5, использующее транзакцию MSDTC (обрабатываемую TransactionScope), выполняет чтение и запись в базы данных: Alpha и Beta.
2. Таблица «AnExample» в этой транзакции обновляется только на Alpha.
3. MSDTC-транзакция успешно фиксируется.
4. Таблица "AnExample", вероятно, обновлена ​​в Альфа , и изменение немедленно реплицируется в Гамма
5. Никаких изменений не происходит в Beta (профилировщик подтверждает, что в базе данных не происходит никаких действий), а также не возникает никаких ошибок в журналах SQL или журналах событий
6. Повторный запуск того же запроса, который обновляет «AnExample» в Management Studio с теми же учетными данными, выполнен успешно (происходит репликация на Beta )
7. Выполнение транзакции MSDTC. Запись в другую таблицу в Beta , затем точно такая же запись в таблицу Alpha "AnExample" с тестовым приложением, использующим основные приложения DAL, строки подключения и конфигурацию, также полностью завершается происходит репликация в Beta )

Это привело нас к мысли, что в главном приложении происходят некоторые изменения, которые не происходят изолированно.

Возможные улики / красная сельдь

Единственное различие, которое мы видим между нашими успешными тестами и фактическим запросом, используемым основным приложением, состоит в том, что уровень изоляции каким-то образом изменился. Для успешных запросов устанавливается только уровень изоляции транзакции Read Committed, тогда как в сценариях сбоя он устанавливается на сериализуемость (несмотря на отсутствие явного вызова для изменения уровня изоляции в кодовой базе или хранимых процедурах).

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

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

-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level *serializable*

Это что-то вроде головного убора.

Answer 1

Итак, мы нашли то, что кажется проблемой. Как описано выше; у нас есть распределенная транзакция, которая записывает в Alpha затем Beta . Запись в Beta затем успешно реплицируется в Gamma , а в Alpha происходит тихо Однако было одно упущение, что одна из записей в Alpha фактически реплицируется в Beta (проблема схемы большой базы данных). Перемещение этой записи в Beta означало, что репликация внезапно завершилась успешно.

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

Надеюсь, это поможет кому-то еще.

Answer 2

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

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