Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. - Базы данных. Учебник для высших учебных заведений (6-е изд.) - 2009 (960530), страница 26
Текст из файла (страница 26)
При интенсивных обращениях к распределенной БД, большом числе взаимодействующих узлов,низкоскоростных и ненадежных каналах связи обработка запросов по этойсхеме становится практически невозможной.Модель тиражирования данных, в отличие от технологии распределенныхБД, предполагает дублирование данных (создание точных копий) в узлах сети(рис. 4.7).
Данные всегда обрабатываются как обычные локальные. Поддержкуидентичности копий друг другу в асинхронном режиме обеспечивает компонентсистемы, называемый репликатором (replicator). При этом между узлами сетимогут передаваться как отдельные изменения, так и группы изменений. В течение некоторого времени копии БД могут отличаться друг от друга.К основным достоинствам модели тиражирования БД (в сравнении с предыдущей моделью) относятся: более высокая скорость доступа к данным, таккак они всегда есть в узле; существенное уменьшение передаваемого по каналам связи потока информации, поскольку происходит передача не всех операций доступа к данным, а только изменений в БД; повышение надежностимеханизмов доступа к распределенным данным, поскольку нарушение связине приводит к потере работоспособности системы (предполагается буферизация потока изменений, позволяющая корректно возобновить работу послевосстановления связи).Часть 1.
Основы построения126БДбазданныхБДзапросыРис. 4.7. Модель тиражирования БДОсновной недостаток модели тиражирования БД заключается в том, чтона некотором интервале времени возможно «расхождение» копий БД. Еслиотмеченный недостаток некритичен для прикладных задач, то предпочтительно иметь схему с тиражированием БД.Доступ к общим даннымПри обслуживании обращений к общим данным средства управления БД должны обеспечивать по крайней мере два основных метода доступа: монопольный иколлективный. Основными объектами доступа в различных системах могут бытьцеликом БД, отдельные таблицы, записи, поля записей. В СУБД, предоставляющих возможность разработки, объектами доступа также могут выступать спецификации отчетов и экранных форм, запросы и программы.Монопольный доступ обычно используется в двух случаях:• во-первых, когда требуется исключить доступ к объектам со стороны другихпользователей (например, при работе с конфиденциальной информацией);• во-вторых, когда производятся ответственные операции с БД, не допускающие других действий, например, изменение структуры БД.В первом случае пользователь с помощью диалоговых средств С У Б Д илиприкладной программы устанавливает явную блокировку.
Во втором случаепользователь тоже может установить явную блокировку, либо положитьсяна С У Б Д . Последняя обычно автоматически устанавливает неявную (без ведома пользователя или приложения) блокировку, если это необходимо.В режиме коллективного доступа полная блокировка на используемыеобъекты, как правило, не устанавливается.
Коллективный доступ возможен,4. Информационныесистемыв сетях127например, при одновременном просмотре таблиц. Попытки получить монопольный доступ к объектам коллективного доступа должны быть пресечены.Например, в ситуации когда один или несколько пользователей просматривают таблицу, а другой пользователь собирается удалить эту же таблицу.Для организации коллективного доступа в СУБД применяется механизмблокировок.С у т ь б л о к и р о в к и с о с т о и т в том, что на время в ы п о л н е н и я ка-кой-либо операции в БД доступ к используемому объекту со стороны другихпотребителей временно запрещается или ограничивается.
Например, при копировании таблицы она блокируется от изменения, хотя и разрешено просматривать ее содержимое.Рассмотрим некоторый типичный набор блокировок. В конкретных программах схемы блокирования объектов могут отличаться от описываемой.Выделим четыре вида блокировок, перечисленные в порядке убывания строгости ограничений на возможные действия:• полная блокировка;• блокировка от записи;• предохраняющая блокировка от записи;• предохраняющая полная блокировка.Полная блокировка.
Означает полное запрещение всяких операций над основными объектами (таблицами, отчетами и экранными формами). Этот видблокировки обычно применяется при изменении структуры таблицы.Блокировка от записи. Накладывается в случаях, когда можно использовать таблицу, но без изменения ее структуры или содержимого. Такая блокировка применяется, например, при выполнении операции слияния данныхиз двух таблиц.Предохраняющая блокировка от записи. Предохраняет объект от наложения на него со стороны других операций полной блокировки, либо блокировки от записи. Этот вид блокировки позволяет тому, кто раньше «захватил»объект, успешно завершить модификацию объекта. Предохраняющая блокировка от записи совместима с аналогичной блокировкой (предохраняющейблокировкой от записи), а также с предохраняющей полной блокировкой (см.далее).
Примером необходимости использования этой блокировки являетсярежим совместного редактирования таблицы несколькими пользователями.Предохраняющая полная блокировка. Предохраняет объект от наложенияна него со стороны других операций только полной блокировки. Обеспечивает максимальный уровень совместного использования объектов. Такая блокировка может использоваться, например, для обеспечения одновременногопросмотра несколькими пользователями одной таблицы. В группе пользователей, работающих с одной таблицей, эта блокировка не позволит никому изменить структуру общей таблицы.При незавершенной операции с некоторым объектом и запросе на выполнение новой операции с этим же объектом производится попытка эти опера-128Часть 1.
Основыпостроениябазданныхции совместить. Совмещение возможно тогда, когда совместимыми оказываются блокировки, накладываемые конкурирующими операциями.В отношении перечисленных выше четырех блокировок действуют следующие правила совмещения:• при наличии полной блокировки над объектом нельзя производить операции, приводящие хотя бы к одному из видов блокировок (полная блокировка несовместима ни с какой другой блокировкой);• блокировка от записи совместима с аналогичной блокировкой и предохраняющей полной блокировкой;• предохраняющая блокировка от записи совместима с обоими видами предохраняющих блокировок;• предохраняющая полная блокировка совместима со всеми блокировками, кроме полной.Обычно в С У Б Д каждой из выполняемых с БД операций соответствуетопределенный вид блокировки, которую эта операция накладывает на объект.Пользователям современных С У Б Д , работающим в интерактивном режиме,не нужно помнить все тонкости механизма блокировки, поскольку системадостаточно «разумно» осуществляет автоматическое блокирование во всехслучаях, когда это требуется.
При этом система сама стремится предоставитьвсем пользователям наиболее свободный доступ к объектам. При необходимости пользователь и программист могут воспользоваться командными илиязыковыми средствами явного определения блокировок. Например, в С У Б ДParadox для явного блокирования отдельной записи во время редактирования таблицы используется команда Record | Lock.ТупикиЕсли не управлять доступом к совместно используемым объектам, то между потребителями ресурсов могут возникать тупиковые ситуации (клинчи,«смертельные объятия» или блокировки). Следует отличать понятие блокировки в смысле контроля доступа к объектам (мы придерживаемся такоготермина) от блокировки в смысле тупикового события.Существует два основных вида тупиков: взаимные (deadlock) и односторонние (livelock).Простейшим случаем взаимного тупика является ситуация, когда каждый из двух пользователей стремится захватить данные, уже захваченныедругим пользователем (рис.
4.8а). В этой ситуации пользователь-1 ждет освобождения ресурса N, в то время как пользователь-2 ожидает освобождения от захвата ресурса М. Следовательно, никто из них не может продолжить работу.В действительности могут возникать и более сложные ситуации, когда выполняются обращения трех и более пользователей к нескольким ресурсам.Пример одной из таких ситуаций приведен на рис. 4.86.4. Информационныесистемыв сетяха)129б)Рис. 4.8. Примеры взаимных тупиков в распределенных БДОдносторонний тупик возникает в случае требования получить монопольный доступ к некоторому ресурсу как только он станет доступным и невозможности удовлетворить это требование.Системы управления распределенными БД, очевидно, должны иметь соответствующие средства обнаружения или предотвращения конфликтов, атакже разрешения возникающих конфликтов.
Одной из наиболее сложныхявляется задача устранения конфликтов в неоднородных системах в случае,если некоторая программа не обрабатывает или обрабатывает некорректносигналы (уведомления) о наличии конфликтов. При этом важно не толькосохранить целостность и достоверность данных в распределенных БД, но ивосстановить вычислительный процесс, иногда парализующий пользователей и программы ожиданием чего-то.Пользователи и разработчики приложений в распределенной среде должны предусматривать обработку сигналов о тупиках.ПротоколыфиксациитранзакцийВ настоящее время наиболее широко используются два протокола фиксации транзакций: двухфазный и трехфазный.
Рассмотрим их вкратце.Прежде всего, будем считать, что выполняется распределенная транзакция, с которой связан некоторый узел, функционирующий как координатор(диспетчер). Обычно координатором является узел сети, где транзакция былаинициирована. Узлы, на которых глобальная транзакция создает агентов, назовем участниками (диспетчерами ресурсов). Координатор транзакции знаетидентификаторы всех участников, а каждый участник знает идентификаторкоординатора, но не обязан знать идентификаторы других участников.5 Зак.
541130Часть 1. Основы построениябазданныхДвухфазный протокол фиксации транзакций выполняется в два этапа:голосование (voting phase) и принятие решения (decision phase). Этот протокол предполагает, что каждый узел имеет свой собственный журнал, с помощью которого можно зафиксировать или отменить транзакцию. Для этого вжурналы координатора и участников вносятся записи о приеме и посылкекоманд (сообщений). Во избежание блокирования из-за бесконечного ожидания ответов от других участников протокола в протоколе используетсямеханизм тайм-аутов.На первом этапе координатор опрашивает всех участников командойPREPARE, готовы ли они к фиксации транзакции и переходит к ожиданиюответов.На втором этапе если хотя бы один из участников потребует отката (команда ABORT) или не ответит на запрос в течение установленного интервала времени, координатор указывает всем участникам на необходимость выполненияотката данной транзакции (команда GLOBAL_ABORT).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
