СУБД — Восстановление данных

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

Классификация отказов

Чтобы увидеть, где возникла проблема, мы обобщаем отказ на различные категории, а именно:

Сбой транзакции

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

Причины сбоя транзакции могут быть:

• Логические ошибки — когда транзакция не может быть завершена из-за ошибки в коде или из-за внутренней ошибки.

• Системные ошибки — когда система базы данных сама завершает активную транзакцию, потому что СУБД не может выполнить ее, или она должна остановиться из-за какого-либо состояния системы. Например, в случае тупика или недоступности ресурса система прерывает активную транзакцию.

Логические ошибки — когда транзакция не может быть завершена из-за ошибки в коде или из-за внутренней ошибки.

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

Системный сбой

Существуют проблемы, внешние по отношению к системе, которые могут привести к внезапной остановке системы и ее аварийному завершению. Например, перебои в электроснабжении могут вызвать сбой основного аппаратного или программного сбоя.

Примеры могут включать ошибки операционной системы.

Ошибка диска

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

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

Структура хранения

Мы уже описали систему хранения. Вкратце, структуру хранения можно разделить на две категории —

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

• Энергонезависимое хранилище — эти воспоминания созданы для того, чтобы выдерживать сбои системы. Они огромны по объему хранения данных, но медленнее по доступу. Примерами могут быть жесткие диски, магнитные ленты, флэш-память и энергонезависимое ОЗУ (с резервным питанием от батареи).

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

Энергонезависимое хранилище — эти воспоминания созданы для того, чтобы выдерживать сбои системы. Они огромны по объему хранения данных, но медленнее по доступу. Примерами могут быть жесткие диски, магнитные ленты, флэш-память и энергонезависимое ОЗУ (с резервным питанием от батареи).

Восстановление и атомарность

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

Когда СУБД восстанавливается после сбоя, она должна поддерживать следующее:

• Он должен проверять состояния всех транзакций, которые выполнялись.

• Транзакция может быть в середине некоторой операции; СУБД должна обеспечивать атомарность транзакции в этом случае.

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

• Никакие транзакции не позволят оставить СУБД в несогласованном состоянии.

Он должен проверять состояния всех транзакций, которые выполнялись.

Транзакция может быть в середине некоторой операции; СУБД должна обеспечивать атомарность транзакции в этом случае.

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

Никакие транзакции не позволят оставить СУБД в несогласованном состоянии.

Существует два типа методов, которые могут помочь СУБД в восстановлении, а также в поддержании атомарности транзакции.

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

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

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

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

Восстановление на основе журнала

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

Восстановление на основе журнала работает следующим образом:

• Файл журнала хранится на стабильном носителе.

• Когда транзакция входит в систему и начинает выполнение, она записывает в нее журнал.

Файл журнала хранится на стабильном носителе.

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

<T n , Start>

• Когда транзакция изменяет элемент X, она записывает журналы следующим образом:

Когда транзакция изменяет элемент X, она записывает журналы следующим образом:

<T n , X, V 1 , V 2 >

В нем говорится, что T _n изменило значение X с V ₁ до V ₂ .

• Когда транзакция заканчивается, она регистрирует —

<T n , commit>

База данных может быть изменена с использованием двух подходов —

• Отложенная модификация базы данных — все журналы записываются в стабильное хранилище, а база данных обновляется при фиксации транзакции.

• Немедленное изменение базы данных — каждый журнал следует за фактическим изменением базы данных. То есть база данных модифицируется сразу после каждой операции.

Отложенная модификация базы данных — все журналы записываются в стабильное хранилище, а база данных обновляется при фиксации транзакции.

Немедленное изменение базы данных — каждый журнал следует за фактическим изменением базы данных. То есть база данных модифицируется сразу после каждой операции.

Восстановление с параллельными транзакциями

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

Контрольно-пропускной пункт

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

восстановление

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

• Система восстановления считывает журналы в обратном направлении от конца до последней контрольной точки.

• Он поддерживает два списка: список отмены и список повторов.

• Если система восстановления видит журнал с <T _n , Start> и <T _n , Commit> или просто <T _n , Commit>, она помещает транзакцию в повторный список.

• Если система восстановления видит журнал с <T _n , Start>, но журнал фиксации или отмены не найден, она помещает транзакцию в список отмены.

Система восстановления считывает журналы в обратном направлении от конца до последней контрольной точки.

Он поддерживает два списка: список отмены и список повторов.

Если система восстановления видит журнал с <T _n , Start> и <T _n , Commit> или просто <T _n , Commit>, она помещает транзакцию в повторный список.

Если система восстановления видит журнал с <T _n , Start>, но журнал фиксации или отмены не найден, она помещает транзакцию в список отмены.

Все транзакции в списке отмены затем отменяются и их журналы удаляются. Все транзакции в повторном списке и их предыдущие журналы удаляются и затем переделываются перед сохранением их журналов.