Лекции и практики (1). Курс лекций и материалы для практических занятий

• Название: Курс лекций и материалы для практических занятий
• Дата: 17.03.2023
• Размер: 1.01 Mb.
• Имя файла: Лекции и практики (1).docx
• Тип: Курс лекций; #996812
• страница: 30 из 75

Лекция 7.

МНОГОПОЛЬЗОВАТЕЛЬСКИЙ ДОСТУП К ДАННЫМ

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

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

1. Механизм транзакций

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




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

Транзакция обладает следующими свойствами:

1. 
   Логическая неделимость (атомарность, Atomicity) означает, что выполня- ются либо все операции (команды), входящие в транзакцию, либо ни одной. Система гарантирует невозможность запоминания части изменений, произ- ведённых транзакцией. До тех пор, пока транзакция не завершена, её можно "откатить", т.е. отменить все сделанные командами транзакции изменения. Успешное выполнение транзакции (фиксация) означает, что все команды транзакции проанализированы, интерпретированы как правильные и без- ошибочно исполнены.
   
2. 
   Согласованность (Consistency): транзакция начинается на согласованном множестве данных и после её завершения множество данных согласовано. Состояние БД является согласованным, если данные удовлетворяют всем установленным ограничениям целостности и относятся к одному моменту в состоянии предметной области.
   
3. 
   Изолированность (Isolation), т.е. отсутствие влияния транзакций друг на друга. (На самом деле это влияние существует и регламентируется стандар- том: см. раздел 6.3. "Уровни изоляции транзакций").
   
4. 
   Устойчивость (Durability): результаты завершённой транзакции не могут быть потеряны. Возврат БД в предыдущее состояние может быть достигнут только путём запуска компенсирующей транзакции.
   

Транзакции, удовлетворяющие этим свойствам, называют ACID-транзакциями (по первым буквам названий свойств).

Для управления транзакциями в системах, поддерживающих механизм транзакций и язык SQL, используются следующие операторы:

• 
  фиксация транзакции (запоминание изменений): COMMIT [WORK];
  
• 
  откат транзакции (отмена изменений): ROLLBACK [WORK];
  
• 
  
  создание точки сохранения: SAVEPOINT <имя_точки_сохранения>; (Ключевое слово WORK необязательно). Для фиксации или отката транзакции система создаёт неявные точки фиксации и отката (рис. 6.1).
  

Рис. 6.1. Неявные точки фиксации и отката транзакции
По команде rollback система откатит транзакцию на начало (на неявную точку отката), а по команде commit – зафиксирует всё до неявной точки фикса- ции, которая соответствует последней завершённой команде в транзакции. Если в транзакции из нескольких команд во время выполнения очередной команды возникнет ошибка, то система откатит только эту ошибочную команду, т.е. от- менит её результаты и сохранит прежнюю неявную точку фиксации.

Для обеспечения целостности транзакции СУБД может откладывать за- пись изменений в БД до момента успешного выполнения всех операций, вхо- дящих в транзакцию, и получения команды подтверждения транзакции (commit). Но чаще используется другой подход: система записывает изменения в БД, не дожидаясь завершения транзакции, а старые значения данных сохраня- ет на время выполнения транзакции в сегментах отката.

Сегмент отката (rollback segment, RBS) – это специальная область памя- ти на диске, в которую записывается информация обо всех текущих (незавер- шённых) изменениях. Обычно записывается "старое" и "новое" содержимое из- менённых записей, чтобы можно было восстановить прежнее состояние БД при откате транзакции (по команде rollback) или при откате текущей операции (в случае возникновения ошибки). Данные в RBS хранятся до тех пор, пока тран- закция, изменяющая эти данные, не будет завершена. Потом они могут быть перезаписаны данными более поздних транзакций.

Команда savepoint запоминает промежуточную "текущую копию" состо- яния базы данных для того, чтобы при необходимости можно было вернуться к состоянию БД в точке сохранения: откатить работу от текущего момента до точки сохранения (rollback to <имя_точки>). На одну транзакцию может быть несколько точек сохранения (ограничение на их количество зависит от СУБД).

Для сохранения сведений о транзакциях СУБД ведёт журнал транзакций. Журнал транзакций – это часть БД, в которую поступают данные обо всех изменениях всех объектов БД. Журнал недоступен пользователям СУБД и под- держивается особо тщательно (иногда ведутся две копии журнала, хранимые на разных физических носителях). Форма записи в журнал изменений зависит от СУБД. Но обычно там фиксируется следующее:

• 
  номер транзакции (номера присваиваются автоматически по возрастанию);
  
• 
  состояние транзакции (завершена фиксацией или откатом, не завершена, находится в состоянии ожидания);
  
• 
  точки сохранения (явные и неявные);
  
• 
  команды, составляющие транзакцию, и проч.
  

Начало транзакции соответствует появлению первого исполняемого SQL- оператора. При этом в журнале появляется запись об этой транзакции.

По стандарту ANSI/ISO транзакция завершается при наступлении одного из следующих событий:

• 
  Поступила команда commit (результаты транзакции фиксируются).
  
• 
  Поступила команда rollback (результаты транзакции откатываются).
  
• 
  Успешно завершена программа (exit, quit), в рамках которой выполнялась транзакция. В этом случае транзакция фиксируется автоматически.
  
• 
  Программа, выполняющая транзакцию, завершена аварийно (abort). При этом транзакция автоматически откатывается.
  

Примечания:

1. 
   Возможна работа в режиме AUTOCOMMIT, когда каждая команда воспринимается системой как транзакция. В этом режиме пользователи меньше задерживают друг друга, требуется меньше памяти для сегмента отката, зато результаты ошибочно вы- полненной операции нельзя отменить командой rollback.
   
2. 
   В некоторых СУБД реализованы расширенные модели транзакций, в которых суще-
   

ствуют дополнительные ситуации фиксации транзакций. Например, в СУБД Oracle команды DDL выполняются в режиме AUTOCOMMIT, т.е. не могут быть откачены.

Все изменения данных выполняются в оперативной памяти в буфере дан- ных, затем фиксируются в журнале транзакций и в сегменте отката и периоди- чески (при выполнении контрольной точки) переписываются на диск. Процесс формирования контрольной точки (КТ) заключается в синхронизации данных, находящихся на диске (т.е. во вторичной памяти) с теми данными, которые находятся в ОП: все модифицированные данные из ОП переписываются во вто- ричную память. В разных системах процесс формирования контрольной точки запускается по-разному. Например, в СУБД Oracle КТ формируется:

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

Внесение изменений в журнал транзакций всегда носит опережающий характер по отношению к записи изменений в основную часть БД (протокол WAL – Write Ahead Log). Эта стратегия заключается в том, что запись об изме- нении любого объекта БД должна попасть во внешнюю память журнала тран- закций раньше, чем изменённый объект попадёт во внешнюю память основной части БД. Если СУБД корректно соблюдает протокол WAL, то с помощью журнала транзакций можно решить все проблемы восстановления БД после сбоя, если сбой препятствует дальнейшему функционированию системы (например, после сбоя приложения или фонового процесса СУБД).

Таким образом, при использовании протокола WAL изменённые данные почти сразу попадают в базу данных, ещё по поступления команды commit. По- этому фиксация транзакции чаще всего заключается в следующем:

1. 
   Изменения, внесённые транзакцией, помечаются как постоянные.
   
2. 
   Уничтожаются все точки сохранения для данной транзакции.
   
3. 
   Если выполнение транзакций осуществляется с помощью блокировок, то освобождаются объекты, заблокированные транзакцией (см. раздел 6.4).
   
4. 
   В журнале транзакций транзакция помечается как завершённая, уничтожа- ются системные записи о транзакции в оперативной памяти.
   

А при откате транзакции вместо п.1 обычно выполняется считывание из сег- мента отката прежних значений данных и переписывание их обратно в БД (остальные пункты сохранятся без изменений). Поэтому откат транзакции практически всегда занимает больше времени, чем фиксация.