Отслеживание изменений в корпоративной базе данных SQL Server - Как работает отслеживание изменений
ОГЛАВЛЕНИЕ
Как работает отслеживание изменений
Как я уже упоминал, отслеживание изменений – это синхронный процесс, который куда менее сложен, чем сбор данных изменений. Это часть транзакции, которая вносит изменение в строку в отслеживаемой таблицы и тот факт, что строка изменилась, отслеживается в отдельной таблице. Данная таблица – это то, что называется внутренней таблицей, и ее имя с местом хранения нельзя контролировать. Я не считаю это проблемой, поскольку в этой таблице должно быть гораздо меньше данных, чем в таблице изменений, используемой для сбора данных изменений. Но, как я сейчас объясню, проблемы с пространством на диски все же возможны.
Тот факт, что отслеживание изменений выполняется синхронно, означает, что внутри каждой транзакции происходит гораздо меньшей дополнительной обработки, изменяющей отслеживаемую таблицу. Воздействие на производительность подобно тому, что имеет место при существовании на таблице некластеризованного индекса, который необходимо изменять с каждым изменением таблицы. Сами транзакции также отслеживаются при их последовательной фиксации во внутренней таблице sys.syscommittab.
Отслеживание изменений включается и отключается с использованием обычного синтаксиса ALTER DATABASE и ALTER TABLE и следует той же модели, что и сбор данных изменений, где оно должно быть включено на уровне базы данных перед включением на уровне таблицы. Последовательность операций будет выглядеть примерно следующим образом:
ALTER DATABASE AdventureWorks2000 SET CHANGE_TRACKING = ON (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON); GO USE AdventureWorks2000; GO ALTER TABLE Person.Person ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = ON); GO
Требуемые разрешения для включения отслеживания изменений на уровнях базы данных и таблицы также отличаются от требуемых для включения сбора данных изменений: db_owner и владельца таблицы, соответственно. Когда отслеживание изменений включается на уровне базы данных, можно установить период хранения, а также указать, будут ли данные изменений очищаться автоматически. Период хранения по умолчанию – 2 дня, с максимумом в 90 дней и минимумом в одну минуту.
Автоматическая очистка также включается по умолчанию. При внесении изменений в эти параметры, необходимо оценить те же приоритеты, о которых я говорил применительно к сбору данных изменений, – что важнее для приложения: пространство на диске или производительность.
По умолчанию для каждой строки собирается лишь факт ее изменения. Это выполняется путем создания заметки из первичного ключа изменившейся строки (что означает невозможность отслеживать изменения на таблице без первичного ключа), вместе с номером версии (после того как на базе данных включено отслеживание изменений, устанавливается номер версии, что позволяет определить порядок операций) и тип операции, выполнившей изменение. Как вариант, можно также отследить, какие столбцы изменились, это требует 4 байт на изменившийся столбец.
Наблюдение за пространством на диске несколько отличается от отслеживания изменений, поскольку данные об изменениях хранятся во внутренних таблицах. Чтобы найти имена используемых внутренних таблиц, просто используйте представление каталога системы sys.internal_tables:
SELECT [name] FROM sys.internal_tables WHERE [internal_type_desc] = 'CHANGE_TRACKING'; GO
Затем передайте имя в sp_spaceused, чтобы увидеть, сколько используется дискового пространства.
В отличие от сбора данных изменений, когда включено отслеживание изменений, существуют ограничения на DDL, который можно выполнять на отслеживаемой таблице. Наиболее заметным ограничением является невозможность как-либо изменять основной ключ. Другое ограничение, заслуживающее упоминания здесь, заключается в том, что ALTER TABLE SWITCH потерпит неудачу, если на любой из затронутых таблиц было включено отслеживание изменений. Это, скорее всего, вызывается тем фактом, что не имеет смысла автоматически начинать или удалять отслеживание изменений для отключаемого из отслеживаемой, разбитой на разделы, таблицы, раздела или отслеживаемой таблицы, включаемой в разбитую на разделы таблицу, соответственно.
Изменения извлекаются из внутренних таблиц изменений с использованием новой функции CHANGETABLES (CHANGES …). Она принимает имя отслеживаемой на предмет изменений таблицы плюс номер версии с предыдущего раза, когда она использовалась, и возвращает информацию о всех строках, изменившихся с прошлого раза. Существуют различные функции для поиска текущей и наиболее старой допустимой версии. Приложение может затем использовать возвращенную информацию для запроса таблицы, отслеживаемой на предмет изменений, чтобы получить реальные значения столбцов. Это, само собой, многоэтапный процесс – сперва получается текущая версия, затем эта версия используется для запроса отслеживания изменений и затем собственно таблицы запрашиваются на предмет данных столбцов, соответствующих этой версии.
В постоянно изменяющейся системе возможно получить непоследовательные или неверные результаты, если не поддерживать какого-либо рода неизменное представление версии, данных изменений и собственно данных столбцов. Чтобы сделать это, можно использовать изоляцию снимка и поместить многоэтапный процесс в прямую транзакцию. Этот способ работает эффективно, но имеет потенциальные недостатки. Изоляция снимка может сказаться на производительности рабочей нагрузки и влияет на производительность и использование пространства в tempdb. Дополнительные сведения об этом можно найти по адресу technet.microsoft.com/library/cc280358.