II. ЛИНТЕР и операционное окружение
A. Мобильность
ЛИНТЕР работает на многих программно-аппаратных платформах:
MS WINDOWS NT/2000/XP/2003 Server, MS WINDOWS 95/98, Windows CE, Embedded Linux (Zaurus), PalmOS, Linux, MCBC, FreeBSD, ИНТРОС, UNIXWare, UNIX SYSTEM V, SINIX, SUN Solaris, Digital UNIX, USIX, OS/9000, OS-9, QNX 4, QNX 6, VAX/VMS, OpenVMS, HP-UX, OC2000, Novell NetWare, MS DOS, AIX, IRIX, VXWorks.
Кроме того, уместно отослать читателя к гл. XV «Будущее системы ЛИНТЕР».
На всех платформах базовый вариант системы ЛИНТЕР работает внешне одинаково. Это первое требование мобильности – идентичность внешних интерфейсов системы на всех платформах.
Таким образом, пользователь, переходя с одной платформы на другую, оказывается в привычной для себя обстановке.
Было бы неправильно думать, что ЛИНТЕР не использует преимущества, которые дает внешним интерфейсам та или иная платформа. ЛИНТЕР их использует. Однако в базовом варианте системы применяется только тот минимум, который присутствует на всех платформах. Этим можно объяснить полную идентичность интерфейсов систем, работающих на разных машинах, в разных операционных средах.
Кроме внешнего интерфейса, ЛИНТЕР мобилен также и по программному интерфейсу. При переносе прикладной информационной системы на другую платформу не возникнет проблем, связанных с программными интерфейсами (Call-интерфейсом, LinAPI и Pci).
Следующий уровень мобильности - мобильность по данным. ЛИНТЕР лишь частично удовлетворяет этому уровню, т.к. использует особенности арифметического процессора конкретной платформы (целые и вещественные числа с плавающей точкой аппаратно зависимы), а также особенности кодировки символов.
Другие типы (числа с фиксированной точкой, дата) машинно независимы, и с ними проблем мобильности у пользователя не возникнет.
Совместимость по данным – наиболее важный момент при работе в разнородной сети. При работе в сетях СУБД ЛИНТЕР полностью обеспечивает совместимость данных с той техникой и операционной системой, которая находится на узле сети, запросившем эти данные.
B. Переменные среды окружения
При загрузке системы ядро ЛИНТЕР должно определить, где находится база, с которой хочет работать пользователь. Как дать понять системе, с какой из баз данных ядро будет работать в данный момент?
Это делается через переменные среды окружения. Такие переменные могут обозначать (содержать) имя физического устройства, путь в иерархическом дереве файловой структуры до нужного каталога, и т. п.
Переменные среды окружения - полезный элемент операционной системы, который рекомендуется использовать, чтобы делать программы менее зависимыми от физического расположения файлов.
Ядро СУБД ЛИНТЕР при загрузке сначала определяет наличие переменной среды окружения с именем - SY00
Эта переменная должна содержать путь до главных файлов базы данных, её системных таблиц.
Если специально не был указан (при помощи ключа /BASE при запуске системы) другой каталог, то ядро системы свяжется именно с той базой, главные файлы которой находятся в каталоге, обозначенном SY00.
При отсутствии в указанном SY00 каталоге соответствующих файлов, ядро сообщит об ошибочной ситуации и прекратит работу.
Если переменная с именем SY00 не определена, ядро будет считать, что база данных находится в специально указанном (при запуске системы) или в текущем каталоге.
Переменные среды во многих операционных системах могут быть локальные (известные только процессам, запущенным с конкретного терминала) и глобальные (известные всем). Программе, обращающейся за данными к СУБД, не обязательно знать, где расположены данные, что означает SY00, и т.д. Эта переменная среды окружения необходима ядру ЛИНТЕР, тестеру структур базы Testdb, а также Gendb - генератору системной базы.
При создании таблицы можно указать место, где нужно расположить файлы таблицы. Указывая конкретное место на диске (дисках) для файлов таблицы, пользователь должен понимать, что переменные среды окружения, содержащие обозначение этого места, должны быть известны ядру системы.
Эти переменные должны быть известны системе не только на этапе создания таблицы, но и при следующих запусках системы, т.к. их имена попали в каталоги базы, и при обращении к таблице поиск ее файлов будет выполняться по содержимому этих переменных.
Если пользователь не указывает место расположения файлов таблицы, ядро разместит их самостоятельно либо на устройстве SY00 (при наличии), либо в каталоге по умолчанию (для ядра).
Обратите внимание, СУБД ЛИНТЕР имеет возможности использования различных кодировок и данных в UNICODE. Поэтому в систему введена переменная - LINTER_CP
для указания кодировки (по умолчанию) клиентского приложения.
Кроме SY00, утилиты системы используют еще переменную - LINTER_BIN
указывающую путь до местоположения дистрибутивных утилит ЛИНТЕР. Кроме них в этом каталоге находятся справочные файлы. Если в системе не установлена переменная с именем LINTER_BIN, то информация для справок будет искаться в текущем каталоге.
Интерактивный интерфейс - Inl использует для редактирования текущего запроса один из редакторов операционной среды. Спецификация командной строки запуска нужного редактора должна содержаться в переменной - LINTER_EDIT
C. Файлы и файловая система
СУБД ЛИНТЕР хранит каждую таблицу в виде набора файлов и пользуется всеми возможностями, которые предоставляет файловая система операционной системы.
Так, в многопользовательских/сетевых системах доступность файлов базы данных для пользователя (минуя доступ через СУБД) отслеживается операционной системой. Поэтому для ограничения доступа к файлам базы данных нужно, чтобы запуск ядра осуществлял только один пользователь.
Еще одна возможность, которой пользуется ЛИНТЕР, - это расширяемость файлов. Эта возможность позволяет тратить меньше усилий на расчет размера файлов таблицы, реже модифицировать ее физическую структуру. Но чрезмерное увлечение этой особенностью может привести к малоэффективному использованию дискового пространства и, конечно, к уменьшению скорости.
Если пользователь имеет точное представление об объеме и характере данных прикладной системы, то лучше однажды выделить место под файл. Последний при этом окажется «более непрерывным» и, следовательно, более эффективным при работе с СУБД.
Файлы операционной системы, используются не только ядром, но и утилитами ЛИНТЕР.
Ядро ЛИНТЕР неформально использует файловый процессор операционной системы, добавляя к нему еще и свой аппарат, который более осведомлен о характере процессов ввода/вывода из файлов базы.
Ядро ведет свой пул элементов ввода/вывода и использует свои алгоритмы буферизации/блокировок наряду с тем, что делает операционная система. Сочетание алгоритмов, учитывающих особенности СУБД, и универсальных алгоритмов операционной системы дает хорошие результаты.
D. Многозадачная среда
ЛИНТЕР - открытая система, предназначенная для использования именно в многозадачных операционных средах. Поэтому алгоритмам распараллеливания обработки запросов уделялось пристальное внимание.
При этом максимально используется то распараллеливание, которое дает операционная система, и в дополнение к этому ядро СУБД проводит собственное распараллеливание обработки запросов.
Алгоритм обработки запросов ведется несколькими задачами (ядро, транслятор запросов, транслятор хранимых процедур, сортировщик (и) ответов), распараллеливанием работы которых занимается операционная система.
Ядро, как реентерабельная программа примет пришедший на обработку запрос, поставит его в ряд параллельно обрабатываемых запросов и, квантуя обработку этих запросов, будет переключаться с одного запроса на другой.
Широкие возможности по настройке ЛИНТЕР включают и настройки, позволяющие сделать конкретную многозадачную прикладную систему более эффективной.
Более того, в системе предусмотрены средства слежения за распараллеливанием, которое проводит ядро. Пользуясь ими можно точнее установить эффективные параметры настройки системы или понять, что и в какой момент мешает общему потоку запросов, поступающих от пользовательских задач.
Средства слежения позволят системному аналитику написать программу сбора статистики (профиль) работы СУБД, получить полезные рекомендации и сделать конкретные выводы для улучшения настройки ЛИНТЕР.
Обратите внимание, что параллельно могут обрабатываться не только запросы, посланные из разных задач, но также и запросы одной задачи.