Максимов Н.В., Голицына О.Л., Васина Е.Н. Управление данными

Подождите немного. Документ загружается.

261

Рис. 9.4. Проблема пропавшего изменения

Для избежания подобных ситуаций к СУБД по части синхрониза-

ции параллельно выполняемых транзакций предъявляется минимальное

требование - отсутствие потерянных изменений.

Чтение «грязных» данных

Другой пример коллизий при несогласованной работе двух парал-

лельных транзакций представлен на рис. 9.5.

Как показано на рисунке, Диспетчер 1 и Диспетчер 2 опять выпол-

няют действия, описанные в предыдущем примере, но Диспетчер 2 на-

чинает запрашивать данные о нагрузке преподавателя в тот момент, ко-

гда изменения, сделанные Диспетчером 1, уже зафиксированы в столбце

Нагрузка, а транзакция еще не закончилась. Запрос Диспетчера 2 воз-

вращает значение 400, и Диспетчер 2 вынужден отменить свои действия

потому, что 400 часов – это максимальное разрешенное значение на-

грузки. Между тем транзакция Диспетчера 1 закончилась возвратом к

исходному состоянию, т.е. на самом деле Диспетчер 2 мог бы успешно

завершить операцию.

262

Рис. 9.5. Проблема чтения «грязных» данных

Это тоже не соответствует требованию изолированности пользова-

телей (каждый пользователь начинает свою транзакцию при согласован-

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

данные). Чтобы избежать ситуации чтения «грязных» данных, необхо-

димо требовать, чтобы до завершения одной транзакции, изменившей

некоторый объект, никакая другая транзакция не могла читать изменяе-

мый объект.

Чтение несогласованных данных

Рассмотрим ситуацию, которая приводит к получению несогласо-

ванных данных при выполнении операций над БД (рис. 9.6).

По-прежнему Диспетчер 1 выполняет операцию по заполнению

строки учебного плана, а Диспетчер 2 при выполнении своей операции

должен сделать выбор между двумя преподавателями в соответствии с

их текущей нагрузкой.

Начиная работу практически одновременно с Диспетчером 1, Дис-

петчер 2 получает следующие сведения: нагрузка первого преподавателя

263

(ID_Преподаватель = 5) составляет 350 часов, а нагрузка второго пре-

подавателя (ID_Преподаватель = 7) составляет 370 часов. Далее Дис-

петчер 2 принимает решение в пользу первого преподавателя, но по-

вторный запрос нагрузки возвращает значение 400, т.к. Диспетчер 1 уже

сохранил новые данные в таблице «Кадровый_состав».

В большинстве систем обеспечение изолированности пользовате-

лей в подобных ситуациях является максимальным требованием к син-

хронизации транзакций.

Рис. 9.6. Проблема чтения несогласованных данных

Строки-призраки

К более тонким проблемам изолированности транзакций относит-

ся так называемая проблема строк-призраков, вызывающая ситуации,

которые также противоречат изолированности пользователей. Рассмот-

рим следующий сценарий.

Диспетчер 1 инициирует Транзакцию 1, которая выполняет опера-

тор выборки строк таблицы в соответствии с некоторым условием (на-

пример, формирование списка студентов, сдавших дисциплину с

ID_Дисциплина = N, по таблице «Сводная_ведомость»). До завершения

Транзакции 1 Транзакция 2, вызванная Диспетчером 2, вставляет в таб-

лицу «Сводная_ведомость» новую строку, удовлетворяющую условию

отбора Транзакции 1 (данные о результате сдачи дисциплины N еще од-

ним студентом), и успешно завершается. Транзакция 1 повторно выпол-

няет оператор выборки, и в результате появляется строка, которая отсут-

ствовала при первом выполнении оператора. Конечно, такая ситуация

противоречит идее изолированности транзакций.

264

9.4. Сериализация транзакций

Чтобы добиться изолированности транзакций, СУБД должна ис-

пользовать специальные методы регулирования совместного выполне-

ния транзакций.

Метод сериализации транзакций - это механизм их выполнения по

такому плану, когда результат совместного выполнения транзакций эк-

вивалентен результату некоторого последовательного выполнения этих

же транзакций. Обеспечение такого механизма является основной функ-

цией управления транзакциями. Система, в которой поддерживается ме-

тод сериализации транзакций, реально обеспечивает изолированность

пользователей при работе с БД.

Основная реализационная проблема метода состоит в обеспечении

такого выполнения транзакций, при котором не слишком ограничива-

лась бы их параллельность. Простейшим решением является действи-

тельно их последовательное выполнение, но существуют ситуации, ко-

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

это не приведет к проблемным ситуациям. Примерами могут служить

транзакции, выполняющие только операции чтения, или транзакции, ра-

ботающие с разными объектами базы данных.

На самом деле между транзакциями могут существовать следую-

щие виды конфликтов:

− Транзакция 2 пытается изменять объект, измененный не закон-

чившейся Транзакцией 1 (W-W – конфликт);

− Транзакция 2 пытается изменять объект, прочитанный не за-

кончившейся Транзакцией 1 (R-W – конфликт);

− Транзакция 2 пытается читать объект, измененный не закон-

чившейся Транзакцией 1 (W-R – конфликт).

Практические методы сериализации транзакций основываются на

учете этих конфликтов.

9.5. Захват и освобождение объекта

Для обеспечения сериализации транзакций применяются методы

«захвата» и «освобождения» объектов, производимого по инициативе

транзакции: транзакция «захватывает» объект, что приводит к его бло-

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

вершении. При этом захваты объектов несколькими транзакциями на

чтение совместимы (т.е. нескольким транзакциям разрешается читать

один и тот же объект), захват объекта одной транзакцией на чтение не

совместим с захватом другой транзакцией того же объекта на запись, и

захваты одного объекта разными транзакциями на запись не совмести-

мы. Тем самым, выделяются два основных режима захватов:

265

− совместный режим - S (Shared), означающий разделяемый за-

хват объекта и необходимый для выполнения операции чтения объекта;

− монопольный режим - X (eXclusive), означающий монопольный

захват объекта и необходимый для выполнения операций записи, удале-

ния и модификации.

Наиболее распространенным в СУБД, основанных на архитектуре

«клиент-сервер», является подход, реализующий соблюдение двухфаз-

ного протокола захватов объектов БД. В общих чертах протокол состоит

в том, что перед выполнением любой операции над объектом базы дан-

ных от имени транзакции запрашивается захват объекта в соответст-

вующем режиме (в зависимости от вида операции – совместном или мо-

нопольном). В соответствии с этим протоколом выполнение транзакции

разбивается на две фазы: первая фаза транзакции - накопление захватов;

вторая фаза (фиксация или откат) - освобождение захватов.

При соблюдении двухфазного протокола основная проблема со-

стоит в том, что следует считать объектом для захвата?

В контексте реляционных баз данных возможны следующие вари-

анты:

− файл - физический (с точки зрения базы данных) объект, об-

ласть хранения нескольких отношений и, возможно, индексов;

− таблица - логический объект, соответствующий множеству за-

писей данного отношения;

− страница данных - физический объект, хранящий записи одного

или нескольких отношений, индексную или служебную информацию;

− запись - элементарный физический объект базы данных.

Очевидно, что чем крупнее объект захвата, тем меньше захватов

будет поддерживаться в системе, и на это, соответственно, будут тра-

титься меньшие накладные расходы. Более того, если выбрать в качестве

уровня объектов для захватов файл или отношение, то будет решена да-

же проблема строк-призраков. Однако, при использовании для захватов

крупных объектов возрастает вероятность конфликтов транзакций и тем

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

Фактически, при укрупнении объекта синхронизационного захвата мы

умышленно огрубляем ситуацию и видим конфликты в тех ситуациях,

когда на самом деле конфликтов нет.

Таким образом, можно резюмировать, что транзакция – это закон-

ченный блок обращений к базе данных и некоторых действий над ней,

для которого гарантируется выполнение четырех условий, так называе-

мых свойств ACID (Atomicity, Consistency, Isolation, Durability).

− Атомарность – операции транзакции образуют неразделимый

атомарный блок с определенным началом и концом. Этот блок либо вы-

266

полняется от начала до конца, либо не выполняется вообще. Если в про-

цессе выполнения транзакции произошел сбой, происходит откат к ис-

ходному состоянию.

− Согласованность – по завершении транзакции все задейство-

ванные объекты находятся в согласованном состоянии.

− Изолированность – одновременный доступ транзакций различ-

ных приложений к разделяемым объектам координируется таким обра-

зом, чтобы эти транзакции не влияли друг на друга.

− Долговременность – все изменения данных, осуществленные в

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

Контрольные вопросы

1. Дайте определение транзакции

2. Охарактеризуйте модели автоматического и управляемого вы-

полнения транзакций.

3. Назовите виды конфликтов при параллельном выполнении

транзакций.

4. Что такое сериализация транзакций?

5. Охарактеризуйте методы «захвата» и «освобождения» объектов.

6. Назовите основные режимы «захвата» объектов.

7. Что такое журнал транзакций?

8. Перечислите основные сервисные программные средства вос-

становления базы данных в составе СУБД.

267

Глава 10. Управление базами данных в СУБД

Для обеспечения эффективного контролируемого управления дос-

тупом к данным, целостности и сокращения избыточности хранимых

данных большинство СУБД должны быть тесно связаны с операционной

системой: многопользовательские приложения, обработка распределен-

ных запросов, защита данных, использование многопроцессорных сис-

тем и мультипоточных технологий требуют использовать ресурсы,

управление которыми обычно является функцией ОС. Соответственно,

средства управления доступом и обеспечения защиты также обычно ин-

тегрируются с соответствующими средствами операционной системы.

Напомним, что с точки зрения операционной системы база данных

– это один или несколько обычных файлов ОС, доступ к данным кото-

рых осуществляется не напрямую, а через СУБД. При этом данные

обычно располагаются на машине-сервере, а СУБД обеспечивает кор-

ректную и эффективную их обработку из приложений, выполняющихся

на машинах-клиентах.

С другой стороны, в рамках СУБД, база данных – это логически

структурированный набор объектов, связанных не только с хранением и

обработкой прикладных данных, но и обеспечивающих целостность БД,

управление доступом, представление данных и т.д. Например, в MS SQL

Server база данных включает следующие объекты:

- таблицы;

- хранимые процедуры;

- триггеры;

- представления;

- правила;

- пользовательские типы данных;

- индексы;

- пользователи;

- роли;

- публикации;

- диаграммы.

Кроме того, при создании базы данных для нее всегда определяет-

ся журнал транзакций, который используется для восстановления со-

стояния базы данных в случае сбоев или потери данных. Журнал разме-

щается в одном или нескольких файлах. В журнале регистрируются все

транзакции и все изменения, произведенные в их рамках. Транзакция не

считается завершенной, пока соответствующая запись не будет внесена

в журнал.

Управление системой баз данных производится обычно с помо-

щью нескольких сервисных программ – отдельных приложений, выпол-

няемых в среде операционной системы. Рассмотрим основные функции

268

и компоненты управления на примере сервера реляционных баз данных

MS SQL Server.

Большая часть функций администрирования

работы пользовате-

лей, серверов и баз данных сосредоточена в приложении SQL Server En-

terprise Manager, которое позволяет осуществлять, в том числе, следую-

щие функции:

- запускать и конфигурировать SQL Server;

- управлять доступом пользователей к объектам БД;

- создавать и модифицировать базы данных и их объекты, такие,

как таблицы, индексы, представления и т.д.

- управлять выполнением заданий «по расписанию»;

- управлять репликациями;

- создавать резервные копии баз данных и журналов транзакций.

10.1. Планирование БД

Использование концепции файлов и файловых групп для физиче-

ского размещения хранимых данных упрощает управление базами дан-

ных и дисковой памятью, а также обеспечивает гибкость при размеще-

нии конкретных объектов на устройстве или устройствах. Причем в этом

случае обеспечивается реальное распределение данных между всеми

входящими в группу файлами (отдельными дисковыми устройствами

или RAID-массивами): дисковые устройства действительно одновре-

менно, а не поочередно будут заполняться поступающими данными, по-

скольку данные будут пропорционально «чередоваться» по файлам

группы (рис. 10.1).

data1.mdf

data2.mdf

Рис. 10.1. Чередование данных в файловой группе

Большинство функций администрирования, таких как создание, удаление или редактирование объ-

ектов БД в SQL Server можно проводить тремя способами: при помощи специализированных диало-

говых «мастеров», средствами Enterprise Manager или командами языка T-SQL (надмножество языка

SQL-92, включающее дополнительные функции, операторы условия и цикла, хранимые процедуры и

т.д.), выполняемым из приложения или, например, из утилиты Query Analizer.

Таблица

269

Для повышения производительности системы в ряде случаев мо-

жет использоваться индекс - отдельная физическая структура в базе

данных, создаваемая на основе таблицы и предназначенная для ускоре-

ния выборки данных, поиск которых осуществляется по значению из

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

обеспечения уникальности строк и столбцов таблиц, упорядочения дан-

ных таблицы в отдельном файле или группе файлов для повышения ско-

рости доступа.

Однако наличие индекса замедляет такие операции с таблицей, как

вставка, обновление и удаление данных: индексы являются динамиче-

ски поддерживаемыми структурами, т.е. при вставке, удалении или об-

новлении данных информация в индексах также должна быть изменена

для отражения выполненных в таблице изменений. Для такой обработки

требуются дополнительные операции ввода-вывода.

Кластерный индекс представляет собой двоичное дерево, в кото-

ром на нулевом уровне (уровне листьев) содержатся страницы актуаль-

ных данных таблицы, а физическое расположение информации в данном

индексе логически упорядочено. Такое размещение данных позволяет

сократить время доступа к данным, но только при отборе по этому ин-

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

осуществляется только через индекс и доступ начинается всегда с корня.

Для отдельной таблицы можно построить только один кластерный

индекс.

В случае некластерных индексов страницы уровня листа содержат

не текущие данные таблицы (как в случае кластерного индекса), а указа-

тель на строку данных, включающий номер страницы данных и поряд-

ковый номер записи на станице.

Рис. 10.2. Кластерный и некластерный индексы

270

Некластерный индекс позволяет быстро получить доступ к дан-

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

Для каждой таблицы можно создавать до 249 некластерных индексов

(рис. 10.2).

10.2. Управление доступом

Система безопасности SQL Server имеет несколько уровней безо-

пасности:

- Операционная система;

- SQL Server;

- База данных;

- Объект базы данных.

С другой стороны механизм безопасности предполагает существо-

вание четырех типов пользователей:

- системный администратор, имеющий неограниченный доступ;

- владелец БД, имеющий полный доступ ко всем объектам БД;

- владелец объектов БД;

- другие пользователи, которые должны получать разрешение на

доступ к объектам БД.

Модель безопасности SQL Server включает следующие компонен-

ты:

• Тип подключения к SQL Server;

• Пользователь базы данных;

• Пользователь guest;

• Роли (roles).

10.2.1. Тип подключения к SQL Server

При подключении (и в зависимости от типа подключения) SQL

Server поддерживает два режима безопасности:

• Режим аутентификации Windows NT;

• Смешанный режим аутентификации.

Режим аутентификации Windows NT. В этом режиме использу-

ется система безопасности Windows NT и ее механизм учетных записей.

Этот режим позволяет SQL Server использовать имя пользователя и па-

роль, которые определены в Windows, и тем самым обходить процесс

подключения к SQL Server. Таким образом, пользователи, имеющие

действующую учетную запись Windows, могут подключиться к SQL

Server, не сообщая своего имени и пароля. Когда пользователь обраща-

ется к СУБД, последняя получает информацию об имени пользователя и