Система отслеживания измененных данных (CDC)

  • Статья

Применимо к:SQL Server Управляемый экземпляр SQL Azure

В этой статье вы узнаете о системе отслеживания измененных данных (CDC), которая записывает действия в базе данных при изменении ее таблиц и строк.

В этой статье объясняется, как CDC работает с SQL Server и Управляемый экземпляр SQL Azure. Сведения о База данных SQL Azure см. в разделе CDC с База данных SQL Azure.

Обзор

Запись измененных данных использует агент SQL Server для записи журналов, обновлений и удалений, происходящих в таблице. Таким образом, он делает эти изменения данных доступными для легкого использования с помощью реляционного формата. Данные столбца и необходимые метаданные должны применять эти измененные данные к целевой среде, записываются для измененных строк и хранятся в таблицах изменений, которые зеркало структуру столбцов отслеживаемых исходных таблиц. Кроме того, табличное значение функций доступно для систематического доступа к данным об изменениях потребителями.

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

Поток данных

На следующем рисунке показан основной поток данных для системы отслеживания измененных данных.

Change data capture data flow diagram.

Источником измененных данных для системы отслеживания является журнал транзакций SQL Server . По мере того, как в исходных отслеживаемых таблицах выполняются операции вставки, обновления и удаления, в журнал добавляются записи, описывающие эти изменения. Журнал служит входом для процесса отслеживания. Затем он считывает журнал и добавляет сведения об изменениях связанной таблицы изменений в отслеживаемой таблице. Предусмотрены функции для перечисления изменений, появляющихся в таблицах изменений в заданном диапазоне, а также для возврата данных в виде отфильтрованного результирующего набора. Отфильтрованный результирующий набор обычно используется процессом приложения для обновления представления источника во внешней среде.

Экземпляр системы отслеживания

Прежде чем можно будет отслеживать изменения в отдельных таблицах базы данных, необходимо явно активировать систему отслеживания измененных данных в этой базе данных. Это делается с помощью хранимой процедуры sys.sp_cdc_enable_db. После того как база данных будет активирована, с помощью хранимой процедуры sys.sp_cdc_enable_tableисходные таблицы можно определить как отслеживаемые. Если для таблицы активирована система отслеживания измененных данных, создается связанный экземпляр системы отслеживания изменений для распространения данных об изменениях в исходной таблице. Экземпляр системы отслеживания состоит из таблицы изменений и одной-двух функций запроса. Метаданные, подробно описывающие конфигурацию экземпляра системы отслеживания, сохраняются в таблицах отслеживания измененных метаданных cdc.change_tables, cdc.index_columnsи cdc.captured_columns. Эти сведения можно получить с помощью хранимой процедуры sys.sp_cdc_help_change_data_capture.

Все объекты, связанные с экземпляром системы отслеживания, создаются в схеме системы отслеживания измененных данных для активированной базы данных. Требования к имени экземпляра записи — это допустимое имя объекта и уникальность в экземплярах отслеживания базы данных. По умолчанию имя — <имя> схемы name_table исходной таблицы. Связанная с ним таблица изменений именуется путем добавления ключевого слова _CT к имени экземпляра системы отслеживания. Функция, которая используется для запроса всех изменений, именуется путем добавления к началу имени экземпляра системы отслеживания префикса fn_cdc_get_all_changes_. Если экземпляр записи настроен для поддержки чистых изменений, функция запроса net_changes также создается и называется путем подготовки fn_cdc_get_net_changes_ к имени экземпляра записи.

Важно!

С одной исходной таблицей одновременно можно связать не более двух экземпляров отслеживания.

Таблица изменений

Первые пять столбцов таблицы изменений для системы отслеживания измененных данных являются столбцами метаданных. Они предоставляют дополнительные сведения, относящиеся к регистрируемому изменению. Остальные столбцы отражают опознанные отслеживаемые столбцы исходной таблицы по имени и типу. В этих столбцах хранятся данные отслеживаемых столбцов из исходной таблицы.

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

Каждая строка в таблице изменений также содержит другие метаданные для разрешения интерпретации действия изменения. Столбец __$start_lsn определяет номер LSN фиксации, который был присвоен изменению. Зафиксированный номер LSN определяет как операции изменения, которые были проведены в рамках одной транзакции, так и порядок транзакций. Столбец __$seqval можно использовать для упорядочивания дополнительных изменений, происходящих в той же транзакции. Столбец __$operation регистрирует операцию, связанную с изменением: 1 = удаление, 2 = вставка, 3 = обновление (исходный образ), 4 = обновление (результирующий образ). Столбец __$update_mask представляет собой маску переменной битовой маски с одним определенным битом для каждого захваченного столбца. Для вставки и удаления записей маска обновления имеет все биты. Однако обновить строки будут иметь эти биты, соответствующие измененным столбцам.

Период действия

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

База данных

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

В верхней конечной точке по мере того, как процесс отслеживания фиксирует каждый новый пакет информации об изменениях, новые записи добавляются к cdc.lsn_time_mapping для каждой транзакции, для которой имеются записи в таблице изменений. В таблице сопоставлений сохраняются регистрационный номер транзакции в журнале и время фиксации транзакции (столбцы start_lsn и tran_end_time соответственно). Максимальное значение номера LSN, обнаруженное в cdc.lsn_time_mapping , представляет верхнюю конечную точку диапазона периода действия. Соответствующее ей время фиксации используется как базовое значение, из которого очистка данных по истечении срока хранения вычисляет новое значение нижней конечной точки.

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

Экземпляр системы отслеживания

Хотя это обычно для интервала действия базы данных и интервала действия отдельного экземпляра записи совпадает, однако не всегда верно. Период действия экземпляра отслеживания начинается, когда процесс отслеживания распознает экземпляр отслеживания и начинает записывать связанные с ним изменения в таблицу изменений. В результате, если экземпляры записи создаются в разное время, каждая из них будет иметь другую низкую конечную точку. Столбец start_lsn результирующего набора, который возвращается функцией sys.sp_cdc_help_change_data_capture , показывает текущую нижнюю конечную точку для каждого определенного экземпляра отслеживания. Когда процесс очистки очищает записи таблицы изменений, он корректирует значения start_lsn для всех экземпляров отслеживания, чтобы отразить новую нижнюю конечную точку для каждого доступного набора информации об изменениях. Корректируются только те экземпляры отслеживания, текущие значения start_lsn которых меньше, чем новая нижняя конечная точка. Со временем, если не создаются новые экземпляры отслеживания, периоды действия для всех отдельных экземпляров постепенно совпадают с периодом действия для базы данных.

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

Функция sys.fn_cdc_get_min_lsn используется для получения текущего минимального номера LSN для экземпляра отслеживания, а функция sys.fn_cdc_get_max_lsn — для извлечения текущего максимального номера LSN. При запросе данных об изменении, если указанный диапазон LSN не лежит в этих двух значениях LSN, функции запроса отслеживания измененных данных завершаются ошибкой.

Обработка изменений исходных таблиц

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

Процесс отслеживания, ответственный за заполнение таблицы изменений, помещает таблицу изменений в фиксированной структуре столбцов, игнорируя новые столбцы, не определенные для записи, когда исходная таблица была включена для отслеживания измененных данных. Если отслеживаемый столбец удален, значения NULL предоставляются для столбца в последующих записях изменений. Однако если существующий столбец подвергается изменению типа данных, изменение распространяется в таблицу изменений, чтобы гарантировать, что механизм отслеживания не приводит к потере данных для отслеживаемых столбцов. Процесс отслеживания также отправляет все изменения в структуре столбцов отслеживаемой таблицы в таблицу cdc.ddl_history. Потребители, желающие получить предупреждение о корректировке, которую, возможно, придется внести в нисходящие приложения, используют хранимую процедуру sys.sp_cdc_get_ddl_history.

Как правило, текущий экземпляр записи продолжает сохранять свою форму при применении изменений DDL к связанной исходной таблице. Однако можно создать второй экземпляр записи для таблицы, которая отражает новую структуру столбцов. Этот параметр позволяет процессу записи вносить изменения в одну и ту же исходную таблицу в две разные таблицы изменений с двумя разными структурами столбцов. Таким образом, в то время как одна таблица изменений будет поставлять данные в текущие рабочие приложения, вторая будет служить источником данных для среды разработки, принимающей данные нового столбца. Позволив средству отслеживания одновременно заполнять обе таблицы изменений, можно добиться перехода от одного формата к другому без потери информации. Это может случиться в любое время, когда происходит перекрытие временных шкал двух систем отслеживания измененных данных. Если это влияет на переход, устаревший экземпляр отслеживания можно удалить.

Важно!

С одной исходной таблицей одновременно можно связать не более двух экземпляров отслеживания.

Связь с агентом чтения журнала

Логика процесса отслеживания измененных данных внедрена в расширенную хранимую процедуру sp_replcmds, во внутреннюю серверную функцию, являющуюся частью программы sqlservr.exe, а также используемую репликацией транзакций, которая считывает изменения из журнала транзакций. Если в базе данных в SQL Server или Управляемом экземпляре SQL активирована только система отслеживания измененных данных, создается задание отслеживания агента SQL Server как средство вызова хранимой процедуры sp_replcmds. Если реплика также присутствует, средство чтения журналов транзакций используется только для удовлетворения потребностей в изменении данных для обоих этих потребителей. Такой метод значительно снижает возможность состязания, если в одной базе данных активирована как система отслеживания измененных данных, так и репликация.

Переключение между этими двумя режимами работы для записи измененных данных происходит автоматически при изменении состояния реплика отслеживания измененных данных.

Примечание.

В SQL Server и Управляемый экземпляр SQL Azure оба экземпляра логики захвата требуют агент SQL Server для выполнения процесса.

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

Важно!

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

Кроме того, процесс отслеживания используется также для ведения журнала DDL-изменений в отслеживаемых таблицах. Инструкции DDL, связанные с системой отслеживания измененных данных, создают записи в журнале транзакций базы данных каждый раз, когда удаляется база данных или таблица с активированной системой отслеживания измененных данных или добавляются, изменяются или удаляются столбцы такой таблицы. Эти записи журнала обрабатываются процессом отслеживания, который затем отправляет соответствующие DDL-события в таблицу cdc.ddl_history. Сведения о событиях DDL, влияющих на отслеживаемые таблицы, можно получить с помощью хранимой процедуры sys.sp_cdc_get_ddl_history.

Предупреждение

  • MaxCmdsInTran не предназначен для включения всегда. Он существует для обхода случаев, когда кто-то случайно выполнял большое количество операций DML в одной транзакции (что приводит к задержке в распределении команд до тех пор, пока вся транзакция не находится в базе данных распространителя, блокировки удерживаются и т. д.). Если вы обычно попадаете в эту ситуацию, просмотрите логику приложения, чтобы найти способы уменьшения размера транзакции.
  • MaxCmdsInTran не поддерживается, если указанная база данных публикации включена как CDC, так и реплика tion. Использование MaxCmdsInTran в этой конфигурации может привести к потере данных в таблицах изменений CDC. Это также может привести к ошибкам PK, если параметр MaxCmdsInTran добавляется и удаляется при реплика больших транзакций.

Задания агентов

Два задания агент SQL Server обычно связаны с базой данных с включенным сбором измененных данных: одной из них, которая используется для заполнения таблиц изменений базы данных, и той, которая отвечает за очистку таблицы изменений. Оба задания состоят из одного шага, выполняющего команду Transact-SQL. Вызываемая команда Transact-SQL — это определенная хранимая процедура отслеживания измененных данных, реализующая логику задания. Оба задания создаются, когда система отслеживания измененных данных активируется в первой таблице базы данных. Задание очистки создается всегда. Задание отслеживания создается, только если для базы данных не определена публикация транзакций. Задание отслеживания также создается, когда в базе данных активируется как система отслеживания измененных данных, так и репликация транзакций, а задание агента чтения журнала транзакций удаляется, поскольку в базе данных теперь отсутствуют заданные публикации.

Как задание отслеживания, так и задание очистки создаются с помощью параметров по умолчанию. Задание отслеживания запускается немедленно. Оно выполняется постоянно, обрабатывая до 1 000 транзакций за цикл просмотра с 5-секундной задержкой между циклами. Задание очистки выполняется ежедневно в 2 утра. Он сохраняет записи таблицы изменений в течение 4320 минут или 3 дней, удаляя не более 5000 записей с одной инструкцией удаления.

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

На внутреннем уровне задания системы отслеживания измененных данных создаются и удаляются хранимыми процедурами sys.sp_cdc_add_job и sys.sp_cdc_drop_jobсоответственно. Эти хранимые процедуры открыты для доступа, чтобы администратор мог управлять созданием и удалением этих заданий.

Администратор не может явно управлять применяемой по умолчанию конфигурацией заданий агента для системы отслеживания измененных данных. Для изменения параметров конфигурации по умолчанию используется хранимая процедура sys.sp_cdc_change_job . Кроме того, хранимая процедура sys.sp_cdc_help_jobs позволяет просматривать текущие параметры конфигурации. Задание отслеживания и задание очистки при запуске извлекают параметры конфигурации из таблицы msdb.dbo.cdc_jobs. Любые изменения, внесенные в эти значения, с помощью sys.sp_cdc_change_job не вступают в силу, пока задание не будет остановлено и перезапущено.

Предоставляются две другие хранимые процедуры, позволяющие запускать и останавливать задания агента отслеживания измененных данных: sys.sp_cdc_start_job и sys.sp_cdc_stop_job.

Примечание.

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

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

Запись измененных данных не может работать должным образом, если служба ядро СУБД или служба агент SQL Server работает под учетной записью NETWORK SERVICE. В этом случае может возникать ошибка 22832.

Взаимодействие с другими компонентами

Запись измененных данных имеет некоторые ограничения при работе с другими функциями SQL Server. Ознакомьтесь с дополнительными сведениями о взаимодействии .

Известные проблемы

Сведения о известных проблемах и ошибках, связанных с записью измененных данных, см. в статье "Известные проблемы с CDC".

См. также