Транзакции и восстановление
Транзакции представляют собой основную единицу восстановления в системах с базами данных. Именно диспетчер восстановления СУБД обеспечивает поддержку двух из четырех основных свойств ACID транзакций (неразрывность и устойчивость) даже при наличии сбоев в системе. Диспетчер восстановления должен обеспечить, что при восстановлении после сбоя для каждой отдельной транзакции в базе данных будут постоянно фиксироваться либо все внесенные ею изменения, либо ни одно из них. Ситуация осложняется тем фактом, что запись в базу данных не представляет собой неразрывного действия (выполняемого за один шаг), и поэтому существует вероятность, что, когда выполнение транзакции будет завершено путем фиксации, внесенные ею изменения не будут реально отражены в базе данных по той простой причине, что еще не достигли файлов базы данных.
Еще раз вернемся к первому из рассмотренных в данной теме примеру, в котором требовалось увеличить количество студентов в группе ТМ-32 (см, табл. 8.1). При выполнении операции чтения СУБД осуществляет следующие действия:
Определяет дисковый адрес блока данных, содержащего запись с первичным ключом х.
Считывает блок данных с диска и помещает его в буфер СУБД в оперативной памяти.
Копирует сведения о количестве студентов из буфера СУБД в переменную КС.
При выполнении операции записи СУБД осуществляет следующие действия:
Определяет дисковый адрес блока данных, содержащего запись с первичным ключом х.
Считывает блок данных с диска и помещает его в буфер СУБД в оперативной памяти.
Копирует сведения о количестве студентов из переменной КС в буфер СУБД.
Выводит блок данных из буфера СУБД в оперативной памяти на диск.
Буфера СУБД занимают определенную часть оперативной памяти и используются для обмена данными со вторичной памятью системы. Только после того, как соответствующий буфер выгружен во вторичную память, можно считать, что выполненные операции обновления приобрели постоянный характер. Выгрузка буферов в базу данных может инициироваться по специальной команде (например, по команде фиксации транзакции) или же автоматически, как только буфер будет заполнен. Выдачу явного указания о необходимости записи содержимого буферов во вторичную память называют принудительной записью.
Если отказ системы произойдет между записью данных в буфер и выгрузкой буфера во вторичную память, диспетчер восстановления должен уточнить состояние транзакции, выполнявшей запись в момент аварии. Если транзакция уже выдала команду фиксации, то для обеспечения устойчивости ее результатов диспетчер восстановления должен выполнить ее повторно (redo) (эту операцию часто называют накатом), чтобы восстановить все внесенные ею изменения.
С другой стороны, если на момент отказа системы транзакция еще не была зафиксирована, диспетчер восстановления должен отменить (undo) любые ее результаты (выполнить их откат), что будет гарантировать соблюдение ее неразрывности. Если требуется выполнить откат только одной транзакции, то это – частичный откат. Частичный откат может инициироваться планировщиком, когда транзакция откатывается и перезапускается по требованию протокола управления параллельным доступом, как описано в предыдущем разделе. Кроме того, транзакция может отменяться в одностороннем порядке, например, по требованию пользователя или в результате возникновения исключительной ситуации в прикладной программе. Если требуется выполнить откат всех активных транзакций, то это – глобальный откат.
Пример выполнения операций отката и наката
На рис. 8.5 показано несколько параллельно выполняющихся транзакций Т1,..., Т6.
Рис. 8.5. Пример выполнения операций отката и наката
Работа СУБД начинается в момент времени t0, а в момент времени tf происходит сбой. Предположим, что результаты транзакций Т2 и Т3 уже были выгружены во вторичную память к моменту отказа системы.
Очевидно, что транзакции Т1 и T6 еще не были зафиксированы на момент отказа системы. Следовательно, при перезапуске СУБД диспетчер восстановления должен отменить эти транзакции. Однако остается не вполне понятным, какие изменения, выполненные остальными (зафиксированными) транзакциями Т4 и Т5, были перенесены в базу данных во вторичной памяти. Причина этой неопределенности состоит в том, что одна часть содержимого временных буферов СУБД могла быть уже выведена на диск, а другая – нет. При отсутствии какой-либо дополнительной информации диспетчеру восстановления потребуется выполнить принудительный накат транзакций Т2, Т3, Т4 и Т5.