Любицкий Ю.В. Базы данных
Подождите немного. Документ загружается.
Хранимые процедуры представляют собой программы, которые хранятся в
базе данных (обычно в ее словаре) и управляются СУБД. Одна процедура может
быть востребована несколькими клиентами.
В процессе работы клиент обращается к серверу, вызывая необходимую
процедуру. Сервер выполняет процедуру и фиксирует все возникшие при этом
изменения в базе данных, а также возвращает клиенту полученные результаты.
Такая технология существенно уменьшает объем информации, передаваемой
между клиентом и сервером.
В рассматриваемой модели сервер является активным, через механизм
триггеров (действий, выполняющихся автоматически при возникновении
определенных событий или ситуаций в БД) он может самостоятельно
инициировать обработку информации в базе данных [ 4 ].
Модель сервера баз данных применяется в СУБД MS SQL Server, Oracle,
Informix, Ingress и т. д.
Основными недостатками данной модели являются большая загрузка
сервера и зависимость хранимых процедур от СУБД, для которой они
разработаны.
Модель сервера приложений ( Application Server , AS )
Эта модель позволяет уменьшить нагрузку на сервер. В отличие от
рассмотренных двухуровневых моделей она является трехуровневой (рис. 14):
Клиент Сервер приложений Сервер БД База данных
Запуск
процедур
Результаты
выполнения
процедур
Рис. 14. Модель сервера приложений
Сервер приложений предоставляет некоторые общие услуги клиентам.
Сервер баз данных обеспечивает выполнение только непосредственных
функций СУБД: создания, ведения, хранения, поддержания целостности баз
данных и т. д.
51
Ввод и
отображение
данных
Реализация
прикладных
функций
СУБД
Достоинствами модели сервера приложений являются ее гибкость и
универсальность. Основной недостаток – высокие затраты ресурсов серверов.
В качестве примеров программ, поддерживающих работу серверов
приложений, можно привести BEA WebLogic Server, Inprise Application Server и
IBM WebSphere Application Server [ 15 ].
4.4. Управление распределенными данными
При работе с распределенными базами данных необходимо решать две
проблемы:
1) сохранения согласованности БД при одновременных изменениях
хранимых данных в нескольких узлах системы;
2) обеспечения совместного доступа нескольких пользователей к общей
информации.
Для организации распределенной базы данных могут быть использованы две
стратегии.
Фрагментация БД
В рамках этой стратегии база данных делится на фрагменты, размещаемые в
разных узлах системы. В полностью фрагментированной системе данные не
должны дублироваться (на практике реализовать это требование практически
невозможно). Сведения о месте расположения и других характеристиках
каждого фрагмента хранятся в глобальном словаре данных, который может
распределяться между несколькими узлами или содержаться только в одном из
них.
Достоинствами фрагментации БД являются экономное использование
внешней памяти (уменьшается дублирование информации) и постоянное
поддержание базы данных в актуальном состоянии. Недостаток – высокие
требования к пропускной способности и надежности каналов связи, по которым
практически непрерывно передаются команды и данные.
Репликация (тиражирование) БД
Эта стратегия допускает хранение одинаковых данных в нескольких узлах
системы. В идеальной распределенной базе данных такого дублирования
информации не должно быть, тем не менее на практике оно используется
достаточно часто для обеспечения требований производительности, доступности
и безопасности. Репликация является обоснованной, например, если одни и те
же данные регулярно используются в различных узлах.
52
Каждая копия данных обрабатывается (в том числе и изменяется)
пользователями автономно, независимо друг от друга. Идентичность копий
обеспечивается передачей сделанных изменений между узлами с помощью
компонента системы, называемого репликатором [ 15 ]. Передача изменений
выполняется асинхронно, поэтому аналогичные данные, хранящиеся в
различных узлах, некоторое время могут различаться между собой (это является
основным недостатком метода). Другой недостаток – большие затраты внешней
памяти для хранения информации.
По сравнению со стратегией фрагментации БД, репликация обеспечивает
более высокую скорость обращения пользователей к данным; уменьшение
объема информации, передаваемой по сети; меньшую зависимость качества
работы системы от используемых каналов связи.
Сведения о месте расположения и других характеристиках каждого объекта
распределенной базы данных хранятся в глобальном словаре данных
(каталоге). Хранение глобального словаря данных и управление им могут
реализовываться различными способами [ 2, 12 ]:
1. Полностью распределенный подход – в каждом узле системы содержится
часть глобального каталога, характеризующая только объекты базы данных,
хранящиеся в этом узле. Работа системы не зависит от некоторого центра
управления, при необходимости доступа из одного узла к данным, размещенным
в другом узле, требуется просмотр всех локальных каталогов, пока не будет
найдена необходимая информация.
2. Полностью реплицированный подход – полная копия глобального каталога
данных хранится в каждом узле системы. При этом ускоряется поиск нужных
данных, но при изменении объекта базы данных в одном узле требуется
обновление каталогов, хранящихся во всех узлах.
3. Централизованный подход – глобальный каталог данных хранится только
в одном узле системы. Обеспечение работы системы требует более простых
средств, чем при реализации других подходов, но качество работы системы во
многом зависит от надежности функционирования узла, в котором находится
каталог. Кроме того, этот подход предъявляет повышенные требования к
ресурсам системы.
4. Комбинированный подход – в каждом узле системы содержится локальный
каталог, включающий сведения о части базы данных, размещенной в этом узле,
в одном из узлов хранится и глобальный каталог данных. Этот подход более
53
эффективен, чем централизованный, но также требует высокой надежности
работы узла, в котором хранится глобальный каталог данных.
На практике перечисленные подходы не используются, в основном
применяется метод перманентных идентификаторов [ 2, 12 ]. Идея метода
заключается в том, что каждый объект базы данных имеет логическое имя (на
которое при работе ссылаются пользователи) и системное имя, включающее
идентификаторы узла, в котором был создан объект, и узла, в котором в данное
время хранится объект. После создания объекта его системное имя заносится в
каталоги данных всех других узлов.
В каталоге каждого узла хранятся сведения о каждом объекте, созданном или
хранимом в этом узле. Перемещения объекта базы данных между узлами
отслеживаются локальным каталогом узла, в котором был создан объект. Если
какому-нибудь узлу системы необходим этот объект, он предварительно
обращается к узлу, где объект был создан, и определяет по каталогу этого узла
новое место хранения объекта.
При совместной работе нескольких пользователей с общей информацией
могут применяться монопольный и коллективный методы доступа к
распределенным данным.
Монопольный доступ организуется с помощью полных блокировок,
реализуемых непосредственно СУБД или прикладными программами.
Монопольный доступ к данным обычно применяется при работе с
конфиденциальной информацией или при выполнении фундаментальных
преобразований БД (например, изменения ее структуры), когда требуется
полностью исключить работу с данными других пользователей [ 15 ].
В режиме коллективного доступа к данным полная блокировка не
допускается. Применяется механизм временных блокировок, ограничивающих
или запрещающих работу пользователя или приложения с объектами базы
данных, когда эти объекты используются другими пользователем или
приложением. Например, если реплицированные данные изменяются в одном
узле системы, в других узлах они блокируются. После фиксации сделанных
обновлений в узле, где они были выполнены, другие узлы пытаются изменить
свои реплицированные данные и зафиксировать полученные результаты. Данные
в исходном узле остаются заблокированными до тех пор, пока обновления не
будут зафиксированы во всех узлах. Если в одном или нескольких узлах
реализовать обновления данных не удалось, производится отмена (откат)
выполненных действий в масштабах всей системы.
54
Расширением рассмотренной технологии является метод двухфазной
фиксации транзакций (понятие транзакции будет рассмотрено в п. 5) [ 15 ].
На первом этапе регистрируются все изменения, происходящие в отдельных
узлах системы. При этом временно сохраняется возможность их отмены.
Информация о сделанных изменениях пересылается управляющему компоненту
системы, контролирующему данный процесс.
На втором этапе, после получения от всех узлов системы подтверждения о
правильности и непротиворечивости выполненных операций, управляющий
компонент системы передает всем узлам команду окончательно зафиксировать
сделанные изменения.
5. Восстановление баз данных
При работе с базой данных ее целостность может быть нарушена по ряду
причин:
1) в результате несогласованности или ошибочности действий,
выполняемых при обработке данных СУБД, прикладными программами или
пользователями;
2) при аварийном завершении работы прикладной программы;
3) в результате потери содержимого оперативной памяти компьютера
(мягкий сбой), например, при отключении питания;
4) при выходе из строя физического устройства внешней памяти, на
котором хранится база данных (жесткий сбой).
При возникновении любой из перечисленных ситуаций СУБД должна
автоматически выполнить процесс возвращения базы данных в исходное
согласованное состояние. Этот процесс называется восстановлением базы
данных и поддерживается с помощью журнала, в котором СУБД регистрирует
все действия (транзакции), выполняемые с данными.
5.1. Транзакции
Транзакцией называется последовательность элементарных операций,
выполняемых над базой данных и переводящих базу данных из одного
непротиворечивого состояния в другое. Транзакция – это логическая
единица работы с базой данных [ 2 ].
55
Рассмотрим пример транзакции. Предположим, в базе данных хранятся
сведения о наличии товаров на складах и в магазинах торговой фирмы. При
перемещении некоторого товара со склада в магазин в базе данных необходимо
выполнить несколько изменений: а) уменьшить количество единиц товара,
хранящегося на складе, на заданную величину; б) соответственно увеличить
количество единиц данного товара в магазине. Следовательно, рассматриваемая
транзакция представляет собой не отдельную операцию, реализуемую СУБД, а
скорее, согласование нескольких таких операций.
При успешном завершении транзакции полученные результаты сохраняются
во внешней памяти (фиксация транзакций).
Если во время выполнения транзакции (до ее завершения) произойдет сбой,
база данных останется в несогласованном состоянии. Это является следствием
того, что в промежуточных точках выполнения транзакции целостность базы
данных нарушается (товар со склада уже отправлен, а в магазин он еще не
поступил). Для восстановления базы данных (ее возвращения в исходное
состояние), действия, уже выполненные такими транзакциями, отменяются
(откат транзакций).
Транзакции должны обладать следующими свойствами:
1) атомарности (Atomicity) – транзакция должна выполняться полностью
или не выполняться совсем;
2) согласованности (Consistency) – транзакция переводит базу данных из
одного согласованного состояния в другое с возможным нарушением
согласованности в промежуточных точках транзакции;
3) изолированности (Isolation) – транзакции должны выполняться
автономно друг от друга, при этом изменения, вносимые в базу данных
некоторой транзакцией, до ее фиксации должны быть скрыты от других
транзакций;
4) долговечности (Durability) – после завершения и фиксации транзакции,
все изменения, вызванные этой транзакцией в базе данных, сохраняются даже
при возникновении сбоев в системе.
Транзакции, удовлетворяющие перечисленным требованиям, называют
ACID-транзакциями.
5.2. Журнал транзакций
56
Как указывалось ранее, все транзакции регистрируются СУБД в журнале
транзакций. Этот журнал недоступен пользователям, хранится во внешней
памяти (иногда в виде двух копий на разных физических носителях) и содержит
информацию обо всех изменениях базы данных, вызванных выполняемыми
транзакциями. Сведения, содержащиеся в журнале транзакций, используются
для восстановления последнего по времени согласованного состояния базы
данных после аппаратных или программных сбоев.
Процесс восстановления базы данных заключается в отмене результатов
незавершенных транзакций при сохранении в БД всех изменений, сделанных
зафиксированными транзакциями.
Необходимость выполнения индивидуального отката транзакции может
возникнуть в случаях возникновения ошибок при обработке данных, взаимной
блокировки параллельно выполняемых транзакций или при аварийном
завершении работы прикладной программы, не позволившем зафиксировать
транзакцию. В этих ситуациях журнал транзакций используется для
последовательной отмены действий (начиная с последнего из них), которые
выполнялись в рамках транзакции, откат которой производится.
При внезапной потере содержимого оперативной памяти (мягкий сбой)
поражаются все выполнявшиеся в это время транзакции, но физического
нарушения базы данных не происходит. Согласованное состояние базы данных
восстанавливается СУБД после перезагрузки операционной системы по
журналам транзакций, хранящимся во внешней памяти. Если транзакция
находилась в состоянии выполнения и не была завершена, все действия,
выполненные этой транзакцией, отменяются с помощью рассмотренной ранее
технологии индивидуального отката транзакций. В ситуации, когда транзакция
успешно завершилась, но ее результаты не были физически сохранены в базе
данных, СУБД реализует повторное выполнение этой транзакции.
При жестком сбое (произошли нарушения в работе аппаратных средств)
некоторая часть базы данных может быть разрушена физически. В этом случае
журнал транзакций не позволяет устранить все возникшие дефекты.
Предварительно необходимо восстановить базу данных по ее резервной
(архивной) копии, созданной в некоторый предшествующий момент времени, и
хранящейся на независимом надежном устройстве внешней памяти. Журнал
транзакций используется на втором этапе восстановления, когда
предпринимается попытка повторной реализации транзакций, выполнявшихся
после создания резервной копии базы данных.
57
5.3. Выполнение транзакций в многопользовательских системах
В процессе одновременной работы нескольких пользователей с одними и
теми же объектами базы данных СУБД параллельно выполняет множество
транзакций. При этом могут возникнуть следующие проблемы [ 12 ].
58
1. Проблема потери обновления.
Предположим, в базе данных хранится запись со сведениями о наличии на
складе некоторого товара (поля Название товара – Количество, шт.):
Костюм 50
Эта запись считывается двумя пользователями. У каждого из них имеется
одинаковая исходная информация, что на складе хранится 50 костюмов.
Первому пользователю необходимо отобразить в базе данных факт
поступления на склад ста костюмов. Он изменяет имеющиеся данные и
сохраняет обновленную запись в базе данных. Количество костюмов составляет
150 штук.
Второму пользователю требуется учесть информацию о передаче 20
костюмов со склада в магазин. Он изменяет имеющиеся у него данные и также
сохраняет запись.
В результате в базе данных будет храниться ошибочная информация о
наличии на складе 30 костюмов (в действительности их должно быть 130), так
как изменения, внесенные первым пользователем, утрачены.
2. Проблема зависимости от незафиксированных обновлений.
Эта проблема возникает, когда одна транзакция выполнила обновление
данных, но не зафиксировала его, а другая транзакция начинает использовать
эти данные. При отмене первой транзакции будет получен неправильный
результат.
Для иллюстрации указанной ситуации воспользуемся записью базы данных
из предыдущего примера.
С помощью первой транзакции в базе данных необходимо учесть факт
передачи со склада в магазин ста костюмов. Так как на складе нет такого
количества товаров, очевидно, что произошел сбой. Вероятно, ошибка допущена
оператором, вводившим информацию. Возможность возникновения подобной
ситуации контролируется СУБД, предусматривающей отмену транзакций,
приводящих к ошибочным результатам. Тем не менее временно, до завершения
транзакции и последующей ее отмены, количество костюмов в исходной записи
базы данных изменится и будет равно минус 50.
Выполняемая параллельно вторая транзакция учитывает поступление на
склад двухсот костюмов. В итоге общее количество костюмов на складе
составит 150 штук.
59
СУБД завершает первую транзакцию, отменяет ее и восстанавливает
исходное состояние базы данных. В результате количество костюмов на складе
равно 50. При этом утрачены сведения о поставке новой партии товаров.
3. Проблема несогласованного анализа.
Данная проблема может возникнуть, когда одна транзакция получает доступ
к множеству записей, некоторые из которых в это время обновляются другой
транзакцией.
Предположим, что в базе данных хранятся записи о наличии товаров на трех
складах торгового предприятия (поля Название склада – Количество, шт.):
Склад 1 50
Склад 2 100
Склад 3 200
Первая транзакция подсчитывает суммарное количество товаров на всех
складах предприятия, последовательно считывая из БД записи с данными.
Вторая транзакция предусматривает перемещение 100 штук товара с третьего
склада на первый. Очевидно, что эта транзакция не может изменить суммарное
количество товаров.
Допустим, что действия в рамках транзакций выполняются в следующем
порядке:
1. Первая транзакция читает первую запись. Количество товаров – 50 штук,
следовательно, их суммарное количество также пока равно 50.
2. Вторая транзакция читает третью запись. Количество товаров – 200 штук.
3. Первая транзакция читает вторую запись. Количество товаров – 100 штук,
сумма равна 150.
4. Вторая транзакция вычитает 100 штук товара из количества, указанного в
третьей записи. Обновленное значение количества товаров в третьей записи
составляет 100 штук.
5. Первая транзакция читает третью запись. Количество товаров – 100 штук,
сумма равна 250.
6. Вторая транзакция читает первую запись и добавляет к хранящемуся в ней
количеству товаров (50 штук) 100 поступивших единиц. Обновленное значение
количества товаров в первой записи составляет 150 штук.
В результате несогласованного анализа первая транзакция неправильно
вычислила суммарное количество товаров. Оно составило 250 штук при
фактическом значении 350 штук.
60