Лекция 14 Транзакции и восстановление баз данных




Скачать 246.8 Kb.
НазваниеЛекция 14 Транзакции и восстановление баз данных
Дата публикации23.05.2013
Размер246.8 Kb.
ТипЛекция
uchebilka.ru > История > Лекция

Лекция 14 Транзакции и восстановление баз данных



Краткая аннотация. В лекции изучается свойство долговечности транзакций. При этом особое внимание уделяется нештатным ситуациям – сбоям в работе системы управления базами данных и способам преодоления их последствий. Одним из основных средств восстановления базы данных после сбоев является журнал транзакций. Для восстановления данных с помощью журнала транзакций применяются различные модели восстановления данных.
Список ключевых терминов. Виды сбоев. Индивидуальный откат транзакции. Мягкий сбой (утрата данных в оперативной памяти). Жесткий сбой (утрата данных во внешней памяти). Журнал транзакций. Грязные страницы. Модели восстановления базы данных. Простая модель восстановления. Модель полного восстановления. Модель восстановления с неполным протоколированием.

^ Цель лекции. Изучить свойство долговечности транзакций. Рассмотреть виды и причины нештатных ситуаций (сбоев) в работе системы управления базами данных и способы преодоления их последствий. Познакомиться с применением журнала транзакций для восстановления данных на основе различных моделей восстановления данных.


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

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

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

14.1 Необходимость и виды восстановления базы данных
Восстановление базы данных может производиться в следующих случаях:

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

  • Мягкий сбой системы и утрата данных в оперативной памяти системы;

  • Жесткий сбой и утрата данных во внешней памяти системы.

Индивидуальный откат транзакции. Откат индивидуальной транзакции может быть инициирован либо самой транзакцией путем подачи команды ROLLBACK, либо системой управления базами данных. СУБД может инициировать откат транзакции в случае возникновения какой-либо ошибки в работе транзакции (например, деление на нуль) или если эта транзакция выбрана в качестве жертвы при разрешении тупика.

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

^ Жесткий сбой системы (аварийный отказ аппаратуры). Жесткий сбой характеризуется повреждением внешних носителей памяти. Жесткий сбой может произойти, например, в результате поломки головок дисковых накопителей.

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

Страницы базы данных, содержимое которых в буфере оперативной памяти отличается от содержимого на диске, называются «грязными» (dirty) страницами. Система управления базами данных постоянно поддерживает список «грязных» страниц – dirty-список. Запись «грязных» страниц из буфера на диск называется выталкиванием страниц во внешнюю память. Очевидно, необходимо предусмотреть такие правила выталкивания буферов базы данных и буферов журнала транзакций, которые обеспечивали бы максимальную скорость выполнения транзакций, а также гарантию восстановления данных завершенных и удаление данных незавершенных транзакций.

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

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

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

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

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

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

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

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

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

1) Просматривается список записей, сделанных данной транзакцией в журнале транзакций от последнего изменения к первому изменению;

2) Выбирается очередная запись из списка данной транзакции.

3) Выполняется противоположная по смыслу операция: вместо операции INSERT выполняется соответствующая операция DELETE, вместо операции DELETE выполняется INSERT, и вместо прямой операции UPDATE обратная операция UPDATE, восстанавливающая предыдущее состояние объекта базы данных.

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

При успешном завершении отката в журнал заносится запись о конце транзакции.
^ 14.2.2 Восстановление данных после мягкого сбоя
Несмотря на протокол WAL, после мягкого сбоя не все физические страницы базы данных содержат измененные данные, т.к. не все «грязные» страницы базы данных были вытолкнуты во внешнюю память.

Последний момент, когда гарантированно были вытолкнуты «грязные» страницы – это момент принятия последней контрольной точки. Имеется 5 вариантов состояния транзакций по отношению к моменту последней контрольной точки и к моменту сбоя, показанных на рисунке 14.1.



Рисунок 14.1 – Пять вариантов транзакций по отношению к последней контрольной точке
Последняя контрольная точка принималась в момент tc. Мягкий сбой системы произошел в момент tf. Транзакции T1T5 характеризуются следующими свойствами:

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

Транзакция T2 начата до принятия контрольной точки и успешно завершена после контрольной точки, но до наступления сбоя. Записи журнала транзакций, относящиеся к этой транзакции вытолкнуты во внешнюю память. Страницы данных, измененные этой транзакцией, только частично вытолкнуты во внешнюю память. Для данной транзакции необходимо повторить заново те операции, которые были выполнены после принятия контрольной точки.

Транзакция T3 начата до принятия контрольной точки и не завершена в результате сбоя. Такую транзакцию необходимо откатить. Проблема, однако, в том, что часть страниц данных, измененных этой транзакцией, уже содержится во внешней памяти – это те страницы, которые были обновлены до принятия контрольной точки. Следов изменений, внесенных после контрольной точки в базе данных нет. Записи журнала транзакций, сделанные до принятия контрольной точки, вытолкнуты во внешнюю память, те записи журнала, которые были сделаны после контрольной точки, отсутствуют во внешней памяти журнала.

Транзакция T4 начата после принятия контрольной точки и успешно завершена до сбоя системы. Записи журнала транзакций, относящиеся к этой транзакции вытолкнуты во внешнюю память журнала. Изменения в базе данных, внесенные этой транзакцией, полностью отсутствуют во внешней памяти базы данных. Такую транзакцию необходимо повторить целиком.

Транзакция T5 начата после принятия контрольной точки и не завершена в результате сбоя. Никаких следов этой транзакции нет ни во внешней памяти журнала транзакций, ни во внешней памяти базы данных. Для такой транзакции никаких действий предпринимать не нужно, ее как бы и не было вовсе.

Восстановление системы после мягкого сбоя осуществляется как часть процедуры перезагрузки системы. При перезагрузке системы транзакции T2 и T4 необходимо частично или полностью повторить, транзакцию T3 – частично откатить, для транзакций T1 и T5 никаких действий предпринимать не нужно. При перезагрузке система управления базами данных выполняет следующие действия:

1) Создает два списка транзакций UNDO (отменить) и REDO (повторить). В список UNDO заносятся все транзакции из последней записи контрольной точки, т.е. все транзакции, выполнявшиеся в момент принятия контрольной точки. Список REDO остается пустым. В нашем случае будет: UNDO = {T2, T3}, REDO = {}.

2) Начиная с записи контрольной точки, просматривается вперед журнал транзакций.

3) Если в журнале транзакций обнаруживается запись о начале транзакции, то эта транзакция добавляется в список UNDO. В нашем случае будет: UNDO = {T2, T3, T4}, REDO = {}. Заметим, что следов транзакции T5 в журнале транзакций нет.

4) Если в файле регистрации обнаруживается запись COMMIT о фиксации транзакции, то эта транзакция добавляется в список REDO. В нашем случае будет: UNDO = {T2, T3, T4}, REDO = {T2, T4}. Заметим, что записи о завершении этих транзакций имеются во внешней памяти журнала транзакций в соответствии с минимальным требованием выталкивания записей журнала при фиксации транзакции.

5) Когда достигается конец журнала транзакций, оба списка анализируются. При этом из списка UNDO удаляются те транзакции, которые попали в список REDO. В нашем случае будет: UNDO = {T3}, REDO = {T2, T4}.

6) После этого система просматривает журнал транзакций назад, начиная с момента контрольной точки и откатывая все транзакции из списка UNDO. В нашем случае будут откатываться те операции транзакции T3, которые были выполнены до принятия контрольной точки.

7) Окончательно, система просматривает журнал транзакций вперед, начиная с момента контрольной точки, и повторно выполняет все операции транзакций из списка REDO. В нашем случае, система выполнит повторно все операции транзакции T4 и те операции транзакции T2, которые были выполнены после принятия контрольной точки.
^ 14.2.3. Восстановление данных после жесткого сбоя
При жестком сбое база данных на диске нарушается физически. Основой восстановления в этом случае является журнал транзакций и архивная копия базы данных. Архивная копия базы данных должна создаваться периодически, а именно с учетом скорости наполнения журнала транзакций.

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

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

^ 14.3 Восстановление данных в SQL Server
14.3.1 Журнал транзакций и виды восстановления данных в SQL Server
Каждая база данных SQL Server содержит журнал, в который записываются все транзакции и все изменения базы данных, выполняемые каждой транзакцией. Журнал транзакций – это важная составляющая базы данных, и понимание и управление этим журналом является важной частью роли администратора базы данных. Это особенно верно для модели полного восстановления и модели восстановления с неполным протоколированием, которые требуют регулярного резервного копирования журналов.

Журнал транзакций в SQL Server обладает следующими характеристиками:

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

2) Формат записей журнала и страниц не обязан следовать формату страниц данных.

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

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

SQL Server поддерживает следующие операции восстановления данных:

  • восстановление отдельных транзакций;

  • восстановление всех незавершенных транзакций при запуске SQL Server;

  • накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;

  • поддержка репликации транзакций;

  • поддержка решений с резервными серверами.

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

^ Восстановление всех незавершенных транзакций при запуске SQL Server. Если на сервере, где работает SQL Server, происходит сбой, базы данных могут остаться в таком состоянии, в котором часть изменений не была переписана из буферного кэша в файлы данных, и могут быть изменения в файлах данных, совершенные незаконченными транзакциями. Когда экземпляр SQL Server будет запущен, он выполнит восстановление каждой базы данных. Будет выполнен накат каждого записанного в журнал изменения, которое, возможно, не было переписано в файл данных. Чтобы сохранить целостность базы данных, будет также произведен откат каждой незавершенной транзакции, найденной в журнале транзакций.

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

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

^ Поддержка решений с резервными серверами. Решения резервного сервера, зеркальное отображение базы данных и доставка журналов в значительной степени полагаются на журнал транзакций. В сценарии доставки журналов основной сервер отправляет активный журнал транзакций основной базы данных одному или более адресатам. Каждый сервер-получатель восстанавливает журнал в свою локальную базу данных-получатель. В сценарии зеркального отражения базы данных каждое обновление в базе данных, основной базе данных, будет немедленно воспроизведено в отдельной полной копии базы данных, зеркальной базе данных. Экземпляр основного сервера немедленно отсылает каждую запись журнала на экземпляр зеркального сервера, который применяет поступающие записи журнала к зеркальной базе данных, путем ее непрерывного наката.
^ 14.3.2 Модели восстановления данных в SQL Server
Операции резервного копирования и восстановления данных выполняются в контексте модели восстановления. Модель восстановления – это свойство базы данных, которое управляет процессом регистрации транзакций, определяет, требуется ли для журнала транзакций резервное копирование, а также определяет, какие типы операций восстановления доступны.

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

  • простая модель восстановления;

  • модель полного восстановления;

  • модель восстановления с неполным протоколированием.

Обычно в базе данных используется модель полного восстановления или простая модель восстановления. Сведения об имеющихся моделях восстановления представлены в таблице 14.1.
Таблица 14.1 – Модели восстановления данных в SQL Server

Модель

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

Описание

Риск потери результатов работы

^ Восстановить до заданного момента времени?

Простая

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

Изменения с момента создания последней резервной копии не защищены. В случае аварийной ситуации эти изменения придется вносить повторно.

Возможно восстановление только до конца резервной копии.

Полная

Необходимы резервные копии журналов. Потеря результатов работы из-за повреждения файлов данных исключена.

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

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

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

^ С неполным протоколированием

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

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

Возможно восстановление до конца любой резервной копии. Восстановление до заданной точки не поддерживается.


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

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

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

^ Модель полного восстановления. Модель полного восстановления обеспечивает модель обслуживания для баз данных, в которых необходима поддержка длительных транзакций. Требуются резервные копии журналов. При использовании этой модели выполняется полное протоколирование всех транзакций, и сохраняются записи журнала транзакций до момента их резервного копирования. Модель полного восстановления позволяет восстановить базу данных до точки сбоя при условии, что после сбоя возможно создание резервной копии заключительного фрагмента журнала. Кроме того, модель полного восстановления поддерживает восстановление отдельных страниц данных.

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

Новая база данных наследует модель восстановления от базы данных model. Модель восстановления по умолчанию базы данных model зависит от выпуска SQL Server, однако она может быть изменена любым пользователем, имеющим разрешение ALTER на базу данных.
^ 14.3.3 Выбор подходящей модели восстановления данных в SQL Server
Выбор подходящей модели восстановления для базы данных зависит от доступности и требований к восстановлению базы данных.

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

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

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

^ Требования к восстановлению могут быть сформулированы, в частности, как ответы на следующие вопросы:

1) Насколько важно избежать потери изменений?

2) Насколько сложно воссоздать утраченные данные?

3) Имеются ли две или более баз данных, которые должны быть логически согласованы?

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

^ Кадровые требования определяются тем, имеются ли в организации системные администраторы и администраторы баз данных. Если нет, то кто отвечает за выполнение операций резервного копирования и восстановления и какова квалификация этих лиц.

^ Шаблоны использования данных определяются как ответы на следующие вопросы:

1) Как часто изменяются данные этой базе данных?

2) Изменяются ли некоторые таблицы значительно чаще, чем другие?

3) Существуют ли критические рабочие периоды? Если да, то какие шаблоны использования применяются в эти периоды?

4) Существуют ли в базе данных пиковые нагрузки по операциям вставки и обновления? Возможно, потребуется создать расписание резервного копирования данных, которое должно производиться в периоды минимальной активности. При высокой интенсивности операций ввода-вывода обычно применяется только резервное копирование журналов.

5) Производятся ли рискованные обновления базы данных и возникают ли в ней ошибки приложений, которые невозможно сразу обнаружить? Если да, то рассмотрите использование модели полного восстановления. Это позволит использовать резервные копии журналов для восстановления базы данных до состояния на определенный момент времени.

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

1) Простая модель восстановления рекомендуется использовать при следующих условиях.

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

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

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

2) Модель полного восстановления, а также при необходимости модель с неполным протоколированием рекомендуется использовать при выполнении какого-либо из следующих условий:

  • необходимо иметь возможность восстановить все данные;

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

  • необходимо иметь возможность восстановления до точки сбоя;

  • необходимо иметь возможность восстановления отдельных страниц;

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

3) Модель восстановления с неполным протоколированием предназначена исключительно как дополнение к модели полного восстановления. Рекомендуется применять ее только в периоды проведения крупномасштабных массовых операций, во время которых нет необходимости восстановления базы данных на определенный момент времени.

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

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

Информацию по теме лекции можно найти в [5-9], [14-16], [23-26], [33], [43-45], [61-62].

^ Ключевые термины

«Грязные» страницы – страницы базы данных, содержимое которых в буфере оперативной памяти отличается от содержимого на диске.

^ Жесткий сбой системы (аварийный отказ аппаратуры) характеризуется повреждением внешних носителей памяти, например, в результате поломки дисковых накопителей.

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

^ Индивидуальный откат транзакции инициируется самой транзакцией путем подачи команды ROLLBACK, либо системой управления базами данных в случае возникновения какой-либо ошибки в работе транзакции (например, деление на нуль) или если эта транзакция выбрана в качестве жертвы при разрешении тупика.

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

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

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

^ Простая модель восстановления - отсутствуют резервные копии журналов, автоматически освобождается место на диске, занятое журналами, устраняя необходимость в управлении размером журналов транзакций.

^ Краткие итоги

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

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

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

Страницы базы данных и журнала транзакций не записываются сразу на диск, а предварительно буферизируются в оперативной памяти. Страницы базы данных, содержимое которых в буфере отличается от содержимого на диске, называются «грязными» страницами. Запись «грязных» страниц из буфера на диск называется выталкиванием страниц во внешнюю память. Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является протокол журнализации Write Ahead Log (WAL) – «пиши сначала в журнал».

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

Добавить документ в свой блог или на сайт

Похожие:

Лекция 14 Транзакции и восстановление баз данных iconЛекция Введение в теорию баз данных Лекция посвящена рассмотрению...
Цель: выявить основные структурные элементы баз данных и основные принципы, используемые при их разработке

Лекция 14 Транзакции и восстановление баз данных iconВосстановление баз данных Interbase (Firebird) стандартными средствами
В статье Восстановление баз данных я описывал как можно восстановить базу данных Interbase (Firebird) с помощью программы Репликатор....

Лекция 14 Транзакции и восстановление баз данных iconЛекция Введение в базы данных
Обсуждается состав пользователей и распределение обязанностей в информационных системах с базами данных. Дается обзор моделей баз...

Лекция 14 Транзакции и восстановление баз данных iconЛекция 19. Основные направления развития технологий баз данных
В данной лекции рассматривается история развития технологии обработки данных, даются характеристики постреляционным, объектно-ориентированные...

Лекция 14 Транзакции и восстановление баз данных iconЛекция 1 (2 часа)
Базы данных являются одной из основных составляющих информационных технологий предприятий. В настоящее время без применения баз данных...

Лекция 14 Транзакции и восстановление баз данных icon3. Лекция: Введение в реляционную модель данных Вопросы: Основные понятия реляционных баз данных
Эдгаром Коддом. В последние десятилетия этот подход является наиболее распространенным (с оговоркой, что в называемых в обиходе реляционными...

Лекция 14 Транзакции и восстановление баз данных icon1. Архитектура баз данных
Архитектура баз данных субд, которые поддерживают реляционную модель данных. Средства субд для создания базы данных и работы с ее...

Лекция 14 Транзакции и восстановление баз данных iconПримерная должностная инструкция главного специалиста администратора...
Администратор баз данных в соответствии с возложенной на него задачей выполняет следующие функции

Лекция 14 Транзакции и восстановление баз данных iconПроектирование реляционных баз данных с использованием нормализации
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм

Лекция 14 Транзакции и восстановление баз данных iconЛекция Введение в теорию баз данных
Что из перечисленного ниже является основными элементами системы инвертированных списков

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
uchebilka.ru
Главная страница


<