Теория и практика построения баз данных (1088289), страница 87
Текст из файла (страница 87)
В связи с этим повторная обработка обычно не является реально осуществимой формой восстановления от сбоев в системах параллельной обработки. Восстановление через откат-накат Второй подход к восстановлению заключается в том, чтобы периодически делать копии (снимки) базы данных и вести журнал всех изменений, произведенных транзакциями в базе данных со времени последнего копирования.
В этом случае, когда происходит сбой, можно использовать один из двух методов. При первом методе, который называется накатом (го!1(огчгагг!), база данных восстанавливается ло сохраненного состояния, после чего выполняются все правильные транзакции. (Мы не обрабатываем транзакции повторно, поскольку прикладные программы пе участвуют в процессе восстановления. Все, что мы делаем — это производим изменения в базе данных согласно записям в журнале.) Второй метод называется откатом (го!!Ьас1с). При этом методе мы отменяем изменения, произведенные в базе данных ошибочными или частично выполненными транзакциями. Затем повторно запускаются правильные транзакции, которые выполнялись в момент возникновения сбоя. Оба эти метода требуют ведения журнала (!ой) результатов транзакций.
Этот журнал содержит записи изменений, произведенных с данными, в хронологическом порядке. Прежде чем транзакция будет выполнена, ее необходимо записать и журнал. Тогда, если крах системы произойдет в интервале между записью транзакции в журнал и выполнением ее, то в худшем случае у нас будет иметься запись о невыполненной транзакции. Если, напротив, транзакции сначала выполняются. а затем уже записываются в журнал, то возможен нежелательный вариант, когда изменения в базе данных произведены, но запись об этих изменениях отсутствует.
В такой ситуации неискушенный пользователь может повторно ввести транзакцию, которая уже выполнена. В случае сбоя журнал используется как для отмены, так и для повторного выполнения транзакций (рпс. 11.14), Чтобы была возможна отмена транзакций, журнал должен содержать копию каждой записи (или страницы) базы данных, сделанную перед ее изменением. Такие записи называются исходными образами (Ье(оге-1п1айез). Отмена транзакции производится путем последовательной записи в базу данных исходных образов всех произведенных ею изменений.
Чтобы было возможно повторное выполнение транзакций, журнал должен содержать копию каждой записи (или страницы) базы данных, сделанную после ее изменения Такие записи называются колечнььии образами (а(гег-ппаяез). Транзакпия выгюлнястся повторно путем последовательной записи в базу данных конечных образов всех произведенных ею изменений. Пример фрагмента журнала транзакций представлен на рис. 11.15, а. В этом примере каждая транзакция имеет уникальное имя для целей идентификации. Все образы каждой транзакции связаны между собой указателями.
Один указатель указывает на предыдущее изменение, сделанное данной транзакцией (обратный указатель), а другой — на следующее изменение, сделанное данной транзакцией (прямой указатель). Нуль в поле указателя означает конец списка. Подсистема восстановления СУБД использует эти указатели для нахождения всех записей, относящихся к данной транзакции. На рис. 11.15, б приведен пример связи между записями в журнале. Восстановление базы данных 411 *** КРАХ СИСТЕМЫ *** База данньж с измененными таблицами КЛИЕНТ, ПРОДАВЕЦ и ЗАКАЗ Исходные образы записей в таблицах КЛИЕНТ и ПРОДАВЕЦ Относительный номер записи ОТ1 2 11:42 СТАРТ ОТ1 4 11;43 ИЗМЕНИТЬ КЛИЕНТ 100 (старое значение) (новое значение) ОТ2 5 11:46 СТАРТ 5 11:47 ОТ1 ИЗМЕНИТЬ ПРОДАВЕЦ АА (старое значение) (новое значение) ОТ1 7 11.'47 ВСТАВИТЬ ЗАКАЗ 11 (значение) СТ1 0 9 11:46 СТАРТ СОХРАНИТЬ ОТ1 5 0 11.'49 ОТ2 3 0 11 50 СОХРАНИТЬ СТ1 6 10 11 51 ПРОДАВЕЦ ВВ ИЗМЕНИТЬ (старое значение) (новое значение) СТ1 9 0 11:51 10 СОХРАНИТЬ 410 Глава 11.
Многопользовательские базы данных Рис. 11.14. Откат и накат транзакций: а — отмена изменений в базе данных (откат); б — повторное выполнение изменений в базе данных (накат] Рис. 11.15. Журнал транзакций: а — элементы данных, содержащиеся в записи журнала транзакций; б — пример журнала с тремя транзакциями Остальные элементы данных журнала — это время выполнения действия. тип операции (АНТАНТ обозначает начало транзакции, СОММ)Т завершает транзак~игю, снимая все наложенные ею блокировки), объект, над которым производилось действие (например, тип и идентификатор записи), а также исходные и конечные образы.
Принять данные о заказе от браузера. Считать данные из таблиц КЛИЕНТ и ПРОДАВЕЦ. Внести изменения в считанные записи. Записать обновленные данные в таблицу КЛИЕНТ. Записать о5новпенные данные в таблицу ПРОдАВЕц (Дей виЯ запис нь Добавить новую строку в таблицу ЗАКАЗ. Процессор восстановления (применяет к базе данных исходные образы записей в таблицах КЛИЕНТ и ПРОДАВЕЦ и удаляет новую запись из таблицы ЗАКАЗ) База данных, из которой удалена неудачная транзакция б Рис.
11.16. Пример стратегии восстановления: а — транзакция, добавляющая новый заказ; б — процесс удаления данных о заказе Если есть журнал с исходными и конечными образами, то отмена и повторное выполнение транзакций происходит элементарно (но мы все равно опишем этот процесс). На рис. 11.16, чтобы отменить транзакцию, программа восстановления просто заменяет каждую измененную запись ее исходным образом. Когда все исходные образы будут восстановлены, транзакция будет отменена.
Чтобы повторно выполнить транзакцию, програзтма восстановления начинает с версии базы 412 Глава 11. Многопользовательские базы данных Поддержание репозитария данных 413 данных, существовавшей на момент начала данной транзакции, и записывает в базу все конечные образы. Как уже говорилось, это действие подразумевает, что имеется снимок базы данных с более ранней ее версией. Восстановление базы данных до ее последнего снимка и повторное выполнение всех транзакций может потребовать значительного времени. Чтобы уменьшить задержку, в СУБД иногда используются контрольные точки.
Колтрольлая точка ~сЬескрошс) — это точка синхронизации между базой данных и журналом транзакций. Для вставки контрольной точки СУБД отклоняет новые запросы, завершает обработку текущих запросов и сбрасывает свои буферы на диск. Затем СУБД ждет, пока операционная система не сообщит, что все текущие операции записи на писк и в журнал успешно выполнены. Теперь база данных и журнал синхронизированы.
После этого в журнале делается запись о контрольной точке. Позже база данных может быть восстановлена с контрольной точки, при этом нужно будет записать конечные образы только тех транзакций, которые начались после контрольной точки. Вставка контрольной точки — недорогая операция, и можно выполнять трц илн четыре (а можно и больше) таких операции в час. Таким образом, для восстановления потребуется не более 15-20 минут работы.
Большинство СУБД вставляют контрольные точки автоматически, делая человеческое вмешательство ненужным. Конкретные примеры приемов резервного копирования и восстановления в Огас!е и БОЕ Бегчег вы увидите в следующих двух главах. На данный момент вам нужно просто понимать основные идеи и сознавать, что обеспечение разработки адекватных планов резервного копирования и восстановления, а также создание снимков и журналов базы данных являются обязанностью администратора базы данных.
Управление СУБД Кроме управления работой с данными и структурой базы данных, администратор обязан управлять самой СУБД. Он должен собирать и анализировать статистику производительности системы и идентифицировать области, чреватые возникновением проблем. Вспомните, что база данных обслуживает множество пользовательских групп.
Администратор базы данных должен рассматривать все жалобы на медленный отклик системы, неточность данных, сложность в использовании и т. и. Если требуются какие-то изменения, администратор должен составить план этих изменений и реализовать их. Администратор должен периодически осуществлять мониторинг пользовательской активности при работе с базой данных. Отчеты могут содержать информацию о том, какие пользователи были наиболее активны, какие файлы и, возможно, элементы данных использовались, какие методы доступа были при этом задействованы. Также в отчетах может присутствовать информация о типах и частоте возникновения ошибок.
Администратор анализирует эту информацию с целью определить, нужны ли какие-либо изменения в структуре базы данных лля повышения производительности или упрощения работы пользователей. Если такие изменения необходимы, администратор обеспечивает их реализацию. Администратор базы данных должен анализировать текущую статистику производительности базы данных и активности пользователей. При обнаружении каких-либо проблем с производительностью (в ходе анализа отчета пли по жалобе пользователя) администратор должен определить, требуется ли модификаппя структуры базы данных или системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
