А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
/intl
Содержит gdsintl - библиотеку, содержащую информацию о кодировках (аналогично GDSINTL.DLL под Windows)
/lib
Каталог содержит клиентские библиотеки libgs.so и libib_util.so, которые являются аналогами gds32.dll и ib_ util.dll в Windows. Также в этом каталоге находится библиотека libgs.a, которая представляет собой библиотеку для статической сборки клиента
/misc
Каталог содержит Firebird. xinetd - файл конфигурации для менеджера сервисов xinetd, в котором описаны параметры клона InterBase 6.x Firebird
/UDF
Каталог, в котором должны находиться UDF-библиотеки пользователя. По умолчанию содержит только библиотеку ib_udf
isc4 gdb
База данных пользователей InterBase
isc_config
Файл, хранящих настройки конфигурации для InterBase; аналогичен файлу ibconfig в версии InterBase под Windows
isc_eventl .teststation
Файл, который содержит список событий Используется менеджером блокировок
iscjockl. teststation
Файл, который содержит таблицу блокировок. Используется менеджером блокировок
InterBase log
Файл протокола InterBase
InterBase msg
! Файл сообщений InterBase
services, isc
Файл, который содержит информацию о соответствии номера порта имени сервиса, который будет использоваться для InterBase (обычно постановка в соответствие выглядит как gdsdb/tcp 3050). Эту постановку в соответствие необходимо добавить в файл /etc/services (обычно автоматически добавляется установщиком InterBase)
Рассмотрев икра те состав InterBase Classic Server для Linux, рассмотрим теперь более подробно состав каталога BIN в этой версии. Он отличается в основном программными модулями, специфичными для архитектуры Classic.
Каталог BIN в InterBase Classic Server для Linux
Как будет ясно из главы "Classic и SuperServer", в Classic-архитектуре состав основных исполняемых файлов InterBase меняется - к нему добавляется менеджер блокировок и различные утилиты для управления InterBase. Файлы в каталоге Вт описаны в таблице 4 20.
Табл 4.20. Файлы в каталоге Bin InterBase CS для Linux
Файл
Описание файла
changeDBAPassword.sh
Полезные скрипты на языке shell для некоторых действий:
CSchangeRunUser sh
смены пользователя SYSDBA, смены пользователя,
CSrestoreRootRunUser.sh
с правами которого запускается InterBase
gbak
Утилита резервного копирования и восстановления
gdef
Утилита, позволяющая создавать и изменять метаданные
gds_drop
Утилита, которая останавливает InterBase
gds_met_server
Основной исполняемый файл InterBase в Classic-версии InterBase
gds_lock_mgr
Менеджер блокировок
gds_lock_print
Утилита, применяющаяся для анализа таблицы блокировок
gds_pipe
Утилита, предназначенная для поддержки приложений, использующих POSIX-сигналы
gfix
Утилита модификации и восстановления базы данных
gpre
Препроцессор С для разработчиков на InterBase API
gsec
Утилита управления базой данных пользователей isc4.gdb
gsplit
Утилита для разделения/слияния одного большого файла базы данных в/из нескольких
gstat
Утилита для анализа статистики по базам данных InterBase
isc4 gbak
База данных пользователей InterBase
isql
Interactive SQL - утилита для ввода команд SQL и исполнения SQL-скриптов
qli
Query Language Interpretator - интерпретатор языка GDML
Заключение
В данной главе были рассмотрены две версии InterBase: Super под Windows и Classic под Linux, чтобы читатель получил представление о том, какой совокупностью файлов представлен InterBase. Состав файлов для InterBase обеих версий был рассмотрен на примере клона InterBase 6 - Firebird 1.0.
Classic и SuperServer
На данный момент существуют два варианта архитектуры InterBase, которые значительно отличаются друг от друга методами работы с клиентами, организацией взаимодействия собственных модулей и даже составом модулей, входящих в определению реализацию архитектуры. Условно эти две различных архитектуры назвали Classic и SuperServer. Чтобы быстро войти в курс дела, коротко рассмотрим главные особенности этих архитектур.
Архитектура Classic кратко характеризуется следующей фразой: "каждому клиенту - собственный сервер". Это означает, что на каждое клиентское соединение на компьютере-сервере запускается серверный процесс, который обслуживает одного клиента. Сколько у нас будет клиентов, установивших соединения, столько экземпляров сервера запустится для их обслуживания (имейте в виду, что одна клиентская программа может открывать сколько угодно соединений с сервером).
Архитектуру SuperServer можно по аналогии охарактеризовать как "на всех клиентов - один сервер". Это означает, что все клиентские соединения обслуживаются одним серверным процессом, где каждым конкретным клиентом занимаются отдельные потоки (threads).
Сразу следует сказать, что компания Borland уже давно, еще до опубликования исходных кодов InterBase 6, заявляла о своей решимости полностью отказаться от архитектуры Classic и перейти исключительно на SuperServer, ввиду ее многочисленных достоинств.
Тем не менее Classic жива и поныне, имеет своих многочисленных приверженцев и не собирается так просто "сдаваться". Причины этой нешуточной схватки двух подходов мы сейчас рассмотрим, и начнем, конечно же, с исторического экскурса.
Ограничим глубину погружения в историю версией InterBase 4.x. Изначально InterBase 4 имел архитектуру Classic - это были версии 4.0 и 4.1. Версия 4.2 стала первым SuperServer в ряду продуктов InterBase. Версия InterBase 5.x уже не имела реализаций архитектуры Classic под платформу Windows - только SupeiSeiver, но для Linux существует версия InterBase 5.6 с архитектурой Classic. В InterBase б сохраняется та же ситуация - под ОС семейства Unix/ Linux существуют InterBase 6 как в варианте SuperServer, так и в варианте Classic, а под Windows - только SuperServer.
Следует заметить, что деление на Classic и SuperServer не означает, что имеются два варианта исходных кодов для каждого вида архитектуры - один для Classic и другой для SuperServer (иначе со временем получились бы два разных сервера). Оба эти варианта архитектуры (и все реализации под разные ОС) производятся из общего набора исходных кодов с помощью директив Ifdef, разделяющих платформенно- и архитектурно-зависимые участки кода друг от друга. С помощью набора этих директив определяют, какой вариант и для какой платформы собирать. Естественно, для разных ОС сборка осуществляется с использованием разных библиотек ввода-вывода, управления памятью и т. д. Таким образом, начиная с версии InterBase 5.x компания Borland перестала разрабатывать вариант сервера под Windows с архитектурой Classic, в результате чего этот вариант архитектуры доступен только поклонникам Unix/Linux-систем, а версии Classic под Windows ни в вариантах реализации от Borland, ни от Firebird не существует.
В конце 2001 года появился еще один альтернативный клон InterBase 6 - СУБД Yaffil, авторами которой являются петербургские программисты Олег Иванов и Алексей Карякин. Этот вариант InterBase как раз и имеет реализацию архитектуры Classic под Windows. Подробнее о Yaffil можно узнать в приложении "Yaffil - российский клон InterBase 6.x".
Стоит ли использовать Yaffil или ставить Firebird/InterBase 6.x на Linux, чтобы ощутить прелести и оценить недостатки архитектуры Classic, - мы сейчас и попытаемся разобраться.
Classic
Рассмотрим подробнее архитектуру Classic-варианта сервера InterBase. В этой модели, как было сказано ранее, для каждого клиентского соединения запускается собственный серверный процесс, который обслуживает данного клиента. Процессом запуска управляет внешний процесс (это inetd или xinetd для Unix-систем).
Серверные процессы изолированы друг от друга. Как и любые другие процессы в ОС, они не могут свободно читать и писать друг у друга в памяти. Тем не менее работать они будут с одной базой данных, в результате чего могут возникнуть конфликты и рассогласования данных в базе данных. Представьте себе, что один серверный процесс пытается изменить страницу в базе данных, которую в данный момент изменяет другой процесс. Очевидно, что возникнет конфликт на почве распределения ресурсов. Чтобы сообщить о том, что определенные ресурсы в базе данных в данный момент используются и разрешить возникающие при "дележке" конфликты, существует специальный процесс - менеджер блокировок (gds_lock_mgr). Необходимость в менеджере блокировок возникает, когда второй клиент подсоединяется к базе. Именно в этот момент менеджер блокировок загружается в память, чтобы "следить за порядком".
Помимо разрешения конфликтов, существует дополнительная необходимость управления сервером в смысле администрирования. К сожалению, в Classic невозможно с клиента получить информацию о количестве клиентских соединений, обслуживаемых в данный момент сервером, так как для каждого клиента существует только один сервер, а информация об остальных серверных процессах, обслуживающих других клиентов, ему недоступна. Также в Classic- вариантах InterBase 6 и его клонов пока не реализовано Services API, которое позволяет управлять сервером через клиентские соединения, а не через специальные программы. Правда, надо отметить, что Yaffil Classic Server имеет реализацию Services API.
