Сбор измененных данных — _$start_lsn — интерпретация этого значения

Когда я смотрю в одну из наших таблиц CDC, я вижу четыре строки в таблице со значением __$start_lsn 0x000CB13700041C06001B.

Мой вопрос заключается в следующем. Когда SQL Server записал четыре строки, содержащие этот номер lsn, в таблицу CDC, записал ли он только четыре строки, которые когда-либо будут иметь этот номер lsn, или возможно, что следующая транзакция может включать больше строк с тем же номером lsn?

Или, другими словами, когда я просматриваю или запрашиваю таблицу CDC для определенного LSN, могу ли я быть уверен, что никогда не увижу больше строк в будущем с тем же самым LSN?


sql-server sql-server-2008 change-data-capture
person Randy Minder    schedule 30.04.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

он написал только четыре строки, которые когда-либо будут иметь этот lsn

да. Посмотрите, как они описывают запрос всех новых изменений с момента последнего набора изменений.

Для типичных приложений запрос данных об изменениях будет непрерывным процессом, периодически запрашивая все изменения, произошедшие с момента последнего запроса. Для таких запросов вы можете использовать функцию sys.fn_cdc_increment_lsn для получения нижней границы текущего запроса из верхней границы предыдущего запроса. Этот метод гарантирует, что ни одна строка не будет повторяться, поскольку интервал запроса всегда рассматривается как закрытый интервал, в который включены обе конечные точки. Затем используйте функцию sys.fn_cdc_get_max_lsn, чтобы получить верхнюю конечную точку для нового интервала запроса. См. шаблон Перечислить все изменения с момента предыдущего запроса для примера кода, чтобы систематически перемещать окно запроса, чтобы получить все изменения с момента последнего запроса.

(Мой акцент)

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

person Damien_The_Unbeliever    schedule 30.04.2014
comment
Спасибо, Дэмиен. Просто чтобы я четко понимал, я могу с уверенностью предположить, что если я увижу строки с номером LSN, скажем, 123 (чего никогда не будет) в таблице, я могу быть уверен, что больше никогда не увижу строк с тем же номером LSN в таблице в следующей транзакции или в любое время в будущем? - person Randy Minder; 30.04.2014

arrow_upward
0
arrow_downward

В дополнение к превосходному ответу Damien_The_Unbeliever я добавлю, что LSN являются основным идентификатором изменений в базе данных. Из этой статьи BOL:

Каждая запись в журнале транзакций SQL Server уникально идентифицируется по порядковому номеру журнала (LSN). Номера LSN упорядочены таким образом, что если номер LSN2 больше номера LSN1, то изменение, описанное записью журнала, на которую ссылается номер LSN2, произошло после изменения, описанного номером LSN записи журнала.

(выделено мной)

Вы также можете сделать несколько других выводов из второго предложения. Из-за присущей LSN упорядоченности вы можете упорядочить их в своем запросе, и вы получите порядок, в котором эти вещи были зафиксированы в журнале. Вы также можете сделать вывод об уникальности этого оператора, поскольку если LSN2 = LSN1, то эти записи были зафиксированы в журнале одновременно.

person Ben Thul    schedule 30.04.2014