Введение в системы БД (542480), страница 137
Текст из файла (страница 137)
Однако в целях упрощения представления материала желательно рассматривать их по отдельности (по крайней мере до тех пор, пока не будет закончено описание основных концепций). В настоящей главе основное внимание уделяется восстановлению, а параллельность будет рассмотрена в главе 15, хотя время от времени здесь неизбежно будут встречаться ссылки на вопросы, относящиеся к параллельности. Восстановление в системе баз данных означает, в первую очередь, восстановление самой базы данных, т.е. возвращение базы данных в определенное состояние, которое считается корректным (или, точнее говоря, непротиворечивым'), если в результате какого-либо сбоя текущее состояние стало противоречивым или по крайней мере подозрительным.
Основной принцип, на котором строится подобное восстановление, достаточно прост и может быть выражен одним словом — избыточность. (Эта избыточность организуется на физическом уровне. По причинам, указанным в части!!1, такую избыточность не следует показывать на логическом уровне.) Иначе говоря, убедиться в том, что база данных действительно восстанавливаема, можно, получив гарантии, что любая часть содержащейся в базе данных информации может быть реконструирована из другой информации, избыточно сохраняемой где-то в системе. Прежде чем идти дальше, необходимо уяснить, что принцип восстановления (а в действительности и обработки транзакций в целом) в значительной степени не зависит от того, какой является базовая система: реляционной или какой-либо еще. (С другой стороны, слелует отметить, что исторически сложилось так, что большая часть теоретических исследований в области обработки транзакций была выполнена и продолжает выполняться именно в реляционном контексте.) Нужно также заметить, что это весьма обширный предмет обсуждения, и мы сможем познакомить читателя только с наиболее важными и основополагающими принципами.
Для более углубленного изучения предмета можно обратиться к источникам, указанным в списке литературы в конце данной главы (в частности, обратите особое внимание на издание [! 4.12]). План этой главы выглядит следующим образом. После короткого введения в разделах !4.2 и 14.3 описываются фундаментальные понятия транзакции и восстановления гпранзакции (т.е, восстановления базы данных после неудачного выполнения какой-либо З Здесь термин "непративарвчивае састакние" азначает "удавлвтварлются асв известныв ограничения ивлагтнасти". Обратите внимание, чта непротиворечивое састалние не абязательна значит коррекхное, тогда как корректное состояние обязательно должна быть непративаречивым.
Нвпративоречивае состояние лхажвт, твлх нв лхвнвв, быть некорректным в там слхысле, чта ана неточно отражает истинное состояние двл в реальном мире. Значение термина "непративаречивае состоянии" можно апргделить как "корректное в рачках твх ограничений, которые угтанаалены в рассматриваемой системе ". 544 Часть 1)г Управление транзакциями транзакции). Затем в разделе 14.4 более глубоко обсуждается проблема восстановления системы (восстановление после одновременного нарушения выполнения всех текущих транзакций, вызванного неким сбоем системы). После этого в разделе!4.5 кратко рассматривается восстановление носителей (т.е.
восстановление после какого-либо физического повреждения базы данных, например из-за поломки головок дискового накопителя). Далее в разделе 14.6 описывается исключительно важная проблема двухфазной фиксации транзакций, а в разделе !4.7 обсуждаются относящиеся к делу операции языка Я! !Ь.
И наконец в разделе 14.8 приводятся краткое резюме и несколько заключительных замечаний. 14.2. Транзакции Как уже указывалось в разделе 14.1, мы начнем с изучения фундаментального понятия транзакции. Транзакция — это логическая единица работы. Рассмотрим следующий пример. Предположим сначала, что переменная-отношение Р (переменная- отношение деталей) включает дополнительный атрибут ТОТОТУ, представляющий собой общий объем поставок для каждой детали. Другими словами, предполагается, что значение атрибута ТОТОТТ для любой конкретной детали равно сумме всех значений атрибута ОТУ для всех поставок данной детали (в терминах главы 8 это ограничение базы данных). На рис.
14.1 показан псевдокод процедуры вставки в базу данных сведений о новой поставке со значением 1000 для поставщика '85' и детали 'Р1' (команда 1ЯЯЕЕТ добавляет сведения о новой поставке в отношение ЯР, а команда ОРОйТЕ обновляет значение атрибута ТОТОТУ для детали 'Р1'). Рис 14 1 Пример гпранзакции (псевдокод) 545 Глава 14. Восстановление В приведенном примере предполагается, что речь идет об одиночной, атомарной операции.
На самом деле добавление сведений о новой поставке — это выполнение двух обновлений в базе данных: операции 1КЕЕКТ и операции ПРОАТЕ. Более того, в базе ланных между этими двумя обновлениями временно нарушается требование, что значение атрибута ТОТЯТТ для детали 'Р1' равно сумме всех значений атрибутов ЯТ1 для этой детали. Таким образом, логическая единица работы (т.е. транзакция) вовсе необязательно является простой одиночной операцией системы баз данных; чаще всего она представляет собой последовательность из нескольких таких операций. В общем случае выполнение этой последовательности переводит базу данных из одного непротиворечивого состояния в другое, причем в промежуточных точках выполнения база данных может находиться в противоречивом состоянии.
Из этого следует, что не допустимо, чтобы одно из обновлений было выполнено, а другое нет, так как в этой ситуации база данных останется в противоречивом состоянии. В идеальном случае необходимо иметь абсолютную гарантию, что всегда будут выполняться оба обновления. К сожалению, подобную гарантию дать нельзя, поскольку нельзя исключить вероятность того, что может случиться что-то непредвиденное, причем в самый неподходящий момент. Например, между операциями 1ИЯЕКТ и ОРОАТЕ может произойти сбой системы или же во время выполнения второй операции может возникнуть арифметическое переполнение и т.п. Однако система, поддерживающая обработку транзакций, гарантирует максимум из того, что можно гарантировать, а именно — что если во время выполнения неких обновлений произойдет ошибка (по любой причине), то все эти обновления будут отменены.
Таким образом, транзакция изи полностью выполняется, ази полностью отменяется (как будто она вообще не выполнялась), т.е. выполнение неатомарной последовательности операций с точки зрения внешнего наблюдателя будет выглядеть так же, как выполнение атомарной операции. Системный компонент, обеспечивающий атомарность (или ее подобие), называется менеджером транзакций или диспетчером обработки транзакций (1гапзасйоп ргосеззшЕ пюппог — Тр-пюпйог), а ключевыми элементами в его выполнении служат операторы СОИИЬТ и КОЬЬВАСК. ° Оператор СОИИ1Т (зафиксировать) сигнализирует об успеизном окончании транзакции. Он сообшает менеджеру транзакций, что логическая единица работы успешно завершена, база данных вновь находится (нли будет находиться) в непротиворечивом состоянии, а все обновления, выполненные данной логической единицей работы, теперь могут быть "зафиксированы", т.е. сделаны постоянными.
° Оператор КОЬЬВАСК (откатить) сигнализирует о неудачном окончании транзакции. Он сообшает менеджеру транзакций, что произошла какая-то ошибка, база данных находится в противоречивом состоянии и следует выполнить "откат" всех проведенных при выполнении этой транзакции обновлений, т.е.
они должны быть отменены. Таким образом, в приведенном примере оператор СОИИ1Т должен выполняться, если оба обновления прошли успешно, после чего выполненные в базе данных изменения стануг постоянными. Если что-то не так, если обновление было прервано каким-либо условием ошибки, то выполняется оператор КОЬЬВАСК и любые внесенные изменения отменяются. Замечание. Даже если в последнем случае попытаться выполнить оператор СОИИ1Т, то система, в принципе, все равно должна проверить соблюдение существующих ограничений целостности, обнаружить противоречивость возникшего состояния базы данных и 546 Часть 1К Управление транзакциями принудительно выполнить откат. Однако следует быть реалистами и понимать, что система не всегда может знать обо всех уместных в каждой конкретной ситуации ограничениях, а потому выполнение оператора ВОЬЬВАСК по требованию пользователя следует считать необходимым.
На момент написания этой книги коммерческие СУБД обладали лишь ограниченными возможностями проверки ограничений целостности в процессе фиксации транзакций. Кстати, следует отметить, что реальные приложения могут не только модифицировать базу данных (или пытаться это сделать), но также отсылать пользователю некоторые сообщения о том, что произошло. В нашем примере можно отослать пользователю сообщение "Сведения о поставке введены" после выполнения операции СОММ1Т и сообщение "Ошибка — сведения о поставке не введены" в противном случае. Выдача сообщений, в свою очередь, имеет дополнительное значение для восстановления.