Идентификатор транзакции репликации SQL Server 2005/8

У меня есть сценарий, в котором я использую репликацию транзакций для репликации нескольких баз данных SQL Server 2005 (один и тот же экземпляр) в одну удаленную базу данных (другой экземпляр на отдельной физической машине).

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

До этого момента все нормально.

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

Базовый пример: у меня есть таблица TUser и таблица TAddress. Если бы мне пришлось создать и то, и другое в одной транзакции, они также были бы реплицированы в одной транзакции. Однако в реплицированной базе данных сработало бы два триггера, что в настоящее время заставляет мой код постобработки запускаться дважды. Что я действительно хотел бы отметить, так это то, что эти два изменения прибыли в реплицируемую в одной транзакции.

Возможно ли это каким-либо образом? Существует ли описанный мной идентификатор и доступен ли он?


person Mike Tours    schedule 13.11.2009    source источник


Ответы (1)


Короткий ответ: нет, нет ничего подобного, на что можно было бы положиться. Подводя итог, можно сказать, что да, он существует, но ни в коем случае не рекомендуется использовать его для чего-либо.

Учитывая, что репликация согласована с транзакционной точки зрения, один из подходов, который вы могли бы рассмотреть, - это поместить идентификатор для первичной записи (в данном случае TUser, поскольку TAddress связан с TUser) в очередь (используя что-то вроде Service Broker в идеале или потенциально определяемая пользователем очередь), а затем выполните постобработку, извлекая данные из очереди и обрабатывая их отдельно.

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

Несколько мыслей, надеюсь, что это поможет.

person boydc7    schedule 13.11.2009
comment
Спасибо за ваш ответ. Не могли бы вы предоставить какую-либо информацию относительно подробного резюме ответа. Даже если это невозможно, я хотел бы знать, о чем вы думали. - person Mike Tours; 16.11.2009
comment
Что касается других решений, оба были рассмотрены. Однако приведенный мною пример был очень упрощенным и на самом деле представляет собой базу данных финансовых систем с сотнями таблиц. Изменения сервисного брокера и опроса не учитываются. Мы достигли того же уровня после изрядного количества исследований, но действительно хотели бы иметь возможность связывать различные изменения таблиц с одной транзакцией, если это возможно. Я считаю, что доступны некоторые системные значения транзакций, но не уверен, насколько они надежны? - person Mike Tours; 16.11.2009