С помощью чего обеспечивается возможность восстановления состояния бд после сбоев
С помощью чего обеспечивается возможность восстановления состояния бд после сбоев
Требование атомарности транзакций утверждает, что не законченные или откатившиеся транзакции не должны оставлять следов в базе данных. Это означает, что данные должны храниться в базе данных с избыточностью, позволяющей иметь информацию, по которой восстанавливается состояние базы данных на момент начала неудачной транзакции. Такую избыточность обычно обеспечивает журнал транзакций. Журнал транзакций содержит детали всех операций модификации данных в базе данных, в частности, старое и новое значение модифицированного объекта, системный номер транзакции, модифицировавшей объект и другая информация.
Виды восстановления данных
Во всех трех случаях основой восстановления является избыточность данных, обеспечиваемая журналом транзакций.
Дополнительное условие на выталкивание буферов накладывается тем требованием, что каждая успешно завершившаяся транзакция должна быть реально зафиксирована во внешней памяти. Какой бы сбой не произошел, система должна быть в состоянии восстановить состояние базы данных, содержащее результаты всех зафиксированных к моменту сбоя транзакций.
Третьим условием выталкивания буферов является ограниченность объемов буферов базы данных и журнала транзакций. Периодически или при наступлении определенного события (например, количество страниц в dirty-списке превысило определенный порог, или количество свободных страниц в буфере уменьшилось и достигло критического значения) система принимает так называемую контрольную точку. Принятие контрольной точки включает выталкивание во внешнюю память содержимого буферов базы данных и специальную физическую запись контрольной точки, которая представляет собой список всех осуществляемых в данный момент транзакций.
Оказывается, что минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией. При этом последней записью в журнал, производимой от имени данной транзакции, является специальная запись о конце этой транзакции.
Индивидуальный откат транзакции
Для того чтобы можно было выполнить по журналу транзакций индивидуальный откат транзакции, все записи в журнале от данной транзакции связываются в обратный список. Началом списка для не закончившихся транзакций является запись о последнем изменении базы данных, произведенном данной транзакцией. Для закончившихся транзакций (индивидуальные откаты которых уже невозможны) началом списка является запись о конце транзакции, которая обязательно вытолкнута во внешнюю память журнала. Концом списка всегда служит первая запись об изменении базы данных, произведенном данной транзакцией. В каждой записи имеется уникальный системный номер транзакции, чтобы можно было восстановить прямой список записей об изменениях базы данных данной транзакцией.
Восстановление после мягкого сбоя
Несмотря на протокол WAL, после мягкого сбоя не все физические страницы базы данных содержат измененные данные, т.к. не все «грязные» страницы базы данных были вытолкнуты во внешнюю память.
Рисунок 1 Пять вариантов транзакций
Восстановление после жесткого сбоя
При жестком сбое база данных на диске нарушается физически. Основой восстановления в этом случае является журнал транзакций и архивная копия базы данных. Архивная копия базы данных должна создаваться периодически, а именно с учетом скорости наполнения журнала транзакций.
Восстановление начинается с обратного копирования базы данных из архивной копии. Затем выполняется просмотр журнала транзакций для выявления всех транзакций, которые закончились успешно до наступления сбоя. (Транзакции, закончившиеся откатом до наступления сбоя, можно не рассматривать). После этого по журналу транзакций в прямом направлении повторяются все успешно законченные транзакции. При этом нет необходимости отката транзакций, прерванных в результате сбоя, т.к. изменения, внесенными этими транзакциями, отсутствуют после восстановления базы данных из резервной копии.
Восстановление данных и стандарт SQL
Стандарт языка SQL не содержит требований к восстановимости данных, оставляя эти вопросы на усмотрение разработчиков СУБД.
Выводы
Главное требование долговечности данных транзакций состоит в том, что данные зафиксированных транзакций должны сохраняться в системе, даже если в следующий момент произойдет сбой системы. Избыточность хранения данных, позволяющую восстановить систему после сбоя обычно обеспечивает журнал транзакций.
Страницы базы данных и журнала транзакций не записываются сразу на диск, а предварительно буферизируются в оперативной памяти. Страницы базы данных, содержимое которых в буфере отличается от содержимого на диске, называются «грязными» (dirty) страницами. Запись «грязных» страниц из буфера на диск называется выталкиванием страниц во внешнюю память.
Минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией.
Индивидуальный откат транзакции выполняется при помощи журнала транзакций.
Восстановление системы после мягкого сбоя осуществляется как часть процедуры перезагрузки системы. При перезагрузке системы транзакции проходят процедуру идентификации для выявления завершившихся и прерванных в результате сбоя транзакций. Транзакции, успешно завершившиеся до наступления сбоя, и данные о которых отсутствуют в базе данных, повторяются заново. Транзакции, не успевшие завершиться к моменту сбоя, и данные о которых имеются в базе данных, откатываются.
Восстановление системы после жесткого сбоя выполняется при помощи архивной копии базы данных и журнала транзакций.
Восстановление БД после сбоев. Типы сбоев. Архивные копии БД. Журнал БД. Зафиксированные транзакции. Стратегия двухфазной фиксации.
Восстановление БД – это процесс возвращения ее в корректное состояние, утраченное в результате сбоя или отказа сиситемы.
При мягком сбое пропадает содержимое буферов оперативной памяти.
Целью процесса восстановления после мягкого сбоя является состояние базы данных, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций.
1. производят откат незавершенных транзакций (UNDO)
2. повторно воспроизводят (REDO) те операции завершенных транзакций, результаты которых не отображены во внешней памяти
Основой восстановления является архивная копия и журнал изменений базы данных
Таким образом, наряду с журналом, для защиты от отказов в составе СУБД должны быть предусмотрены средства регулярного создания архивных копий базы данных.
Архивная копия-это полная копия БД к моменту начала заполнения журнала
восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя.
Журнал – часть БД, вкот поступают данные обо всех изменениях основной части БД. Журнал не доступен пользователю. Цель журнализации – возможность восстановления.
Стратегия двухфазной фиксации: результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии БД, а незафиксированные должны отсутствовать.
Администрирование БД.
Администрирование базы данных – это функция управления базой данных, ответственность, за которую несет АБД.
Администратор базы данных (АБД) – отвечает за выработку требований к базе данных, её проектирование, реализацию, эффективное использование и сопровождение, включая управление учётными записями пользователей БД и защиту от несанкционированного доступа. Не менее важной функцией администратора БД является поддержка целостности базы данных.
Задачи АБД могут незначительно отличаться в зависимости от вида применяемой СУБД, но в основные задачи входит:
-Проектирование базы данных.
-Оптимизация производительности базы данных.
-Обеспечение и контроль доступа к базе данных.
-Обеспечение безопасности в базе данных.
-Резервирование и восстановление базы данных.
-Обеспечение целостности баз данных.
-Обеспечение перехода на новую версию СУБД.
Устойчивость информационной базы, физическая и логическая независимость данных.
Интегрированная информационная база должна быть построена в соответствии с некоторой моделью предметной области. От обоснованности этой модели, ее достоверности и адекватности во многом зависит работа АИС.
Независимость данных заключается в том, что программист всегда знает ответы на эти вопросы, то есть его программа не зависит от изменения в расположении, формате данных и способе доступа к ним. Существует два уровня независимости.
Физическая независимость данных означает, что физическое расположение и организация данных могут изменяться, не вызывая при этом изменений ни общей логической структуры данных, ни прикладных программ.
Логическая независимость данных значит, что добавление новых сегментов в БД не должно вызывать изменения ранее транслируемых прикладных программ, не связанных с отработкой экземпляров добавленного сегмента.
Трехуровневая архитектура СУБД.
Трехуровневая архитектура СУБД позволяет обеспечить независимость хранимых данных от использующих их программ.
1.На внешнем уровне пользователи воспринимают данные, где отдельные группы пользователей имеют свое представление на базу данных. Каждый тип пользователей может применять для работы с БД свой язык общения. Конечные пользователи употребляют либо язык запросов, либо специальный язык, поддерживаемый приложениями и вызывающий определенные для пользователя экранные формы и пользовательские меню.
2.Внутренняя схема описывает физическую реализацию БД и предназначена для достижения оптимальной производительности и экономии дискового пространства. На внутреннем уровне осуществляется взаимодействие СУБД с методами доступа ОС с целью размещения данных на ЗУ, создания индексов, извлечения данных и т. д.
На внутреннем уровне хранится следующую информацию: распределение дискового пространства для хранения данных и индексов, сведения о размещении записей, сведения о сжатии данных и выбранных методов их шифрования.
3.Ниже внутреннего уровня находится физический уровень, который контролируется операционной системой, но под руководством СУБД. Физический уровень учитывает, каким образом данные будут представлены в машине.
Реализация трехуровневой архитектуры БД требует, чтобы СУБД переводила информацию с одного уровня на другой, то есть преобразовывала адреса и указатели в соответствующие логические имена и отношения и наоборот. Выгодой такого перевода является независимость логического и физического представления данных, но и плата за эту независимость не малая — большая системная задержка.
Способы восстановления БД
Одна из основных функций администратора БД – быть готовым к возможному отказу системы. В случае возникновения отказа база данных должна быть восстановлена быстро и с минимально возможными потерями. Процесс восстановления БД требует от АБД:
— определения, какие структуры базы данных затронуты и требуют восстановления;
— выполнения соответствующих шагов по восстановлению;
— рестарта экземпляра БД для восстановления его нормальной работоспособности;
— проверки, что в базе данных не остались некорректные данные, и действия пользователей не пропали.
Цель этих мероприятий – наиболее быстрый возврат к нормальной работе пользователей с БД. В то же время необходимо уберечь пользователей БД от любых проблем, связанных с возможными потерями и необходимостью дублирования работ по ведению данных.
Процесс восстановления зависит от типа отказа и размеров части базы, на которую отказ повлиял. Администратор БД должен предвидеть любой тип отказа и иметь соответствующую стратегию восстановления. При выборе стратегии восстановления необходимо исходить из альтернативы, связанной со степенью «восстановимости» и затратами на защиту БД. В общем случае, чем больше гарантия защиты данных, тем больше затраты на ее реализацию со стороны АБД.
Поскольку обработка данных в многопользовательских системах не может быть возобновлена точно с того места, где она была прервана, то существует возможность отойти назад до некоторой известной точки состояния БД и возобновить работу с БД с неё.
Наиболее простой стратегией является возможность восстановления базы данных из её копии, которая периодически делается администратором БД. Затем при возникновении сбоя база данных восстанавливается, и заново производятся все утерянные транзакции, например, осуществляется повторный ввод данных, не отраженных в ранее сделанной копии. Такая стратегия для баз данных с большим числом пользователей может и не позволить вернуть систему в то состояние, в котором она находилась до сбоя из—за того, что при параллельной работе трудно восстановить и синхронизовать все действия пользователей. Какой—то объем данных будет утрачен.
Существует ещё один подход к восстановлению БД. Он заключается в том, чтобы периодически делать копии базы данных и вести журнал всех изменений, произведенных в базе данных транзакциями со времени последнего копирования. Восстановление в случае сбоя может быть произведено одним из двух методов. Первый – база данных восстанавливается до известного (отраженного в копии) состояния, после чего выполняются все правильные транзакции согласно записям в журнале. Метод называют «откат вперед» (rolling forward). Второй метод – в случае сбоя отменяются все ошибочные транзакции, затем запускаются правильные транзакции, которые выполнялись в момент сбоя – «откат назад», (rolling back). Для восстановления данных любым из этих методом требуется ведение журнала результатов транзакций. Современные СУБД имеют такие средства. Журнал транзакций позволяет сохранять действия, произведенных с данными в хронологическом порядке — прежде чем транзакция будет выполнена, она будет записана в журнал. В случае сбоя журнал используется как для отмены, так и для выполнения заданных транзакций. Журнал транзакций рекомендуется размещать на отдельном устройстве, что дает возможность повысить производительность и надежность системы баз данных:
— в случае потери работоспособности носителя данных сохраняется возможность создания резервной копии журнала транзакций;
— повышается скорость записи в журнал транзакций, так как операции ввода/вывода, разделенные между двумя устройствами, выполняются быстрее;
— рост объема журнала транзакций не понизит общую производительность системы;
— создание архивных копий журнала транзакций и данных происходит быстрее, поскольку они создаются отдельно друг от друга.
Размеры журнала транзакций варьируются в зависимости от объема модифицируемых данных и частоты создания архивных копий. Как правило, выделяют от 10 до 25% места, зарезервированного для данных.
Запись действий, производимых тем или иным пользователем БД, может вестись также администратором БД и другими способами, например, посредством использования различных триггеров.
Управление СУБД
К функциям, которые выполняет администратор БД, относятся также сбор и анализ статистики производительности работы СУБД, управление этой производительностью.
Производительность CУБД зависит от многих факторов – от используемой сервером БД операционной системы, от выделенных системных ресурсов, от параметров настройки ядра СУБД, от структуры запросов клиентских приложений к БД (например, производительность повышается при преимущественном использовании простых запросов, хранимых процедур, триггеров) и др.
Способ узнать, насколько эффективно функционирует сервер БД — это осуществление мониторинга состояния и производительности системы в целом с помощью специальных средств, входящих в состав СУБД. К показателям, определяющим производительность системы, относятся показатели статистики работы СУБД такие, как число логических чтений (чтение из кэш—памяти), число физических чтений (чтение с физического носителя), число разборов sql – выражений, общее число сортировок (на диске и в памяти), среднее число записей в сортировке, процент откатов в транзакциях, большое количество других показателей, которые соответствуют определенному виду обработки данных. АБД должен следить за тем, чтобы количественные значения показателей собранной статистики отвечали требуемым, и при обнаружении каких—либо отклонений принимать соответствующие решения.
Важной задачей для АБД является также разбор жалоб пользователей на медленный отклик системы, длительное время выполнения тех или иных запросов. Выполняя запрос, любая современная серверная СУБД строит большое количество планов выполнения данного запроса на основе собранной статистики по таблицам и индексам, используемым в запросе. Для каждого плана СУБД вычисляет его «стоимость». Соответственно, для выполнения запроса выбирается план с наименьшей стоимостью. Если ситуация в БД сильно изменилась (добавился большой объем новых данных), то собранная ранее статистика является уже не актуальной для разбора выполняемого в настоящий момент запроса, запрос выполняется дольше, чем рассчитывал пользователь. Вновь собранная (на другом объеме данных) статистика ускоряет выполнение запроса. Решение о том, выполнять или не выполнять сбор статистики, какой должна быть частота периодичности этой процедуры, АБД должен принимать в зависимости от ситуации.
Вопросы проектирования приложений БД
Восстановление базы данных до точки сбоя — полное восстановление
В этом подразделе описывается восстановление до точки сбоя. Сведения в этом разделе относятся только к тем базам данных, которые используют модель полного восстановления или модель восстановления с неполным протоколированием.
Восстановление до точки сбоя
Создайте резервную копию заключительного фрагмента журнала базы данных, взяв за основу следующую инструкцию BACKUP :
Восстановите базу данных из ее полной резервной копии, взяв за основу следующую инструкцию RESTORE DATABASE :
Можно также восстановить базу данных из ее разностной резервной копии, взяв за основу следующую инструкцию RESTORE DATABASE:
Примените все журналы транзакций, включая резервную копию заключительного фрагмента журнала (созданную на первом шаге), указав предложение WITH NORECOVERY в инструкции RESTORE LOG:
Восстановите базу данных, выполнив следующую инструкцию RESTORE DATABASE:
Пример
Перед запуском этого примера необходимо завершить следующие подготовительные действия.
По умолчанию, база данных AdventureWorks2012 имеет простую модель восстановления. Поскольку в этой модели не поддерживается восстановление до момента сбоя, настройте AdventureWorks2012 на использование модели полного восстановления, выполнив следующую инструкцию ALTER DATABASE :
Создайте полную резервную копию базы данных при помощи следующей инструкции BACKUP:
Создайте резервную копию журналов:
В следующем примере после создания резервной копии заключительного фрагмента журнала базы данных AdventureWorks2012 производится восстановление ранее созданной резервной копии (на этом шаге предполагается, что имеется доступ к диску, на котором хранятся журналы).
Вначале создается резервная копия заключительного фрагмента журнала базы данных, которая захватывает активный журнал и оставляет базу данных в состоянии восстановления. После этого в данном примере производится восстановление резервной копии базы данных, применяется раннее созданная процедура резервного копирования журналов и создается резервная копия заключительного фрагмента журнала. Наконец, отдельным шагом производится восстановление базы данных.
По умолчанию, при обработке инструкции, выполняющей окончательное восстановление резервной копии, производится восстановление базы данных.
Журнализация и восстановление БД после сбоя
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее целостное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера, например, аварийное выключение питания, и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. В любом из описанных случаев для восстановления БД нужно располагать некоторой избыточной информацией. Наиболее распространенным методом формирования и поддержания избыточной информации является ведение журнала изменений БД.
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились из-за использования буферов оперативной памяти, содержимое которых в этой ситуации пропадает. При соблюдении стратегии упреждающей записи, во внешней памяти журнала должна находиться информация, относящаяся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций, а потом повторно воспроизводят те операции завершенных транзакций, результаты которых не отображены во внешней памяти.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия является полной копией БД к моменту начала заполнения журнала. Восстановление БД состоит в том, что, исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя.