Отслеживание изменений в корпоративной базе данных SQL Server - Более простые способы отслеживания изменений в SQL Server 2008
ОГЛАВЛЕНИЕ
Более простые способы отслеживания изменений в SQL Server 2008
SQL Server 2008 представляет две новых технологии, намного упрощающие отслеживание изменений в данных: отслеживание изменений и сбор данных изменений. Обе функции отслеживают изменившиеся данные (а также используют операции вставки, обновления и удаления, чтобы проследить, как именно изменились данные) и устраняют нужду в пользовательских решениях. За исключением этих сходств механизмы этих функций и объекты их отслеживания на деле довольно различны.
Сбор данных изменений использует асинхронный механизм, отслеживающий все изменения, происходящие в таблице (или определенном наборе столбцов в таблице), включая сами значения столбцов. Он разработан для ситуаций, подобных описанному мною ранее процессу хранилища данных ETL.
Рис. 1 иллюстрирует потребление данных изменений через временные интервалы. Механизм сбора данных изменений извлекает измененные данные в набор таблиц, с последними изменениями на верху таблицы. Процесс ETL может затем запросить у таблиц, содержащих данные изменений, все изменения, произошедшие за определенный временной период. Этот механизм позволяет процессу ETL ограничить объем данных, который должен быть потреблен в каждом пакете.
Рис. 1. Данные истории изменений потребляются через временные интервалы
Отслеживание изменений, с другой стороны, использует синхронный механизм, отслеживающий только изменение определенной строки в таблице (и, при желании, список изменившихся столбцов). Это разработано как ответ на проблемы, вроде описанного мною выше случая с изредка подключающейся системой. Этот подход проиллюстрирован на рис. 2.
Рис. 2. Использование данных отслеживания изменений изредка подключающейся системой
Обе функции увеличивают объем ввода/вывода и число записей в журнал, но это также верно и для пользовательских решений – данные изменений нужно где-то хранить. Принципиальное различие этих функций от пользовательского решения в том, что таблицы, используемые для хранения данных изменений, должны быть в той же базе данных, что и отслеживаемые таблицы. Это значит, что все данные изменений будут включены в резервные копии и затем переданы по сети, путем доставки журналов или зеркального отражения баз данных.
В плане разработки две эти функции должны существенно уменьшить сложность отслеживания изменений. Ни одна из них не требует изменений схемы или триггеров. Обе имеют настраиваемые, автоматические процессы очистки, сортируют изменения по времени завершения транзакций и предоставляют встроенные функции для извлечения информации об изменениях.
С точки зрения управления у каждого из подходов есть свои «за» и «против». Как и в случае с любой технологией, существует масса информации, которую необходимо усвоить, прежде чем браться за разработку и развертывание решений, использующих эти функции. В оставшейся части статьи я дам обзор обеих этих функций, касаясь того, как они работают и практических моментов, которые следует обдумать, перед использованием их в рабочей среде.