Установка серверной части
Для установки сервера необходимо:
Выполнять установку как указано в разделе «Установка». При этом обязательно должны быть указаны следующие компоненты - Ядро ЛИНТЕР, Демонстрационная база данных и Сетевые драйверы. Остальные компоненты устанавливаются по желанию.
Псевдографический интерфейс
Утилита ldba– утилита администрирования с псевдографическим интерфейсом. С ее помощью можно создавать различные объекты БД и управлять доступом к ним, не обладая знаниями языка баз данных SQL. При этом возможность ввода SQL-запросов и их выполнения осталась.
По сравнению с inl в нее добавлены возможности просмотра данных в виде скроллируемой таблицы и экспорта/импорта информации в/из текстового формата.
Установка клиентской части
Для установки клиентской части необходимо выполнить следующее:
Выполнять установку как указано в разделе «Установка». При этом обязательно должны быть указана компонента - Сетевые драйверы. Остальные компоненты устанавливаются по желанию.
В открывшемся окне Edit database servers list следует обязательно прописать параметры сервера. При этом можно воспользоваться кнопкой «Ping» для проверки соединения.
Установка клиентской части СУБД ЛИНТЕР завершена.
Графический интерфейс
Утилиты lindesk и lindeskx – утилиты администрирования с графическим интерфейсом. С их помощью можно создавать различные объекты БД и управлять доступом к ним, не обладая знаниями языка баз данных SQL . Они предоставляют самые широкие возможности по администрированию БД.
Быстрый старт ЛИНТЕР (Windows)
Научно-производственное предприятие РЕЛЭКС, www.relex.ru
CALL-интерфейс
Это интерфейс самого нижнего уровня для С /C++. В основе всех остальных интерфейсов лежит именно Call-интерфейс. Он имеет самый маленький размер из всех описанных ниже интерфейсов. Он самый быстрый. Но он требует кропотливой работы программиста для заполнения всех необходимых данных. Также разбор ответов программист должен выполнять самостоятельно.
Call-интерфейс можно использовать и из других языков программирования, но для этого придется вызывать его функции в стиле языка C.
В дистрибутиве этот интерфейс поставляется в исходных кодах и в виде уже откомпилированной библиотеки. Это файлы inter.h , intlib.c из каталога intlib. В пользовательских программах необходимо использовать inter.h и inter325.lib для соответствующего компилятора.
Примеры работы с указанным интерфейсом расположены в каталогах samples/c и samples/call.
Для работы с данными типа DECIMALS и DATE используются специальные библиотеки decimals и tick . Они объединены в библиотеку dectic 32. lib . Заголовочные файлы находятся в каталоге intlib.
Что такое ЛИНТЕР
ЛИНТЕР – это программный продукт, предназначенный для создания и поддержки информационных систем различного назначения на основе реляционной модели хранения данных.
В состав ЛИНТЕР входят:
система управления базами данных (СУБД) – сертифицированная, многоплатформенная, масштабируемая, защищенная СУБД поддерживающая:
язык обработки баз данных SQL-92 с расширениями стандарта;
режим реального времени;
расширенную защиту данных;
процедурный язык обработки данных;
механизмы триггеров и последовательностей;
механизм транзакций и восстановления после сбоев.
средства управления БД – набор утилит, предназначенных для создания конфигурирования и администрирования БД;
средства поддержки БД – набор утилит, предназначенных для поддержки БД в процессе ее эксплуатации (тестирование структуры БД, миграция и конвертирование данных, резервное копирование и восстановление данных);
сетевые средства организации и поддержки удаленного доступа к БД;
интерфейсные средства – программные средства для разработки клиентских приложений на языках программирования:
С / С ++;
Pascal(Delphi , Kylix)
PHP;
PERL/DBI;
TCL/TK;
Python;
Java;
и др.
ODBC–драйвер для разработки клиентских приложений, совместимых с различными СУБД;
OLE DB–провайдер для разработки клиентских приложений и использованием современных средств разработки приложений;
JDBC–драйверы для поддержки доступа к БД из Internet-приложений;
средства для организации и поддержки полнотекстового (фразового) поиска в текстовых документах различных форматов (PDF, HTML, XML, ASCII и др.), аналогичные индексации и поиску документов в поисковых серверах Internet;
средства репликации (тиражирования данных);
инструментальные средства разработки приложений.
Основные сферы применения ЛИНТЕР:
информационные системы различного назначения среднего уровня (объем хранимой информации до сотен гигабайт и количество одновременно работающих пользователей до сотен);
системы реального времени;
системы с высокими требованиями к безопасности и конфиденциальности информации;
встроенные системы;
информационно-поисковые системы с расширенными средствами поиска информации.
DBExpress интерфейс
DBExpress интерфейс реализован в виде разделяемой библиотеки lindbex.dll, расположенной в каталоге bin дистрибутива. Он предназначен для использования стандартных классов в среде Delphi и С++.
Для корректного функционирования драйвера, БД должна содержать ODBC-каталог (см. описание catalog.sql в разделе ODBC-драйвер).
Для использования драйвера в программе достаточно создать стандартный объект TSQLConnection и прописать у него в свойствах LibraryName и VendorLib полный путь к драйверу lindbex.dll.
Интерактивный SQL
Утилита inl обеспечивает выполнение SQL-запросов в интерактивном режиме (запросы и команды управления передаются inl в интерактивном диалоге) и в пакетном режиме (запросы выбираются из входного файла).
Интерактивный SQL может использоваться:
для проверки (отладки) синтаксиса и семантики Sql-запросов в процессе разработки пользовательских приложений;
для получения и анализа временных характеристик обрабатываемых запросов;
для выполнения Sql-скриптов как в интерактивном режиме, так и в командных файлах операционной системы;
для форматирования и выдачи на экран (или на печать) результатов поисковых Sql-запросов.
Утилита относится к группе административных инструментов, т. к. с ее помощью можно выполнять все SQL-операторы по созданию объектов БД и по управлению доступом к ним.
Пример запуска утилиты
inl –u SYSTEM/MANAGER
SQL>create table test (I int, c char(10), vc varchar(10));
Ядро СУБД
Ядро СУБД ЛИНТЕР – это программа, исполняющаяся в фоновом режиме и обменивающаяся с клиентскими задачами информацией через механизмы межпроцессного взаимодействия посредством CALL-интерфейса.
Ядром является программа linternt.exe. Она может выполняться как сервис и как приложение ОС.
Клиентские приложения обращаются к БД через ядро системы только с помощью внутреннего (CALL) интерфейса. Все остальные программные интерфейсы (odbc, jdbc и т.д.) также используют этот интерфейс для взаимодействия с ядром СУБД.
Любое приложение, прежде чем обратиться с запросом к СУБД, должно открыть канал.
Канал СУБД ЛИНТЕР – это логическая линия обмена пользовательского приложения и ядра СУБД. Каждое приложение, пославшее запрос, принимает сообщения, адресованные именно ему.
Запросы, посланные по разным каналам, будут обрабатываться параллельно.
По одному каналу запросы могут обрабатываться только последовательно.
Язык баз данных SQL
Язык SQL ( Structured Query Language ) является языком обработки и манипулирования данными СУБД ЛИНТЕР. Он основан на стандарте ANSI / ISO SQL -92. При реализации языка в него были внесены некоторые элементы, не специфицированные в стандарте SQL -92. Это касается конструкций, относящихся к интернационализации имен объектов базы данных (БД) - таблиц, столбцов и пр., а также набора скалярных функций, введенных в СУБД ЛИНТЕР для совместимости с SQL СУБД Oracle .
В частности, в SQL СУБД ЛИНТЕР реализованы:
предложение UNION;
полный набор операций соединения JOIN;
все спецификации по описанию ограничений целостности;
для совместимости с некоторыми известными СУБД (Oracle, DB2, Informix, MicrosoftSQL Server и др.) в язык SQL введено множество встроенных функций;
конструкции по управлению контролем доступа к информации;
иерархические запросы к таблице и т.д.
Расширения стандарта включают:
конструкции для работы с BLOB-столбцами;
конструкции для работы с внешними файлами;
введены последовательности, совместимые с СУБД Oracle;
разрешено горячее тестирование таблицы, т.е. предложение TEST TABLE <имя> ;
разрешено горячее архивирование объектов БД;
разрешено использование нескольких таблиц во FROM в операциях UPDATE и DELETE, например:
DELETE FROM таблица JOIN список _ таблиц WHERE ...
UPDATE таблица JOIN список _ таблиц WHERE ...
разрешена конструкция INTO в SELECT-операторе для совместимости с некоторыми диалектами языка SQL, например:
SELECT список_выражений INTO список_параметров FROM ...
разрешена конструкция CAST NULL AS <тип> ;
разнообразные возможности ALTER TABLE по модификации структуры таблицы – от изменения имен (таблицы, её столбцов) до изменений важнейших характеристик самой таблицы и её столбцов (например, размеров, числа файлов, места их расположения, а для столбцов - длины данных, значений по умолчанию и т.д.);
конструкции для полнотекстового поиска и т.д.
JDBC–интерфейс
В дистрибутиве ЛИНТЕР поставляется 3 драйвера JDBC – JDBC спецификаций 1,2 и 3. Кроме того, поставляются классы JNDI для JDBC 2 и 3.
Для работы с ЛИНТЕР из Java-программ необходимо, во-первых, запустить jdbc-драйвер для БД, с которой нужно работать из JAVA–программы.
Для этого необходимо запустить ядро СУБД и программу linapid . По умолчанию эта программа обслуживает запросы по порту 1070. Данная программа запускается программой linadm (нажатием на иконку JDBC-listener)
Для того чтобы включить возможность доступа к ЛИНТЕР из Java– программы, необходимо включить в переменную среды CLASSPATH клиентскую часть JDBC–драйвера LinJdbc.jar (для JDBC 1), расположенную в каталоге classes дистрибутива ЛИНТЕР. Например :
CLASSPATH=%CLASSPATH%;c:/linter/classes/LinJDBC.jar
Примеры использования jdbc расположены в каталоге linter/samples/jdbc.
Для использования драйвера доступа к ЛИНТЕР в JAVA-программе необходимо задать драйвер "jdbc.LinJdbc.LinterDriver", а для подключения к серверу необходимо указывать строку соединения "jdbc:Linter:localhost:1070:local", где localhost - IP адрес машины, где запущен сервер linapid, 1070 – порт.
Для использования драйверов JDBC 2 и 3 необходимо использовать linjdbc-1.2.jar
и linjdbc-1.4.jar
Имя драйвера для них - com.relx.jdbc.LinterDriver, формат строки соединения – “jdbc:linter:linapid:<host>:<port>:<database>” – назначения полей совпадают с полями для драйвера спецификации 1.
Конвертирование данных из формата dbf
Утилита dbf2lin выполняет прямое преобразование данных из формата dbf в ЛИНТЕР .
LinAPI-прикладной интерфейс
Аналогично CALL–интерфейсу интерфейс LinAPI предназначен для использования его в программах на языках программирования C (C++). В отличие от CALL–интерфейса каждое действие с БД или ответами выполняется отдельной функцией. Разделены понятия соединения и курсора. Введено понятие statement (оператор) как некой внутренней структуры, позволяющей выполнять претранслированные запросы и хранящей в себе информацию о претранслированном запросе.
Примеры программ с использованием LinAPI интерфейса можно найти в каталоге samples/linapi.
Сама библиотека находится в каталоге intlib. Это файлы linapi.h (заголовочный) и lapi325.lib (для соответствующего компилятора).
ODBC–интерфейс
Данный интерфейс реализует спецификацию 3.51 интерфейса Microsoft ODBC.
В составе ЛИНТЕР поставляется 2 ODBC драйвера – lindbbc.dll и linodbcw.dll – соответственно, ANSI- и UNICODE-драйверы. По умолчанию они устанавливаются в системе под именами Linter 5.9 и Linter 5.9 Unicode (для версии 5.9) соответственно.
Если при попытке соединения с сервером вы получили ошибку 25024 или 2202 при обращении к функциям каталога, то БД не была подготовлена для использования ODBC интерфейса (отсутствует соответствующий словарь). Для возможности работы вы должны выполнить запросы из файла dict/catalog.sql.
Для этого лучше всего воспользоваться утилитой inl :
inl –u SYSTEM/MANAGER -f dict/catalog.sql
Останов ядра
Выполняется программой shut или программой linadm или из приложения пользователя путём подачи команды «SHUT» Call-интерфейса.
Программе shut в качестве параметров передаются имя пользователя БД и его пароль, причем пользователь должен иметь привилегии для останова СУБД (привилегии DBA).
Например ,
shut SYSTEM MANAGER
В программе linadm необходимо выбрать необходимую для останова БД, нажать правую кнопку мыши и выбрать пункт shutdown. Затем указать имя пользователя и пароль.
Параметры БД
В таблице 2 приведены количественные параметры БД ЛИНТЕР.
Таблица2 . Параметры БД ЛИНТЕР
|
Характеристика |
Значение | ||
|
Максимальное число таблиц в БД |
65535 | ||
|
Максимальное число столбцов в таблице |
250 | ||
|
Максимальное число строк в таблице |
500 млн. | ||
|
Максимальная длина записи таблицы |
4 Кбайт* | ||
|
Максимальное количество ключей в таблице |
1024 | ||
|
Максимальная длина ключа |
1024 | ||
|
Максимальное число таблиц в запросе (на одном уровне) |
32 | ||
|
Максимальная длина имени обекта БД |
66 символов | ||
|
Максимальное длина SQL -оператора |
32Кбайт |
* - до 64К в версиях 6 и выше
Perl интерфейсы
В состав СУБД ЛИНТЕР входят два интерфейса для Perl. Один из них оригинальный, второй является драйвером для стандартного средства доступа к БД DBI.
Обычно модуль интерфейса от Perl к СУБД ЛИНТЕР поставляется в дистрибутиве в готовом к использованию, откомпилированном виде. Это два файла LinPerl.dll и LinPerl.pm в каталоге intlib/perl.
Использовать этот модуль возможно двумя способами:
добавить к путям поиска библиотек каталог bin. Для этого необходимо установить соответствующее значение переменной окружения PERL5LIB, например:
PERL5LIB=%PERL5LIB%;c:/linter/intlib/perl
скопировать файлы LinPerl.dll и LinPerl.pm в один из каталогов поиска библиотек perl.
Перед использованием любых функций обращения к Linter в свою Perl-программу вы должны добавить строку:
use LinPerl;
Получить информацию о синтаксисе и наименованиях функций можно с помощью команды
perldoc LinPerl
В составе дистрибутива в каталоге samples/perl размещены примеры использования интерфейса ЛИНТЕР к Perl.
Если у Вас есть необходимость пересобрать интерфейс ЛИНТЕР к Perl, то необходимо запустить программу–конфигуратор configure. Программа определит наличие Perl и необходимых заголовочных файлов в системе. После этого надо перейти в каталог linter/perl и подать команду make.
Интерфейс DBI поставляется как в виде готового модуля, так и с возможностью пересборки. Он представляет собой файлы Linter.dll в каталоге intlib/perl и Linter.pm в каталоге intlib/perl/DBD.
В каталоге samples/dbi содержатся примеры использования.
Конфигурирование переменной PERL5LIB выполняется аналогично с первым интерфейсом, только при копировании модулей необходимо учитывать, что Linter.pm должен копироваться в каталог драйверов DBI.
PHP -интерфейс
Прежде всего, необходимо отметить, что в настоящее время существует как минимум три несовместимых по внутренним интерфейсам версии PHP. Это старая версия 3, и более поздние 4 и 5 версии. Мало того, в четвертой и пятой версии PHP любое расширение (extension) языка, а именно им является интерфейс ЛИНТЕР, должно быть пересобрано под конкретную версию сборки языка.
Модуль можно будет или встроить в расширения PHP, которые будут загружаться автоматически при запуске PHP, или пользоваться напрямую загрузкой расширения функцией dl.
На машине должен быть установлен PHP или в виде исполняемого файла или в виде модулей web-сервера Apache или IIS.
Скомпилированные интерфейсы находятся в каталоге intlib/php дистрибутива ЛИНТЕР и размещены по отдельным каталогам для различных версий.
В каталоге linter/samples/php содержатся примеры использования интерфейса PHP к ЛИНТЕР.
Полнотекстовый поиск
Понятие «полнотекстовый» (или фразовый) поиск подразумевает поиск по полному тексту или по всем текстовым полям документа (БД). Любой текстовый документ, как правило, имеет внутреннюю структуру - деление на параграфы, отступ для заголовка, для подписи, таблицы. Текстовые редакторы позволяют делать эту структуру достаточно сложной - выделять текст шрифтами и вариантами их начертания, делать списки, выравнивание и т.д. и т.п. Кроме того, различные редакторы имеют разные форматы хранения данных (.doc, .html, .rtf, .txt и др.). Некоторые документы (например, в формате .html), помимо средств визуального оформления информации, имеет разметку внутренней структуры - заголовок, тело документа, ключевые слова. Поэтому в задачу полнотекстового поиска входит понимание внутренней структуры и «расшифровка» разных форматов документов с помощью специальных средств - конверторов или фильтров.
СУБД ЛИНТЕР со средствами фразового поиска рекомендуется использовать в проектах, где основными определяющими факторами являются скорость поиска и извлечения текста по фразе в больших хранилищах информации (например, WWW-сервер). Средства фразового поиска дают возможность упростить схему хранения данных в приложении и избежать создания некоторых дополнительных таблиц.
Система фразового поиска обеспечивает:
варианты поиска слов: по началу, окончанию, подстроке, целому слову, поиск с использованием символов шаблона;
поиск по словам, набранным с ошибками (нечеткий поиск). Поддерживаются три основных типа ошибок (перестановка, пропуск, замена буквы).
Завершением транзакции управляет пользователь, однако, процедура также может зафиксировать или откатить изменения, сделанные в ее теле (и теле ее дочерних процедур) операторами COMMIT и ROLLBACK.
Для упрощения обработки ошибок в языке хранимых процедур предусмотрен механизм работы с исключительными ситуациями, в качестве которых могут рассматриваться ошибки выполнения SQL - запросов, ошибки времени исполнения (вызов несуществующей процедуры, деление на ноль и т.д.) или пользовательские исключения.
В момент возникновения исключения управление сразу автоматически передается на соответствующую ветку блока обработки исключений (EXCEPTIONS), что избавляет от необходимости «засорения» кода процедуры многочисленными условными операторами, проверяющими результат завершения каждого оператора. Процедура может обработать исключение либо завершиться и передать исключение на верхний уровень (оператор RESIGNAL).
Процедуры могут использоваться как хранимые функции, расширяющие язык SQL.
Для загрузки текста хранимой процедуры (триггера) используются:
spc – утилита с командным интерфейсом;
spman – утилита с псевдографическим интерфейсом;
lindeskx – графическая утилита администрирования;
обычный программный интерфейс подачи SQL -запросов.
Утилиты spman и lindeskx являются полноценными средами для разработки и отладки хранимых процедур и триггеров.
Они обеспечивают:
создание, просмотр, редактирование исходного кода объектов отладки;
управление постоянными точками останова (добавление, удаление, запрет, разрешение, определение/ редактирование свойств);
запуск на выполнение объекта отладки по команде пользователя или наступлению события;
различные режимы работы:
выполнение с прерыванием в точках останова;
пошаговое выполнение;
выполнение до временной точки останова;
выполнение до возврата;
выполнение с трассировкой.
задание и просмотр отладочной информации:
просмотр локальных переменных;
отслеживаемые переменные и выражения;
вычисление выражений;
просмотр стека вызовов;
ведение протокола отладки.
Процедурный язык
СУБД обладает мощным встроенным механизмом хранимых процедур и триггеров, что позволяет существенно расширить возможности языка SQL, организуя процедурную обработку данных на сервере согласно алгоритму пользователя.
По функциональной мощности хранимые процедуры СУБД ЛИНТЕР в некоторых аспектах даже превышают стандарт ANSI / ISO SQL -92/ PSM (Persistent Stored Modules), а именно:
использование оттранслированных запросов и запросов с параметрами (динамически изменяемых запросов),
управление транзакциями,
возможность работы с курсором.
Процедурный язык включает все необходимые операции с переменными и значениями каждого типа данных СУБД ЛИНТЕР, вызовы разнообразных стандартных функций (таких, как преобразование типов, работа со строчными данными и т.д.), операцию присваивания (тот факт, что присваивание является операцией, а не отдельным оператором, позволяет строить, например, такие конструкции: a := b := c := 0;).
Все операции со всеми типами данных реализуют трехзначную логику, то есть поддерживается значение NULL для любого типа данных, которое означает состояние «значение не определено».
Набор операторов позволяет закодировать алгоритмы любой сложности.
Для обработки результатов SELECT-запросов в процедурах используются курсоры (CURSOR), тип которых объявляется в соответствии со структурой ответа. Цикл работы с курсором может включать его открытие оператором OPEN (как результат запроса или выполнения другой процедуры), выборку данных оператором FETCH (в любом направлении) и закрытие (CLOSE) или, если процедура возвращает курсор, возврат (RETURN).
Процедуры могут работать со столбцами типа BLOB. Для этого используются стандартные функции чтения/записи в BLOB, которые ассоциируются с текущей строкой курсора.
Понятие «курсор» используется исключительно для выборки данных. Для выполнения любых DML и DDL запросов (запросов отличных от SELECT-запроса) используется оператор EXECUTE.
Все операции процедур по модификации данных входят в пользовательскую транзакцию.
Python интерфейс
Драйвер Python представляет собой динамически подгружаемую библиотеку, написанную полностью на языке С. Для загрузки драйвера в программу Python достаточно выполнить:
import LinPy
Компоненты поставляются отдельно по запросу пользователя.
[1] Если указанный Вами каталог не существует, то он будет создан.
Для установки в чужой каталог необходимо иметь соответствующие привилегии.
[2] Локальная сеть должна быть настроена для работы в одном из протоколов: TCP/IP, IPX/SPX или Netbios.
[3] Для загрузки текстов процедур и триггеров в БД может использоваться утилита inl. Т.к. символ ';' является признаком окончания запроса в утилите inl с одной стороны и разделителем операторов в процедурном языке (на котором пишутся тексты хранимых процедур и триггеров) с другой, то для загрузки текстов хранимых процедур (триггеров) применяется экранирование символа ';', т.е., если это разделитель операторов в процедурном языке, то после него ставится знак комментария "//".
Резервное копирование и восстановление
Утилита «горячего» архивирования lhb позволяет архивировать БД целиком или отдельные ее объекты, не останавливая работу СУБД. Утилита позволяет также выполнять инкрементное архивирование и архивирование по сценарию, что обеспечивает большую гибкость при работе программы.
Утилита lhbx выполняет точно такие же действия, но имеет графический интерфейс.
Сетевые средства
Сетевые утилиты позволяют работать с БД удаленно с других машин или, соответственно, с серверами на других машинах. Для передачи данных используется протоколы TCPIP, SPX, NetBios.
В состав сетевых утилит входит сетевой сервер dbs_wnt и сетевой клиент dbc_wnt . Сетевой сервер представляет собой программу, которая, будучи запущена на одной машине с ядром СУБД, обеспечивает доступ к указанному ядру СУБД (и, соответственно, к БД этого ядра) через сеть.
Сетевой клиент представляет собой редиректор, который переадресует запросы от клиентских задач в сеть.
Для организации работы через сеть необходимо запустить один процесс dbs_wnt на машине, где работает ядро СУБД. На клиентских машинах необходимо запускать процессы сетевых клиентов dbc_wnt . Запуск сервера осуществляется обычно программой linadm посредством указания при запуске БД check-boxа - start network listener. Запуск клиентского драйвера осуществляется из linadm нажатием на иконку Network agent.
Для конфигурации dbc_ent необходимо настроить файл конфигурации nodetab . Он может быть отредактирован в процессе установки или после из утилиты linadm путём выбора пункта «список баз»
Создание новой БД
Создание новой БД осуществляется программой linadm или программой gendb.
В программе linadm необходимо выбрать сервер и по правой кнопке – «создать БД». В появившемся многозакладочном диалоге необходимо отметить указать все необходимые параметры. Обязательным является только имя БД. Следует помнить, что для работы различных программных интерфейсов и подсистем ядра СУБД требуются словари. Их создание можно потребовать, выбрав соответствующие пункты на закладке «Словари».
В случае если БД создана без поддержки словарей, то они могут быть загружены посредством любой административной утилиты, позволяющей выполнять запросы. Файлы, содержащие словари расположены после установки в каталоге DICT.
Средства реального времени
СУБД ЛИНТЕР имеет ряд свойств, позволяющих отнести ее (с некоторыми допущениями) к системам реального времени:
возможность выполнения запросов в асинхронном режиме. Результат окончания выполнения асинхронной операции обрабатывается процедурой обработки ответа, которая запускается тогда, когда от ядра СУБД будет получен ответ.
возможность обрабатывать запросы в соответствии с установленными для них приоритетами. Более важные (приоритетные) запросы будут выполнены раньше низкоприоритетных, им будут отданы системой все возможные ресурсы и т.п.
поддержка аппарата событий, т.е. возможность приложения устанавливать особые ситуации в БД и обеспечивать реакцию на их возникновение. Например, какое-то приложение специальным SQL-запросом устанавливает событие A (допустим, это модификация данных в таблице). Другие приложения могут запросить, чтобы их оповестили о возникновении события A. По возникновению этого события, запросившие его приложения будут прерваны, включатся соответствующие процедуры обработки ответа (на запрос об оповещении). По окончании обработки события (например, после того, как получены изменённые данные), приложение продолжит работу с того места, где оно было прервано.
возможность отделения этапа трансляции запроса от этапа его выполнения, т.е. запрос можно один раз оттранслировать, а затем многократно выполнять, наполняя его каждый раз новым константным содержанием (привязка параметров). Это особенно удобно в программах сбора информации. При этом можно сочетать выполнение оттранслированного запроса и асинхронный режим его выполнения, что очень важно в системах управления технологическими процессами (например, при съёме информации с датчиков и занесения их в базу данных).
возможность слежения из приложения за состоянием использования ресурсов ядра СУБД, что позволяет написать приложение с супервизорскими функциями. Такое приложение производит слежение за процессами, происходящими в ядре СУБД ЛИНТЕР, и может решить, что обработка какого-то запроса требует слишком много ресурсов, и приостановить или прервать его обработку.
Tcl/Tk интерфейс
Интерфейс представляет собой исполняемый модуль интерпретатора Tcl со встроенным интерфейсом доступа к ЛИНТЕР под названием linsh (для Tk он называется linwish ) расположенный в каталоге bin. Они (и компоненты для их сборки) поставляются отдельно по запросу пользователя.
Тестирование БД
Утилиты testdb и testdbx производят проверку физической целостности структуры БД. Эта проверка может потребоваться, например, после отключения питания оборудования во время выполнения длинной транзакции.
Даже если СУБД не производила никаких действий, все равно рекомендуется производить проверку БД после каждого некорректного завершения работы ядра.
Рекомендуется следующая последовательность действий:
сразу же после такого завершения работы ядра создать архив БД средствами ОС;
запустить и сразу же остановить работу ядра СУБД с копией БД;
запустить testdb в режиме проверки;
в случае обнаружения ошибок утилиту testdb необходимо запустить заново в режиме исправления ошибок;
потом еще раз в режиме тестирования.
Типы данных
В таблице 1 приведены типы данных, поддерживаемые СУБД ЛИНТЕР .
Таблица 1 . Типы данных СУБД ЛИНТЕР
| Тип данных | Обозначение | Длина, байт | |||
| Строка символов фиксированной длины | CHAR | До 4000 | |||
| Строка символов переменной длины | VARCHAR | До 4000 | |||
| Строка байтов фиксированной длины | BYTE | До 4000 | |||
| Строка байтов переменной длины | VARBYTE | До 4000 | |||
| Строка UNICODE –символов фиксированной длины | N CHAR | До 2000 символов | |||
| Строка UNICODE –символов переменной длины | NVAR CHAR | До 2000 символов | |||
| Короткое целое | SMALLINT | 2 | |||
| Целое | INTEGER | 4 | |||
| Длинное целое | BIGINT | 8 | |||
| Вещественное число (плавающая точка) | REAL | 4 | |||
| Вещественное число (плавающая точка) | DOUBLE | 8 | |||
| Вещественное число (фиксированная точка) | NUMERIC | 16 | |||
| Логическое значение | BOOLEAN | 1 | |||
| Дата | DATE | 16 | |||
| BLOB-объект | BLOB | до 2 млрд. | |||
| Внешний файл | EXTFILE |
Установка
Для установки СУБД необходимо:
Установить в привод компакт-дисков CD-ROM с дистрибутивом СУБДЛИНТЕР и запустить программу инсталляции RDBMSLinterSQL.exe из каталога, содержащего дистрибутив. На экране появится окно с сообщением о том, что программа InstallShield Wizard производит распаковку файлов RDBMS Linter SQL и подготовку к запуску.
Ознакомиться с лицензионным соглашением. В случае согласия с лицензионным соглашением нажать кнопку «Да» (в противном случае установка СУБД не выполняется).
Ввести регистрационную информацию и лицензию или выбрать установку демо-версии и нажать кнопку «Далее».
Программой будет предложена папка по умолчанию для размещения файлов СУБД ЛИНТЕР. В случае согласия с предложенной папкой нажать кнопку «Далее». В случае несогласия нажать кнопку «Обзор» и в отобразившемся дереве выбрать нужную папку.
Выбрать необходимые компоненты для установки, а затем нажать кнопку «Далее» (Рис. 1):
Рис. 1. Выбор компонентов для установки
СУБД ЛИНТЕР для Microsoft Windows NT/2000 может работать в двух режимах:
как приложение ОС;
как сервис (служба) ОС;
Второй режим будет возможен только в том случае, если была установлена компонента Сервисы. Для возможности установки данной компоненты необходимо иметь права администратора системы, так как при этом создаются служебные сервисы.
Предлагается указать наименование папки, в которую будет произведена установка значков и нажать «Далее».
Выбрать действия, которые программа должна выполнить сразу после завершения процесса установки, нажать «Далее».
Начинается процесс установки СУБД ЛИНТЕР, который сопровождается выдачей на экран информации об установленных компонентах и состоянии процесса установки. В процессе установки высвечивается окно конфигурирования ODBC драйверов.
Перед окончательным завершением установки появляется окно со списком серверов данных, которые можно в этот момент добавить.
Установка локального варианта СУБД ЛИНТЕР завершена.
После установки в переменную PATH желательно (но необязательно) добавить путь к подкаталогу 'bin' дистрибутива. Это облегчит работу с консольными утилитами, а также сделает доступными динамические библиотеки.
Демонстрационная БД содержится в каталоге 'db\Demo'. Сразу после установки СУБД ЛИНТЕР настроена на работу с этой базой.
Установка клиент-серверного варианта
Установка клиент-серверного варианта выполняется в два этапа:
на сервере:
установка серверной части СУБД ЛИНТЕР на компьютере, выполняющим функции ЛИНТЕР-сервера;
настройка сетевых средств сервера.
на всех клиентских компьютерах:
установка клиентской части СУБД ЛИНТЕР;
настройка сетевых средств;
настройка файла сетевой конфигурации.
Установка лицензии
Установка лицензии выполняется инсталлятором. Пользователь должен внести регистрационную информацию, полученную с дистрибутивом в ответ на один из экранов установки. В случае, если СУБД будет использоваться для ознакомления с возможностями, необходимо отметить check-box «Demo».
Встроенный SQL ( C / C ++)
Встроенный SQL предназначен для объединения возможностей языка программирования высокого уровня С/C++ с возможностями языка баз данных SQL СУБД ЛИНТЕР. Он позволяет выполнять любой Sql-оператор из прикладной программы. Для этого Sql-операторы непосредственно встраиваются в текст программы на C/C++ в соответствии с синтаксическими правилами встроенного языка. В результате получение исполняемого кода программы распадается на следующие этапы:
Прекомпиляция с использованием прекомпилятора (препроцессора), входящего в состав СУБД ЛИНТЕР, исходного текста программы (отдельного модуля), содержащего конструкции встроенного SQL. Прекомпилятор заменяет конструкции встроенного SQL либо операторами языка С/C++, либо вызовами соответствующих функций библиотеки прекомпиляторного интерфейса. Результатом прекомпиляции является исходный текст программы, содержащей только конструкции языка C/C++.
Компилирование полученного текста программы (модуля) стандартным С/C++-компилятором, результатом чего будет объектный код программы (модуля). Если программа (модуль) не содержит конструкции встроенного SQL, то они компилируются только компилятором C/C++.
Компоновка всех объектных модулей программы совместно с библиотекой встроенного SQL (поставляемой в дистрибутиве СУБД ЛИНТЕР) и системными библиотеками. Результатом будет исполняемый код программы.
При компоновке программы используется библиотека pci.lib из каталога intlib.
Примеры программ и makefile можно посмотреть в каталоге samples/pcc.
Выгрузка данных
Для сохранения структуры и данных в текстовом формате используется программа dbstore . Причем могут сохраняться не только собственно данные, но и объекты БД (таблицы, пользователи, представления, синонимы и др.). Вы можете указать в командной строке, какой объект требует сохранения, и он будет сохранен в виде sql–файла, который впоследствии можно передать утилите inl для создания этого объекта заново. Данные таблиц сохраняются отдельно в формате lod–файлов для последующей загрузки их в БД посредством утилиты loarel .
Утилита может сохранять в виде набора файлов всю БД – включая ее таблицы, триггеры, последовательности, пользователей и т.п. При этом будут созданы shell–программы для последовательного восстановления сохраненных данных в другую БД.
Утилита migration позволяет сделать те же самые действия, но имеет графический интерфейс. Она совмещает в себе функциональные возможности dbstore и loarel .
Загрузка данных
Утилита loarel может быть использована для загрузки данных, сохраненных в lod–файлах в таблицы БД. Входной файл может быть результатом экспорта данных различных программ (например, MS Access).
Запуск ядра
Архитектура СУБД ЛИНТЕР предполагает, что одно ядро может быть запущено для одной БД. Для этого при запуске указывается путь к конкретной БД.
Запуск ядра может выполняется или из программы linadm(по правой кнопке мыши и выборе пункта Startup) или запуском «RDBMS Linter kernel» из программной группы LINTER. Путь к БД в последнем случае можно будет или задать из меню программы.
Можно запустить ядро СУБД из командной строки подав команду linternt.exe /local /base=..., где ... - путь к БД.
Автоматический запуск и завершение работы СУБД
Рассмотрим два shell-скрипта на запуск и останов СУБД. Эти программы впоследствии будут использованы в примере на автоматический запуск СУБД.
Отдельно сделаем файл настроек, в который внесем все изменяемые параметры запуска СУБД, описанные выше. Этот файл будет располагаться в каталоге /linter/bin и называться constants.
"Горячее" архивирование
Однако, при наличии развитых встроенных средств резервного копирования СУБД, останов базы для целей архивирования необходимым не является. Если воспользоваться программой lhb, то можно обеспечить "горячее" архивирование – без остановки базы данных. Рассмотрим несколько вариантов архивирования.
Первый вариант – периодическое полное архивирование базы данных. С помощью программы cron будет запускаться программа lhb и делать архивную копию базы данных в файл или на ленту.
Второй вариант – расширение первого – изредка архивируется полная база данных, и, периодически, выполняется инкрементный backup, который создает архив-продолжение полного архива.
Третий вариант – полное (или инкрементное) архивирование в режиме – wait. В этом случае данные, необходимые для архивирования попадают в архив практически одновременно с занесением в базу данных.
В принципе можно отказаться от использования программы cron и работать исключительно с помощью языка скриптов lhb. В этом режиме программа lhb должна будет запускаться в стартовой программе для СУБД.
Для автоматического запуска lhb необходимо будет добавить в конец файла startlin строки на запуск программы, в которых указать bsl-скрипт для исполнения lhb. Например:
# стартуем lhb $LINTER_BIN/lhb script -ft script.bsl -fl script.log
Инкрементное архивирование
Теперь рассмотрим вариант реализации процедуры инкрементного архивирования. В приведенном ниже примере полный архив базы данных создается 2 раза в неделю, а инкрементирование архива происходит 2 раза в день.
Для реализации этого метода написаны две shell-программы – srclhb.startinc и arclhb.inc. Первая из них отвечает за полное архивирование, а вторая за инкрементные части. В crontab необходимо добавить 2 строки
30 02 ,13 * * * /linter/bin/arclhb.inc 50 00 * * 0 ,4 / linetr/bin/arclhb.startinc
Далее приводятся тексты примеров архивирования.
Использование ЛИНТЕР в качестве встроенной СУБД.
, , ,
Научно-производственное предприятие РЕЛЭКС
С развитием информационных технологий возрастают требования, предъявляемые к прикладным системам, а, следовательно, и к инструментам разработки. Основой любой современной прикладной программы является система управления базами данных (СУБД). Именно от СУБД во многом зависят наиболее важные параметры системы, такие как скорость, надежность, отказоустойчивость и многие другие.
В принципе основные функции СУБД (хранение данных и доступ к ним) могло бы взять на себя приложение. Однако это, как правило, не выгодно, так как усложняет процесс разработки, отладки, сопровождения и пр. В общем, как ни крути, а без системы управления базами данных современному приложению просто не обойтись.
С другой стороны возникает еще одна проблема, связанная с тем, что конечному пользователю приложения абсолютно неинтересно как и с помощью чего построена система. Следовательно, перед программистом, разрабатывающим приложение, стоит задача «сокрытия» от конечного пользователя присутствия в прикладной системе достаточно больших и сложных подсистем (порой даже более сложных, чем использующие их приложения). Эту проблему можно условно разделить на несколько подзадач.
Во-первых, нежелательно загружать конечного пользователя дополнительными и совершенно ненужными ему знаниями (например, зачем бухгалтеру знать, что существует некая база данных и тем более как она устроена).
Во-вторых, не стоит заставлять его делать действия, не связанные непосредственно с функциями приложения (например, оператору по продаже железнодорожных билетов совершенно не требуется запускать процедуры проверки физических структур базы данных).
В-третьих, хочется снизить до минимума требования к обслуживающему персоналу разрабатываемой прикладной системы. То есть программа должна быть достаточно простой в администрировании, чтобы можно было обойтись как можно меньшим количеством высокооплачиваемых сотрудников, занимающихся поддержкой приложения.
Итак, можно сказать, что одним из основных критериев оценки встраиваемости открытой подсистемы, в частности СУБД, является «видимость» этой подсистемы для пользователя в конечном приложении.
Использование встроенного языка сценариев BSL
Все предыдущие варианты использовали программу crontab в качестве программы, которая запускает задачи по расписанию. Вместо этого можно использовать встроенный язык сценариев bsl программы lhb для обеспечения тех же самых возможностей работы по расписанию.
Для запуска на исполнение bsl-скрипта необходимо из стартового файла (например linstart) запустить программу lhb с параметром script.
Ниже приводится программа на языке bsl которая сохраняет базу данных при запуске и затем каждый день в 02:00. При этом предыдущие файлы переименовываются соответственно в arc1.lhb...arc4.lhb. Свежий файл имеет имя db.lhb. Если при запуске lhb задать ключ -fl FILE.LOG, то история сохранения будет накапливаться в файле FILE.LOG
используемая каждым из процессов сортировки
#################################################### #constants SY00=/linter/db #путь к базе
#путь к исполняемым файлам ЛИНТЕР LINTER_BIN=/linter/bin
#Память, используемая системой в 4к страницах POOL=1000
#Память, используемая каждым из процессов сортировки SPOOL=500
#Номер "ящика обмена" между задачами #это "ящик обмена" по умолчанию LINTER_MBX=20561 export LINTER_MBX SY00
#Порт TCP IP, который слушает сетевой сервер dbs_tcp #это сетевой порт по умолчанию PORT=1060 ####################################################
Сделаем сразу еще один файл. Он должен будет содержать имя пользователя и пароль на завершение работы с базой данных. Этот файл должен быть обязательно очень хорошо защищен с точки зрения операционной системы, то есть читать его содержимое должен только владелец.
USER="SYSTEM" PASSWORD="MANAGER"
Этот файл будет называться private_passwd.
Теперь, используя этот файл, можно сделать простые программы на запуск и останов СУБД.
Далее приводиться текст небольшой программы на запуск ЛИНТЕРа
Проверяем не запущен ли сервер
#################################################### #!/bin/sh
#Включаем файл с описанием переменных LINTER_BIN=/linter/bin . $LINTER_BIN/constants
#И файл с паролем . $LINTER_BIN/private_passwd
#NET_MBX=1458 #Любой не используемый в дальнейшем #export NET_MBX # Проверяем не запущен ли сервер $LINTER_BIN/chklinter -u $USER'/'$PASSWORD if [ $? -ne 0 ]; then echo "Linter already runnig" exit 1 fi
#Проверяем наличие каталога блокировочного файла if [ ! -d $SY00/lock ]; then mkdir $SY00/lock #создаем каталог if [ $? -ne 0 ];then echo "Error create locking directory" exit 1; fi fi
#Проверяем наличие блокировочного файла if [ -f $SY00/lock/lock ];then echo "Linter not correct shutdown" exit 1 fi
#стартуем SQL сервер $LINTER_BIN/linter /BASE=$SY00 /POOL=$POOL /SPOOL=$SPOOL
#ждем 60 сек запуска ЛИНТЕРа $LINTER_BIN/chklinter -u $USER'/'$PASSWORD -t 60 if [ $? -eq 0 ]; then echo "Error Running linter" exit 1 fi
#Создаем блокировочный файл touch $SY00/lock/lock if [ $? -ne 0 ]; then echo "Error create locking file" exit 1 fi
#Синхронизируем файловый кеш ОС с диском sync
#стартуем сетевой сервер $LINTER_BIN/dbs_tcp /P=$PORT ####################################################
В этой программе использовано несколько дополнительных программ из дистрибутива СУБД ЛИНТЕР и несколько технических приемов. Рассмотрим работу этого файла подробнее.
После включения описанных выше файлов – constants и privare_passwd, производится проверка наличия запущенной копии ядра с тем же LINTER_MBX, что и указанный в нашей программе. Это делается с помощью программы chklinter. Аргументы этой программы берутся из private_passwd. Если программа вернула код завершения 0, то ЛИНТЕР уже запущен. В противном случае – нет.
В данной shell-программе применяется механизм блокировки для предотвращения запуска базы данных в случае некорректного завершения (ниже будет приведена программа, завершающая работу СУБД, она удаляет блокировочный файл).
В конце стартового файла производится запуск сетевого драйвера для обеспечения доступа к данной базе по сети.
Теперь рассмотрим примерный файл на останов СУБД.
#################################################### #!/bin/sh # stoplin #Включение файла с описанием настроек
LINTER_BIN=/linter/bin . $LINTER_BIN/constants
#Включение файла с описанием имени пользователя и пароля . $LINTER_BIN/private_passwd
#Проверка работы ЛИНТЕРа $LINTER_BIN/chklinter -u $USER'/'$PASSWORD if [ $? -eq 0 ]; then echo "Linter not running" exit 1 fi
#Остановка сервера echo -e $USER'\n'$PASSWORD | $LINTER_BIN/shut
#ожидаем завершения работы for i in 1 3 5 10 20 30;do $LINTER_BIN/chklinter -u $USER'/'$PASSWORD if [ $? -ne 0 ];then sleep $i else
#удаление файла блокировки rm -f $SY00/lock/lock if [ $? -ne 0 ]; then echo "Error delete locking file" exit 1 fi exit 0 fi done
echo "Error shutdown linter" exit 1 ################################################
Используя программы для старта ЛИНТЕР, можно запускать СУБД при старте прикладной системы. Здесь приводится пример для Linux дистрибутивов, совместимых с RedHat. Для этого в каталоге /etc/rc.d/init.d необходимо создать новый файл с названием, к примеру, linter примерно следующего содержания:
и всех файлов ЛИНТЕР. su
############################################### #!/bin/sh # # Auto start-stop Linter SQL server
LINTER_BIN=/linter/bin . /etc/rc.d/init.d/functions case "$1" in start) echo -n "Starting Linter SQL server: "
#Работаем из-под специального пользователя - владельца #файлов базы данных и всех файлов ЛИНТЕР. su oleg -c $LINTER_BIN/startlin
#Обязательно должно совпадать с названием программы touch /var/lock/subsys/linter.s ;; stop) echo -n "Stopping Linter SQL server: " su oleg -c $LINTER_BIN/stoplin rm -f /var/lock/subsys/linter.s ;; restart) $0 stop $0 start ;; *) echo "Usage: linter {start|stop|restart}" exit 1 esac #############################################
После этого необходимо создать ссылки на этот файл в каталогах /etc/rc.d/rcX.d, где X - уровень загрузки, причем ссылка должна начинаться с буквы K - для останова и с буквы S – для старта, потом должны следовать две цифры, определяющие порядок вызова среди остальных. Для старта целесообразно использовать большие числа (запускать ЛИНТЕР одним из последних среди прочих доменов), а для останова – маленькие (останавливать одним из первых). За двумя числами должно следовать название программы из каталога /etc/rc.d/init.d. Останов вносится обычно в уровни загрузки 0 и 6 (останов ОС и перезагрузка), а запуск в каталог уровня загрузки 3.
Принципиально важно, чтобы название, которое идет сразу за двумя цифрами, определяющими последовательность, совпадало с именем блокировочного файла в /var/lock/subsys. Если Вы изменили название стартовой программы, то обязательно измените и название блокировочного файла, иначе при попытке завершения работы системы программа останова СУБД не будет вызвана, что может привести к разрушению базы данных.
Неудачное завершение программы startlin или автоматического старта свидетельствует или о уже запущенном ядре СУБД или о некорректном завершении (без использования программы stoplin). В любом случае необходимо выяснить причину неудачного запуска и, возможно, провести мероприятия по тестированию целостности базы с использованием утилиты testdb.
В приведенном примере, в случае неуспешного запуска ЛИНТЕР (по любым причинам – даже по наличию блокировочного файла), запуск СУБД отменяется. Однако в реальной системе естественно будет необходимо попытаться восстановить базу данных в любых случаях, в которых это возможно.
Run gendb script if it
################################################## #!/bin/sh # # 1. shutdown linter kernel # 2. run testdb -r # 3. run gendb # 4. start linter kernel # 5. run inl # 6. shutdown linter kernel # 7. run testdb
#Включение файла с описанием настроек LINTER_BIN=/linter/bin . $LINTER_BIN/constants
#Включение файла с описанием имени пользователя и пароля . $LINTER_BIN/private_passwd
#NET_MBX=1458 #export NET_MBX # stop Linter $LINTER_BIN/stoplin
$LINTER_BIN/testdb -r -f /tmp/testdb.log -i 1 -p $POOL -s /tmp/idx.sql -g /tmp/gen.gdb retc=$? [ $retc -eq 0 ] && { echo -n "Database is OK" rm -f /tmp/idx.sql /tmp/gen.gdb exit 0 }
# Run gendb script if it exists [ -s /tmp/gen.gdb ] && { msg=`$LINTER_BIN/gendb /tmp/gen.gdb` #??? [ $? -ne 0 ] && { echo -n "Error running gendb : $msg" echo -n "Database recovery failed!" exit 1 } }
# Run sql script if exists [ -s /tmp/idx.sql ] && { # start linter kernel $LINTER_BIN/linter >
>
/tmp/linter.log # wait for linter startup (max 180 sec) $LINTER_BIN/chklinter -u $USER'/'$PASSWORD -t 180 [ $? -eq 0 ] && { echo -n "Can not start Linter kernel!" exit 1 } $LINTER_BIN/inl -u $USER'/'$PASSWORD -f /tmp/idx.sql [ $? -ne 0 ] && { echo -n "Error running inl" echo -n "Database recovery failed!" exit 1 } $LINTER_BIN/shut -u $USER'/'$PASSWORD $LINTER_BIN/lsyncd } $LINTER_BIN/testdb -r -f /tmp/testdb.log -i 1 -p $POOL -s /tmp/idx.sql -g /tmp/gen.gdb [ $? -eq 0 ] && { echo -n "Database successfully recovered." rm -f /tmp/idx.sql /tmp/gen.gdb exit 0 } echo -n "Database NO successfully recovered." exit 1 ######################################################
Эту программу можно вызвать в случае, если у нас обнаружен lock файл. Однако на проверку программой testdb может уйти достаточно много времени. Поэтому лучше вызывать этот файл только в случае, если ядро СУБД не запустилось.
Таким образом, с учетом всего вышесказанного файл startlin должен выглядеть следующим образом:
Проверяем наличие каталога блокировочного файла
####################################################### #!/bin/sh
#Включаем файл с описанием переменных LINTER_BIN=/linter/bin . $LINTER_BIN/constants
#И файл с паролем . $LINTER_BIN/private_passwd
#NET_MBX=1458 #Любой не используемый в дальнейшем #export NET_MBX
#Проверяем, не запущен ли сервер $LINTER_BIN/chklinter -u $USER'/'$PASSWORD if [ $? -ne 0 ]; then echo "Linter already runnig" exit 1 fi
# Проверяем наличие каталога блокировочного файла if [ ! -d $SY00/lock ]; then mkdir $SY00/lock #создаем каталог if [ $? -ne 0 ];then echo "Error create locking directory" exit 1; fi fi
#Проверяем наличие блокировочного файла if [ -f $SY00/lock/lock ];then echo "Linter not correct shutdown" fi
#стартуем SQL сервер $LINTER_BIN/linter /BASE=$SY00 /POOL=$POOL /SPOOL=$SPOOL retval=$?
#ждем 3 мин запуска ЛИНТЕРа [ $retval -eq 0 ] && $LINTER_BIN/chklinter -u $USER'/'$PASSWORD -t 180 if [ $retval -ne 0 -o $? -eq 0 ]; then $LINTER_BIN/linrecover if [ $? -ne 0 ]; then echo "Recover fail" exit 1 else $LINTER_BIN/linter /BASE=$SY00 /POOL=$POOL /SPOOL=$SPOOL fi fi
#Создаем блокировочный файл touch $SY00/lock/lock if [ $? -ne 0 ]; then echo "Error create locking file" exit 1 fi
#Синхронизируем файловый кеш ОС с диском sync
#стартуем сетевой сервер $LINTER_BIN/dbs_tcp /P=$PORT #######################################################
если запускать из crontab, то
######################################################### #!/bin/sh
DIR_ARC=/mnt/db DEVICE_ARC=/dev/hdd1 LINTER_BIN=/linter/bin . $LINTER_BIN/constants
# если запускать из crontab, то эта переменная не установлена PATH=/bin:/usr/bin:/usr/local/bin:$LINTER_BIN export PATH
#монтируем устройство архивации #(можно опустить если подмонтировано постоянно) mount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error mount $DEVICE_ARC" exit 1 fi
#проверяем наличие каталога if [ ! -d $DIR_ARC ]; then echo "Arcive directory not exist" exit 1 fi
#останавливаем СУБД stoplin
#создаем архив tar cfz $DIR_ARC/db.new $SY00/* RETVAL=$?
#запускаем СУБД startlin
#Проверяем окончание архивации if [ $RETVAL -ne 0 ]; then echo "Error create arcive" exit 1 fi
#Переименовываем более старые архивы, храним 5 последних PREV="" for i in 4 3 2 1 tgz ; do if [ "$PREV"AA = AA ]; then rm -f $DIR_ARC/db.$i else if [ -f $DIR_ARC/db.$i ]; then mv -f $DIR_ARC/db.$i $DIR_ARC/db.$PREV fi fi PREV=$i done
#переименовываем новый архив mv -f $DIR_ARC/db.new $DIR_ARC/db.tgz
#отмонтируем устройство архивирования umount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error umount $DEVICE_ARC" exit 1 fi
############################################
Далее необходимо настроить системный демон cron на запуск архивации, допустим по средам и воскресеньям в 2 часа ночи. Для этого запускаем crontab –e и добавляем следующую строку:
00 02 * * 00,03 /linter/bin/arclin
После чего, Вы вставляете магнитооптический диск в привод и уходите домой, а на следующее утро уже можете запереть свежий архив базы в сейф.
если запускать из crontab эта
########################################################## #!/bin/sh
DIR_ARC=/mnt/db DEVICE_ARC=/dev/hdd1 LINTER_BIN=/linter/bin . $LINTER_BIN/constants . $LINTER_BIN/private_passwd
# если запускать из crontab эта переменная не установлена PATH=/bin:/usr/bin:/usr/local/bin:$LINTER_BIN export PATH
#монтируем устройство архивации #(можно опустить если подмонтировано постоянно) mount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error mount $DEVICE_ARC" exit 1 fi
#проверяем наличие каталога if [ ! -d $DIR_ARC ]; then echo "Arcive directory not exist" exit 1 fi
#создаем архив lhb s -u $USER'/'$PASSWORD -f $DIR_ARC/db.new
#Проверяем окончание архивации if [ $? -ne 0 ]; then echo "Error create arcive" exit 1 fi
#Переименовываем более старые архивы, храним 5 последних PREV="" for i in 4 3 2 1 lhb ; do if [ "$PREV"AA = AA ]; then rm -f $DIR_ARC/db.$i else if [ -f $DIR_ARC/db.$i ]; then mv -f $DIR_ARC/db.$i $DIR_ARC/db.$PREV fi fi PREV=$i done
#переименовываем новый архив mv -f $DIR_ARC/db.new $DIR_ARC/db.lhb
#отмонтируем устройство архивирования umount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error umount $DEVICE_ARC" exit 1 fi ###########################################################
В итоге мы получили результат полностью эквивалентный приведенному выше примеру за исключением того, что база данных не должна останавливаться в процессе архивирования данных.
Файл arclhb.startinc
############################################################## #!/bin/sh
DIR_ARC=/mnt/db DEVICE_ARC=/dev/hdd1 LINTER_BIN=/linter/bin . $LINTER_BIN/constants . $LINTER_BIN/private_passwd
#если запускать из crontab, эта переменная не установлена PATH=/bin:/usr/bin:/usr/local/bin:$LINTER_BIN export PATH
#монтируем устройство архивации #(можно опустить, если подмонтировано постоянно) mount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error mount $DEVICE_ARC" exit 1 fi
#проверяем наличие каталога if [ ! -d $DIR_ARC ]; then echo "Arcive directory not exist" exit 1 fi
#создаем архив lhb s -u $USER'/'$PASSWORD -f $DIR_ARC/db.new -startinc
#Проверяем окончание архивации if [ $? -ne 0 ]; then echo "Error create arcive" exit 1 fi
#Переименовываем более старые архивы, храним 5 последних PREV="" for i in 4 3 2 1 lhb ; do if [ "$PREV"AA = AA ]; then rm -f $DIR_ARC/db.$i else if [ -f $DIR_ARC/db.$i ]; then mv -f $DIR_ARC/db.$i $DIR_ARC/db.$PREV fi fi PREV=$i done
#переименовываем новый архив mv -f $DIR_ARC/db.new $DIR_ARC/db.lhb
#отмонтируем устройство архивирования umount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error umount $DEVICE_ARC" exit 1 fi #############################################################
Файл arclhb.inc
############################################################# #!/bin/sh
DIR_ARC=~/mnt/db DEVICE_ARC=/dev/hdd1 LINTER_BIN=~/linter/bin . $LINTER_BIN/constants . $LINTER_BIN/private_passwd
#если запускать из crontab эта переменная не установлена PATH=/bin:/usr/bin:/usr/local/bin:$LINTER_BIN export PATH
#монтируем устройство архивации #(можно опустить если подмонтировано постоянно) mount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error mount $DEVICE_ARC" exit 1 fi
#проверяем наличие каталога if [ ! -d $DIR_ARC ]; then echo "Arcive directory not exist" exit 1 fi
#создаем архив lhb s -u $USER'/'$PASSWORD -f $DIR_ARC/db.lhb -inc
#Проверяем окончание архивации if [ $? -ne 0 ]; then echo "Error create arcive" exit 1 fi
#отмонтируем устройство архивирования umount $DEVICE_ARC if [ $? -ne 0 ]; then echo "Error umount $DEVICE_ARC" exit 1 fi
#############################################################
new name for old file
############################################################## /*--------------------------------------------------------*/ Variables: USERNAME ="SYSTEM"; /* user name */ USERPASSWORD ="MANAGER"; /* user password */ ARCDEVICE ="./"; /* for new files */ ARCFNAME =""; /* new name for old file */ CHKSUF = ".lhb"; /* suffix for checkpoint file */ NUMFILE = 1; /*--------------------------------------------------------*/
Rights: Everyday ( time = '02:00' ) { NUMFILE = 1; while ( NUMFILE < 5 ) { if ( exist ( ARCDEVICE+"arc" + TOSTR(NUMFILE) + ".lhb" ) ) { if ( NUMFILE == 1 ) delete ( ARCDEVICE+"arc" + TOSTR(NUMFILE) + ".lhb" );
else rename ( ARCDEVICE+"arc" + TOSTR(NUMFILE) + ".lhb" , ARCDEVICE+"arc" + TOSTR(NUMFILE-1) + ".lhb" );
} /* if */ NUMFILE = NUMFILE + 1; } /* while */ rename ( ARCDEVICE+"db.lhb" , ARCDEVICE+"arc" + TOSTR(NUMFILE-1) + ".lhb" );
backup ( "s -u "+USERNAME+"/"+USERPASSWORD+" -f "+ARCDEVICE+"db.lhb"+" -qc DF" );
logprint ( CTIMESTAMP() + " --- File " + "db" + CHKSUF + " created.\n" );
Exception: /* for everyday */ print ( "Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
logprint ( CTIMESTAMP() + " --- Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
stop; } /* Everyday */ /*--------------------------------------------------------*/
Special: before /* just after the start */ { NUMFILE = 1; while ( NUMFILE < 5 ) { if ( exist ( ARCDEVICE+"arc" + TOSTR(NUMFILE) + ".lhb" ) ) { if ( NUMFILE == 1 ) delete ( ARCDEVICE+"arc" + TOSTR(NUMFILE) + ".lhb" );
else rename ( ARCDEVICE+"arc" + TOSTR(NUMFILE) + ".lhb" , ARCDEVICE+"arc" + TOSTR(NUMFILE-1) + ".lhb" );
} /* if */ NUMFILE = NUMFILE + 1; } /* while */ rename ( ARCDEVICE+"db.lhb" , ARCDEVICE+"arc" + TOSTR(NUMFILE-1) + ".lhb" );
backup ( "s -u "+USERNAME+"/"+USERPASSWORD+" -f "+ARCDEVICE+"db.lhb"+" -qc DF" );
logprint ( CTIMESTAMP() + " --- File " + "db" + CHKSUF + " created.\n" );
} after /* after stop or Ctrl-C */ { print ( " --- Stop backup system" );
if ( CERROR != 0 ) logprint ( CTIMESTAMP() + " --- Error present: " + TOSTR(CERROR) );
logprint ( CTIMESTAMP() + " --- Stop backup system\n" );
} iferr /* global */ { print ( "Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
logprint ( CTIMESTAMP() + " --- Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
stop; }
/*--------------------------------------------------------*/ ###############################################################
Следующий пример включает в себя более сложную схему – с инкрементированием. Программа сохраняет базу данных при запуске, и затем каждый день в 02:00 добавляет накопленные изменения. Если при запуске lhb задать ключ -fl FILE.LOG, то история сохранения будет накапливаться в файле FILE.LOG
new name for old file
############################################################### /*--------------------------------------------------------*/ Variables: USERNAME ="SYSTEM"; /* user name */ USERPASSWORD ="MANAGER"; /* user password */ ARCDEVICE ="./"; /* for new files */ ARCFNAME =""; /* new name for old file */ CHKSUF = ".lhb"; /* suffix for checkpoint file */ /*--------------------------------------------------------*/
Rights: Everyday ( time = '15:35' ) { backup ( "s -u "+USERNAME+"/"+USERPASSWORD+" -f "+ARCDEVICE+ "db.lhb"+" -qc DF -inc" );
logprint ( CTIMESTAMP() + " --- File " + "db" + CHKSUF + " updated.\n" );
Exception: /* for everyday */ print ( "Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
logprint ( CTIMESTAMP() + " --- Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
stop; } /* Everyday */ /*--------------------------------------------------------*/
Special: before /* just after the start */ { backup ( "s -u "+USERNAME+"/"+USERPASSWORD +" -f "+ARCDEVICE+"db.lhb"+ " -qc DF -startinc" );
logprint ( CTIMESTAMP() + " --- File " + "db" + CHKSUF + " created.\n" );
} after /* after stop or Ctrl-C */ { print ( " --- Stop backup system" );
if ( CERROR != 0 ) logprint ( CTIMESTAMP() + " --- Error present: " + TOSTR(CERROR) );
logprint ( CTIMESTAMP() + " --- Stop backup system\n" );
} iferr /* global */ { print ( "Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
logprint ( CTIMESTAMP() + " --- Error=" + TOSTR(CERROR) + " , LinError=" + TOSTR(LINERROR) + " , SysError=" + TOSTR(SYSERROR) );
stop; }
/*--------------------------------------------------------*/ ###############################################################
Более полное описание языка bsl можно найти в документации на СУБД ЛИНТЕР, а описание программы cron и файла в документации на операционную систему.
Набор утилит, необходимых приложению
Как уже было сказано, первое, с чем необходимо определиться при встраивании СУ БД в свой продукт – это состав необходимых файлов ЛИНТЕР и их расположение в дереве устанавливаемого продукта. Следует отметить, что так как исполняемые и служебные файлы БД представляют собой нечто целое и отличное от комплекта программ пользователя, то логично сгруппировать их в отдельном каталоге (или каталогах). Там же рекомендуется расположить и управляющие программы на запуск, останов и управление системой.
Все программы ЛИНТЕР завершаются с кодами завершения, указывающими на причину или состояние завершения работы. Это сильно облегчает написание управляющих программ.
В составе дистрибутива ЛИНТЕР содержатся следующие необходимые для функционирования СУБД файлы: linter, sql, intsrt, tsp – файлы ядра СУБД. Они должны быть исполняемыми. Собственно это и есть минимальный комплект программ для встраивания в прикладную систему (если отсутствует необходимость в сетевом доступе). Все остальные функции управления базой данных можно реализовать на уровне прикладной программы. Естественно, в случае поставки такого минимального комплекта, необходимо поставлять уже готовую стартовую базу данных.
Запуск ядра осуществляется запуском на исполнение программы linter. Эта программа почти сразу переводит себя в состояние background и продолжает функционировать параллельно. Однако, корректный код завершения этой программы не гарантирует, что СУБД уже запущена.
Для определения состояния программы "запущено" существует вспомогательная утилита chklinter. От результата проверки зависит код завершения программы. У программы есть параметр – timeout – время ожидания запуска. Она будет ждать соответствующее время перед определением состояния "ядро не запущено".
Существует еще несколько полезных программ, которые могут реализовать различные функции управления системой. Первая из них – программа shut. Эта программа инициирует завершение работы СУБД или выдает диагностическое сообщение о причинах невозможности исполнения данной операции.
Эта программа посылает команду CALL-интерфейса SHUT ядру.
Таким образом, пользовательская программа в принципе сама может содержать это управляющее воздействие. Следует помнить, что команда shut не завершает работу ядра. Она только проверяет доступ пользователя и планирует завершение работы системы. Собственно завершение произойдет несколько позже.
Программа shut требует имя пользователя и пароль для успешной работы. Соответственно в случае, если эта программа используется в shell-программах, необходимо использовать специальные средства для хранящегося открытым текстом пароля. Ниже будут приведены некоторые рекомендации по обеспечению защищенности этой информации.
В некоторых случаях необходимо точно знать момент действительного завершения работы ядра СУБД. Для этих целей предназначена программа lsyncd. Эта программа не завершается до тех пор, пока не завершится работа ядра СУБД ЛИНТЕР.
Существует еще несколько полезных утилит, которые могут пригодиться для работы пользовательского приложения. Прежде всего – это программа архивации данных lhb, программа тестирования физической целостности базы данных - testdb, программа пакетной загрузки данных (из формата CSV) - loarel, программа исполнения операторов SQL – inl, программа сохранения базы данных в виде текстовых файлов – dbstore, программа конвертации из .dbf формата – dbf2lin. Далее мы рассмотрим эти утилиты подробнее.
Программа архивирования базы данных lhb обладает широчайшими возможностями, она может делать архивные копии, как отдельных объектов базы данных, так и всей базы целиком. Причем процесс архивации абсолютно прозрачен для пользователя прикладной системы, то есть не требует остановки работы приложения. Программа lhb может записывать создаваемый архив напрямую на ленту, в файл, на дискеты (с разбивкой по томам), на stdout (это позволяет сделать конвейер).
Программа тестирования базы данных testdb позволяет проверять и в случае физического повреждения структуры базы данных восстанавливать ее.
При этом развитый набор опций позволяет управлять сложностью (а, следовательно, и временем) проверки и дополнительными операциями по восстановлению базы данных.
Программа пакетной загрузки данных loarel позволяет загрузить данные в указанную таблицу из текстового файла. Утилита, как правило, применяется при создании первоначальной базы данных, также может использоваться при периодических массовых загрузках пользовательских данных.
Программа выполнения операторов SQL inl позволяет интерактивно или из файла исполнять один или несколько операторов SQL, получать, просматривать и выводить во внешние файлы результаты выполнения запросов. Эту утилиту удобно использовать при создании первоначальной БД или для исполнения специфических административных функций.
Программа сохранения БД в виде текстовых файлов dbstore очень удобна для получения в виде обычных текстовых файлов всего содержимого базы данных – от структуры таблиц до текстов триггеров.
Программа конвертации из .dbf формата dbf2lin используется в случаях, если необходимо импортировать данные из .dbf таблиц. С помощью интерфейса командной строки можно одной командой загрузить .dbf файл в базу данных ЛИНТЕР.
Здесь стоит сказать о еще одной весьма полезной утилите, входящей в состав СУБД ЛИНТЕР - программе генерации базы данных - gendb. Она позволяет при необходимости создать новую базу данных или изменить параметры уже существующей.
Параметры конфигурации ядра системы.
Теперь обратимся к параметрам конфигурации ядра СУБД, определяющим работу системы – расположение системных файлов БД, размер допустимой памяти для системы, параметры, позволяющие запускать несколько ядер на одной машине.
СУБД ЛИНТЕР отличается относительно малым количеством настраиваемых параметров. Собственно, практически все они были перечислены выше. Все эти величины берутся или из параметров командной строки или из переменных среды окружения процесса.
Первый параметр – путь к системным файлам базы данных. Этот параметр представляет собой значение переменной среды окружения SY00. Это абсолютный или относительный путь. Если путь относительный, то он задается относительно текущего каталога. Данный параметр может быть задан в shell-файле на запуск ядра СУБД. Например, для bash (и далее в тексте, если не указано обратное, используется именно этот shell-интерпретатор) –
export SY00=/ usr /linter/db linter
В приведенном примере одновременно переменная устанавливается и становится доступной всем запускаемым процессам. При запуске ядра СУБД, оно будет искать базу данных в каталоге /usr/linter/db. По умолчанию (если не задана переменная среды SY00) системные файлы ищутся в текущем каталоге.
Кроме передачи пути к системным файлам через переменную среды, допускается задавать это значение через параметр /base ядра.
Размер выделяемой системе оперативной памяти контролируется двумя параметрами запуска ядра СУБД.
СУБД ЛИНТЕР спроектирована так, что при работе не требует память, дополнительно к использованной в момент загрузки. Если ядру потребуется дополнительное пространство для хранения промежуточных результатов, то оно автоматически организует свою собственную "виртуальную" память, проецируемую на один из системных файлов базы данных. Подобный механизм работы с памятью обеспечивает прикладной системе гарантию отказоустойчивости ядра СУБД из-за нехватки оперативной памяти.
При запуске ядро выделяет себе часть памяти под внутренние структуры, а часть под высокоэффективный пул страниц базы данных, работающий в режиме write-back.
Размер этого пула задается параметром запуска ядра /pool.
linter /pool=1000
Память выделяется страницами по 4096 байт. В приведенном примере выделено 4 мегабайта памяти под пул страниц базы данных. Если этот параметр при запуске не указывается, то пул по умолчанию считается равным 200 страницам.
Еще одним важным параметром, влияющим на объем используемой ядром памяти является пул сортировки. В случае появления запроса на сортировку данных, СУБД сортирует данные не все сразу, а по частям, сообразуясь именно с этим параметром.
linter /spool=500
В этом примере каждый процесс сортировки будет использовать максимум 500*4096 байт памяти. Если этот параметр опускается, то по умолчанию пул сортировки считается равным половине пула страниц базы данных.
Из приведенного описания можно сделать вывод, что чем больше выделено памяти этими параметрами, тем быстрее будет работать система. На самом деле это не совсем так. Дело в том, что с ростом выделенного ядру объема памяти, уменьшается память, доступная для других приложений. Кроме того, растут накладные расходы на обслуживание "виртуальной" памяти большего объема. В любом случае, следует немного поэкспериментировать и найти оптимальный размер памяти необходимый для конкретной задачи.
Ниже приводится пример автоматического определения размера выделяемой памяти в зависимости от количества доступной
# calculate pool size freemem=`vmstat | awk '{ if(NR == 3) print $5 }'` # give 1/3 of free memory to linter poolsize=`exp $freemem / 3 / 4096` [ $poolsize -lt 2000 ] && poolsize=2000
Последним из описываемых параметров является параметр, позволяющий запустить несколько копий ядра СУБД на одной машине. Ядро СУБД общается с клиентскими задачами при помощи различных средств межзадачного обмена: IPC или Unix Domain Sockets или Posix механизмы обмена. Если Вы не планируете запускать на одной машине одновременно несколько различных баз данных, то можете пропустить дальнейшие рекомендации, касающиеся работы нескольких копий ядра СУБД на одной машине.
Периодическое получение полного архива БД
Рассмотрим несколько примеров архивирования. Первый вариант представляет собой периодическое получение полного архива. Создаем shell-программу (arclhb) для запуска программы архивирования и помещаем ее в каталог /linter/bin. В crontab прописываем строку (с помощью crontab –e):
15 05 * * * /linter/bin/arclhb
Ниже приведен те кст пр ограммы arclhb
Работа нескольких копий ядра СУБД на одной машине.
В любом случае, необходимо однозначно идентифицировать различные одновременно активные базы. Для этой цели служит переменная LINTER_MBX. Значение этой переменной – число в диапазоне от 1024 до 65000.
export LINTER_MBX=12000 linter
По умолчанию значение этого уникального идентификатора – 20561. Доступ к различным ядрам может осуществляться или через сеть, или если у клиентской задачи переменная среды имеет то же значение, что и у соответствующего ядра.
Останов ядра СУБД выполняется, как уже говорилось выше, программой shut. Эта программа имеет несколько параметров очень удобных для использования в пакетном режиме исполнения. Параметр –u задает имя пользователя и пароль, под которыми будет выполнено соединение с базой данных, и которые будут проверяться ядром СУБД на доступ. Например, для демонстрационной базы данных будет работать следующая конструкция:
shut –u SYSTEM/MANAGER
В принципе можно использовать альтернативный метод останова СУБД – посылка ядру (программе linter) сигнала SIGTERM. Только надо помнить, что двойная посылка этого сигнала приведет к немедленной деактивации программы, что при запуске системы приведет к восстановлению базы данных по журналу.
Работа СУБД ЛИНТЕР в сети
Сетевые компоненты СУБД ЛИНТЕР представляют собой 2 исполняемых файла – dbs_tcp (драйвер сервера) и dbc_tcp (драйвер клиента). Программа dbc_tcp, кроме того, использует файл настроек серверов nodetab (текстовый файл, содержащий простое описание удаленных серверов).
Одной из отличительных особенностей СУБД ЛИНТЕР является практически полная прозрачность сетевых интерфейсов. Сетевой драйвер имитирует обычный интерфейс ядра СУБД на локальной машине, при этом, позволяя работать с удаленными ядрами.
Для того чтобы разрешить сетевой доступ к некоторому активному ядру СУБД, необходимо просто запустить драйвер сервера с указанием обслуживаемого сетевого порта. Для работы с удаленной машины необходимо прописать в файле nodetab символическое наименование сервера, с которым собираются работать, его IP адрес (или DNS-имя) и сетевой порт. Затем запустить драйвер сетевого клиента. После этих процедур Вы сможете работать через сеть с удаленным ядром СУБД.
Создание архивной копии базы данных
Кроме обязательных процедур запуска и останова ядра СУБД, важными являются так же процедуры периодического резервного копирования базы данных. Необходимость этой процедуры здесь не обсуждается, просто приводятся примеры автоматического архивирования базы данных. Использовать эту возможность или нет – решать Вам, но мы бы советовали все-таки не пренебрегать дополнительной возможностью защиты информации.
Самая тривиальная процедура – получение простого архива базы данных средствами операционной системы. Эта процедура проста, но требует остановки ядра СУБД на время архивирования данных. В приведенном ниже примере не учитывается возможность расположения базы данных в нескольких каталогах, но модифицировать эту программу будет для такого случая совсем не сложно.
Восстановление информации при сбоях
В СУБД ЛИНТЕР имеются встроенные средства для автоматического восстановления данных после некорректного завершения работы системы. В случае, если ядро СУБД запускается на базе данных, которая не была корректно закрыта, то автоматически запускается процедура восстановления по журналу транзакций. Если этой процедуре удастся полностью корректно восстановить базу данных, то ядро СУБД автоматически загрузится, как и в случае обычного запуска.
Если в процессе восстановления по журналу транзакций возникнет ошибка, то необходимо применить процедуру восстановления базы данных с помощью автономной утилиты тестирования физической целостности базы данных. Эта программа частично восстанавливает базу данных, а частично создает .gdb и .sql файлы для программ gendb и inl соответственно.
Для завершения процесса восстановления в случае, если создан файл .gdb необходимо выполнить этот файл программой gendb, затем запустить ядро и выполнить файл .sql и только после этого процедура восстановления будет завершена. В примере, приводимом ниже (файл linrecover), отражен процесс восстановления базы данных для случая, если это необходимо.
Зачем нужна встроенная СУБД
Вопрос о необходимости встраивания СУ БД в пр икладную программу достаточно спорен. Безусловно, чтобы встроить СУБД в дистрибутив приложения необходимо потратить определенное количество сил и средств. Естественно, возникает вопрос: а надо ли это? Зачем усложнять приложение? Почему бы просто не поставлять СУБД отдельно от прикладной программы? Чтобы ответить на эти вопросы, рассмотрим необходимость встраивания СУБД в конечное приложение на примере СУБД ЛИНТЕР.
ЛИНТЕР распространяется в виде дерева каталогов, содержащих исполняемые файлы системы, управляющие программы на shell-языках, данные системного словаря для создания новой БД, примеры, описания, конфигурационные программы, makefiles и т.д.
При установке системы автоматически выполняются конфигурационные программы, которые настраивают ее на конкретную среду пользователя. После этих операций СУБД готова к работе. Далее необходимо устанавливать пользовательскую систему, создавать стартовую базу данных для ее работы, настраивать права доступа к программам СУБД и пользователя и т. п.
При таком варианте инсталляции конечному пользователю будет установлено большое количество примеров и программ, которые не нужны при работе с приложением, не говоря уже о том, что сам процесс инсталляции системы будет значительно усложнен. Существует альтернативный вариант установки – необходимая часть программных модулей и управляющих программ встраивается в дистрибутив пользовательской программы, устанавливается и настраивается вместе с ним. При этом надо определиться с набором административных операций, необходимых СУ БД в пр оцессе эксплуатации пользовательской программы.
