Проверяемый текст
Пушников А.Ю. Введение в системы управления базами данных. Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999.
[стр. 41]

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

Требование атомарности транзакций утверждает, что не законченные или откатившиеся транзакции не должны оставлять следов в базе данных.
Это означает, что данные должны храниться в базе данных с избыточностью, позволяющей иметь информацию, по которой восстанавливается состояние базы данных на момент начала неудачной транзакции.
Такую избыточность обычно обеспечивает журнал транзакций.
Журнал транзакций содержит детали всех операций модификации данных в базе данных, в частности, старое и новое значение модифицированного объекта, системный номер транзакции, модифицировавшей объект и другая информация.
Виды восстановления данных Восстановление базы данных может производиться в следующих случаях:
Индивидуальный откат транзакции.
Откат индивидуальной транзакции может быть инициирован либо самой транзакцией путем подачи команды ROLLBACK, либо системой.
СУБД может инициировать откат транзакции в случае возникновения какой-либо ошибки в работе транзакции (например, деление на нуль) или если эта транзакция выбрана в качестве жертвы при разрешении тупика.

Мягкий сбой системы (аварийный отказ программного обеспечения).
Мягкий сбой характеризуется утратой оперативной памяти
41
[стр. 173]

Если все транзакции в смеси подчиняются протоколу доступа к данным, то проблемы параллелизма решаются (почти все, кроме "фантомов"), но появляются тупики.
Состояние тупика (dead locks) характеризуется тем, что две или более транзакции пытаются заблокировать одни и те же объекты, и бесконечно долго ожидают друг друга.
Для разрушения тупиков система периодически или постоянно поддерживает графа ожидания транзакций.
Наличие циклов в графе ожидания свидетельствует о возникновении тупика.
Для разрушения тупика одна из транзакций (наиболее дешевая с точки зрения системы) выбирается в качестве жертвы и откатывается.
Для решения проблемы "фантомов", а также для уменьшения накладных расходов, вызываемых большим количеством блокировок, применяются более сложные методы.
Одним из таких методов являются преднамеренные блокировки, блокирующие объекты разной величины строки, страницы, таблицы, файлы и др.
Альтернативным является метод предикатных блокировок Имеются также методы сериализации, не использующие блокировки.
Это метод временных меток и механизм выделения версий.
Механизм выделения версий удобен тем, что он позволяет одновременно, и читать, и изменять одни и те же данные разными транзакциями.
Это увеличивает степень параллельности, и общую производительность системы.
Стандарт SQL не предусматривает понятие блокировок.
Вместо этого вводится понятие уровней изоляции.
Стандарт предусматривает 4 уровня изоляции:  READ UNCOMMITTED уровень незавершенного считывания.
 READ COMMITTED уровень завершенного считывания.
 REPEATABLE READ уровень повторяемого считывания.
 SERIALIZABLE уровень способности к упорядочению.
Транзакции могут запускаться с различными уровнями изоляции.
Глава 11.
Транзакции и восстановление данных В данной главе изучаются возможности восстановления данных после сбоев системы, т.е.
свойство (Д) долговечность транзакций.
Главное требование долговечности данных транзакций состоит в том, что данные зафиксированных транзакций должны сохраняться в системе, даже если в следующий момент произойдет сбой системы.
Казалось бы, самый простой способ обеспечить такую гарантию это во время каждой операции сразу записывать все изменения на дисковые носители.
Такой способ не является удовлетворительным, т.к.
имеется существенное различие в скорости работы с оперативной и с внешней памятью.
Единственный способ достичь приемлемой скорости работы состоит в буферизации страниц базы данных в оперативной памяти.
Это означает, что данные попадают во внешнюю долговременную память не сразу после внесения изменений, а через некоторое (достаточно большое) время.
Тем не менее, что-что во внешней памяти должно оставаться, т.к.
иначе неоткуда получить информацию для восстановления.


[стр.,174]

Требование атомарности транзакций утверждает, что не законченные или откатившиеся транзакции не должны оставлять следов в базе данных.
Это означает, что данные должны храниться в базе данных с избыточностью, позволяющей иметь информацию, по которой восстанавливается состояние базы данных на момент начала неудачной транзакции.
Такую избыточность обычно обеспечивает журнал транзакций.
Журнал транзакций содержит детали всех операций модификации данных в базе данных, в частности, старое и новое значение модифицированного объекта, системный номер транзакции, модифицировавшей объект и другая информация.
Виды восстановления данных Восстановление базы данных может производиться в следующих случаях:
Индивидуальный откат транзакции.
Откат индивидуальной транзакции может быть инициирован либо самой транзакцией путем подачи команды ROLLBACK, либо системой.
СУБД может инициировать откат транзакции в случае возникновения какой-либо ошибки в работе транзакции (например, деление на нуль) или если эта транзакция выбрана в качестве жертвы при разрешении тупика.

Мягкий сбой системы (аварийный отказ программного обеспечения).
Мягкий сбой характеризуется утратой оперативной памяти
системы.
При этом поражаются все выполняющиеся в момент сбоя транзакции, теряется содержимое всех буферов базы данных.
Данные, хранящиеся на диске, остаются неповрежденными.
Мягкий сбой может произойти, например, в результате аварийного отключения электрического питания или в результате неустранимого сбоя процессора.
 Жесткий сбой системы (аварийный отказ аппаратуры).
Жесткий сбой характеризуется повреждением внешних носителей памяти.
Жесткий сбой может произойти, например, в результате поломки головок дисковых накопителей.
Во всех трех случаях основой восстановления является избыточность данных, обеспечиваемая журналом транзакций.
Как и страницы базы данных, данные из журнала транзакций не записываются сразу на диск, а предварительно буферизируются в оперативной памяти.
Таким образом, система поддерживает два вида буферов буферы страниц базы данных и буферы журнала транзакций.
Страницы базы данных, содержимое которых в буфере (в оперативной памяти) отличается от содержимого на диске, называются "грязными" (dirty) страницами.
Система постоянно поддерживает список "грязных" страниц dirty-список.
Запись "грязных" страниц из буфера на диск называется выталкиванием страниц во внешнюю память.
Очевидно, необходимо предусмотреть такие правила выталкивания буферов базы данных и буферов журнала транзакций, которые обеспечивали бы два требования: 1.
Максимальную скорость выполнения транзакций.
Для этого необходимо выталкивать страницы как можно реже.
В идеале, если оперативная память была бы бесконечной, и сбои никогда бы не происходили, наилучшим выходом была бы загрузка всей базы данных в оперативную память, работа с данными только в оперативной памяти, и запись измененных страниц на диск только в момент завершения работы всей системы.
2.
Гарантию, что при возникновении сбоя (любого типа), данные завершенных транзакций можно было бы восстановить, а данные незавершенных транзакций бесследно удалить, т.е.
обеспечение восстановления последнего согласованного состояния базы данных.
Для этого что-то выталкивать на диск все-таки необходимо, даже если мы обладали бы бесконечной оперативной памятью.

[Back]