Особенности технологий баз данных

На практике доступ к базе данных чаще всего имеет одна программа (один пользователь). Однако бывают ситуации, когда одновременно (параллельно) выполняется несколько программ или несколько прогонов одной и той же программы. В системе продажи проездных билетов, например, продавать билеты и изменять таким образом количество свободных мест могут одновременно несколько агентов. Здесь следует позаботиться о правилах, регулирующих доступ к базе данных двух или более программ, иначе не исключена возможность продажи билетов на одно и то же место двум пассажирам. Таким образом, не следует допускать параллельного выполнения двух процессов, которые читают и изменяют значение одного и того же объекта. Аналогичный пример можно привести с платежной технологии по переводу денежных средств с одного счета на другой.

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

Одним из способов избежать параллельного чтения и изменения одного и того же объекта является блокирование отдельных элементов базы. База данных разбивается на отдельные части, которые можно блокировать. Блокируя определенную часть, трансакция (розовый "прогон" программы) может препятствовать доступу других транзакций в этой части базы до того момента, пока она не разблокирует ее. Функциональный компонент СУБД (управление блокировкой) назначает и регистрирует блокировки, а также играет роль арбитра между двумя (и более) запросами на блокирование одной и той же части базы данных. Элементами блокировки в реляционной модели данных могут быть отдельные компоненты кортежей, отдельные кортежи, блок кортежей и даже отношения.

Чтобы убедиться в необходимости блокировки элементов базы данных, рассмотрим две сделки - Т1, и Т2. Каждая из них имеет доступ к элементу А и увеличивает его значение на единицу. Обе сделки является "прогоном" программы Р:

Значение А содержится в базе данных. Программа Р читает (Read) значения А в свое рабочее пространство, добавляет к нему единицу и записывает (Write) результат

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

Таблица 2.27

Трансакции, демонстрируют необходимость блокировки элемента А

Значение А в базе данных

7

7

7

7

8

8

Трансакция Т1

Трансакция Т2

Значение А в рабочем пространстве Т1

Значение А в рабочем пространстве Т2

Read А

7

Read А

7

7

A = A + 1

8

7

А = А + 1

8

8

Write А

8

8

Write А

8

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

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

Р: Lock A; Read А; А = А + 1; Write A; Unlock А.

Если Т1 и Т2 - два исполнения программы Р и первой начинается Т1, то она начинается с блокирования А. Система предоставляет это блокирование с условием, что другая транзакция НЕ заблокировала А, тогда транзакция Т1 (и только она одна) получает доступ к А.

Если Т2 начинается до завершения Т1 то как только Т2 попытается выполнить команду Блокировать A (Lock А), система заставит ее ждать до выполнения первой сделкой команды списка A (Unlock А). Только после этого система позволит выполнения транзакции Т2. Таким образом, аномалия, показана в табл. 2.27, не может иметь места, так как одна из транзакций, Т1 или Т2, будет выполнена полностью перед тем, как начнется вторая, а их общим результатом будет увеличение А на два.

К этому времени предполагалось, что каждая транзакция выполняется успешно до своего логического завершения. На практике, однако, различные обстоятельства могут помешать ее завершению:

• по тем или иным причинам, связанным с оборудованием или программным обеспечением, может произойти отказ системы, в этом случае все активные транзакции не способны завершиться. Отказа системы порождают серьезные проблемы - нужно не только найти множество транзакций, работу которых надо "аннулировать", чтобы вернуть систему в прежнее состояние, но и убедиться в том, что есть какой-то способ восстановления такого состояния; • выполнение транзакции может быть принудительно закончен еще до ее завершения (деление на ноль и т.д.). В связи с этим следует предусматривать периодическое копирование базы данных, утилита для копирования должна сама быть сделкой с блокировкой данных. Следует также сохранять на диске историю (журнал) всех изменений в базе данных. Записи журнала, как правило, содержат: уникальный номер транзакции, обусловила изменения в базе данных; предыдущие значения элементов базы; новые значения элементов и т.

 
< Пред   СОДЕРЖАНИЕ   След >