Чтение онлайн

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

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

Протоколирование

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.

Аппаратные сбои обычно подразделяются на два вида:

• мягкие сбои связаны с внезапной остановкой компьютера и обычно являются следствием внезапного выключения питания или «зависания» операционной системы;

• жесткие сбои характеризуются потерей информации на носителях внешней памяти.

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

В любом случае, для восстановления информации в базе данных необходимо иметь некоторую дополнительную информацию. Таким образом, для надежного хранения данных требуется их избыточность. Причем та часть информации, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений базы данных.

Журнал представляет собой недоступную пользователям и поддерживаемую с особой тщательностью часть базы данных, в которую поступают записи обо всех изменениях основной части базы данных. Иногда используются две копии журнала, располагаемые на разных физических дисках.

В разных СУБД изменения базы данных протоколируются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения базы данных, иногда – минимальной внутренней операции модификации страницы внешней памяти. Могут также использоваться одновременно оба подхода.

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

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

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

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

Поддержка языков баз данных

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

• язык определения схем данных (Schema Definition Language, SDL) служит главным образом для определения логической структуры базы данных;

• язык манипулирования данными (Data Manipulation Language, DML) содержит набор операторов манипулирования данными, то есть операторов, позволяющих заносить данные в базу, а также удалять, модифицировать или выбирать существующие данные.

Несколько разных специализированных языков баз данных поддерживалось лишь в ранних СУБД. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базой данных, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language – язык структурированных запросов). Таким образом, указанные выше языки баз данных на сегодняшний день фактически являются подмножествами единого стандартного языка SQL.

Язык SQL позволяет определять схему реляционной базы данных и манипулировать данными. При этом именование объектов базы данных (для реляционной базы данных – именование таблиц и их полей) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов.

Язык SQL содержит специальные средства определения ограничений целостности базы данных. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и контроль целостности базы данных производится на языковом уровне – при компиляции операторов модификации базы данных компилятор SQL на основании имеющихся в базе данных ограничений целостности генерирует соответствующий программный код.