Change Tracking или CDC: выбор потока изменений SQL Server

Поисковому индексу нужно узнать, какие товары изменились, чтобы перечитать их текущее состояние. Хранилищу аналитики могут потребоваться старые и новые значения каждого захваченного изменения. Обе задачи называют инкрементальной синхронизацией, но требования различаются. Change Tracking и Change Data Capture предоставляют разные исходные данные.

Сначала определите важность промежуточных состояний. Если цена менялась три раза, пока потребитель не работал, достаточно последней цены или нужны все переходы? Отдельно решите передачу удалений. Проверка LastModified не обнаружит уже удалённую строку, если факт удаления нигде больше не записан.

Смысл потока определяет выбор

Change Tracking хранит изменённые первичные ключи и метаданные. Текущие значения потребитель получает из исходной таблицы. Это подходит для обновления копии текущего состояния, но не для восстановления всех исторических переходов. Несколько изменений одного ключа не превращаются в полноценный журнал бизнес-событий. Отслеживание изменённых столбцов также не предоставляет их прежние значения.

CDC читает подтверждённые изменения из журнала транзакций в таблицы захвата. В зависимости от режима чтения можно получать захваченные значения до и после изменения либо итоговые изменения диапазона. Существует задержка захвата: успешный COMMIT источника ещё не означает доступность записи в CDC. На обычном SQL Server необходимо следить также за заданиями захвата и очистки.

Эти запросы только читают конфигурацию базы и список таблиц с Change Tracking.

SELECT d.name, d.is_cdc_enabled,
       ct.retention_period, ct.retention_period_units_desc,
       ct.is_auto_cleanup_on
FROM sys.databases AS d
LEFT JOIN sys.change_tracking_databases AS ct
    ON ct.database_id = d.database_id
WHERE d.database_id = DB_ID();

SELECT OBJECT_SCHEMA_NAME(object_id) AS SchemaName,
       OBJECT_NAME(object_id) AS TableName,
       is_track_columns_updated_on
FROM sys.change_tracking_tables;

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

Ни один механизм автоматически не создаёт неизменяемый аудит. Очистка удаляет историю, администратор может изменить настройки, а техническая запись не обязательно объясняет пользователя и бизнес-причину изменения.

Контрольная точка является частью данных

Потребитель Change Tracking сохраняет последнюю успешно применённую версию. Перед дальнейшим чтением её сравнивают с минимальной допустимой версией каждой таблицы.

-- Replace dbo.Products with an existing tracked table.
SELECT CHANGE_TRACKING_CURRENT_VERSION() AS CurrentVersion,
       CHANGE_TRACKING_MIN_VALID_VERSION(
           OBJECT_ID(N'dbo.Products')
       ) AS MinimumValidVersion;

Более старая контрольная точка уже ненадёжна. Нужные метаданные были очищены, и молчаливое продолжение способно оставить устаревшие строки в получателе. Требуется повторная инициализация из согласованного исходного состояния. NULL также требует проверки конфигурации и прав, а не трактовки как нулевой версии.

Для согласованного извлечения проверка точки, получение следующей версии и чтение изменений вместе с исходными строками выполняются по документированному шаблону snapshot isolation. Этот режим должен быть заранее включён. Для удалений нужен LEFT JOIN от изменённых ключей: исходной строки может уже не быть. Материализуйте выборку внутри согласованного чтения, затем завершайте транзакцию до длительной сетевой передачи.

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

CDC использует границы LSN вместо версий Change Tracking. Учитывайте доступный диапазон экземпляра захвата и включённые границы функций чтения. Для перехода к следующему диапазону используйте документированную функцию следующего LSN, а не собственную арифметику над двоичным значением.

Восстановление проектируют до расписания

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

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

Изменение схемы тоже требует договора. Новый столбец источника автоматически не появляется в существующем экземпляре CDC. Согласуйте развёртывание захвата и схемы получателя. Дополнительно проверяйте восстановление после пересоздания отслеживаемой таблицы: старый маркер нельзя считать действительным только потому, что имя объекта сохранилось. Решение завершено лишь тогда, когда процедура повторной инициализации действительно проверена.

Техническая документация: Microsoft Learn: Change Tracking · Microsoft Learn: Change Data Capture · Microsoft Learn: Working with Change Tracking.