Новое в СУБД ЛИНТЕР 6.1

Петр Лысачев, Виталий Максимов, Михаил Ермаков,
Научно-производственное предприятие РЕЛЭКС

В начало

Уровни изоляции транзакций

В ЛИНТЕР 6.1 реализовано четыре уровня изоляции транзакций: READ UNCOMMITTED(1), READ COMMITTED(2), SERIALIZABLE(3), OPTIMISTIC(4) ( оставлен для совместимости с предыдущими версиями СУБД). Следует отметить, что в отличие от предыдущих версий, выборка стабильна при любых уровнях изолированности транзакций.

READ_UNCOMMITTED
П ри работе в этом режиме транзакция видит все свои изменения и изменения, сделанные транзакциями уровней 1-3 (фиксированные и нефиксированные). Транзакция не видит нефиксированных изменений, внесенных OPTIMISTIC транзакцией. Выборка стабильна. Транзакция не может менять данные, измененные и не фиксированные другими транзакциями. При попытке сделать это запрос будет либо ждать завершения конкурирующей транзакции, либо выдаст сообщение об ошибке, говорящее, что данные были изменены (в зависимости от того, какой режим работы канала выбран – блокирующий или неблокирующий ). При попытке создать/модифицировать/удалить запись так, что происходит конфликт ссылочной целостности с нефиксированными данными, сделанными другими транзакциями, запрос будет либо ждать завершения конкурирующей транзакции, либо выдаст сообщение об ошибке, говорящее, что данные были изменены. При попытке сделать ссылку на нефиксированные данные (FK) запрос будет ждать завершения конкурирующей транзакции или завершится ошибкой.

READ_COMMITTED
Транзакция видит все свои изменения и фиксированные изменения, сделанные транзакциями уровней 1-4. Выборка стабильна. Транзакция не может изменять данные, измененные и нефиксированные другими транзакциями. При попытке сделать это, запрос будет либо ждать завершения конкурирующей транзакции, либо выдаст сообщение об ошибке, говорящее, что данные были изменены (в зависимости от того, какой режим работы канала выбран – блокирующий или неблокирующий ). При попытке создать/модифицировать/удалить запись так, что происходит конфликт ссылочной целостности с нефиксированными данными, сделанными другими транзакциями, запрос будет либо ждать завершения конкурирующей транзакции, либо выдаст сообщение об ошибке, говорящее о конфликте по ссылочной целостности.

SERIALIZABLE
Транзакция видит все свои изменения и фиксированные изменения, сделанные транзакциями уровней 1-4, которые завершились до ее старта. Выборка стабильна. Транзакция не может менять данные, измененные и не фиксированные другими транзакциями. При попытке сделать это запрос будет либо ждать завершения конкурирующей транзакции, либо выдаст сообщение об ошибке. При попытке создать/модифицировать/удалить запись так, что происходит конфликт ссылочной целостности с нефиксированными данными, сделанными другими транзакциями, запрос будет либо ждать завершения конкурирующей транзакции, либо выдаст сообщение о конфликте по ссылочной целостности. При попытке модифицировать данные, которые были модифицированы (удалены), причем эти изменения были фиксированы после ее старта, запрос завершится ошибкой НЕСЕРИЙНЫЙ ДОСТУП К ДАННЫМ (8102). Одновременно может существовать ограниченное число соединений с режимом SERIALIZABLE (100). Попытка создать большее число соединений с режимом SERIALIZABLE приведет к сообщению об ошибке "НЕТ СВОБОДНОЙ ТОЧКИ ВХОДА В ТАБЛИЦЕ СЕРИЙНЫХ ТРАНЗАКЦИЙ (8107)".

OPTIMISTIC
Э тот режим унаследован из предыдущих версий СУБД ЛИНТЕР. Транзакция видит все фиксированные изменения, сделанные транзакциями уровней 1-4. Транзакция не видит ни своих, ни чужих нефиксированных изменений. Выборка стабильна. При попытке модифицировать/удалить запись так, что происходит конфликт ссылочной целостности с данными, сделанными другими транзакциями, транзакция завершается (откатывается) с ошибкой 1600. Если при фиксации транзакции происходит ошибка, то транзакция откатывается.

Замечание 1: Проверка выполнимости условий ссылочной целостности выполняется в момент исполнения запроса, а не в момент фиксации транзакции.

Смена уровней изоляции

Уровень изоляции соединения может быть задан при его открытии (как параметр функции “OPEN” CALL интерфейса) или с помощью SQL-запроса (см. ниже), если это первый запрос в текущей транзакции. После первого же DML-запроса изменить уровень изоляции нельзя.

При попытке сделать это запрос вернет ошибку НЕВЕРНАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ КОМАНД (1013). Уровень изоляции соединения по умолчанию – READ COMMITTED с AUTOCOMMIT.

Смена уровня изоляции соединения с открытыми курсорами приведет к смене уровней изоляции всех курсоров соединения (или к ошибке 1013, если хотя бы по одному из них был подан ранее DML-запрос).

SQL-запросы, относящиеся к изоляции транзакций:

SET TRANSATION ISOLATION LEVEL
{READ UNCOMMITTED| READ COMMITTED | SERIALIZABLE | OPTIMITIC};

Индексы

На момент создания индексов работа с таблицей приостанавливается (таблица блокируется).

Индексы создаются только для самой новой версии записи. При этом запросы, стартовавшие до построения индекса, не меняют своей стратегии до их завершения.

Блокировки

Иногда возникает необходимость явного блокирования выборки (FOR UPDATE или FOR BROWSE). Блокировки в ЛИНТЕР реализованы таким образом, что если затребована блокировка “логической” записи, блокируется вся цепочка версий.

Ссылочная целостность и многоверсионность

В отличие от предыдущих версий, в СУБД ЛИНТЕР 6.1 имеется возможность установить, является ли данная запись фиксированной. В связи с этим произошли изменения в отношении проверок допустимости создания ссылок. В СУБД ЛИНТЕР 6.1:

•  не могут быть созданы ссылки на нефиксированные данные, созданные конкурирующими транзакциями других соединений;

•  могут быть созданы ссылки на нефиксированные данные, созданные той же самой транзакцией;

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

BLOB-данные

Ниже перечислены особенности работы с данными типа BLOB:

•  Добавление в BLOB.

•  Как и в предыдущих версиях СУБД ЛИНТЕР, добавление в BLOB осуществляется с помощью команд ABOJ, ABLB. Но если в предыдущих версиях вставка была “видна” конкурирующим транзакциям до фиксации транзакции, произведшей ее, то теперь вставка видна (транзакциям с режимами выше READ UNCOMMITTED) только после фиксации транзакции.

•  Очистка BLOB.

Как и в предыдущих версиях СУБД ЛИНТЕР, очистка BLOB осуществляется командами COBJ, CBLB при этом реальная очистка страниц BLOB происходит в момент фиксации транзакции. Но при наличии конкурирующей SERIALIZABLE транзакции фиксация транзакции не приводит с физической очистке страниц BLOB. Они только помечаются “к удалению”. После того, как все SERIALIZABLE транзакции, стартовавшие до операции очистки BLOB, завершатся, эти страницы могут быть переиспользованы для других BLOB.

Замечание 1: если две транзакции пытаются добавить в BLOB некоторые данные или очистить BLOB, то для одной из них такая попытка завершится ошибкой: ДАННЫЕ БЫЛИ МОДИФИЦИРОВАНЫ (ИЛИ УДАЛЕНЫ) КОНКУРИРУЮЩЕЙ ТРАНЗАКЦИЕЙ. Приостановки выполнения запроса до завершения конкурирующей транзакции не произойдет вне зависимости от текущего режима работы канала ( блокирующий / неблокирующий ).

Замечание 2: запрос на модификацию BLOB, поданный из SERIALIZABLE-транзакции, завершится ошибкой: НЕСЕРИЙНЫЙ ДОСТУП К ДАННЫМ (8102), если BLOB был модифицирован после начала этой транзакции.

Замечание 3: процесс очистки по возможности очищает страницы BLOB, помеченные “к удалению”.

Очистка версий

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

Для этого существует специальный административный SQL-запрос:

PURGE TABLE <name> [ALL];

ALL используется в том случае, когда необходимо очистить таблицу от старых записей полностью, вне зависимости от того, есть ли на данный момент активные транзакции. Очистка таблицы с ключом ALL может привести к тому, что активная SERIALIZABLE-транзакция, стартовавшая до очистки таблицы, увидит изменение в наборе данных.

На время очистки таблица блокируется. Транзакции, пытающиеся работать с этой таблицей, будут ждать завершения процесса очистки. Попытка выполнить очистку таблицы, для которой уже запущен процесс очистки, приведет к ошибке: ТАБЛИЦА УЖЕ В ОЧИСТКЕ (8114).

Модификации Call-интерфейса

Изменения касаются режимов открытия канала. Введены следующие режимы работы каналов:

•  M_READ_UNCOMMITTED – режим READ UNCOMMITTED

•  M_READ_COMMITTED – режим READ COMMITTED

•  M_SERIALIZABLE – режим SERIALIZABE.

Для совместимости с предыдущими версиями сохранен режим M_EXCLUSIVE – то же самое, что M_READ_COMMITTED.

Внутреннее резервное сохранение базы данных

Полное резервное сохранение базы данных (далее – архивация) – это физическое сохранение всей структуры и данных в файл архива.

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

В новой версии ЛИНТЕР появилась возможность внутренней архивации. В отличие от сохранения базы данных, осуществляемого при помощи утилиты lhb (Linter Hot Backup), внутренняя архивация осуществляется без участия внешних утилит, собственно ядром СУБД ЛИНТЕР.

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

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

содержание       назад       вперед