Централизованное блокирование

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

Проблемы централизованного блокирования:

· центральный узел может стать узким местом: как из-за большого объема обработки данных, так и из-за генерируемого вокруг него интенсивного сетевого трафика;

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

Блокирование первичных копий

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

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

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

Распределенное блокирование

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

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

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

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

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

Метки времени

Каждой транзакции присваивается глобальная уникальная метка времени. Значение метки времени явно определяет порядок, в котором транзакции предоставляются СУБД.

Метки времени должны обладать двумя свойствами:

1. Уникальностью. Гарантирует отсутствие одинаковых значений меток времени.

2. Монотонностью. Гарантирует, что значение метки времени всегда возрастает.

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

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

Оптимистические методы

Оптимистические подходы исходят из предположения о том, что конфликты между транзакциями редки, и доводят транзакцию до конца, а затем производят проверку корректности.

Если выясняется, что фиксация данной транзакции повлечет нарушение сериализуемости, то транзакция откатывается и запускается снова.

При оптимистическом подходе каждая транзакция проходит две или три фазы: чтение, подтверждение, и запись.

 

15. Надежность системы. Протоколы обеспечения надежности.

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

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

Отказы выявляются тестированием технических и программных средств и устраняются во время проведения ремонтно-профилактических работ. Устранение отказов достигается путем восстановления работоспособности неисправных элементов системы (ремонта) или замены их резервными элементами.

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

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

В распределенной СУБД различаются четыре типа сбоев:

1. сбой транзакции,

2. сбой узла (системы),

3. сбой носителя (диска),

4. сбой коммуникационной линии.

Сбой транзакции

Причин сбоев транзакции может быть несколько:

§ ошибки, вызванные неверными входными данными,

§ обнаружение возникшего или возможного тупика.

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

Сбой узла

Cбои узлов (системные сбои) могут быть вызваны:

· аппаратными отказами (процессора, оперативной памяти, питания),

· программными ошибками (в системном или прикладном коде).

Следствие системных сбоев – потеря содержимого оперативной памяти, в частности буферов оперативной памяти (часть базы данных, хранимая в буферах, называется неустойчивой базой данных).

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

Сбой носителя

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

 

Рассмотренные выше три типа сбоев характерны и для централизованных, и для распределенных СУБД.

Сбой коммуникационной линии

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

Коммуникационные сбои подразделяются на:

· ошибки в сообщениях,

· нарушение упорядоченности сообщений,

· потерянные (недоставленные) сообщения,

· повреждения на линиях связи

Первые из двух типов сбоев находятся в компетенции сетевых протоколов, два последних лежат в ведении СУБД и должны учитываться в протоколах обеспечения надежности.

Если один узел ожидает сообщения от другого, а оно не поступает, то причин тому может быть несколько:

· сообщение утрачено;

· возникло повреждение на линии связи;

· узел, от которого ожидается сообщение, отказал.

В любом случае ожидающий узел по истечении определенного промежутка времени просто решает, что узел-партнер стал недоступен.

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

Протоколы распределенных СУБД должны уметь адекватно реагировать на подобные ситуации.