ShIgorгрубо:
xdes_id - внутр идентификатор для транзакции
commit_ts - последовательный номер коммита для транзакции (CSN Commit Sequence Number)

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


Не очень понятно как Вы пришли к такому выводу. Точнее кажется, что Вы пришли к такому выводу исключительно из определений этих двух полей. На самом деле, Вы, просто, констатируете факт того, что в sys.dm_tran_commit_table, каким то чудом оказалось две записи с одним commit_ts. Ибо в каком-либо другом контексте фраза "...в один коммит могут влезть несколько разных транзакций" звучит пугающе.

ShIgorНу а дальше понятно - связав обе сущности можно получить умножение записей. CHANGETABLE не обращает внимание на то, что в одном коммите могут оказаться несколько транзакций и для каждого измененного PK он вернет один и тот же commit_ts.


Немного некорректно. У Вас две таблицы в запросе и Вы соединяете их. Первая - changetable(...) работает честно и возвращает одну запись. Она не обязана ничего знать о второй таблице sys.dm_tran_commit_table в которой данные уже задвоены к моменту выполнения.

ShIgorПереводя на мою ситуацию, если бы commit_ts был бы последний на момент запроса, я получил бы ответ:


Тоже непонятно. При чём тут последний коммит или нет?

Что касается конкретно Вашей ситуации, то было опрометчиво писать такой запрос, не зная ключей в таблице sys.syscommittab (это подложенная под представление sys.dm_tran_commit_table таблица). Если не знаете ключей - то нужно перестраховываться чем-то типа

В целом - тема интересная

Прошу прощения. Нечаянно отправил недописанное сообщение. Продолжу:

Что касается конкретно Вашей ситуации, то было опрометчиво писать такой запрос, не зная ключей в таблице sys.syscommittab (это подложенная под представление sys.dm_tran_commit_table таблица). Если не знаете ключей - то нужно перестраховываться чем-то типа



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



Т.е. исследовать откуда же появились две транзакции с одним commit_ts.

Я работаю над универсально обёрткой вокруг CT или CDC. Связано это с тем, что CDC доступен не на всех редакциях SQL. С CDC всё достаточно просто, там LSN и SeqNO из журнала транзакций. Оба numeric(25). В CT же Майкрософт ввёл новые характеристики, обозначающие версию данных sys_change_version тот же самый... bigint. А Sequance вообще спрятали, через функции её не достать, только в таблицах из под DAC.
Т.е. мне интересно внутреннее устройство CT и хотелось бы доковырять этот пример для лучшего понимания внутренностей и засад.
Спасибо.

ShIgor,

Думаю Вы ошибаетесь насчёт sys.dm_tran_commit_table. В её описании чётко написано:
Displays one row for each transaction that is committed for a table that is tracked by SQL Server change tracking
Т.е. одна строка на транзакцию для таблицы. Ничего про строки данных тут нет. Да и было бы странно, если бы системная таблица распухала от информации о действиях над каждой строчкой.
Информация об изменениях в строках, о которой Вы пишете, содержится в специальных таблицах, которые именуются как change_tracking_N, где N - это object_id пользовательской таблицы, для которой включён CT. Вы можете их увидеть в sys.internal_tables.
К сожалению, обратится к этим таблицам можно только через DAC. Там есть ценная информация, недоступная через штатные функции для работы с CT. Например Sequance Value, которое, как раз, и есть постоянно увеличивающаяся величина при корректировке одной отдельно взятой строчки и который легко доступен для CDC при работе со штатными функциями (__$seqval).
Посему, мне кажется, Ваша гипотеза насчёт природы задвоений в sys.dm_tran_commit_table не состоятельна. Причина в чём то другом. Но у меня, к сожалению, не получается добиться воспроизведения Вашей ситуации.

Владислав Колосов,

Ну насчёт "всего нужного" я бы поспорил. В предыдущем посте я упомянул про sequance value, например.
Но обёртка то нужна не для CT как такового, и не для CDC как такового, обёртка нужна вокруг их обоих, для того, чтобы можно было пользоваться любой из них, не обращая внимания на разную реализацию их интерфейсов.
Этим приходится заниматься, поскольку CDC явно выигрышнее (по крайней мере для наших целей), ибо асинхронный, но доступен он только для Enterprise (по крайней мере для 2008R2). А нашу базу могут развернуть и на Express, там доступен только CT.

ShIgor,

Да, извините. Не перечитал и уже позабылось. Освежил немного и получаем:
Ваш вывод:
авториз вышесказанного получается, что в один коммит могут влезть несколько разных транзакций и совсем необязательно от одной таблицы на которых настроен CT.
Не совсем согласен с формулировкой и, особенно в части про то, настроен ли CT на этих таблицах или нет, но исходя из туманных определений полей
авторcommit_ts bigint A monotonically increasing number that serves as a database-specific timestamp for each committed transaction.
xdes_id bigint A database-specific internal ID for the transaction.

приходится делать вывод о том что "commited transaction" в общем случае может относится как один ко многим к "internal ID for the transaction", т.е. тут две разные транзакции имеются в виду.
Исходя из сказанного и помня что в sys.syscommittab уникальный ключ создан именно по полю xdes_id, а не по полю commit_ts, о чём соответствует ошибка в упомянутой Вами статье
автор"Cannot insert duplicate key row in object 'sys.syscommittab' with unique index 'si_xdes_id'. The duplicate key value is (KeyValue).
то правильнее было бы писать запрос типа:


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

В сухом остатке меня интересовало то, что остаётся за кадром. Что заставляет SQL сервер в рамках одной "commited transaction", вдруг, инкрементировать "internal ID for the transaction"? Я легко могу добиться изменения N таблиц в одной транзакции, я могу добиться разного типа изменений в одной транзакции (например оператор MERGE может дать сразу и I и U и D и всё в одной транзакции), но у меня никогда не складывалось Вашей ситуации.
Я надеялся получить ответ из логов, но изучение выхлопа от fn_dblog ничего не даёт. В её выхлопе всего два поля упоминают xdes, это [Max XDESID] и [Master XDESID]. Они там, кстати, записываются в другом формате. В таком же как поле [Transaction ID] (0000:00000000). Но их исследование ничего не даёт, у меня они пустые, по крайней мере в тех записях, которые касаются исследуемой таблицы. Возможно, в Вашем случае, они, как раз, будут непустыми и можно что-то раскопать. Например у меня xdes = 31358819. cast(31358819 as varbinary) = 0x01DE7F63. Первой записью от запроса


вижу:
авторOperation = LOP_COMMIT_XACT, Context = LCX_TRACKED_XDES

что намекает, что по некоему коммиту SQL отследил какой-то xdes.
У Вас на руках два xdes.
Как выглядит лог двух этих транзакций, выведенный в порядке возрастания или убывания [Current LSN]?
Что в поле AllocUnitName, совпадает с изменяемой таблицей?
Сколько Вы насчитаете внутри обычных транзакций (операции LOP_BEGIN_XACT и LOP_COMMIT_XACT)? Подозреваю, что всего одну. А если так - то самое интересное - это то что же происходит на изломе [Transaction ID]?

Забыл подписаться на ветку и опять заработался и забыл про неё.
Извините.

Честно говоря, не очень понял вот это:
ShIgor... с возрастающем LSN у которых первая часть одинаковая, вторых частей 2, и третья часть монотонно возрастающая в рамках 2 части.


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


Если у Вас остались ещё силы, то остаются три вопроса:
1. Эти две транзакции пересекаются по изменяемым данным? Нужно проанализировать что у них в полях Page ID, Lock Information и т.д.
2. Если да, то какой же у вас уровень изоляции, что над таблицей успешно работают две транзакции одновременно, меняющие одни и те же данные одновременно. Может у Вас там SNAPSHOT?
3. Нет возможности опознать что делается в этих двух транзакциях? Делают ли эти две транзакции одно и то же? Т.е. это один и тот же фрагмент кода, в некой процедуре, но запущенной, допустим, двумя пользователями из разных сессий. Какое-то узкое место, которое как-то оптимизировали (тем же SNAPSHOTом например). Или смешались действия двух фрагментов совсем разного кода?

Собственно, если на 1ый и 2ой вопрос ответ "да", то придётся признать, что SQL выводит всё верно. Ну, по крайней мере, объяснимо: "Вот это CT изменение было произведено сразу двумя транзакциями".

ShIgor,

Ну тогда, более-менее, понятно. Со снапшотами у вас, практически, версионная СУБД. Как точно при этом работает CT это уже надо глубоко нырять в тех. документацию. Где б её ещё взять, хотят тут на форуме есть товарищ уровня бог, лазящий по исходникам sqlserver, но его мы звать не будем :). Но ваш кейс вполне объясним. Раз две сессии не испытывают никаких проблем с работой с одними и теми же строками, то CT вполне себе может зарегистрировать их транзакции в одной своей. Как с этим бороться - тоже, в принципе, мы выяснили.

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