Метки времени

Каждой транзакции присваивается глобальная уникальная метка времени. Значение метки времени явно определяет порядок, в котором транзакции предоставляются СУБД.

Метки времени должны обладать двумя свойствами:

1. Уникальностью. Гарантирует отсутствие одинаковых значений меток времени.

2. Монотонностью. Гарантирует, что значение метки времени всегда возрастает.

Все операции БД в рамках данной транзакции должны иметь одну и ту же метку времени. СУБД выполняет конфликтующие операции в порядке меток времени, что гарантирует их последовательное выполнение. Когда две транзакции конфликтуют, одна из них останавливается, откатывается, снова планируется на запуск и ей присваивается новая метка времени.

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

Оптимистические методы

Оптимистические подходы исходят из предположения о том, что конфликты между транзакциями редки, и доводят транзакцию до конца, а затем производят проверку корректности.

Если выясняется, что фиксация данной транзакции повлечет нарушение сериализуемости, то транзакция откатывается и запускается снова.

При оптимистическом подходе каждая транзакция проходит две или три фазы: чтение, подтверждение, и запись.

15. Надежность системы. Протоколы обеспечения надежности.

Надежность ИС – способность ИС выполнять функции, сохраняя эксплуатационные показатели в установленных пределах в течение заданного интервала времени при заданных условиях функционирования.

Надежность системы характеризуется потоком отказов и сбоев в работе системы.

Отказы выявляются тестированием технических и программных средств и устраняются во время проведения ремонтно-профилактических работ. Устранение отказов достигается путем восстановления работоспособности неисправных элементов системы (ремонта) или замены их резервными элементами.

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

Однако это входит в противоречие с проблемой целостности данных, для решения которой необходимо синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих РаБД.

В распределенной СУБД различаются четыре типа сбоев:

1. сбой транзакции,

2. сбой узла (системы),

3. сбой носителя (диска),

4. сбой коммуникационной линии.

Сбой транзакции

Причин сбоев транзакции может быть несколько:

• ошибки, вызванные неверными входными данными,

• обнаружение возникшего или возможного тупика.

Обычный способ обработки таких сбоев заключается в том, чтобы прервать транзакцию и откатить базу данных к состоянию, предшествовавшему началу транзакции.

Сбой узла

Cбои узлов (системные сбои) могут быть вызваны:

• аппаратными отказами (процессора, оперативной памяти, питания),

• программными ошибками (в системном или прикладном коде).

Следствие системных сбоев – потеря содержимого оперативной памяти, в частности буферов оперативной памяти (часть базы данных, хранимая в буферах, называется неустойчивой базой данных).

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

Сбой носителя

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

Рассмотренные выше три типа сбоев характерны и для централизованных, и для распределенных СУБД.

Сбой коммуникационной линии

Коммуникационные сбои являются специфической проблемой распределенных баз данных.

Коммуникационные сбои подразделяются на:

• ошибки в сообщениях,

• нарушение упорядоченности сообщений,

• потерянные (недоставленные) сообщения,

• повреждения на линиях связи

Первые из двух типов сбоев находятся в компетенции сетевых протоколов, два последних лежат в ведении СУБД и должны учитываться в протоколах обеспечения надежности.

Если один узел ожидает сообщения от другого, а оно не поступает, то причин тому может быть несколько:

• сообщение утрачено;

• возникло повреждение на линии связи;

• узел, от которого ожидается сообщение, отказал.

В любом случае ожидающий узел по истечении определенного промежутка времени просто решает, что узел-партнер стал недоступен.

Последствием повреждений на линиях связи может стать фрагментация сети, когда множество узлов распадается на группы, внутри которых имеется связь, а коммуникации между группами невозможны.

Протоколы распределенных СУБД должны уметь адекватно реагировать на подобные ситуации.

Протоколы обеспечения надежности

Протоколы обеспечения надежности поддерживают два свойства транзакций: атомарность и долговечность.

Атомарность означает, что выполняются либо все действия транзакции, либо не выполняется ни одно (принцип "все или ничего"). Атомарность гарантируется даже в условиях возможных отказов.

Долговечность означает, что результат успешно завершенной (зафиксированной) транзакции сохраняется даже при последующих сбоях.

Для обеспечения атомарности и долговечности необходимы:

• протоколы атомарной фиксации,

• протоколы распределенного восстановления.

Протоколы атомарной фиксации

Наиболее популярным протоколом атомарной фиксации является протокол двухфазной фиксации транзакций 2PC (two-phase commit).

Протокол 2PC опирается на следующие фундаментальные правила.

• Если хотя бы один узел отказывается зафиксировать транзакцию (голосует за ее аварийное завершение), то распределенная транзакция аварийно завершается во всех участвующих в ней узлах.

• Если все узлы голосуют за фиксацию транзакции, то она фиксируется во всех участвующих в ней узлах.

1 фаза 2PC - подготовка к фиксации транзакции (голосование).

2 фаза 2PC- глобальные фиксация или откат транзакции (принятие решения).

В простейшем варианте работа 2PC выглядит следующим образом:

На узле, где инициируется транзакция, создается процесс-координатор; на всех прочих затрагиваемых ею узлах создаются процессы-участники. Вначале координатор рассылает участникам сообщение PREPARE, и каждый из них независимо решает, может ли транзакция завершиться на данном узле. Координатор ожидает в пределах установленного тайм-аута. Участники, которые готовы завершить транзакцию, посылают координатору сообщение READY TO COMMIT. Участники, не имеющие возможности зафиксировать свою часть транзакции, возвращают сообщение READY TO ROLLBACK.

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

Заметим, что участникам, проголосовавшим за прерывание, сообщение посылать не нужно, поскольку они сами способны принять решение исходя из правил 2PC. Эта ситуация известна под названием опции одностороннего прерывания.

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

Логика протокола терминирования может быть следующей:

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

В этом случае участник находится в состоянии готовности. Раз он находится в состоянии готовности, то это означает, что ранее он проголосовал за фиксацию и теперь не имеет права изменить свое решение и прервать транзакцию

Протокол трехфазовой фиксации – 3PC

Предпринимались попытки создания неблокирующих протоколов. Пример протокол 3PC.

3PC является неблокирующим протоколом, но лишь при следующих условиях:

• расчленения сети не должно иметь места;

• по крайней один узел всегда должен быть доступен.

Идея протокола 3PC состоит в устранении неопределенности периода ожидания, в который попадают участники после подтверждения своего согласия на фиксацию транзакции и до получения от координатора сообщения о глобальной фиксации или глобальном откате транзакции.

Обратной стороной терминирования является восстановление. Какие действия должен предпринять восстанавливающийся после сбоя узел-координатор, чтобы привести базу данных в корректное состояние?