Отслеживание изменений в корпоративной базе данных SQL Server - Сравнение отслеживания изменений и сбора данных изменений
ОГЛАВЛЕНИЕ
Сравнение отслеживания изменений и сбора данных изменений
Рис. 4 предоставляет попунктовое сравнение отслеживания изменений и сбора данных изменений, позволяя получить лучшее представление о серьезных различиях, актуальных для администраторов баз данных. Из таблицы можно увидеть, что сбор данных изменений намного тяжеловеснее отслеживания изменений. Он требует большего внимания при принятии решений о том, что отслеживать, в силу потенциала к быстрому росту размера таблицы отслеживания, если, скажем, отслеживаемая таблица содержит столбцы BLOB или очень широкие строки. Возможны также проблемы с управлением журналом транзакций, поскольку журнал не будет обрезаться, пока средство чтения журнала не собрало записи из него.
Рис. 4. Сравнение отслеживания изменений и сбора данных изменений.
| Функция | Отслеживание изменений | Сбор данных изменений |
| Синхронность | Да | Нет |
| Требуется агент SQL | Нет | Да |
| Требуется ведение полного журнала или пакетных операций | Нет | Да |
| Предотвращает обрезание журнала | Нет | Да, пока записи журнала не собраны |
| Требуется изоляция снимков | Рекомендуется | Нет |
| Требуются отдельные таблицы для хранения данных отслеживания | Да | Да |
| Требуется первичный ключ | Да | Не по умолчанию |
| Допускается размещение таблиц отслеживания | Нет | Да |
| Потенциальные проблемы с потреблением пространства | Некоторые | Масса |
| Автоматический процесс очистки | Да | Да |
| Ограничения на DDL | Да | Нет |
| Необходимые разрешения для включения | Администратор системы | Владелец базы данных |
Но и отслеживание изменений не лишено своих требований. Например, ему необходим первичный ключ и при его применении настоятельно рекомендуется использовать изоляцию снимков. Изоляция снимков сама по себе может добавить рабочей нагрузке существенных издержек ресурсов и требует гораздо более аккуратного управления tempdb.
Существует одна дополнительная проблема, которую необходимо решать разработчикам и администраторам баз данных: аварийное восстановление. Хотя подробный рассказ о нем выходит за рамки этой статьи, тема аварийного восстановления слишком важна, чтобы не упомянуть о ней.
Обе функции хорошо работают с BACKUP и RESTORE. Проблема возникает тогда, когда база данных восстанавливается и по сути оказывается отброшенной назад во время. Как должны вести себя приложение/система в целом? Специальные решения, разработанные для отслеживания изменений, также сталкиваются с этой проблемой, и о ней следует помнить при использовании SQL Server 2008.
Как и всегда, убедитесь в том, что прочли всю доступную документацию (technet.microsoft.com/library/bb418491) и любые существующие технические документы, перед тем, как браться за работу над проектом, включающим новые функции отслеживания изменений. В первую очередь следует узнать, не могут ли быть применимы к вашему случаю какие-либо проблемы, не освещенные в этой статье. Следует также узнать подробности о новых пакетах обновления и динамических административных представлениях для наблюдения.
В целом эти новые функции являются огромным шагом вперед по сравнению с предыдущими методами отслеживания изменений в данных. Теперь, когда они существуют, можно быть уверенным, что разработчики пожелают использовать их в управляемых читателями решениях.
С ними связаны важные проблемы настройки и управления и я надеюсь, что эта статья дала читателям основательный обзор технологий, могущий позволить им предугадать некоторые из описанных мной проблем и подготовиться к ним.
Автор: Пол С. Рэндал
Иcточник: TechNet Magazine
Опубликована - 03.12.2008