Использование Sql Server Change Data Capture с часто меняющейся схемой

Мы стремимся включить Sql Server Change Data Capture для новой подсистемы, которую мы создаем.

Это на самом деле не потому, что нам это нужно, но нас настаивает на том, что мы имеем полную прослеживаемость истории, и CDC хорошо бы справился с этим требованием с минимальными усилиями с нашей стороны.

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

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

Существует ли механизм обновления таблицы CDC до новой схемы, и есть ли какие-либо рекомендации по работе с захваченными данными при переносе схемы базы данных?

Мы также недавно начали смотреть на CDC. Я не эксперт по этому вопросу, но я думаю, что у меня есть несколько ответов на ваши вопросы.

По большей части, CDC поможет вам достичь цели полностью прослеживаемой истории, но я не думаю, что она поможет вам в этом.

Прежде всего:

мы часто вносим изменения в схему базы данных ... Существует ли механизм обновления таблицы CDC до новой схемы

И здесь я думаю, что CDC подведет вас. Документация MSDN в разделе «Общие сведения об издержках отслеживания изменений» совершенно ясно, что она не будет отслеживать изменения схемы для вас. Например, с Alter Table Add Column:

Если в таблицу отслеживания изменений добавляется новый столбец, добавление столбца не отслеживается. Отслеживаются только обновления и изменения, внесенные в новый столбец.

Drop Column немного сложнее.

Однако вы должны использовать сценарии БД для изменения вашей схемы, поэтому вам не обязательно полагаться на CDC здесь. Это позволяет вам иметь согласованность между вашими схемами контроля качества и производства. И изменение QA должно быть выполнено скриптом, чтобы те же самые изменения могли быть применены к Prod. Не должно быть слишком сложно извлечь изменения схемы из этих сценариев. Это может означать, что измерение времени в вашей истории будет зависеть от версии, а не от фактического времени, но конечный результат будет таким же.

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

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

Существуют ли передовые методики работы с захваченными данными при переносе схемы базы данных?

Относитесь к этому так же, как к ревизии. Вы должны понимать, что именно вы исследуете, почему вы это исследуете и как долго вам нужно хранить эту информацию. Сфера охвата и удержание - две самые большие ошибки, когда дело доходит до такой задачи.

Инструменты отчетности CDC понятны аскетично, поэтому вы должны знать контекст изменений. Слишком легко сказать "отслеживай все !" и в итоге ничего не получится пригодным для использования. Аналогично, вы можете удвоить размер своей базы данных, сохранив копию каждого изменения. На высокопроизводительном столе с большим количеством вставок и удалений вы получите астрономический рост. Само по себе это неплохо, но вам нужно составить бюджет для этого роста и иметь возможность изучить все сгенерированные данные.

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

Вы можете отслеживать добавление столбцов с помощью триггеров DDL.

CREATE TRIGGER trigger_name
ON { ALL SERVER | DATABASE }
[ WITH <ddl_trigger_option> [ ,...n ] ]
{ FOR | AFTER } { event_type | event_group } [ ,...n ]
AS { sql_statement [ ; ] [ ,...n ] |
EXTERNAL NAME < method specifier > [ ; ] }

Вы можете использовать группу событий DDL_TABLE_EVENTS для запуска CREATE, DROP или ALTER таблицы.

Тем не менее, вы можете захотеть взглянуть на SQL Server Audit , если вы используете enterprise> 2008, так как он может «объединить все возможности аудита в спецификации аудита». Эта ссылка msdn содержит подробную статью об этом: http://msdn.microsoft.com/en-us/library/dd392015(v=sql.100).aspx .

CREATE SERVER AUDIT audit_name
TO { [ FILE (<file_options> [, ...n]) ] |
APPLICATION_LOG | SECURITY_LOG }
[ WITH ( <audit_options> [, ...n] ) ] }[ ; ]

<file_options>::=
{FILEPATH = 'os_file_path'
[, MAXSIZE = { max_size { MB | GB | TB } | UNLIMITED } ]
[, MAX_ROLLOVER_FILES = integer ]
[, RESERVE_DISK_SPACE = { ON | OFF } ] }

<audit_options>::=
{ [ QUEUE_DELAY = integer ]
[, ON_FAILURE = { CONTINUE | SHUTDOWN } ]
[, AUDIT_GUID = uniqueidentifier ]}

Затем вы создаете спецификации сервера или базы данных.

В Simple-Talk есть отличная статья о сборе данных об изменениях и очень подробное руководство по CDC, а также документация MSDN, где объясняются различные методы в зависимости от требований. Но они оба могут помочь вам с вашими конкретными требованиями.