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

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

В начало

Особенности внутреннего резервного сохранения

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

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

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

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

На данный момент в системе задано постоянное значение одновременно открытых файлов архива. Это количество равно трем (в следующих версиях СУБД ЛИНТЕР планируется реализовать возможность задания количества одновременно открытых файлов через утилиту gendb при создании базы данных).

Примеры некоторых запросов
на запуск процесса архивации

BACKUP DATABASE ASYNC FILE ‘ File_name.lhb ' 
REWRITE COMMENT ‘ Comment_to_archive_file ';

После подачи этого запроса будет запущен процесс создания файла архива File_name.lhb (если таковой уже имелся на диске – он будет удален без предупреждения), архивный файл будет создан с комментарием « Comment_to_archive_file ». Процесс будет проходить в асинхронном режиме, т.е. пользователь сразу получит код возврата (0 – если процесс запустился), а процесс архивации будет протекать независимо от того, находится ли пользователь, запустивший процесс в соединении с базой. Желательно также запомнить возвращенное значение, соответствующее номеру запущенного процесса, для того, чтобы впоследствии можно было легко посмотреть, на какой стадии находится процесс резервного сохранения, и, если это будет необходимо, для его останова.

BACKUP DATABASE DEVICE ‘SY00'FILE ‘ not_async.lhb ' PASSWORD ‘password';

После подачи этого запроса запустится процесс архивации в файл not_async.lhb на устройстве SY00 (каталог базы данных). Если файл уже существует, будет возвращен соответствующий код возврата и процесс прекратит работу; если файл отсутствует, работа будет продолжена, и пользователь по ее окончании получит соответствующий код возврата (0 – если процесс завершился успешно). Данные в файле будут защищены введенным паролем ‘ password '.

Проблемы безопасности при резервном копировании

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

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

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

•  Это должен быть файл архива, созданный в результате резервного сохранения либо программой lhb , либо в результате внутреннего резервного сохранения.

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

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

•  Имя файла не должно содержать абсолютного пути.

•  В имени не должно присутствовать каталогов и переходов на уровень вверх на каталог (/../)

•  В качестве имени устройства должны выступать устройства, описанные в системной таблице $$$DEVICE (либо устройство SY00). Совершенно естественно, что необходимо наличие этой таблицы в базе данных.

Если указывается имя файла без имени устройства, сохранение будет происходить в каталоге, на который указывает переменная SY00.

Примеры корректных имен файлов, передаваемых в SQL-запросе:

BACKUP DATABASE DEVICE ‘SY00’ FILE 'full_database.lhb';
BACKUP DATABASE DEVICE ‘SY02’ FILE 'another one archive.lhb'; 
(имя SY02 должно присутствовать в системной таблице $$$DEVICE).
BACKUP DATABASE FILE 'small.lhb'; 
(файл будет создан в пути, на который указывает SY00).

Примеры некорректных имен файлов, передаваемых в SQL-запросе:

BACKUP DATABASE FILE 'C:\full_database.lhb';
BACKUP DATABASE FILE 'SY00/ARCHIVES/database.lhb';
BACKUP DATABASE FILE '/../db.lhb';

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

Останов процесс а( ов ) резервного сохранения,
запущенных в асинхронном режиме

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

BACKUP STOP number;

Здесь number – номер, возвращенный после успешного старта процесса архивации (по сути – RowId из таблицы $$$INKERNBACK, соответствующий запущенному процессу). Либо :

BACKUP STOP ALL [SINCE < дата - время >] [UNTIL < дата - время >];

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

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

Работа с кодовыми станицами

В версии 6.1 СУБД ЛИНТЕР была целиком пересмотрена работа с кодовыми страницами. В предыдущих версиях существовала поддержка лишь русскоязычных кодовых страниц (866, 1251, KOI8-R). В связи с распространением СУБД ЛИНТЕР, в том числе и в азиатском регионе, возникла необходимость работы с символьными строками в японской, китайской, корейской и других кодовых страницах. Хранение символьной информации в кодовых страницах, определяемых пользователем, позволило также существенно ускорить работу СУБД в целом, поскольку появилась возможность избежать трансляции данных из одних кодовых страниц в другие. По умолчанию в систему включена поддержка следующих кодовых страниц:

•  однобайтовые: 866, KOI8-R, 1251, 437, 1252, и с ISO 8859-1 по ISO 8859-16;

•  многобайтовые : 932 (Japanese Shift-JIS), 936 ( Simplifield Chinese GBK), 949 (Korean), 950 (Traditional Chinese Big5), EUC Japanese;

•  UNICODE и UTF8.

Реализация подсистемы

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

•  $$$CHARSET – таблица, предназначенная для хранения кодовых страниц. Поле IDENT содержит порядковый номер кодовой страницы, WIN_CODE – код в ОС Windows, NAME – имя, PROP – информацию о свойствах кодовой страницы, PAGE – номер страницы, в INFO собрана информация о «весе» символов кодовой страницы, о верхнем/нижнем регистре и о преобразовании в UNICODE. Эта таблица позволяет хранить как информацию об однобайтовых кодовых страницах, так и о многобайтовых . Многобайтовые кодовые страницы хранятся в виде своих составляющих – набора однобайтовых кодовых страниц и при загрузке в СУБД «собираются» в единое целое с целью получения общей таблицы трансляции в /из UNICODE.

•  $$$TRANSL – эта таблица предназначена для хранения информации о трансляции однобайтовых кодовых страниц друг в друга. Поле IDENT содержит порядковый номер трансляции, CSET_FROM – номер кодовой страницы, из которой осуществляется трансляция, CSET_TO – номер кодовой страницы, в которую осуществляется трансляция, NAM – имя трансляции, MAP – таблица трансляции, собственно, и содержащая информацию о соответствии символов. Если нет готовой таблицы трансляции, при необходимости преобразования символов из одной кодовой страницы в другую она генерируется динамически – через таблицу UNICODE-символов.

Следует отметить, что создание таблиц $$$CHARSET и $$$TRANSL осуществляется на этапе создания системного словаря с помощью SQL-запросов. Добавление и удаление записей в эти таблицы также осуществляется с помощью команд SQL: «CREATE (DROP) CHARACTER SET …;» и «CREATE (DROP) TRANSLATION …;»

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