20. Стратегия временных отметок, оптимистические стратегии.

Оптимистическая стратегия.Основным предположением является то, что любая транзакция T, как правило, работает «одна» и никакая другая транзакция T? не изменяет ни множество чтения, ни множество записи транзакции T до момента ее фиксации. Все конфликты чтения/записи, ограничения целостности проверяются в момент фиксации транзакции T. Транзакция T фиксируется в том и только в том случае, когда от момента ее старта и до момента ее фиксации отсутствовали описанные выше конфликты с любой другой параллельной транзакцией T?. Во всех остальных случаях транзакция T откатывается.

При таком протоколе работы транзакция T не блокирует каким-либо образом объекты данных, к которым она обращается.

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

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

// стратегия временных отметок не найдена

21. Защита бд от отказов. Типы отказов. Архивные копии бд, Журнал бд. Зафиксированные транзакции. Стратегия двухфазной фиксации

Защита БД от отказов

Восстановление базы данных — это функция СУБД, которая в случае логических и физических сбоев приводит базу данных в актуальное и консистентное состояние.

В случае логического отказа или сигнала отката одной транзакции журнал изменений сканируется в обратном направлении, и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Согласно извлеченной информации выполняются действия, отменяющие действия транзакции. Этот процесс называется откат (rollback).

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

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

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

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

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

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

Архивная копия – это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии)

• порядковый номер, тип и время изменения;

• идентификатор транзакции;

• объект, подвергшийся изменению (номер хранимого файла и номер блока данных в нём, номер строки внутри блока);

• предыдущее состояние объекта и новое состояние объекта.

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

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

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

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

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

Резервное копирование (англ. backup copy) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.

Стратегия двухфазной фиксации

Фиксация транзакции – это действие, обеспечивающее запись на диск изменений в БД, которые были сделаны в процессе выполнения транзакции. Протокол двухфазовой фиксации Т состоит из 2 фаз(этапов):

Фаза 1 – подготовка к фиксации глобальной транзакции.

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

Фаза 2 – фиксация глобальной транзакции.

Происходит фиксация всех локальных транзакций. Если произойдет сбой в течение данного этапа, то сервер БД выполнит фиксацию глобальной транзакции вплоть до восстановления соединения.

Клиент видит больш БД, кот сост из мн-ва локальных БД

22. Восстановление БД (совпадает многое с вопросом выше)Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:

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

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

• Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

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