- •8. Распределенные базы данных
- •8.1.Предпосылки возникновения рбд
- •8.2. Классификация систем по способам обработки данных
- •8.3. Однородные и неоднородные системы бд
- •8.4. Стратегия размещения данных в рбд по узлам сети
- •Функции сурбд
- •9. Удаленный доступ взаимодействия с базой данных
- •9.1. Режим работы с бд при удаленном доступе
- •9.2. Архитектура моделей удалённого доступа.
- •2.2.3. Двухуровневые модели. Модель файлового сервера (File Server, fs)
- •9.2.4. Модели удалённого доступа к данным (Remote Data Access, rda) в архитектуре «клиент-сервер»
- •9.2.5. Модель «сервера бд»
- •9.2.6. Хранимые процедуры (хп) и триггеры
- •9.3. Многоуровневые модели 9.3.1. Модель сервера приложений
- •9.3.2. Модель серверов баз данных.
- •9.4. Архитектура распределённых субд
- •10 .Параллельные процессы (или процесс транзакций)
- •10.1. Транзакции
- •10.2. Модели транзакций
- •3.3. Свойства транзакций
- •10.4. Восстановление системы.
- •10.5. Параллельные операции над бд
- •10.6. Проблемы параллелизма
- •10.7. Конфликт транзакций
- •10.8. Элементы блокировки.
- •10.8.1. Бесконечное ожидание и тупики
- •10.8.2. Способы предотвращения тупиков
- •10.9.1. Протоколы и расписания
- •10.9.2. Модель транзакции
- •10.9.3. Протокол, гарантирующий сериализуемость
- •10.10. Модели с блокировками для чтения и записи
- •10.11. Блокировки в Visual FoxPro
- •11. Безопасность бд
- •11.2. Система привилегий.
- •Факультативные возможности grant
- •11.3. Целостность данных
- •11.4. Шифрование данных
- •12. Хранилище данных
- •12.1. Концепция хранилища данных
- •12.2. Многомерная модель данных
- •12.3. Olap – системы
- •12.4. Интеллектуальный анализ данных
10.7. Конфликт транзакций
Анализ проблемы параллелизма показывает, что если не предпринимать специальных мер, то при совместной работе нарушается свойство (И) транзакций - изолированность. Транзакции реально мешают друг другу получать правильные результаты, если они пересекаются и обращаются к одним и тем же данным. В результате конкуренции за данными возникают конфликты доступа к данным.
Различают конфликты: · W-W (Запись-Запись). Первая транзакция изменила объект и не закончилась. Вторая пытается изменить этот объект. Результат – потеря обновления. · R-W (Чтение-Запись) Первая транзакция прочитала объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат – несовместный анализ. · W-R (Запись-Чтение). 1-я транзакция изменила объект и не закончилась. 2-я пытается прочитать этот объект. Результат – чтение двух «грязных» файлов. Конфликты типа R-R (Чтение-чтение) отсутствуют, т.к. данные при чтении не изменяются. График запуска транзакций могут быть:
1. Последовательные – если транзакции выполняются строго по очереди. 2. Чередующиеся – если график содержит чередующиеся элементарные операции транзакций. В первом случае процесс замедляется, но зато выполняется правило. Два графика называются эквивалентными, если при их выполнении будет получен один и тот же результат. График запроса транзакции называется верным (сериализуемым), если он эквивалентен какому-либо последовательному запросу.
Замечание: При выполнении двух различных последовательных (а, следовательно, верных) графиков, содержащих один и тот же набор транзакций, могут быть получены различные результаты. Пусть Т1 выполняет действие «сложить X с 1», а транзакция Т2 – «Удвоить X». Тогда последовательный график {Т1,Т2} даст результат 2(Х+1), а последовательный график {Т2,Т1} даст результат 2Х+1. Таким образом, может существовать несколько верных графиков запуска транзакций, приводящих к разным результатам при одном и том же начальном состоянии базы данных. Существуют два способа разрешить конкуренции между транзакциями.
1. «Притормаживать» некоторые транзакции (таким образом обеспечить, чтобы конкурирующие транзакции выполнялись в разное время).
2. Предоставить конкурирующим транзакциям «разные» экземпляры данных
1-ый реализуется путём использования блокировок
2-ой реализуется путём использования данных из журнала транзакций.
10.8. Элементы блокировки.
База данных может быть разбита на элементы, то есть на части, которые можно блокировать. Блокируя некоторый элемент, транзакция может препятствовать доступу других транзакций к этому элементу до тех пор, пока они не разблокируют его. Природа и размер элементов являются спорными вопросами. Можно видеть большие элементы, подобные отношениям, или малые, такие как отдельные кортежи и даже компоненты кортежей. Выбор больших элементов сокращает накладные расходы системы по поддержанию блокировок, тогда как выбор малых элементов даёт возможность параллельного исполнения многих транзакций. Если типичная транзакция читает или модифицирует один кортеж, который она находит с помощью индекса, то целесообразно трактовать кортежи как элементы. Если же типичная транзакция производит соединение двух или более отношений и тем самым требует доступа ко всем кортежам этих отношений, уместно в качестве элементов выбрать отношения. Рассмотрим теперь программу, которая при взаимодействии с базой данных не только читает, но и записывает её элементы, но и блокирует и разблокирует их. Условимся, что элемент должен быть блокирован до начала чтения или записи и что операция блокировки действует как примитив синхронизации. Это означает, что если транзакция пытается блокировать уже блокированный элемент, ей приходится ждать, пока блокировка не будет снята по команде разблокирования, которая выполняется транзакцией, устанавливающей блокировку. Каждая программа, в конце концов, должна разблокировать любой элемент, который она блокировала. Расписание элементарных шагов двух или более транзакций, такое, что выполняются указанные выше правила, касающиеся блокировок, называются легальным. Пример 2. Программу Р из примера 1. можно было бы записать с блокировками следующим образом:
P: LOCK A; READ A; A:=A+1; WRITE A; UNLOCK A;
Пусть Т1 и Т2 - две исполнимых программы Р. При выполнении Т1 произойдёт блокировка. Если Т2 начинается до завершения Т1, то система заставит её ждать A:=A+1 Т1 |----------------------|
Т2 - - - - - - - - |--------------------| Совместным результатом окажется увеличение А на 2.
