2.8.2.Снимки и триггеры базы данных

Непротиворечивость и
репликация
Из курса :Информационные и программные
ресурсы в ТСС, Глоба Л.С.
Подготовила:
Ст.гр ТИ42м Андриешина У.А.
Содержание 1
1. Непротиворечивость
1.1. Компоненты непротиворечивого чтения
1.1.1. Сегменты отката
1.1.2. Номер системного изменения
1.1.3. Блокировки
1.2. Модели непротиворечивости
1.2.1. Модель последовательной непротиворечивости
1.2.2. Модель непротиворечивости FIFO
1.2.3. Модель слабой непротиворечивости
1.2.4. Протокол первичного архивирования с удаленной записью
1.2.5. Протокол первичного архивирования с локальной записью
1.Непротиворечивость
Непротиворечивость - это одна из
основных характеристик хранилища
данных, в которой определяются правила,
необходимые соблюдать, чтобы хранилище
возвращало разным процессам правильные
результаты.
*Непротиворечивость –
свойство дедуктивной теории (или системы аксиом,
посредством которых теория задаётся), состоящее в том,
что из неё нельзя вывести противоречие, т. е.
какие-либо два предложения А и Ø А, каждое из которых
является отрицанием другого.
(Большая советская энциклопедия)
Для уменьшения риска возникновения противоречивых
данных надо устранить избыточность данных или
контролировать её.
Существуют следующие способы:
1) Если элемент данных хранится в базе только в одном
экземпляре, то для изменения его значения потребуется
выполнить только обновления, причем новое значение
станет доступным сразу всем пользователям базы данных.
2) А если этот элемент данных (с ведома системы) хранится в
базе данных в нескольких экземплярах, то такая система
сможет следить за тем, чтобы копии
не противоречили друг другу.
К сожалению, во многих современных СУБД
такой способ обеспечения
непротиворечивости данных не
поддерживается автоматически.
1.1. Компоненты непротиворечивого чтения:
1. сегменты отката
2. номер системного изменения
(System Change Number — SCN)
3. блокировки.
1.1.1. Сегменты отката
Сегменты отката(С.О.) представляют собой структурные
компоненты базы данных , предназначенные для хранения
информации отката.
Непосредственно перед внесением изменений в данные блока
базы данных в СУБД происходит запись предыдущих значений
этих данных в сегмент отката. С.О. не только обеспечивают
непротиворечивость чтения с поддержкой многих версий, но и
позволяют выполнить откат любой транзакции. В СУБД
поддерживается также один или несколько журналов
восстановления, предназначенных для регистрации всех
выполненных транзакций; эти журналы применяются для
восстановления базы данных в случае аварии системы.
1.1.2.Номер системного изменения
Для соблюдения правильного хронологического порядка операций в
СУБД ведется единый номер системного изменения (SCN),
который представляет собой логическую временную отметку,
которая позволяет зарегистрировать последовательность выполнения
операций.
СУБД записывает текущие значения SCN в журнал восстановления для
обеспечения возможности выполнить накат транзакций в правильной
последовательности. В этой СУБД SCN применяется для определения
того, какая версия элемента данных должна использоваться в
транзакции. SCN позволяет также определить, какая информация,
хранящаяся в сегментах отката, уже не нужна и может быть удалена.
1.1.3. Блокировки
Блокировки неявно применяются при выполнении всех операторов
SQL, поэтому пользователю никогда не требуется явно блокировать
какие-либо ресурсы.
Тем не менее в СУБД предусмотрен механизм, позволяющий
пользователю устанавливать блокировки вручную или
изменять, правила установки и снятия блокировок,
предусмотренные по умолчанию.
Применяемые по умолчанию механизмы
блокировки обеспечивают блокировку
данных на наименее ограничительном уровне,
который гарантирует целостность данных и
вместе с тем позволяет достичь максимальной
степени распараллеливания.
1.2. Модели непротиворечивости,
ориентированные на данные
• Строгая непротиворечивость
• Линеаризуемая(максимально правдоподобная)
непротиворечивость
• Последовательная непротиворечивость
• Причинная непротиворечивость
• непротиворечивость FIFO
• Слабая непротиворечивость
• Свободная непротиворечивость
• Поэлементная непротиворечивость
Последовательная, FIFO, Слабая
Этот выбор обусловлен тем, что первые две
модели обеспечивают глобальную
сериализуемость (способность к
упорядочению) операций, а последняя довольно легко реализуема и является менее
жесткой, чем первые две.
1.2.1. Модель последовательной
непротиворечивости:
Результат любого действия такой же, как если бы
операции (чтения и записи) всех процессов в
хранилище данных выполнялись бы в некотором
последовательном порядке, причем операции
каждого отдельного процесса выполнялись бы в
некотором последовательном порядке,
определяемом его программой.
1.2.2.Модель непротиворечивости FIFO :
Операции записи, осуществляемые единичным
процессом, наблюдаются всеми остальными
процессами в том порядке, в котором они
осуществляются, но операции записи, происходящие
в различных процессах, могут наблюдаться разными
процессами в разном порядке.
1.2.3. Модель слабой непротиворечивости:
Для определения слабой непротиворечивости вводится понятие
переменной синхронизации.
Переменная синхронизации (S) имеет ассоциированный с ней
набор данных и позволяет выполнять над собой единственную
операцию synchronize(S). В ходе выполнения этой операции
изменения сделанные процессом в локальной копии данных
распространяются на все остальные копии данных,
ассоциированные с переменной синхронизации. Также в ходе
этой операции локальная копия обновляется данными из
остальных копий.
1.2.4. Протокол первичного архивирования с
удаленной записью
• Описание протокола:
• Расшифровка обозначений:
W1 - запрос на запись
W2 - пересылка запроса на сервер
W3 - сигнал на обновление резервных копий
W4 - подтверждение выполнения обновления
W5 - подтверждение выполнения записи
R1 - запрос на чтение
R2 - ответ для чтения
1.2.4. Протокол первичного архивирования с удаленной
записью
• При реализации этого протокола необходимо гарантировать,
что в каждый момент времени только один узел имеет доступ
к первичной копии, тем самым, имея возможность изменять
данные.
• Существует асинхронный вариант, при котором
подтверждение о выполнении записи посылается сразу после
обновления первичной копии (не дожидаясь обновления всех
копий). Это повышает производительность операции записи,
однако требует дополнительных действий для обеспечения:
гарантированного обновления всех реплик и согласованного
чтения для узла, инициировавшего обновление (он не должен
иметь возможность считать значение, который имел элемент
данных до записи).
• В случае если все первичные копии находятся на одном узле,
имеем реализацию последовательной непротиворечивости,
иначе не предпринимая дополнительных мер можно говорить
только о непротиворечивости FIFO.
1.2.5. Протокол первичного архивирования с
локальной записью
• Описание протокола:
Расшифровка обозначений:
W1 - запрос на запись
W2 - перемещение элемента данных х на новый первичный сервер
W3 - подтверждение завершения записи
W4 - сигнал на обновление резервных копий
W5 - подтверждение обновления
R1 - запрос на чтение
R2 - ответ для чтения
1.2.5. Протокол первичного архивирования с
локальной записью
• В протоколе подразумевается асинхронное
обновление остальных копий.
• Без дополнительных мер протокол реализует FIFO
непротиворечивость, реализовав полностью
упорядоченную групповую рассылку, можно
получить реализацию последовательной
непротиворечивости.
• Поскольку в протоколе допускается перемещение
первичной копии то необходимо решить задачи
поиска узла, содержащего первичную копию и
смены владельца.
Содержание 2
2.Репликация
2.1. Сравнительные характеристики различных стратегий размещений
данных
2.2.Основные концепции репликации данных
2.3.Синхронная репликация
2.4.Асинхронная репликация
2.5.Полусинхронная репликация
2.6.Типы репликации
2.7.Функциональные средства
2.8.Проблемы реализации
2.8.1.Обновления, выполняемые в составе транзакций
2.8.2.Снимки и триггеры базы данных
2.8.2.1.Снимки
2.8.2.2.Основная идея метода снимков
2.8.2.3.Метод организации очередей
2.8.3.Триггеры базы данных
2.8.4.Выявление и разрешение конфликтов
2.Репликация
Репликация - процесс формирования и воспроизведения
многочисленных копий данных на одном или нескольких узлах.
Существуют четыре стратегии распределения, определяющие
способ размещения данных:
1) централизация - единственная централизованная база данных;
2) фрагментация - каждый фрагмент размещается на одном из узлов;
3) полная репликация –
полная копия всех данных
поддерживается на каждом узле;
4) избирательная репликация –
комбинация первых трех способов.
2.1. Сравнительные характеристики
различных стратегий размещений данных
Локализация
ссылок
Надежность
и
доступность
Производительность
Стоимость
хранения
Затраты на
передачу
данных
Централизованное
размещение
Самая
низкая
Самая низкая
Неудовлетво
рительная
Самая низкая
Самые
высокие
Фрагментированное
размещение
Высокая
Низкая для
отдельных
элем.,
высокая для
системы
Удовлетвори
тельная
Самая низкая
Низкие
Полная репликация
Самая
высокая
Самая
высокая
Высокая при
выполнении
операции
чтения
Самая высокая
Высокие при
операции
обновления,
низкие при
чтении
Избирательная
репликация
Низкая для
отдельных
элементов,
высокая для
системы
Низкая для
отдельных
элем.,
высокая для
системы
Удовлетвори
тельная
Средняя
Низкие
2.2.Основные концепции репликации данных
• Механизм репликации важен, поскольку он позволяет
организации обеспечивать доступ пользователям к актуальным
данным когда они в этом нуждаются.
• Использование репликации позволяет достичь многих
преимуществ, включая повышение производительности (когда
централизованный ресурс оказывается перегруженным),
надежности хранения и доступности данных, наличие
"горячей" резервной копии на случай восстановления,
• Возможность поддержки мобильных пользователей и
хранилищ данных.
2.3.Синхронная репликация
Синхронная репликация- репликация, при которой все копии
копируемых данных обновляются одновременно с изменением
исходной копии.
Этот механизм может быть необходим для некоторого класса
систем, в которых все копии данных надо поддерживать в
абсолютно синхронном состоянии (пример: финансовые
операции).
Недостаток: большое количество сообщений, необходимых для
координации процесса синхронизации данных, создает
значительную дополнительную нагрузку на корпоративную сеть.
2.4.Асинхронная репликация
Асинхронная репликация
предусматривает
обновление целевых баз данных после обновления исходной базы
данных.
Задержка в восстановлении согласованности данных может находиться
в пределах от нескольких секунд до нескольких часов или даже суток.
Однако в конечном итоге данные во всех копиях будут приведены в
синхронное состояние.
Такой подход нарушает принцип независимости
распределенных данных, он вполне может рассматриваться как
приемлемый компромисс между требованиями обеспечения
целостности и доступности данных.
2.5.Полусинхронная репликация
Вариантом, сочетающим в себе возможности синхронной и асинхронной
репликации, является так называемая «semisynchronous» репликация,
или «полусинхронная».
В этом случае репликация проводится синхронной до тех пор, пока это
позволяет быстродействие системы или канала связи.
А затем, вместо замедления и остановки операций записи, временно
переключается в асинхронный режим, продолжая обрабатывать
поступающие данные без задержек, отправляя данные репликации в
асинхронном режиме до тех пор, пока не возникнет возможность
восстановить синхронный режим.
2.6.Типы репликации
• Снимки, предназначенные только для чтения. Иногда
именуются материализованными представлениями. Ведущая таблица
копируется в одной или нескольких удаленных базах данных в виде
так называемых снимков. Изменения в ведущей таблице отражаются в
таблицах снимков при каждом обновлении снимка; периодичность
обновления устанавливается на узле снимка.
• Обновляемые снимки. Аналогичны снимкам, предназначенным
только для чтения, за исключением того, что на узлах, где находятся
снимки, разрешается вносить в них данные и передавать эти
изменения на ведущий узел. И в этом случае периодичность
обновления снимков определяется на узле, где находятся снимки. На
этом узле определяется также периодичность отправки данных об
обновлениях на ведущий узел.
• Репликация с помощью нескольких ведущих копий. Таблица
копируется в одну или несколько удаленных баз данных, в которых эта
таблица может обновляться. Информация об изменениях передается в
другие базы данных с периодичностью, установленной
администратором базы данных для каждой группы репликации.
• Процедурная репликация. Вызов пакетной процедуры или
функции копируется в одной или нескольких базах данных.
2.7.Функциональные средства
Кроме того, что на функциональном уровне служба репликации
распределенных данных должна позволять копировать данные
из одной базы данных в другую синхронно или асинхронно,
существует множество других функций:
• Масштабируемость. Служба репликации должна обеспечивать
эффективное копирование как малых, так и больших объемов
данных.
• Преобразование и трансформация. Служба репликации
должна поддерживать репликацию данных в разнородных
системах, работающих на разных платформах. Для этого могут
потребоваться преобразование и трансформация данных из
одной модели данных в другую или же преобразование
некоторого типа данных в соответствующий тип данных, но для
среды другой СУБД.
2.7.Функциональные средства
• Репликация объектов - должна существовать возможность
копировать объекты, а не просто данные. Например, в
некоторых системах допускается репликация индексов и
хранимых процедур.
• Средства определения схемы репликации - система
должна предоставлять механизм, позволяющий
привилегированным пользователям задавать данные и
объекты, подлежащие репликации.
• Механизм подписки - система должна включать механизм,
позволяющий привилегированным пользователям оформлять
подписку на получение данных и других объектов, подлежащих
репликации.
• Механизм инициализации - система должна включать
средства, обеспечивающие инициализацию вновь создаваемой
копии.
• Простота администрирования - система должна
предоставлять администратору базы данных удобные средства
администрирования системы, проверки ее состояния и
контроля производительности компонентов системы
репликации.
2.8.Проблемы реализации
Тут будет рассмотрено некоторые проблемы реализации методов
репликации данных, а именно:
• Обновления, выполняемые в составе транзакций.
• Снимки и триггеры базы данных.
• Выявление и разрешение
конфликтов.
2.8.1.Обновления, выполняемые в составе
транзакций
На первых порах для реализации механизма репликации применялся
метод, предусматривающий выгрузку необходимых данных на
внешний носитель информации (например, на магнитную ленту), а
затем передачу этого носителя с курьером на второй узел, где эта
копия загружалась в другую компьютерную систему (такой метод
обмена данными часто называют "экспедиторской доставкой"). При
использовании подобного метода решения часто принимались на
основе данных, полученных несколько дней тому назад. Основным
недостатком такого подхода являлось то, что нельзя было добиться
своевременной доставки копий, а при загрузке и выгрузке данных
значительная часть операций выполнялась вручную.
На рисунке показана транзакция, состоящая из
нескольких операций обновления различных таблиц на исходном узле. В
процессе репликации транзакция преобразуется в несколько отдельных
транзакций, каждая из которых обеспечивает обновление определенной
таблицы. Но если часть этих транзакций на целевом узле завершалась
успешно, а остальная часть — нет, то согласованность информации
между двумя базами данных утрачивалась.
2.8.2.Снимки и триггеры базы данных
В этом разделе описаны способы применения снимков для
реализации механизма репликации с применением транзакций.
Кроме того, приведено сравнение этих способов с механизмами,
в которых используются триггеры базы данных.
2.8.2.1.Снимки
Метод снимков позволяет асинхронно распространять
результаты изменений, выполненных в отдельных таблицах,
группах таблиц, представлениях или фрагментах таблиц, в
соответствии с заранее установленным расписанием.
Чаще всего для создания снимков применяется журнал
восстановления базы данных. Это позволяет свести
дополнительную нагрузку на систему к минимуму.
2.8.2.2.Основная идея метода снимков
Состоит в том, что файл журнала является лучшим источником
для получения сведений об изменениях в исходных данных.
Достаточно иметь механизм, который будет обращаться к
файлу журнала для выявления изменений в исходных данных,
после чего распространять сведения об обнаруженных
изменениях во все целевые базы данных, не оказывая никакого
влияния на нормальное функционирование исходной системы.
Различные СУБД реализуют подобный механизм по-разному: в
некоторых случаях данный процесс выполняется самим
сервером СУБД, тогда как в других случаях он выполняется с
помощью отдельного внешнего сервера.
2.8.2.3.Метод организации очередей
Для отправки сведений об изменениях на другие узлы
целесообразно также применять метод организации
очередей. Если произойдет отказ сетевого соединения или
целевого узла, сведения об изменениях могут сохраняться в
очередях до тех пор, пока соединение не будет
восстановлено.
Для обеспечения целостности в процессе доставки сведений
об изменениях необходимо сохранять исходную
последовательность формирования этих сведений.
2.8.3.Триггеры базы данных
Альтернативный подход заключается в предоставлении пользователям
возможности создавать собственные приложения, выполняющие
репликацию данных с использованием механизма триггеров базы данных.
В частности, в СУБД Oracle для сопровождения копии отношения staff на
другом узле, указанном с помощью соединения базы данных с именем
RENTALS. GLASGOW. NORTH. COM можно использовать приведенный
ниже триггер.
Недостатки
• В связи с необходимостью запуска и выполнения триггерных
процедур создается дополнительная нагрузка на систему.
• Триггеры выполняются при каждом изменении строки в
ведущей таблице.
• Триггеры не могут выполняться в соответствии с некоторым
расписанием.
• Если копируется несколько связанных таблиц, синхронизация их
репликации может быть достигнута за счет использования
механизма групповых обновлений. Добиться решения этой задачи
с помощью триггеров значительно сложнее,
• Аннулирование результатов выполнения триггерной процедуры
в случае отмены или отката транзакции — достаточно сложная
задача.
2.8.4.Выявление и разрешение
конфликтов
• Самая ранняя или самая поздняя временная отметка.
Изменяются, соответственно, данные с самой ранней или самой поздней
временной отметкой.
• Приоритеты узлов. Применяется обновление, поступившее с узла с
наибольшим приоритетом.
• Обновления, связанные с вычислением суммы и среднего
значения. Обновления применяются с учетом правил коммутативности.
Этот вариант разрешения конфликтов может использоваться в тех
случаях, когда
обновление атрибута выполняется с применением операций
суммирования,
например salary = salary + х.
• Минимальное или максимальное значение. Применяются
обновления, соответствующие столбцу с минимальным или
максимальным значением.
• По решению пользователя. АБД предусматривает применение
процедуры разрешения конфликта, указанной пользователем. Дело в
том, что для устранения конфликтов многих типов могут быть
предусмотрены разные процедуры.
• Предоставление возможности непосредственного
вмешательства для разрешения конфликта. Сведения о
конфликте записываются в журнал ошибок для последующего анализа
и устранения администратором базы данных вручную.
Выводы:
1)Непротиворечивость - это одна из основных характеристик
хранилища данных, в которой определяются правила,
необходимые соблюдать, чтобы хранилище возвращало
разным процессам правильные результаты.
2)Рассмотрели протокол первичного архивирования с удаленной
записью и с локальной записью на примерах.
3)Определили что такое последовательная модель
непротиворечивости, модель непротиворечивости FIFO и
модель слабой непротиворечивости.
4) Репликация - процесс формирования и воспроизведения
многочисленных копий данных на одном или нескольких
узлах.
5)Рассмотрели типы и виды репликации.
6)Рассмотрели триггеры баз данных.
Список литературы:
• Коннолли, Томас, Бегг, Карелии. Базы данных.
Проектирование, реализация и сопровождение. Теория и
практика. 3-е издание. : Пер. с англ. — М. :Издательский дом
"Вильяме",2003. — 1440 с. : ил. — Парал. тит. англ.
• http://www.intuit.ru/department/database/
• http://blog.aboutnetapp.ru/archives/29
Спасибо за внимание!