23. Распределенные бд.

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

«+»: пользователи узлов всегда обеспечены актуальной инф-ей; Экономное использ-е памяти.

«-»: высокие требования к каналам связи.

Доступ к данным.

Методы: монопольный, коллективный.

Монополь: 1) когда треб исключить доступ к объекту со стороны др. польз-ей; 2) когда производится ответственные операции с БД, не допускающие других действий. В 1-м случае уст-ся блокировка. Во 2-м – явная блокировка или положиться на СУБД.

Виды блокировок:

1. Полная 2.Блокировка от записи. 3.Предохраняющая блокировка от записи

4. Предохраняющая полная блокировка.

Первая распределенная СУБД System R*.

1. Пользователи остаются в среде языка SQL. Это возможно благодаря обеспечению прозрачности местоположения данных.

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

3. Высокая степень эффективности системы является одним из наиболее ключевых требований к распределенным системам управления базами данных вообще и к System R* в частности. Для достижения этой цели используются 2 основных приема: 1) выполнению запроса предшествует его компиляция; 2) возможность перемещения удаленных отношений в локальную базу данных.

В System R* реализовано:

• Средства именования объектов и организации распределенного каталога

• Распределенная компиляция и выполнение запросов

• Средства оптимизации запросов

• Представление

• Средства управления ТА-ми

• Синхронизация

• Алгоритм обнаружения тупиков

. В System R* не реализовано:

• Горизонтальное и вертикальное распределение отношений

• Дублирование отношений в нескольких узлах с поддержкой согласованности копий

• Поддержка мгновенных снимков состояния БД в соответствии с запросом.

Новое в организации распределенного каталога и как решался вопрос именования:

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

В SR* распределенная компиляция. Компиляция запроса производится на этапе компиляции прикладной программы или в динамике при выполнении ТА..

Будем называть главным узлом тот узел сети, в котором инициирован процесс компиляции предложения SQL, и дополнительными узлами - те узлы, которые вовлекаются в этот процесс в ходе его выполнения.

На самом грубом уровне процесс компиляции можно разбить на следующие фазы:

1. В главном узле производится грамматический разбор предложения SQL с построением внутреннего представления запроса в виде дерева. Локальные имена меняются на системные идентификаторы.

2. В главном узле генерируется глобальный план выполнения запроса

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

4. в узлах послед стадии компиляции, оптимизация и генерация машинных кодов.

ТА явл распределенными. Начин-ся на главном узле, что влечет инициирование ТА в доп. узлах.

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