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

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

1.2.1.
Индивидуальный откат транзакции Для того чтобы можно было выполнить по журналу транзакций индивидуальный откат транзакции, все записи в журнале от данной транзакции связываются в обратный список
[33].
Началом списка для не закончившихся транзакций является запись о последнем изменении базы данных, произведенном данной транзакцией.
Для закончившихся транзакций (индивидуальные откаты которых уже невозможны) началом списка является запись о конце транзакции, которая обязательно вытолкнута во внешнюю память журнала.
Концом списка всегда служит первая запись об изменении базы данных, произведенном данной транзакцией.
В каждой записи имеется уникальный системный номер транзакции, чтобы можно было восстановить прямой список записей об изменениях базы данных данной транзакцией.
Индивидуальный откат транзакции выполняется
следующим образом:
44
[стр. 175]

Таким образом, имеется две причины для периодического выталкивания страниц во внешнюю память недостаток оперативной памяти и возможность сбоев.
Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных.
Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) "пиши сначала в журнал", и состоит в том, что если требуется вытолкнуть во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи о его изменении.
Это означает, что если во внешней памяти базы данных содержится объект, к которому применена некоторая команда модификации, то во внешней памяти журнала транзакций содержится запись об этой операции.
Обратное неверно если во внешней памяти журнала содержится запись о некотором изменении объекта, то во внешней памяти базы данных может и не быть самого измененного объекта.
Дополнительное условие на выталкивание буферов накладывается тем требованием, что каждая успешно завершившаяся транзакция должна быть реально зафиксирована во внешней памяти.
Какой бы сбой не произошел, система должна быть в состоянии восстановить состояние базы данных, содержащее результаты всех зафиксированных к моменту сбоя транзакций.
Третьим условием выталкивания буферов является ограниченность объемов буферов базы данных и журнала транзакций.
Периодически или при наступлении определенного события (например, количество страниц в dirty-списке превысило определенный порог, или количество свободных страниц в буфере уменьшилось и достигло критического значения) система принимает так называемую контрольную точку.
Принятие контрольной точки включает выталкивание во внешнюю память содержимого буферов базы данных и специальную физическую запись контрольной точки, которая представляет собой список всех осуществляемых в данный момент транзакций.
Оказывается, что минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией.
При этом последней записью в журнал, производимой от имени данной транзакции, является специальная запись о конце этой транзакции.

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

Началом списка для не закончившихся транзакций является запись о последнем изменении базы данных, произведенном данной транзакцией.
Для закончившихся транзакций (индивидуальные откаты которых уже невозможны) началом списка является запись о конце транзакции, которая обязательно вытолкнута во внешнюю память журнала.
Концом списка всегда служит первая запись об изменении базы данных, произведенном данной транзакцией.
В каждой записи имеется уникальный системный номер транзакции, чтобы можно было восстановить прямой список записей об изменениях базы данных данной транзакцией.
Индивидуальный откат транзакции выполняется следующим образом:
 Просматривается список записей, сделанных данной транзакцией в журнале транзакций (от последнего изменения к первому изменению).
 Выбирается очередная запись из списка данной транзакции.


[стр.,178]

результате сбоя, т.к.
изменения, внесенными этими транзакциями, отсутствуют после восстановления базы данных из резервной копии.
Наиболее плохим случаем является ситуация, когда разрушены физически и база данных, и журнал транзакций.
В этом случае единственное, что можно сделать это восстановить состояние базы данных на момент последнего резервного копирования.
Для того чтобы не допустить возникновение такой ситуации, базу данных и журнал транзакций обычно располагают на физически разных дисках, управляемых физически разными контроллерами.
Восстановление данных и стандарт SQL Стандарт языка SQL не содержит требований к восстановимости данных, оставляя эти вопросы на усмотрение разработчиков СУБД.
Выводы Главное требование долговечности данных транзакций состоит в том, что данные зафиксированных транзакций должны сохраняться в системе, даже если в следующий момент произойдет сбой системы.
Избыточность хранения данных, позволяющую восстановить систему после сбоя обычно обеспечивает журнал транзакций.
Восстановление базы данных может производиться в следующих случаях:  Индивидуальный откат транзакции.
 Мягкий сбой системы (аварийный отказ программного обеспечения).
 Жесткий сбой системы (аварийный отказ аппаратуры).
Страницы базы данных и журнала транзакций не записываются сразу на диск, а предварительно буферизируются в оперативной памяти.
Страницы базы данных, содержимое которых в буфере отличается от содержимого на диске, называются "грязными" (dirty) страницами.
Запись "грязных" страниц из буфера на диск называется выталкиванием страниц во внешнюю память.
Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является протокол журнализации Write Ahead Log (WAL) "пиши сначала в журнал".
Минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией.
Индивидуальный откат транзакции выполняется
при помощи журнала транзакций.
Восстановление системы после мягкого сбоя осуществляется как часть процедуры перезагрузки системы.
При перезагрузке системы транзакции проходят процедуру идентификации для выявления завершившихся и прерванных в результате сбоя транзакций.
Транзакции, успешно завершившиеся до наступления сбоя, и данные о которых отсутствуют в базе данных, повторяются заново.
Транзакции, не успевшие завершиться к моменту сбоя, и данные о которых имеются в базе данных, откатываются.
Восстановление системы после жесткого сбоя выполняется при помощи архивной копии базы данных и журнала транзакций.

[Back]