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

2004 г

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

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

Содержание:

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

Среди новых возможностей ядра системы стоит отметить поддержку многоверсионности данных, внутреннее резервное сохранение баз данных ( in-kernel backup ), улучшения системы репликации и возможность получения планов исполнения запросов. Были добавлены новые типы данных, введены национальные многобайтовые кодировки. Помимо этого, велась работа по переносу СУБД на другие платформы, в частности QNX RTP (QNX 6), WinCE , O С 2000. Для более удобной работы с СУБД на PDA было разработано средство синхронизации баз данных DBSync.

В сервисных средствах ориентация была сделана на разработку межплатформенных графических утилит, функционирующих как в Win32, так и в UNIX-подобных ОС. Были разработаны первые версии утилит для администрирования СУБД, сохранения и восстановления баз данных, тестирования баз данных, миграции данных.

Большое внимание было уделено развитию различных интерфейсов и конвертеров данных. Были разработаны или получили значительные изменения драйверы DBExpress , OLE DB Provider , NATIVE ODBC for PHP, UNICODE ODBC driver .

В данной статье мы попытаемся обозначить основные черты СУБД ЛИНТЕР 6.1.

Новые RT-OC

XXI-й век не зря называют веком информационных технологий. Каждый день обрушивает на нас такое количество информации, что человек просто не в силах с ней справиться. Появление карманных компьютеров (КПК) позволило автоматизировать хранение и анализ информации, находящейся «в кармане». Эти устройства год от года становятся все более популярными.

Но если есть устройство, предназначенное для работы с данными, должно быть и программное обеспечение, облегчающее эту работу. Сегодня СУБД ЛИНТЕР уже реально функционирует под ОС Microsoft Windows CE. СУБД ЛИНТЕР для Windows CE, несмотря на жесткие требования, налагаемые аппаратурой КПК, является полноценным SQL-сервером и ни в чем не уступает системам, работающим на "больших" компьютерах.

Впрочем, присутствие СУБД ЛИНТЕР на КПК не ограничивается только Windows CE. Так же поддерживается Linux на КПК Sharp Zaurus. В ближайших планах компании РЕЛЭКС перенос СУБД ЛИНТЕР на ОС EPOC компании Symbian , устанавливаемой в таких устройствах, как "умные телефоны" ( smart phones ).

Предыдущие версии ЛИНТЕР поддерживали системы реального времени VxWorks , QNX 4 RTOS и отечественную ОС реального времени ОС 2000. ЛИНТЕР 6.1, кроме перечисленных систем, поддерживает еще и новую версию ОС QNX Neutrino RTOS v6.

СУБД ЛИНТЕР уже давно позволяла создавать многопоточные приложения для ОС Windows. В новой версии ЛИНТЕР эта возможность реализована также для Unix, Linux, Solaris, FreeBSD, QNX v6 и других систем, поддерживающих потоки POSIX. Для этого в состав дистрибутива включены специальные версии интерфейсов intlib и linapi, поддерживающие потоки POSIX.

Были разработаны новые графические утилиты для Unix-систем. В версию 6.1 включены следующие инструменты:

утилита "горячего" (без останова работы ядра СУБД) архивирования базы данных lhbx ;

утилита сохранения и восстановления базы данных (и отдельных элементов БД) в текстовом формате;

утилита тестирования базы данных;

новый графический "рабочий стол" ЛИНТЕР, ранее поставлявшийся только в составе Windows-версий.

Многоверсионность

С версии 6.1 ЛИНТЕР становится многоверсионной СУБД. Многоверсионная СУБД – это система, основанная на многоверсионной модели данных.

Основными понятиями являются: “логическая” запись – запись, видимая клиентской задаче, и “физическая” запись – единица хранения набора полей в таблице.

Структура многоверсионных таблиц

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

Эти “физические” записи собраны в односвязные списки (цепочки). Все элементы списка (версии) имеют один и тот же “логический” номер (ROWID). Клиентская задача “видит” именно эти логические номера.

В списке “физические” записи упорядочены по времени их создания. Каждый элемент имеет информацию о времени его создания и номере соединения, создавшего его. Удаление “логической” записи приводит к порождению новой версии записи, помеченной как “удаленная”.

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

Кроме того, при модификации “логической” записи цепочка сканируется на предмет наличия в ней старой версии, и если такая существует, она используется повторно. Это значит, что при условии отсутствия “длинных” транзакций цепочки записей не разрастаются безгранично. BLOB-файлы также содержат версии BLOB, принадлежащие разным версиям “логической” записи.

Иерархия каналов и конкуренция каналов

В ЛИНТЕР 6.1 реализована двухуровнев ая ие рархия каналов: соединения и принадлежащие им курсоры (подчиненные каналы).

В отличие от предыдущих версий СУБД ЛИНТЕР, в которых конкурирующей единицей считался процесс, теперь единица конкуренции – соединение.

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

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

Режимы работы каналов и их наследование

В ЛИНТЕР 6.1, в отличие от предыдущих версий, нет отдельного режима работы, называемого AUTOCOMMIT. Этот режим обладал отдельным (относительно режимов EXCLUSIVE и OPTIMISTIC) алгоритмом работы с журналом. Считалось, что режим AUTOCOMMIT – это не транзакционный режим.

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

В новой версии существует специальный модификатор режима работы канала – AUTOCOMMIT. Этот режим логически соответствует AUTOCOMMIT в предыдущих версиях СУБД ЛИНТЕР. Если канал открывается с таким модификатором, то каждый DML-запрос неявно вызывает завершение транзакции. Режим AUTOCOMMIT можно включать и отключать с помощью SQL запроса :

SET CHANNEL AUTOCOMMIT {ON|OFF};

В ЛИНТЕР 6.1 введено два режима работы канала по отношению к конфликтам с другими каналами. Это блокирующий и неблокирующий режимы работы канала. Если канал находится в блокирующем режиме работы, то конфликт с нефиксированными данными, сделанными конкурирующим соединением, приведет к приостановке канала до завершения конкурирующей транзакции.

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

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

SET CHANNEL {WAIT | NOWAIT}

где WAIT задает блокирующий, а NOWAIT – не блокирующий режим работы канала.

Замечание 1: Запросы на модификацию режимов работы каналов должны быть первыми в канале после начала транзакции (до любых DML-запросов). Если запрос на изменение режима подан после DML-запроса, он вернет ошибку НЕВЕРНАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ КОМАНД (1013).

Замечание 2: Открываемый курсор наследует текущий режим работы соединения. Смена режима работы соединения не влияет на режимы работы открытых ранее курсоров.

вперед