Отслеживание изменений в корпоративной базе данных SQL Server

ОГЛАВЛЕНИЕ

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

В хранилище данных обычно как-либо представлены таблицы из базы данных оперативной обработки транзакций (OLTP), но схемы таблиц могут существенно отличаться. Это означает необходимость процесса извлечения, преобразования и загрузки данных (extract, transform, load – ETL), перемещающего данные из базы данных OLTP в хранилище данных. 

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

Мобильные устройства вездесущи в современной бизнес-среде, а это значит, что работа с изредка подключаемыми системами обязательна. С точки зрения систем баз данных проблема состоит в эффективном обновлении хранилища данных на устройстве, которое подключается нечасто, особенно если само хранилище маленькое и радикально отличается по схеме от основной базы данных.

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

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

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

Другой причиной для отслеживания изменений является поддержка аудита, что важно в наши дни. Аудит отслеживает вносимые изменения, а также то, когда произошло изменение и кто его выполнил. Это безусловно переносит дело на новый уровень, с жесткими ограничениями относительно устойчивости, безопасности и верности законченного журнала аудита.

Технологии, которые были разработаны для отслеживания изменений данных в SQL Server 2008, не предназначались для поддержки аудита, однако SQL Server 2008 предлагает новый компонент, именуемый подсистемой аудита SQL Server, предназначенный специально для аудита. Рик Бихэм (Rick Byham) рассказывал о компоненте подсистемы аудита SQL Server Audit в своей статье "SQL Server 2008: Security" «SQL Server 2008: Безопасность», в апрельском выпуске журнала TechNet Magazine за 2008 год (доступен по адресу technet.microsoft.com/magazine/cc434691).

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