6. 40. Индивидуальный откат транзакций.

Индивидуальный откат транзакции.

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

Индивидуальный откат транзакции выполняется следующим образом:

• выбирается очередная запись из списка данной транзакции;

• выполняется противоположная по смыслу операция (например, вставка вместо удаления); тем самым восстанавливается предыдущее состояние объекта базы данных;

• обратные операции журнализируются;

• при успешном завершении отката в журнал заносится запись о конце транзакции; с точки зрения механизма журнализации такая транзакция является зафиксированной.

7. 41. Восстановление после мягкого сбоя.

Восстановление после мягкого сбоя.

К числу проблем, возникающих при мягком сбое, относится тот факт, что одна логическая операция модификации базы данных может изменить несколько физических блоков базы данных. Несмотря на применение протокола WAL, после мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, т.е. часть страниц внешней памяти соответствует измененному состоянию объекта, а часть - нет. К такому состоянию не применима операция восстановления логического уровня. Если состояние объекта соответствует состоянию объекта до/после его изменения, то состояние внешней памяти базы данных называют физически согласованным.

Контрольные точки.

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

Контрольные точки организуются через установленный временной интервал и включают выполнение следующих действий:

1. запись всех имеющихся в оперативной памяти записей журнала во торичную память;

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

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

8. 42. Восстановление после жёсткого сбоя.

Восстановление после жесткого сбоя, механизм резервного копирования.

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

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

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

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