Асинхронный сервер и отмена выполняющихся запросов

В сервере Yaffil предполагается реализовать асинхронную модель сервера, при лом для передачи запросов на отмену операции будет использоваться основное соединение.

Клиентский интерфейс отмены запросов предполагается совместимым с аналогичным расширением API в версии InterBase 6.5

Безопасная работа с внешними таблицами

Файлы внешних таблиц могут располагаться ТОЛЬКО в одном из каталогов, разрешенных конфигурационным параметром EXTERNAE_FIEE_DIRECTORY. а также в их подкаталогах

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

EXTERNAL_FILE_DIRECTORY "с:\"

EXTERNAL_FILE_DIRECTORY "d:\"

Таким образом, любой файл на диске становится доступным для доступа через внешние таблицы, что соответствует прежнему, небезопасном}' поведению InterBase pre-7 и Firebird 1.0. Из-за серьезных проблем с безопасностью НЕ РЕКОМЕНДУЕТСЯ использовать такие установки.

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

Логическое имя каталога необязательно и задается вторым аргументом:

EXTERNAL_FILE_DIRECTORY "c:\databases\files" myfiles

На логическое имя можно ссылаться при задании внешней таблицы. Для этого нужно указать логическое имя каталога после символа $ в начале имени внешнего файла. Например:

CREATE TABLE customers EXTERNAL FILE "$myflies/customers.txt" ( ... );

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

CREATE TABLE customers EXTERNAL FILE

"с:/databases/files/customers.txt" (...) ;

И наконец, можно задавать файл внешней таблицы с указанием имени относительно каталога базы данных:

CREATE TABLE customers EXTERNAL FILE "files/customers.txt" ( ... );

При этом каталог, в котором находится файл, должен быть разрешен параметром EXTERN AL_FILE_DIRECTORY.

НЕ РЕКОМЕНДУЕТСЯ разрешать для размещения файлов внешних таблиц каталоги с базами данных, поскольку в этом случае пользователи получают доступ к файлам этих баз данных. Если есть желание разместить внешние таблицы рядом с базой данных, то следует создать подкаталог для внешних файлов для каждой базы данных и разрешить его в EXTERNAL_FELE_DIRECTORY. Допустим, все базы данных лежат в c:\databases, среди которых sales.gdb. Создаем каталог sales_files, разрешаем его для использования:

EXTERNAL_FILE_DIRECTORY "с:\databases\sales_files"

Безопасность внешних таблиц. Параметр EXTERNAL FILE DIRECTORY

В определенных условиях внешние таблицы (external table) могут быть источником проблем в безопасности. Известно, что в предыдущих версиях InterBase, используя механизм внешних таблиц, можно было выкрасть всю базу целиком, от первого до последнего байта!

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

Внешние таблицы должны находиться в каталоге <interbase_hoine>/ext. InterBase будет сначала искать внешние таблицы в этом каталоге.

Если внешняя таблица находится не в каталоге /ext, то путь к каталогу, где она находится, нужно указать в ibconfig при помощи параметра EXTERNAL_FELE_DIRECTORY Параметр можно указывать несколько раз для всех каталогов, где могут находиться внешние таблицы.

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

Безопасность временных таблиц

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

Большие индексы

Планируется значительно увеличить максимальный размер ключа индекса с нынешних 128-256 (в зависимости от типов данных) байт в InterBase/Firebird. Как известно, при создании индексов по текстовым полям с национальным порядком сортировки (COLLATION) на каждый символ отводится 3 байта. Тем самым реальная максимальная длина индекса в настоящее время составляет 83 символа, что недостаточно для многих приложений.

Дальнейшее развитие языка SQL

Развитие будет осуществляться по следующим направлениям:

добавление новых или расширение возможностей существующих команд DDL, в частности по работе с доменами, признаками полей таблиц, кодом процедур и триггеров;

реализация уникальных ограничений (unique constraints) с возможностью хранений NULL-значений;

расширение состава встроенных функций в соответствии с SQL-стандартом (TRIM, POSITION, ROUND и т. п.);

поддержка стандартного типа BOOLEAN (принимающего значения TRUE, FALSE или UNKNOWN) в полях, переменных и логических предикатах языка;

большее соответствие существующих команд SQL-стандарту.

Дистрибутив

Первое, на что стоит обратить внимание, это отличие в именах файлов. Исполняемый файл сервера теперь называется либо fbserver (в случае архитектуры SS). либо fb_inet_server (в случае CS). Следует отметить, что теперь сервер с классической архитектурой доступен и для пользователей платформы Win32. Клиетская библиотека носит имя fbclient. В дистрибутивы для Win32 входит также библиотека gds32.dll. которая теперь является просто "заглушкой", перенаправляющей все вызовы к fbclient.dll, и поставляется исключительно для совместимости с существующими приложениями. Все новые приложения, ориентирующиеся на использование этой и последующих версий Firebird, должны обращаться к новой клиентской библиотеке (т. е. fbclient). Стандартная библиотека языковых кодировок теперь называется fbintl. Также изменились имена некоторых других файлов.

Вариант сервера с классической архитектурой для платформы Win32 несколько отличается от аналогичных дистрибутивов для UNIX-систем. Главная особенность - это единый пакет, включающий в себя SS и CS сборки сервера, причем оба варианта скомпонованы статически. Это позволило избежать реализации кода сервера в библиотеке, разделяемой всеми процессами, и обеспечить четкое разделение клиентской и серверной подсистем. Результатом этого стала независимость стандартных инструментов командной строки (isql, gbak, gfix и т. д.) от дистрибутива сервера, а также возможность смены архитектуры установленного сервера "на лету", т. е. без переустановки дистрибутива.

Далее, версия сервера для платформы Win32 теперь использует другой ключ реестра (HKLM\Software\FirebirdSQL\Firebird). В случае отсутствия данного ключа сервер все равно будет работоспособен, его базовая директория при этом будет определяться физическим расположением файлов сервера. Следовательно, в простейшем случае (при запуске сервера как приложения, т. е. с ключом командной строки "-а") установка вообще не требуется - достаточно просто скопировать файлы сервера в отдельный каталог и запустить его.

Теперь можно иметь возможность запуска сервера Firebird параллельно с сервером IB/FBI на одном компьютере, а также запуска нескольких копий сервера (все это при условии работы на разных портах, что настраивается перед запуском сервера).

Помимо собственно СУБД, проект Firebird включает также драйверы ODBC. JCA-JDBC (Туре 4) и .NET-провайдер, которые распространяются вместе с сервером или отдельно.

Дополнительные национальные кодовые страницы и порядки сортировки

В Yaffil добавлены следующие национальные кодовые страницы и порядки сортировки:

CS_WIN1257 - страны Прибалтики, кодовая страница Windows - 1257

Порядки сортировки:

WIN1257_EE - Эстония

WIN1257_LV-литва

WIN1257_LT- Латвия

CS_KOI8R - Россия KOI8. кодовая страница Windows - 20866

Порядки сортировки:

KOI8R

KOI8R_RU

CS_KOI8U - Украина KOI8-U, кодовая страница Windows - 21866

Порядки сортировки:

KOI8U

KOI8LLUA

Также для кодовой страницы WIN 1251 добавлены порядки сортировки:

WIN1251_UA

WIN1251_RU

Достигнутые результаты

Большая часть запланированных функциональных возможностей была реализована к сентябрю 2002 года, и в конце сентября были выпущены первые неофициальные сборки новой версии (snapshots) для платформы Win32 Приблизительно через месяц была выпущена первая альфа-версия, которая, будучи нестабильной и предназначенной исключительно для технологического тестирования, тем не менее давала возможность ознакомиться с особенностями новой версии и предоставить производителям стороннего ПО условия для адаптации под нее своих продуктов Помимо платформы Win32, были выпущены сборки новой версии сервера для Linux, MacOS X (Darwin) и SINIX-Z.

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

Единое имя файла параметров InterBase

Теперь файл параметров InterBase 7 имеет единое имя как для платформы Windows, так и для Linux - ibconfig.

Firebird 1.5 - Open Source DBMS

Прошел год с момента выпуска первой версии СУБД Firebird (12 апреля 2002 года) и. 1аким образом, с момента официального вхождения продукта в мир Open Source и начала завоевания собственного авторитета. Но это уже в прошлом, нас же больше интересует состояние дел на текущий момент, а также планы развития проекта на ближайшее будущее. Сейчас с полной определенностью можно сказать, что этот год прошел не зря для Firebird Была проделана большая работа, результаты которой можно наблюдать сегодня. Ниже будет подробно рассказано о том, что уже сделано и что еще предстоит сделать участникам проекта для достижения поставленных ими целей, главной из которых является выпуск в свет версии 1.5 в начале 2003 года.

Firebird 2.0 - взгляд в будущее

Итак, выше мы узнали о том, что сделано в рамках версии Firebird 1.5, теперь самое время поговорить о том, что нам стоит ожидать от следующей версии, которая будет носить номер 2.0.

Группировка по номеру столбца

Сервер Yaffil расширяет синтаксис инструкции group by. Допускается указывать номера столбцов для группировки, как в инструкции oreder by.

Пример:

select count(a), b from t group by 2

Группировка по встроенным функциям и UDF

Разрешена группировка и использование встроенных функций и UDF.

Пример:

select sum(vent) from sales group by extract(year from sale date)

Хранение конфигурации в системном реестре

Для платформы Windows системный реестр - основное средство хранения конфигурационной информации. Текстовый файл IBCONFIG, используемый сейчас, имеет недостаток, связанный с невозможностью задания сложной конфигурации, имеющей иерархическую структуру. Кроме того, не так-то просто приложениям анализировать этот файл и вносить изменения в него.

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

Процедурный язык в SQL запросах

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

В сервере Yaffil предполагается ввести возможность выполнения процедурных команд SQL в запросах, передаваемых с клиента, включая использование локальных переменных, операторы IF, WHILE, конструкции SELECT INTO и FOR SELECT.

Имена индексов ограничений

Использование явных планов в Yaffil в триггерах и процедурах существенно упрощается благодаря возможности именования индексов, автоматически создаваемых сервером для ограничений первичных, внешних ключей и ограничений уникальности. В версиях InterBase такие индексы приобретают системные имена в формате RDBSPRIMARYX для индексов первичных ключей, RDB$FOREIGNX для индексов внешних ключей и RDB$X для индексов ограничений уникальности. X обозначает номер индекса данного типа по порядку с момента создания базы данных (или восстановления из резервной копии). Так как эти номера могут измениться при следующем восстановлении базы данных, фиксировать такие индексы в плане становится опасным. Возникает тупиковая ситуация: автоматический план неэффективен, явный план записать нельзя. Разработчикам приходится создавать собственные индексы, целиком дублирующие системные. Однако появление новых индексов на таблице влечет к увеличению дискового пространства, занимаемого базой, замедлению операций обновления, кроме того повышению вероятности выбора оптимизатором неверного плана из-за увеличения числа вариантов соединений таблиц.

В Yaffil индексы для ограничений могут принимать имена соответствующих ограничений.

Нужное поведение включается параметром CONSTRAINT_INDEX_NAME в конфигурационном файле. Например:

SQL> create table T (id into not null, constraint PK_T primary

key (id));

SQL> show index;

PK_T UNIQUE INDEX ON Т(ID)

Имена объектов длиной 68 символов

Возможная длина имен объектов в InterBase 7 теперь равна 67 символов вместо 31 символа ранее. Да, именно 67 - хотя в заголовке этого раздела написано 68. фактически хранится лишь 67 символов, а последний символ представляет собой завершающий 0.

Очевидно, чтобы воспользоваться данной возможностью, необходимо обновить версию клиентской библиотеки gds32.dll (а Java-разработчики должны использовать Туре 4 драйвер).

Чтобы поддержать данное изменение длины имен объектов, была изменена структура XSQLDA. Надо сказать, что данное изменение весьма неприятно сказалось на клиентских библиотеках доступа к InterBase, таких, как IBX, FIBPlus, dbExpress и т. д. Теперь, чтобы перевести ваше программное обеспечение под InterBase 7, понадобится перекомпилировать существующие клиентские приложения с новыми версиями клиентских библиотек.

Индексы по выражениям

Индексы по выражениям (Expression Indexes) используются в тех случаях, ко- |да необходимо обеспечить быстрый поиск или сортировку по значениям, вычисляемым на основе полей таблицы. Необходимый индекс определяется следующим образом:

CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]]

INDEX index ON table COMPUTED BY (expression)

где index - имя индекса, expression - выражение, построенное на основе полей таблицы. В выражении можно использовать арифметические операции, встроенные функции и UDF. Во время оптимизации запросов, если выражение совпадает с выражением, указанным в условии WHERE или в условии соединения, будет использован индекс.

Например, необходимо сделать выборку записей, имеющих поле типа дата, для определенного месяца по всем годам (на примере базы данных Employee из комплекта поставки InterBase 6):

CREATE INDEX employeejhire_date_month_idx ON employee COMPUTED 

BY (EXTRACT(MONTH FROM hire_date) ) ;

Попробуем выполнить запрос и посмотрим на выбранный оптимизатором план:

SELECT * FROM employee

WHERE EXTRACT(MONTH FROM hire_date) = 1

PLAN (EMPLOYEE INDEX (EMPLOYEE_HIRE_DATE_MONTH_IDX))

Вычисляемое выражение должно полностью определяться значениями полей таблицы, индекс на основе, например, функции CURRENT_TiMESTAMP, скорее всего, будет бесполезен, хотя Yaffil не запрещает использование подобных выражений. В вычисляемых выражениях нельзя использовать подзапросы. Очень интересные возможности появляются при использовании User-Defined Functions (UDF) в вычисляемых выражениях, с их помощью можно выполнять эффективный поиск по практически любому условию.

Инструкция IIF

Инструкция IIF позволяет реализовать дополнительную логику в запросах. Синтаксис:

IIF '(' search_condition ', ' value_if_true ', ' value_if_false')'

Выполняя инструкцию IIF, сервер вычисляет выражение search_condition. Если search_condition, то результатом IIF является выражение value_if_true, в противном случае value_if_false.

Пример:

select iif(re.rdb$collation_id = 0, 'ДА', 'НЕТ') from

rdb$collations re

where re.rdb$collation_name = 'WIN1251'

Выполнив запрос, получим - "ДА".

Инструкцию IIF можно применять и при вычислении выражений.

Пример:

а = b + iif(c is null, 0, с);

Инструкция INSERT INTO ... FROM ... UNION ...

Сервер Yaffil, в отличие от InterBase/Firebird, позволяет использовать объединения UNION для формирования данных на вставку. Пример:

insert into t_a (id) select b.id from b union select с.id from с

Интеграция с платформой Windows NT

Изначально InterBase разрабатывался на платформах Unix и только в начале 9()-\ годов в версии 4.0 был перенесен на Windows NT. К сожалению, при переносе кода мало внимания было уделено платформозависимой оптимизации под Windows NT, в результате данный вариант сервера оказался менее эффективным, чем мог бы быть. В то же время число установок InterBase на Windows NT составляет значительную (а возможно, и большую) часть, поэтому такая ситуация является достаточно печальной.

Кроме того. Windows NT обладает рядом возможностей, использование которых в сервере СУБД позволит добиться нового уровня функциональности и увеличить отдачу при использовании сервера в прикладных системах. Среди таких возможностей назовем интерфейс для аутентификации пользователей по протоколам NTLM или Kerberos, при использовании которого нет необходимости вводить имя пользователя и пароль при каждом соединении, встроенные криптографические средства, координатор распределенных транзакций (MS DTC), асинхронный ввод-вывод, интерфейс WinSock2 и другие. Все перечисленные возможности широко используются другими серверами баз данных, однако полностью игнорируются сервером InterBase/Firebird.

Интегрированная безопасность (NT Integrated Security)

Предполагается использовать принцип single sign-on, при котором при соединении пользователя к базе данных используется учетная запись домена NT. под которой он зарегистрирован в системе Для передачи информации о пользователе используется протокол аутентификации выбранного модуля безопасности (Security Package), например NTLM в системах с доменами типа NT4 или Kerberos для доменов Windows 2000. Далее на уровне сервера учетная запись операционной системы отображается на имя пользователя

Для использования этой возможности необходимо вхождение серверного и клиентского компьютера в домен NT. При использовании интегрированной безопасности пароль пользователя не передается в открытом виде по сети, возможно шифрование и подпись (confidentiality и privacy) сетевого трафика.

Подобные принципы организации безопасности используются в MS SQL, Sybase SQL Studio Anywhere и других СУБД.

Использование переменной окружения ISC_PATH

В Yaffil расширены возможности использования переменной окружения ISC_PATH для задания префикса к пути базы данных. Переменная ISC_PATH используется, если в имени базы данных, указываемом клиентом, не содержит каталогов или имени сервера. Переменная ISC_PATH может использоваться как на клиенте, так и на сервере. Примеры:

Использование ISC_PATH на сервере. Пусть базы данных на сервере находя 1ся в каталоге c:\database. Определим переменную ISC_PATH=c:\database. Далее можно использовать на клиентском компьютере строку соединения вида servemame:database.gdb для открытия базы данных c:\database\database.gdb.

Использование ISC_PATH на клиенте. Пусть базы данных располагаются на сервере serxername в каталоге c:\database. Определим на клиенте переменную ISC_PATH как servername:c:\database. После этого клиент сможет обращаться к базам данных только по короткому имени файла БД, например CONNECT sales.gdb. Используем внешний файл в базе sales.gdb:

CREATE TABLE customers EXTERNAL FILE "sales_flies/customers.txt" ( ... );

Использование сервера Yaffil внутри процесса

С точки зрения прикладной программы различие между встраиваемым сервером и обычным удаленным клиентом заключается в имени библиотеки динамической загрузки (DLL), связываемой с программой. Как известно, обычные приложения используют библиотеку GDS32.DLL, как правило. устанавливаемую в системный каталог Windows. Существование нескольких разных библиотек с одним именем может привести к путанице, особенно если подобная библиотека находится в пути доступа, общего для всех приложений. Версии 4.x InterBase CS. выпущенные фирмой Борланд, используют библиотеку сервера, которая также имеет имя GDS32.DLL.

Yaffil CS реализован в библиотеке YAENG32.DLL, имеющей интерфейс, идентичный GDS32.DLL. Поэтому использовать встраиваемый Yaffil CS можно в приложениях, написанных на IB API или Embedded SQL с помощью указания библиотеки импорт YAENG32.L1B на этапе связывания (linking).

Другая возможность использования нужной библиотеки состоит в динамической загрузке ее во время выполнения приложения.

Если же вы пользуетесь компонентами доступа или драйверами, не позволяющими указывать имя используемой библиотеки, вам остается только один выход - скопировать модуль YAENG32.DLL под именем GDS32.DLL. Не забудьте поместить этот файл в каталог, в котором находится исполнимый (.ехе) модуль программы.

Изменения оптимизатора, направленные на совместимость

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

JDBC Туре 4 DRIVER

Java-разработчики могут быть довольны - наконец у InterBase появился собственный "тонкий" JDBC-драйвер - InterClient 3.0. Это означает, что он не требует никаких дополнительных промежуточных программ вроде InterServer - достаточно просто подключить interclient.jar в свою строку CLASSPATH и работать с InterBase 7. Это значительно упрощает распространение Java-приложений баз данных InterBase.

Помимо упрощения распространения, InterClient 3.0 полноценно поддерживает пул соединений (Connection Pooling) и механизм источников данных (DataSource). Также InterClient 3.0 теперь поддерживает полноценную работу с Blob-полями InterBase 7.

Хочется отметить также превосходную интеграцию InterBase 7 с такими продуктами Borland, как JBuilder и Borland Enterprise Server. Эта связка СУБД, мощного средства разработки и application-сервера позволяет легко разрабатывать J2EE-пpилoжeния.

Некоторым недостатком InterClient 3.0 JDBC Type 4 является то, что он работает только с 7-й версией InterBase, и потому в приложениях, использующих более старые версии, работать не будет. Этот факт тем огорчительнее, что конкурент InterClient - Open Source JayBird от команды Firebird developers все еще находится в стадии бета-тестирования, и поэтому множество Java-разработчиков вынуждено будет пользоваться более старыми версиями InterClient - JDBC Type 3. которые используют промежуточную программу InterServer для работы с базой данных. Для таких разработчиков в поставку InterBase 7 включен хорошо знакомый InterClient JDBC Type 3.

Эффективная работа с временными файлами сортировки

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.

Для сервера InterBase рекомендуется выставить это значение в 1. Для того чтобы изменение вступило в силу, необходимо перезагрузить систему.

Обратите внимание, что некоторые серверные приложения, такие, как Microsoft SQL Server, могут переустанавливать это значение в 0 при своей инсталляции, поскольку не используют файловый кэш.

Эффективное взаимодействие процессов архитектуры Classic Server

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

В отличие от сигналов, в Yaffil на платформе Windows NT/2000 для обмена сообщениями о блокировках используются объекты синхронизации без обращений к ядру ОС. Во время активной работы сервера между процессами передается большое число таких сообщений, в результате заметно снижаются расходы на межпроцессное взаимодействие.

Классическая архитектура на Windows NT (Yaffil CS)

Реализация классической архитектуры Yaffil CS на платформе Windows NT является значительным преимуществом сервера Yaffil по сравнению с другими вариантами InterBase/Firebird, существующими на сегодняшний день. Классическая ветвь InterBase для Windows NT прекратила развитие в 1994 году в связи с началом разработки варианта SuperServer для версии 4.0. Предполагалось, что SuperServer быстро заменит классическую архитектуру, однако реализация SuperServer, имеющая приемлемые характеристики при использовании с большой нагрузкой, не была удачной. В связи с этим до недавнего времени версии InterBase для платформ Solaris и Linux поставлялись в двух вариантах - SuperServer и Classic Server.

Классическая архитектора обладает следующими преимуществами:

Равномерное распределение нагрузки между выполняющимися запросами на разных соединениях.

Эффективное использование многопроцессорных систем (SMP).

Более полное использование оперативной памяти.

Встраиваемый (embedded или in-process) сервер.

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

Не будем здесь останавливаться на отличиях архитектур Classic и SuperServer, подробно описанных выше в этой книге, рассмотрим лишь особенности реализации Yaffil Classic Server.

В отличие от сервера Interbase 4.0 для Windows NT, Yaffil CS способен запускаться не только как служба Windows NT, но и как приложение. Во втором случае в области system tray панели задач Windows появляется красная иконка Yaffil Server. В строке версии вместо пары букв WI (платформа Windows Intel) используются буквы N1 (платформа NT Intel), поскольку именно так обозначала себя первая версия InterBase CS 4.0 для Windows NT.

Количество соединений, поддерживаемых Yaffil Classic Server, ограничено только ресурсами системы, в основном оперативной памятью. Ограничение для InterBase CS 4.0 в 90-120 соединений при запуске сервиса ibremote с параметром "not allowed to interact with desktop" снято в Yaffil CS.

Конфигурация безопасности для базы данных

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

С другой стороны между приложением и базой данных нет посредников, таких? как сетевые устройства и средства межпроцессного обмена данными. Поэтому нет необходимости использовать средства защиты данных при клиент - серверном взаимодействии.

Конфигурирование

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

Кроме того, в версии 1.5 реализован механизм "псевдонимов" (aliases) баз данных, т. е. возможность подключения к БД без знания физического пути к соответствующему файлу. Список псевдонимов хранится в файле aliases.conf, расположенном в корневом каталоге установки сервера. Запись о псевдониме выглядит следующим образом: <aliasnarr,e> = <database pathname>

При этом строка соединения с сервером будет выглядеть следующим образом (в случае TCP/IP): <hostname>:<aliasname>. Это позволяет избавить клиентов от необходимости знать структуру файловой системы сервера и обезопасить сервер от несанкционированного доступа извне.

Миграция баз данных на Yaffil и обратно

При разработке сервера Yaffil большое внимание было уделено безболезненному переходу со всех версий линейки InterBase, начиная с версии 4.0. Это вызвано тем, что в настоящее время существует большое число инсталляций устаревших версий (4.2, 5.6) по причине затрудненного переноса приложений на новые версии InterBase. Проблемы состоят в недостаточной обратной совместимости более новых версий InterBase.

В то же время при использовании сервера Yaffil как обновления для InterBase версий 4.x, 5.x возможные проблемы сведены к минимуму. Как правило, приложение сразу успешно работает без переделок.

Перечислим изменения Yaffil, направленные на обратную совместимость:

Поддержка баз данных, созданных в предыдущих версиях InterBase.

Режим обратной совместимости.

Модификация системных таблиц

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

Чтобы влиять на состояние запросов, транзакций, соединений и т.д., нужно изменить столбец TMP$STATE в соответствующей временной системной таблице. Например, вы можете произвести следующие изменения:

Отключить соединение.

UPDATE TMP$ATTACHMENTS SET TMP$STATE = 'SHUTDOWN' WHERE (TMP$ATTACHMENT_ID = 12345)

Принудительно отменить активную в данный момент или "застрявшую" 2РС (т. е. в состоянии in limbo) транзакцию.

UPDATE TMP$TRANSACTION SET TMP$STATE = 'ROLLBACK' WHERE (TMP$TRANSACTION_ID = 12345)

Остановить выполняемый в данный момент запрос.

UPDATE TMP$STATEMENTS

SET TMP$STATE = 'CANCEL'

WHERE (TMP$STATEMENT_ID = 12345)

Мониторинг состояния сервера

Любители исследовать исходный код InterBase б часто говорят, что в нем скрыта масса интереснейших идей, которые были не доведены до конца по каким-либо причинам. Одной из таких идей, извлеченных и реализованных в InterBase 7, является мониторинг внутреннего состояния сервера.

В InterBase предыдущих версий сервер производил постоянный мониторинг своего состояния — отслеживал выполняющиеся запросы, подключенных пользователей и т. д. Но все эти данные были для внутреннего использования - пользователи не могли получить к ним доступ. Теперь ситуация изменилась - в InteiBase 7 появился удобный интерфейс для доступа к данным о мгновенном состоянии сервера.

InterBase 7 предоставляет механизм "временных системных таблиц" для доступа к данным о своем состоянии. Не надо путать эти временные таблицы с временными таблицами в других СУБД, которые используются для оптимизации выполнения SQL-запросов.

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

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

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

Вот список временных системных таблиц для мониторинга в InterBase 7 с краткими описаниями, взятый с сайта www.ibase.ru:

Табл 2. Системные таблицы для мониторинга в InterBase 7

Доступные системные временные таблицы
Название таблицы	Что содержит
TMPSATTACHMENTS	По записи на каждое соединение к базе данных
TMP$DATABASE	По записи на каждую базу данных, к которой вы подсоединились
TMP$POOL_BLOCKS	По записи на каждый блок памяти в каждом пуле
TMP$POOLS	По записи на каждый пул памяти
TMP$PROCEDURES	По записи на каждую выполненную в данном соединении процедуру
TMP$RELATIONS	По записи на каждую таблицу, к которой было обращение в данном соединении
TMPSSTATEMENTS	По записи на каждый выполняемый в данный момент запрос, для всех соединений
TMP$TRANSACTIONS	По записи на каждую активную (или в состоянии limbo) транзакцию

Надежность и безопасность

В сервере Yaffil исправлено большое число критических ошибок, многие из которых приводят к порче данных. В предыдущих версиях InterBase такие опасные ситуации, как порча памяти (вследствие ошибки в коде сервера, некорректной UDF или испорченных метаданных БД), протекали внешне незаметно до тех пор. пока база данных не была непоправимо испорчена.

Ошибка при работе с памятью в Yaffil, как правило, приводит к немедленному останову сервера с потерей только последних обновляющих транзакций.

В Yaffil, как и в InterBase 7.0, исправлена дыра в безопасности, связанная с использованием внешних таблиц для получения доступа к любому файлу системы. Также в Yaffil исправлена серьезная ошибка, связанная с обработкой структурированных исключений (SEH) Win32 API

Для поддержки нововведений базы данных,

Для поддержки нововведений базы данных, созданные (или восстановленные) в InterBase 7, имеют новую версию внутренней структуры базы данных - On-Disk Structure (ODS). Новая версия ODS несовместима с прежними ODS. Это значит, что старые версии InterBase и клоны InterBase Open Source (Firebird и Yaffil) не будут работать с базами данных, имеющими ODS11.

Миграция баз данных на новую ODS возможна только через backup/restore - по тому же самому принципу, что описан в главе "Миграция". Следует также отметить, что в InterBase 7 все же поддерживаются базы данных 1-го диалекта, хотя при выпуске 6-й версии объявлялось, что далее диалект 1 поддерживаться не будет. Однако очевидно, что все еще очень много пользователей используют базы данных в 1-м диалекте и не могут по различным причинам легко перейти на 3-й диалект Поэтому InterBase 7 поддерживает как 3-й, так и 1-й диалект.

Ниже мы коротко рассмотрим остальные нововведения, напрямую ответственные за появление 11-й версии On-Disk Structure.

Новая версия ODS

Значительная часть запланированных изменений потребует реализации новой версии ODS (On-Disk Structure), что было признано неприемлемым для версии 1.5 (которая является полностью совместимой с IB6/FB1), поэтому введение новой ODS отложено до версии 2.0. Элементами новой ODS будут являться:

увеличение размера полей, хранящих имена метаданных, что позволит обойти текущее ограничение в 31 символ;

увеличение размера ряда внутренних идентификаторов до 64 бит, что позволит, например, хранить больше записей в одной таблице и обрабатывать большее количество транзакций без необходимости цикла backup/restore;

более полная реализация безопасности метаданных на уровне SQL, что снимет сразу ряд имеющихся в настоящее время проблем в этой области;

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

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

возможность работы со значительно большими размерами ключа индекса;

несколько новых типов данных и объектов базы данных.

Новое имя базы данных пользователей

Отныне база данных пользователей isc4.gdb отходит в прошлое, и вместо нее по умолчанию будет использоваться база данных admin.ib. По сути, она выполняет идентичные функции.

Правда, наименование базы данных пользователей теперь не является жестко заданным - используя параметр ADMIN_DB, вы можете задать любое приятное вашему слуху имя базы данных пользователей InterBase.

Новые функции API для работы с Blob и массивами

Были добавлены 10 новых функций InterBase API для поддержки длинных имен объектов. Ниже представлены новые вызовы API:

isc_array_gen_sd!2()

isc_array_get_slice2()

isc_array_lookup_bounds2() 

 isc_array_lookup_desc2()

isc_array_set_desc2() 

isc_array_put_slice2() 

isc_blob_default_desc2() 

isc_blob_gen_bpb2() 

isc_blob_lookup_desc2() 

isc_blob_set_desc2()

Новые ключевые слова

В Interbase 7 появились новые ключевые слова, связанные с вышеупомянутым типом BOOLEAN:

BOOLEAN, TRUE, FALSE, UNKNOWN

Хочется отметить, что в предыдущей версии (6.5) были добавлены следующие ключевые слова:

ROWS, TIES, PERCENT

Их значение разъяснено в документации к InterBase 6.5.

Новый тип данных: BOOLEAN

InterBase теперь поддерживает тип данных BOOLEAN в соответствии со стандартом SQL99. Поля и переменные типа BOOLEAN могут принимать значения TRUE/FALSE/UNKNOWN (да-да, и здесь используется трехзначная логика, как и везде, где есть понятие неопределенного значения). Размер BOOLEAN - 32 бита.

Чтобы создать в таблице поле типа BOOLEAN, достаточно написать что-то вроде этого: CREATE TABLE Tab!el(MyBOOL BOOLEAN)

Возможным значениям типа BOOLEAN - TRUE, FALSE и UNKNOWN соответствуют целые значения 0, 1 и неопределенное значение NULL.

Обзор современных версий семейства InterBase

Yaffil - российский клон СУБД InterBase

Введение

Приоритетные направления развития Yaffil

Интеграция с платформой Windows NT

Производительность

Надежность и безопасность

Отличительные особенности сервера Yaffil

Улучшенная производительность

Улучшенный оптимизатор запросов

Оптимизация сетевого трафика

Эффективная работа с временными файлами сортировки

Оптимальная структура хранения записей

Ускоренная работа с индексами

Улучшенная стратегия вычисления предиката IN и условий, объединенных по OR

Ускоренное обновление данных

Уменьшение времени, необходимого для резервного копирования и восстановления

Индексы по выражениям

Уменьшение размера, занимаемого индексами

Выражения в значениях по умолчанию для доменов

Удобная операция объединения строк

Расширенные возможности указания пользовательских планов

Имена индексов ограничений

Улучшенное время отклика для версии SuperServer

Улучшенный протокол локальных соединений (XNET)

Ограничение времени ожидания для транзакций (Lock timeout)

Расширения SQL

Инструкция IIF

Инструкция INSERT INTO FROM UNION

Выражения в EXCEPTION

Системные переменные ROWS_AFFECTED, GDSCODE, SQLCODE, TRANSACTIONJD, CONNECTIONJD

Группировка по номеру столбца

Значения переменных по умолчанию

Тип данных BIGINT

Дополнительные национальные кодовые страницы и порядки сортировки

Группировка по встроенным функциям и UDF

Oграничение результатов выборки FIRST/SKIP

Увеличение глубины рекурсии процедур и триггеров

Использование переменной окружения ISC_PATH

Безопасная работа с внешними таблицами

Классическая архитектура на Windows NT (Yaffil CS)

Встраиваемый сервер

Конфигурация безопасности для базы данных

Использование сервера Yaffil внутри процесса

Эффективное взаимодействие процессов архитектуры Classic Server>

Изменения оптимизатора, направленные на совместимость

Yaffil Classic Server-замена InterBase Classic 4.0

Миграция баз данных на Yaffil и обратно

Режим обратной совместимости

Возможности, планируемые к реализации в следующих версиях

Одновременный запуск нескольких копий сервера

Интегрированная безопасность (NT Integrated Security)

Асинхронный сервер и отмена выполняющихся запросов

Одновременный запуск нескольких копий сервера (multi-instancing)

Хранение конфигурации в системном реестре

Большие индексы

Заключение

InterBase 7

Семерка - первый шаг нового семейства

Распараллеливание на несколько процессоров

Мониторинг состояния сервера

Модификация системных таблиц

Примеры получения статистики

Безопасность временных таблиц

JDBC Туре 4 DRIVER

Новая структура данных на диске: ODS11

Новый тип данных: BOOLEAN

Новые ключевые слова

Имена объектов длиной 68 символов

Новые функции API для работы с Blob и массивами

Другие изменения в 7-й версии InterBase

SET TERM больше не нужен в isql

Определение версии клиента

Безопасность внешних таблиц. Параметр EXTERNAL_FDLE_DIRECTORY

Единое имя файла параметров InterBase

Рекомендуемое расширение для файлов баз данных - *.ib

Новое имя базы данных пользователей

Заключение

Firebird 1.5 - Open Source DBMS

Продолжение линии 1.0

Версия 1.5 - эволюция или революция?

Достигнутые результаты

Отличительные особенности новой версии

Дистрибутив

Реализация языка SQL

Расширение механизма событий

Производительность

Конфигурирование

Firebird 2.0 - взгляд в будущее

Новая версия ODS

Поддержка SMP

Средства мониторинга

Дальнейшее развитие языка SQL

Заключение

Одновременный запуск нескольких копий сервера (multi-instancing)

Существующие версии InterBase/Firebird не допускают одновременный запуск нескольких процессов сервера. Причина этого в том, что сервер использует глобальные именованные объекты и структуры данных При запуске сервера происходи! проверка на наличие уже запущенного экземпляра, однако иногда ыкая проверка может дать сбой, например в случае запуска в терминальной сессии Windows NT/2000.

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

Для решения такой задачи планируется разделить конфигурацию серверов и пространства имен глобальных объектов. Каждый экземпляр сервера будет использовать отдельный порт протокола TCP или имя Named Pipe.

Отметим, что сервер Yaffil использует отличные от InterBase/Firebird именованные глобальные объекты Таким образом, появляется возможность одновременного запуска и Yaffil и InterBase/Firebird.

Ограничение результатов выборки FIRST/SKIP

Как и в Firebird 1.0, результат выборки SELECT может быть ограничен с использованием инструкций FIRST/SKIP (В Borland InterBase начиная с версии 6.5 используется аналогичная по назначению конструкция ROWS.)

При значении аргумента FIRST, равном 0, результатом выборки будет пустое множество, в отличаие от Firebird 1.0, где будет возбуждено исключение с сообщением о неверном параметре.

Ограничение времени ожидания для транзакций (Lock timeout)

При возникновении конфликта обновления записи в InterBase возможны два варианта поведения транзакции, задаваемых параметром WAIT (isc_tpb_wait / bc_tpb_no_wait). - бесконечное ожидание разрешения конфликта или немедленная выдача ошибки. Режим с ожиданием часто удобнее, так как нет необходимости повторять операцию в случае конфликта, но такой режим является очень опасным из-за возможности бесконечной блокировки приложения.

В сервере Yaffil добавлена возможность ограничивать время ожидания разрешения конфликта заданным интервалом времени. Для этого служит параметр конфигурации LOCK_TIMEOUT, задающий время в секундах. Положительное значение от 1 до 32 767 определяет время ожидания WAIT транзакций. Отрицательное число определяет бесконечное время ожидания. Нулевое значение эффективно превращает WAIT транзакции в NOWAIT. Значение по умолчанию -1 (минус один), что обеспечивает совместимость с другими версиями. Параметр не оказывает влияния на транзакции, запущенные в режиме NOWAIT.

В следующих версиях планируется ввести константу блока ТРВ (transaction parameter block), управляющую временем ожидания при запуске каждой транзакции индивидуально.

Определение версии клиента

Некоторые клиентские библиотеки и драйверы могут иметь необходимость определять версию клиентской библиотеки Interbase. Для этого введены три новые функции API:

isc_get_client_version(),

isc_get_client_major_version(), 

isc_get_client_minor_version().

Оптимальная структура хранения записей

InterBase использует эффективный способ хранения записей на страницах базы данных, используя алгоритм RLE (run length encoding - кодирование последовательностей) при размещении данных, за счет которого базы данных InterBase являются компактными. Несмотря на то что алгоритм является очень простым, он тем не менее требует вычислительных ресурсов при записи и чтении данных на странице.

В зависимости от характера данных упаковка может оказаться нецелесообразной. Наибольший эффект достигается при сжатии "хвостов" из пробелов длинных текстовых строк (типы данных CHAR и VARCHAR), в то время как короткие нетекстовые данные практически несжимаемы.

Для управления сжатием в Yaffil введен параметр конфигурации SQZ_BLOCK. Этот параметр определяет минимальный размер блока строки таблицы (в байтах), начиная с которого будет производиться сжатие. Блоки строки таблиц менее указанного размера хранятся в исходном виде. С увеличением параметра объем базы данных возрастает за счет сокращения затрат времени процессора на упаковку. В то же время увеличение количества данных больше нагружает дисковую подсистему. В зависимости от характера данных (главным образом количества текстовых полей в таблицах) и определенных параметров процессора и дисков системы существует некоторое оптимальное значение SQZ_BLOCK, обеспечивающее максимальную производительность. Алгоритм упаковки, реализованный в Yaffil, дополнительно выравнивает начало и размер сжатого блока на границу машинного слова.

Оптимизация сетевого трафика

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

Объем сетевого трафика Yaffil значительно уменьшен за счет более эффективной передачи полей типа VARCHAR, так как передаются данные фактической длины, а не объявленной в описании типа. Аналогичное улучшение есть в Borland InterBase, начиная с версии 6.5.

Отличительные особенности новой версии

Итак, что же нового приготовили нам разработчики Firebird? Ниже приводится список нововведений с их кратким описанием, сгруппированный по функциональным категориям. Следует заметить, что не все из приводящегося списка в настоящий момент полностью реализовано, поэтому он может несколько отличаться от официального документа Release Notes, включенного в дистрибутив новой версии.

Поддержка SMP

Несмотря на то что классическая архитектура сервера полностью использует возможности SMP-систем, она имеет ряд недостатков, которые накладывают слишком высокие требования на ресурсы сервера в случае очень большого количества соединений с базой данных. Как известно, корпорация Borland отказалась от развития архитектуры Classic и сосредоточила свои усилия на доработке кода SuperServer. В 2002 году мы увидели первый результат их работы - версию InterBase 7.0, в которой декларирована поддержка SMP.

Одной из целей разрабо!ки Firebird 2.0 также является полноценная поддержка SMP во всех вариантах сервера. Здесь можно пойти двумя путями: доработка кода SS (аналогично тому, что сделали в Borland) или объединение кода SS и CS с получением комбинированной архитектуры, позволяющей в зависимости от конфигурации работать либо в режиме разделяемого сервера с общим пулом потоков, либо в режиме выделенного сервера с одним процессом на каждое соединение, либо в одном из смешанных режимов (один сервер на N соединений, один сервер на каждую БД и т. п.). Оба варианта достаточно трудны в реализации, и разработчики проекта еще не приняли окончательного решения на этот счет, но пока наблюдается тенденция к выбору второго варианта (комбинированная архитектура). Это также позволит унифицировать исходный код и упростить внесение в него низкоуровневых изменений.

Примеры получения статистики

Примерами использования системных таблиц для получения полезной статистики могут являться следующие запросы:

10 самых длительно выполняющихся запросов.

SELECT a.tmp$user, s.tmp$timestamp/ s.tmp$sql, s.tmp$quantum

FROM tmp$statements s, tmp$attachments a

WHERE a.tmp$attachment_id = s.tmp$attachment_id

ORDER BY s.tmp$quantum DESC

ROWS 10;

Активность пользователя SYSDBA.

SELECT TMP$USER, TMP$USER_IP_ADDR,

TMP$TIMESTAMP, TMP$STATE, TMP$TRANSACT10NS, TMP$RECORD_SELECTS, TMP$RECORD_INSERTS,

TMP$RECORD_UPDATES, TMP$RECORD_DELETES FROM TMP$ATTACHMENTS WHERE TMP$USER = 'SYSDBA'

Сразу после выхода первого релиза

Сразу после выхода первого релиза был начат процесс анализа реакции пользователей и исправление найденных проблем. Как результат, вскоре были выпущены несколько пострелизных сборок, одна из которых (821) стала в итоге версией 1.0.1, а сборка 908 - 1.0.2.

В версию 1.0.2 вошли несколько исправлений ошибок, основными из которых являются:

корректная реализация 64bit I/O (поддержка больших файлов) для ТЖГХ-сиием,

решение проблемы неправильной строки соединения (опять же для UNIX-систем);

возможность работы с типом INT64 в массивах;

устранение проблем с механизмом двухфазной фиксации транзакций.

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

Производительность

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

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

Был улучшен алгоритм работы оптимизатора запросов, в частности в следующих направлениях:

использование индексов в подзапросах с агрегатами,

игнорирование "плохих" индексов, т. е. индексов, использование которых может привести лишь к замедлению выполнения запроса;

более качественный анализ селективности индексов при построении плана;

оптимальное построение плана в случае доступности одно- и многосегментных индексов;

более совершенное использование индексов в условиях типа "OR", особенно в случае сложных предикатов (в частности, сложных неявных соединений).

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

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

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

Все вышесказанное привело к заметному увеличению производительности. Например, выполнение серии промышленных тестов TPC-R (уже упоминавшейся в этой книге) показало почти трехкратное превосходство новой версии по сравнению с линией 1.0. Разумеется, это не значит, что выполнение абсолютно всех 5апросов будет осуществляться быстрее, но позволяет рассчитывать на улучшение производительности в ряде случаев

Распараллеливание на несколько процессоров

Многие разработчики представляют себе понятие распараллеливания по разному поэтому надо внести ясность, что имеется в виду под этим термином в случае InterBase 7. Прежде всего уточним, что речь идет о выполнении SQL-запросов, посылаемых пользователем. И тут обычно начинаются разночтения.

Одни считают, что распараллеливание - это когда разные части одного и того же SQL-запроса обрабатываются на различных процессорах. Другие считают, что распараллеливание - это когда разные соединения с пользователями "рассаживаются" по разным процессорам и все запросы от пользователя внутри них независимо выполняются на том процессоре, на котором выполняется обработка данного соединения (такой подход реализован в архитектуре Classic Server).

Однако в архитектуре SuperServer, реализованной в InterBase 7, в чистом виде не используется ни тот ни другой тип распараллеливания.

Чтобы понять, как InterBase 7 использует несколько процессоров, давайте немного углубимся в его архитектуру и рассмотрим процесс обслуживания запросов пользователя.

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

Отдельного потока (thread) для индивидуального обслуживания только что подсоединенного клиента не запускается. Это легко можно проверить, написав простенькое приложение, которое откроет несколько сотен соединений с сервером, - и если эти соединения простаивают, то информация о процессе ibserver.exe в Task Manager показывает, что открыто всего 5-8 потоков.

Далее как только подсоединенный пользователь пожелает выполнить какой- либо SQL-запрос, сервер запускает поток, который обслужит данный запрос. После обслуживания данного запроса поток через некоторое время завершает свою работу. Если этот же пользователь снова выполнит другой SQL-запрос, то совершенно не обязательно, что его будет обслуживать ют же самый поток, что и в первый раз.

На самом деле, потоки не запускаются/уничтожаются исключительно по желанию пользователя — InterBase отслеживает среднюю загрузку/частоту выполнения SQL-запросов и держит постоянно открытым пул потоков, содержащий оптимальное число потоков, готовых обработать запросы пользователей.

Такая схема работы не только чрезвычайно экономична - позволяет держать оптимальное количество потоков, но и позволяет (точнее сказать - создает предпосылки для выполнения) выполнять в одном соединении несколько параллельных запросов (например, MSSQL этого не позволяют, требуя открытия отдельного соединения для параллельного выполнения SQL-запросов с одного клиента)

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

Итак, 7-я версия InterBase - это масштабируемый сервер архитектуры SuperServer. Если вы внимательно читали главу "Classic и SuperServer", то знаете, что главным недостатком архитектуры SuperServer была невозможность эффективно использовать несколько процессоров. В 7-й версии InterBase эта проблема была разрешена, и теперь у InterBase есть возможность работать на многопроцессорных серверах.

Не имея исходных кодов семерки, можно лишь с относительно высокой долей вероятности предположить, что разработчики этой версии пошли по пути оптимизации существующего кода, т е InterBase 7 не переписывался "с нуля". Учитывая огромный объем исходного кода сервера, очевидно, что изменить InteiBase 6.x для поддержки распараллеливания, а затем отследить и протестировать эти изменения - это грандиозная работа, за которую пока не взялся никто, кроме разработчиков из Borland.

Как бы то ни было, InterBase 7 может использовать мощь нескольких процессоров одновременно, а также более эффективно обрабатывает одновременно выполняющиеся SQL-запросы даже на однопроцессорных машинах. Это значительно расширяет сферу его применения и увеличивает ту долю рынка, которую InterBase может забрать у других, гораздо более "монстровидных" СУБД.



InterBase 7 предоставляет средства распределения загрузки по нескольким процессорам. Например, вы можете выделить InterBase только 2 из 4 процессоров, а оставшиеся загрузить другими, не менее важными делами. Для управления привязкой InterBase к процессорам используется специальный параметр CPU_AFFINITY в файле конфигурации сервера ibconfig. В документации к InterBase 7 приведена таблица, показывающая, какое значение должен иметь данный параметр для привязки к желаемым процессорам, и мы здесь ее повторять не будем.

Также в ibconfig появился параметр MAX_THREADS, который устанавливает число одновременно открытых в пуле потоков, готовых к обслуживанию запросов. Изменение этого параметра позволяет управлять загрузкой процессоров - чем меньше потоков, тем меньше процессорного времени будет потреблять InterBase. Для однопользовательских приложений рекомендуется установить этот параметр в 1. Максимальное значение этого параметра - 100.

Важно отметить, что MAX_THREADS не ограничивает число возможных соединений (т. е. обслуживаемых клиентов) с сервером, а лишь устанавливает максимальное значение активных потоков. Таким образом, можно "подсказать" серверу, чтобы он не слишком "экономил" и не закрывал потоки при отсутствии загрузки, т е другими словами, был готов к резкому увеличению количества клиентов.

Расширение механизма событий

Механизм оповещения о событиях (event alerters) является способом асинхронной передачи информации с сервера клиенту. Для этого клиент регистрирует свой интерес в конкретных именованных событиях и переходит в режим ожидания оповещений от сервера, который посылает ему их с помощью команды POST_EVENT, доступной в хранимых процедурах и триггерах. События посылаются сервером не сразу, а в момент подтверждения транзакции. При этом каждое событие имеет внутренний счетчик инициации, т. е. если в течение транзакции команда POST_EVENT для данного события была вызвана несколько раз, то клиенту будет доставлено оповещение только однажды, но его счетчик будет содержать количество инициации. Для работы с событиями на клиентской стороне используются следующие функции API: isc_event_block, isc_que_events, isc_wait_for_ event и isc_event_counts.

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

POST_EVENT 'MY_EVENT', NEW.OPER_TYPE || '_ID=' | CAST(NEW.ID AS VARCHAR(IO));

Для получения списка аргументов событий с их собственными счетчиками инициации была введена новая функция API: isc_event_params.

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

Расширения SQL

В сервере Yaffil реализовано несколько дополнительных языковых конструкций SQL по сравнению с Interbase/Firebird:

Расширенные возможности указания пользовательских планов

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

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

В Yaffil появилась возможность указывать явные планы в некурсорных операторах обновления данных, таких, как UPDATE и DELETE. Дополнительно ним можно добиться обновления или удаления строк данных в заданном порядке указав использование индекса в условии ORDER.

Как известно, в InterBase не разрешается использование явных планов в тексте триггеров. Yaffil снимает это ограничение.

Реализация языка SQL

Здесь можно назвать сразу ряд новых возможностей, как-то: новые команды DDL (RECREATE <object>. CREATE OR ALTER <object>, ALTER VIEW), полноценную поддержку больших целых чисел (встроенный тип BIGINT, реализованный как 64-битное целое), универсальные триггеры на набор операций, возможность использования выражений в параметрах процедур, группировка по встроенным функциям (например, EXTRACT) и т. д.

Добавлены новые встроенные функции - CASE, COALESCE и NULLIF (все они являются частью SQL-стандарта). CASE является базовой для этого ряда функций и реализует условную выборку значений из списка, например:

SELECT CASE WHEN (О.TYPE = 0) THEN 'Доход' ELSE 'Расход' END FROM OPERATIONS 0

или так:

SELECT CASE 0.TYPE WHEN 0 THEN 'Доход' ELSE 'Расход' END FROM OPERATIONS 0

Стоит отметить, что у функции CASE может быть любое количество аргументов, т. е. она не ограничивается только простейшей проверкой типа "ЕСЛИ- ИНАЧЕ", например:

SELECT CASE О.TYPE WHEN О THEN 'Доход' WHEN 1 THEN 'Расход'

ELSE '---' END

FOM OPEPATIONS O

Функция COALESCE является упрощением CASE для проверки на NULL, например:

SELECT COALESCE(0. STATUS, '---') 

FROM OPERATIONS O

Результатом COALESCE будет являться первый аргумент, если он не NULL, или второй аргумент в противном случае. Функция NULLIF также является упрощением CASE, но для немного другого случая:

SELECT NULLIF(О.STATUS1, О.STATUS2) 

FROM OPERATIONS O

Результатом NULLIF будет являться NULL, если оба аргумента равны, или первый аргумент в противном случае.

Кроме встроенных функций, добавлены также новые системные переменные:

CONNECTION_ID - идентификатор текущего соединения; " TRANSACTION_ID - идентификатор текущей транзакции;

ROWS_AFFECTED - количество записей, затронутых (т. е. добавленных, исправленных или удаленных) последним выполненным оператором;

GDSCODE и SQLCODE - соответствующие коды исключений, перехваченных в блоках WHEN.

Переменные CONNECTION_ID и TRANSACTION_ID доступны во всех вариантах SQL, в то время как ROWS_AFFECTED, GDSCODE и SQLCODE - только в PSQL (т. е. в хранимых процедурах и триггерах). Клиентское приложение может получить значения упомянутых системных идентификаторов (CONNECTIONJDD и TRANSACTIONJD) через запрос, аналогичный следующему:

SELECT TRANSACTION_ID FROM RDB$DATABASE;

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

EXCEPTION (без параметров) - заново инициирует перехваченное в WHEN-блоке исключение;

EXCEPTION <name> <msg> - инициирует исключение с текстом, определяемым выражением msg.

Еще одним важным нововведением является поддержка точек сохранения (savepoints), действующих внутри транзакции. Этот стандартный механизм позволяет откатить не всю транзакцию, а только часть ее, выполненную после указанной точки сохранения. Для этого используются следующие SQL-команды:

SAVhPOINT <name>

и

ROLLBACK [WORK] TO [SAVEPOINT] <name>.

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

Помимо всего перечисленного, интерес может представлять и возможность динамического выполнения SQL-выражений в хранимых процедурах и триггерах. Для этого используется новая команда EXECUTE STATEMENT <stmt>, где единственным параметром является строка, содержащая выполняемое SQL-выражение. Например:

stmt_var = 'update my_table set flag = 0 where parent_id = ' || 

cast (:param as varchar(10)); 

EXECUTE STATEMENT stmt_var;

Этим новые возможности в SQL не ограничиваются, но их описание выходит за рамки данной i лавы.

Рекомендуемое расширение для файлов баз данных - *.ib

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

Конечно, InterBase 7 по-прежнему будет работать с базами данных, имена файлов которых имеют расширения любых видов и вообще не имеют расширения, но рекомендуется все же использовать *.ib.

Режим обратной совместимости

Данный режим включается установкой параметра конфигурационного файла LEGACY_DIALECT1 в 1. После этого для клиентов диалекта 1 компилятор SQL выражений будет поддерживать только возможности, существовавшие в InterBase версии 5.x. Поведение сервера при работе с клиентами диалектов 2 и 3 не меняется. Режим совместимости приводит к "освобождению" следующих ключевых слов:

COLUMN CURRENTJJSER ROWS_AFFECTED CONNECTIONJD DESCRIPTOR SKIP CURRENT_DATE EXTRACT SUBSTRING CURRENT_ROLE FIRST TRANSACTION_ID CURRENT_TIME LEAVE TYPE CURRENTJITMESTAMP RECREATE

Семерка - первый шаг нового семейства

Чем InterBase 7 отличается от своих предшественников? Вот главный вопрос, на который отвечает эта глава.

Прежде всего надо отметить, что помимо непосредственно технических новшеств и улучшений в InterBase 7 был введен ряд изменений "политического" характера, направленных на разрушение совместимости с Firebird. Можно предположить, что это было сделано в связи с планами компании Borland выпускать новые версии своих продуктов, в том числе и InterBase, не реже чем раз-два в год. Таким образом, InterBase 7 лишь первый шаг в этом направлении, и можно с большой уверенностью сказать, что в 2003 году 8-я версия InterBase принесет нам много сюрпризов.

Но пока давайте сосредоточимся на технических подробностях 7-й версии InterBase.

SET TERM больше не нужен в isql

Как вы знаете из главы "Хранимые процедуры", для создания хранимых процедур и триггеров с помощью SQL-скриптов и интерпретатора isql необходимо предварять и завершать команды создания и изменения процедур и триггеров специальной командой смены разделителя.

В 7-й версии ликвидирована нужда в команде SET TERM - теперь интерпретатор SQL корректно обрабатывает указанные выше команды и не выдает ошибку, которая ранее являлась просто ночным кошмаром для начинающих (во всяком случае, для тех из них, что не любят читать документацию).

Системные переменные ROWS_AFFECTED, GDSCODE, SQLCODE, TRANSACTIONJD, CONNECTIONJD

Переменная ROWS_AFFECTED содержит количество записей, модифицированных в результате выполнения последнего за ipoca.

Переменная GDSCODE содержит значения инструкции gdscode в обработчике WHEN, однако может использоваться вне контекста WHEN.

Переменная SQLCODE содержит значения инструкции sqlcode в обработчике WHEN, однако может использоваться вне контекста WHEN.

Переменная TRANSACTION_ID содержит номер транзакции.

Переменная CONNECTION_ID содержит номер подключения.

Средства мониторинга

Планируется введение ряда так называемых виртуальных таблиц, которые будут предоставлять пользователю или администратору доступ к внутренней информации сервера (подобный подход использован в InterBase 7.0).

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

Тип данных BIGINT

Дополнительный тип данных BIGINT является аналогом типа данных NUMERIC (18.0) и предлагает более лаконичное и понятное название для 64-битного целого.

Удобная операция объединения строк

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

В качестве примера приведем вариант с объединением двух полей:

CREATE TABLE Т(VI VARCHAR(20000), V2 VARCHAR(20000)}.

При попытке написать VI || V2 Interbase/Firebird выдадут ошибку переполнения еще на этапе компиляции. Сервер Yaffil в качестве результата сформирует строку VARCHAR(32765). Ошибка переполнения возникнет, только если количество символов объединения VI и V2, исключая концевые пробелы, превысит 32765.

Улучшенная производительность

Производительность является одним из ключевых факторов, определяющих пригодность сервера СУБД для использования в конкретном приложении. Производительность определяет максимальную нагрузку, которую сервер может нести на выбранной аппаратной платформе, выраженную, например, в количестве одновременно работающих пользователей или количестве операций, выполняемых в единицу времени. К сожалению, скоростные характеристики линейки серверов InterBase часто уступают показателям конкурентов, таких, как MSSQL или Sybase SQL Anywhere. По производительности Yaffil далеко опережает своих аналогов из клона InterBase. При выполнении тех же самых запросов Yaffil работает в 2-3 раза быстрее, чем InterBase 6.0 и Firebird 1.0. Такие результаты достигнуты благодаря многочисленным улучшениям алгоритмов и оптимизацией кода, большое число критических алгоритмов переписаны на ассемблере х86 убраны ненужные системные вызовы

Улучшенная стратегия вычисления предиката IN и условий, объединенных по OR

По сравнению с InterBase и другими клонами, Yaffil выполняет предикат IN гораздо более эффективно. При этом используется только одно построение битовой карты для индекса, независимо от числа параметров. В других клонах InterBase получим значительное замедление при большом числе параметров, (особенно если IN не ограничивает основной объем выборки), несмотря на одинаковый план исполнения запроса. То же самое произойдет и для условия вида OR:

select * from Т where Fl = .. or F2 = ... or F2

Улучшенное время отклика для версии SuperServer

В серверах Bolrand InterBase версии ниже 7.0, использующих архитектуру SuperServer, одновременное обслуживание нескольких клиентов реализовано по схеме многопоточного сервера. Однако переключение процессора между потоками (диспетчеризация) происходит не по требованию операционной системы, а в моменты времени, выбираемые активным потоком "добровольно". Такая схема очень похожа на реализацию многозадачности в Windows 3.1 и называется невытесняющей многозадачностью.

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

В сервере Yaffil данная проблема ослаблена за счет введения дополнительных точек переключения в наиболее часто повторяющихся участках кода сервера. Для рабочих потоков сервера и о цельно для потока сборки мусора есть возможность задавать величину кванта времени с помощью параметров конфигурации THREAD_QUANTUM и SWEEP_THREAD_QUANTUM. Параметр FORCE_RESHEDULE активизирует дополнительные точки переключения. В результате распределение процессорного времени между рабочими потоками происходит более равномерно.

Улучшенный оптимизатор запросов

Оптимизатор - своего рода "мозг" сервера, и степень его интеллектуальности может кардинально повлиять на скорость работы приложений. Неверно выбранный план может привести к увеличению времени выполнения запроса в тысячи раз. За время своей эволюции от версии InterBase 4.0, не способной вообще оптимизировать явные соединения, и до последних версий в оптимизатор InterBase разработчиками Borland вносились изменения, которые хотя и приводили к улучшению планов для определенных случаев, но часто непредсказуемо сказывались на других запросах. Например, в пятой версии InterBase научился корректно оптимизировать соединения в явном синтаксисе ANSI SQL, но другой способ выборки индексов в ряде случаев приводил к катастрофическому увеличению времени выполнения запросов. Подобные неприятности появились в версии 6.0, в результате многие разработчики не могли перенести свои системы на современную платформу.

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

Однако в тех случаях, когда ручного планирования не избежать, Yaffil предоставляет больше возможностей для этого.

Перечислим некоторые улучшения оптимизатора Yaffil.

Выбор индекса с меньшим числом полей при наличии индекса с большим числом полей

Этот случай часто возникает, когда в таблице имеется большое количество индексов, в том числе составных. Оптимизатор Interbase/Firebird всегда пытался выбрать индекс, который охватывает множество полей, в то время как существовал более быстрый и компактный индекс. Оптимизатор Yaffil автоматически разрешает данную ситуацию. Вот пример: Таблица из трех полей Table 1 (Fl, F2, F3) На нее созданы три индекса: IDX_F1(F1), IDX_F1_F2(F1,F2), IDX_F1_F2_F3(F1,F2,F3) Выполняем запрос:

select * from Tablel where Fl = параметр

Получаем следующие планы для использования индексов: Interbase 6.5/FireBird 1.0:

PLAN (Т INDEX (IDX_F1_F2_F3))

Yaffil:

PLAN (T INDEX (IDX_F1))

Interbase 6.5/FireBird 1.0 используют индекс с максимальным количеством полей, хотя очевидно, что в данном случае надо использовать единственный индекс по полю F1, как это и делает Yaffil. Это очень распространенная ошибка, приводящая к замедлению выполнения запроса, обойти которую без явного планирования достаточно сложно.

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

Этот случай возникает, когда выборка делается по одному полю, а сортировка - по другому, при этом имеется индекс по обоим полям. Пример: пусть существует таблица из трех полей T(F1,F2,F3), есть индексы на следующие сочетания полей: на одно поле IDX_F1(F1), на два первых поля IDX_F1_F2(F1,F2), на все три поля IDX_F1_F2_F3(F1,F2,F3).

Производим запрос следующего вида:

select * from T where Fl=.. order by F2

Получаем планы следующего вида: 

FireBird/InterBase 6.5:

PLAN SORT(Т INDEX (IDX_F1_F2_F3))

Yaffil:

PLAN (T ORDER (IDX_F1))

Исключение из обработки индексов с сильно различающейся селективностью

Пример: пусть у нас есть таблица из трех полей T(F1,F2,F3) с индексами на каждое поле IDX_Fl(Fl), IDX_F2(F2) и IDX_F3(F1). Пусть здесь F1 является уникальным полем (первичный ключ, например), a F2 - неуникальным. Производим запрос:

select * from Т where Fl = параметр! and F2 = параметр2 ...

В результате получаем следующие планы: FireBird/InterBase 6.5:

PLAN (Т INDEX (IDX_F1, IDX_F2))

Yaffil:

PLAN (Т INDEX (IDX_F1))

Оптимизатор Yaffil всегда объединяет индексы с учетом селективности.

Отметим, что в качестве критериев отбора индексов используется не только селективность, но и категории условий, используемых в ограничениях. Так, например, "вес" операции "=" больше, чем "вес" операций "<" и ">".

Улучшенный протокол локальных соединений (XNET)

Локальное соединение в InterBase выполняется с использованием буферов разделяемой памяти и обеспечивает более высокую производительность по сравнению с другими протоколами (TCP и Named Pipes). В документации это называется локальным протоколом или IP Server (IPS) по внутренней терминологии Borland. Вместе с тем локальное соединение в InterBase обладает двумя серьезными недостатками, часто делающими его использование невозможным. Прежде всего, локальное соединение не допускает одновременной параллельной (многопоточной) работы нескольких соединений. Второе клиентское соединение будет заблокировано до момента завершения первого.

Кроме того, для установления соединения используется оконное сообщение, посылаемое клиентом специальному скрытому окну сервера. Если сервер InterBase работает как служба NT и клиентское приложение также работает как служба, они могут использовать разные desktops, при этом посылка оконных сообщений между ними невозможна.

Типичный пример подобной конфигурации - WEB-сервер Microsoft Internet Information Server (US), выполняющий приложения, обращающиеся к базам данных InterBase. Традиционно в таких случаях рекомендуется использовать протокол TCP для установления соединений из сервисов NT, что отрицательно сказывается на производительности.

XNET также является реализацией локального соединения с использованием буферов разделяемой памяти, поэтому его скорость передачи данных идентична "старому" локальному протоколу (IPS). Отличие состоит в том, что его реализация допускает одновременное использование на разных потоках без взаимного блокирования. Для установления соединения больше не используются окна и оконные сообщения, поэтому соединения надежно устанавливаются из служб Windows NT.

Оригинально XNET был разработан специалистами фирмы Borland и планировался как замена ненадежному старому локальному протоколу. Начало разработки датировано в исходном коде 1995 годом.

В сервере Yaffil по сравнению с оригинальным кодом внесены изменения, направленные на повышение надежности работы в случае неожиданного "падения" одной из сторон. Возможность соединения с сервером из служб NT также впервые была реализована в Yaffil.

Строка соединения по XNET аналогична обычной строке локального соединения. Протокол XNET не совместим по локальному подключению с другими версиями InterBase/Firebird, поэтому необходимо использовать клиентскую библиотеку (GDS32.DLL), соответствующую версии сервера. В текущей версии XNET недоступен в Yaffil Classic Server.

Уменьшение размера, занимаемого индексами

Индексы, построенные по текстовым полям с национальным порядком сортировки, занимают в среднем на одну треть меньше места на диске по сравнению с Interbase.

Уменьшение времени, необходимого для резервного копирования и восстановления

В InterBase отсутствует возможность инкрементального резервного копирования, при этом сам процесс backup/restore из-за архитектурных особенностей проходит медленнее по сравнению с серверами СУБД, где запись копии происходит постранично. Резервное копирование большой базы может занимать несколько часов, при этом хоть и возможна работа пользователей, но время отклика ухудшается.

На Yaffil резервное копирование и восстановление происходит в несколько раз быстрее, особенно заметно это на больших базах данных (отсутствует деградация скорости копирования со временем).

Ускоренная работа с индексами

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

Ускоренное обновление данных

Наибольший выигрыш в скорости при использовании Yaffil наблюдается при обновлении данных.

Переработаны алгоритмы, связанные с управлением деревом "грязных страниц" буферного кэша, в результате чего устранено замедление при массивных обновлениях данных в рамках одной транзакции. Ликвидирована известная проблема InterBase, при которой задание числа буферов больше некоторого предела (около 10 000) приводит не к увеличению скорости, а совсем наоборот, при этом возможны даже зависания (известная проблема "10 000 буферов").

Устранена деградация скорости при обновлении большого числа рядов данных, а 1аюке при откате большого числа изменений. Быстрее выполняется массовая вставка данных также за счет оптимизации кода.

Увеличение глубины рекурсии процедур и триггеров

Количество рекурсивных вызовов процедур и триггеров увеличено до 1000.

Версия 1.5 - эволюция или революция?

Так что же собой представляет новая версия Firebird? Чтобы получить ответ на этот вопрос, позволим себе небольшой экскурс в историю. Летом 2001 года администраторами и ведущими разработчиками проекта было принято решение о серьезной переработке исходного кода сервера, доставшегося в наследство от корпорации Borland (в то время Inprise). Это было вызвано следующими соображениями.

необходимость инкапсуляции ключевых объектов ядра СУБД для более качественной их защиты и независимых блокировок (что жизненно важно для реализации в сервере полноценной поддержки SMP);

обеспечение удобства программного расширения подсистем сервера;

реализация более гибкого и контролируемого управления памятью;

обеспечение полного контроля над исключительными ситуациями внутри сервера;

возможность использования в разработке современных библиотек и шаблонов программирования.

Одним из методов достижения этих целей было выбрано использование C++ в качестве языка программирования (в оригинале сервер написан на С) и соответствующее портирование существующего исходного кода. Так как этот процесс является достаточно трудоемким, а ветка версии 1.0 в тот момент времени развивалась очень активно, решили создать отдельную ветку для разработки новой версии сервера (20). что обеспечило участникам проекта бесконфликтную параллельную работу над двумя версиями - текущей и будущей. В соответствии с п ином. вс1к\ нашали hiebnd2 - как олицетворение независимости от истоков и обещание заметных нововведений К моменту выхода версии 1 0 портирование кода было завершено, также уже была реализована новая обработка исключительных ситуаций и перепроектирован менеджер памяти Вскоре после этого был разработан новый универсальный механизм подключения к серверу внешних модулей (plugins), который может быть использован для поддержки неограниченного числа определяемых пользователем языковых кодировок, реализации механизмов безопасности посредством РАМ (pluggable authorization modules), сжатия или шифрования сетевого трафика и т. п.

Так как вся эта работа отняла достаточно много времени, было принято решение о стабилизации кода ветки firebird2, внесении в нее нескольких функциональных улучшений (преимущественно в языке SQL), об исправлении ряда ошибок и выпуске данного кода как версии 1.5.

Таким образом, версия Firebird 1.5 является промежуточной между классической 1.0 и революционной 2.0 и представляет собой первый шаг в направлении разработки радикально улучшенного сервера.

Встраиваемый сервер

Как известно, первые версии сервера InterBase, работающие под операционной системой UNIX и другими, более экзотическими ОС, использовали прямое связывание кода сервера с клиентским приложением. Строго говоря, термины клиент и сервер здесь не очень уместны, так как существует всего один процесс.

Можно провести аналогию с технологией COM (Component Object Model), в которой используется термин "in-process server" (сервер внутри процесса) для обозначения компоненте, загружаемых в адресное пространство клиентского приложения. Такой способ загрузки обеспечивает максимальную эффективность за счет отсутствия накладных расходов, связанных с упаковкой параметров вызова (marshalling), передачей упакованного блока данных в адресное пространство сервера с помощью некоторого транспортного механизма (сетевого протокола или буферов разделяемой памяти) и диспетчеризацией вызова обработчика запроса на серверной стороне.

Архитектура Yaffil Classic дает возможность приложениям использовать внутрипроцессный сервер Yaffil. Такое использование часто называют встраиваемым (embedded), подразумевая легковесность и упрощение тиражирования прикладных систем. По сравнению с традиционным сервером, внутрипроцессный Yaffil не требует запуска дополнительного процесса сервера или инсталляции служб NT. Приложению для работы требуется всего лишь одна библиотека динамической загрузки (DLL). Общий объем исполнимых модулей при этом также сокращается.

Однако встраиваемое использование подразумевает некоторые (возможно, значительные для вашего приложения) ограничения.

Встраиваемый сервер может использоваться только в однопоточных приложениях. Существующее ядро InterBase/Firebird/Yaffil не является безопасным для использования из нескольких потоков (thread-safe). Глобальные структуры данных сервера не защищены от одновременного изменения; кроме того, внутри ядра широко используется локальное состояние потока. Таким образом, поведение сервера будет непредсказуемым при вызове функций сервера с нескольких потоков одновременно, а также при использовании соединений, первоначально открытых в другом потоке.

Если вы разрабатываете программы, работающие в среде сервера приложений или Web-сервера, таких? как СОМ+ или IIS, то встраиваемый сервер для вас также непригоден, поскольку подобные среды используют собственное управление потоками.

Эта глава посвящена СУБД Yaffil

Эта глава посвящена СУБД Yaffil (англ. - дятел) и его особенностям.
После открытия исходного кода InterBase разработчики, использующие сервер в своих проектах, стали пытаться его усовершенствовать, приспосабливая к своим нуждам и улучшая характеристики. В то же время ясно, что самостоятельная модификация кода разрозненными разработчиками исключительно в собственных целях приведет к появлению несовместимых версий и трудностям в сопровождении. В мире программного обеспечения с открытым исходным кодом (Open Source) подобная неприятная ситуация достаточно распространена и имеет название code forking.
В конце 2001 года в результате объединения усилий группы российских разработчиков, использующих InterBase на Windows NT, на свет появился проект Yaffil. За основу разработчики взяли исходный код сервера Firebird 1.0, поскольку он являемся единственным динамично развивающимся клоном InterBase с открытым исходным кодом.
Почему было принято решение создавать новый клон, вместо того чтобы интегрировать изменения с проектом Firebird?
К сожалению, политика координаторов и участников проекта Firebird является достаточно жесткой относительно внедрения новых возможностей. Главным приоритетом команды Firebird является создание стабильной версии на базе существующего исходного кода при сохранении полной платформенной независимости. В то же время разработчики Yaffil считают очень перспективным направлением интеграцию сервера с Windows NT, что потребует введения специфичных для данной ОС возможностей в сервер, что неприемлемо для участников проекта Firebird. Оптимизация производительности также реализуется с использованием зависимых от платформы (аппаратной и ОС) модулей, включая участки кода, реализованные на ассемблере.
В данных условиях представляется целесообразным создание отдельного клона InterBase/Firebird с дополнительными возможностями и лучшей производительностью на Windows NT при сохранении совместимости с другими версиями. Под совместимостью подразумевается следующее:
Возможность переноса баз данных от InterBase 4-6.5/Firebird 1.0 к Yaffil через резервную копию базы данных (backup-restore) и обратно, если в базе данных не используются возможности, специфичные для конкретной версии.
Возможность подключения клиентов Yaffil к серверам InterBase 4.x- 6.х/Firebird 1.0, и наоборот, при условии использования того же протокола транспортного уровня.
Поддержка в Yaffil диалекта SQL, используемого в Firebird v 1.0 и InterBase 6.0.

Выражения в EXCEPTION

Сервер Yaffil расширяет синтаксис инструкции exception. Допускаются три варианта использования:

exception 'исключение'; Этот вариант соответствует синтаксисe interbase/Firebird - сервер выбрасывает исключение, заданное соответствующим идентификатором.

exception 'исключение' 'выражение'; В этом случае сервер также выбрасывает исключение, но его текст заменяется на результат вычисления выражения.

exception; Сервер выбрасывает последнее сформированное исключение. Если до выполнения этой инструкции исключений выброшено не было, то инструкция игнорируется. Этот вариант используется для повторного выбрасывания исключения в обработчиках ошибок WHEN.

Выражения в значениях по умолчанию для доменов

Yaffil позволяет использовать сложные выражения для значений по умолчанию в доменах:

CREATE DOMAIN NEW_DOMAIN AS INTEGER DEFAULT (GEN_ID(NEW_GENERATOR, 1))

Подобная возможность позволяет не писать дополнительные триггера для выполнения схожих действий.

для операционной системы Windows

InterBase CS 4. 0 для операционной системы Windows NT до сих пор используется в системах, несущих большую нагрузку. Переход на более новые версии был невозможен в связи с тем, что архитектура Super Server недостаточно пригодна для работы с большим числом одновременных подключений, в то время как версии сервера архитектуры Classic Server перестали выпускаться Borland, начиная с версии 4.2.

Yaffil Classic Server - лучший вариант обновления сервера, сохраняет все преимущества архитектуры Classic, с лучшей производительностью и надежностью, обладает новыми возможностями последних версий линейки Interbase.

представляет собой бурно развивающуюся

СУБД Yaffil 1. 0 представляет собой бурно развивающуюся СУБД, основанную на исходных кодах InterBase 6.0 и Firebird 1.0.
Yaffil обладает лучшей производительностью по сравнению с InterBase 6.0 и Firebird 1 0 и предоставляет новую функциональность, сохраняя при этом совместимость с Borland InterBase 4-6.5 и Firebird 1.0.
Yaffil существует в варианте с классической архитектурой, что позволяет эффективно использовать его в многопользовательских приложениях, а также на SMP системах
Несмотря на молодой возраст и большое число нововведений, Yaffil версии 1.0 в настоящее время является достаточно стабильным сервером и достойно представляет вклад российских разработчиков в создание семейства наследников InterBase 6.0 Open Edition.


Выход InterBase 7 показал всем, что у компании Borland есть еще "порох в пороховницах", и отказываться от этой СУБД она не намерена.
Нельзя сказать, что InterBase 7 поразил воображение пользователей своими нововведениями, но он сделал очень хороший задел на будущее - прежде всего, благодаря эффективной поддержке многих процессоров. Можно ожидать, что в дальнейших версиях InterBase, ближайшая из которых (может быть, 8 или 7.5) ожидается в 2003 году, будут проведены кардинальные изменения в структуре оптимизатора SQL-запросов, которыми ныне щеголяют "братья-СУБД" Firebird 1.5 и Yaffil 1.0.
В любом случае InterBase 7 стал родоначальником новой ветки СУБД на основе InterBase 6.0 и первой значительно отличающейся от семейства InterBase 6 Open Source/Firebird/Yaffil окончательной версией (release) сервера. Часть его нововведений можно расценивать именно как политическую, направленную на четкое позиционирование и отгораживание от других клонов. Это положительная тенденция, потому что вместо группы сходных серверов с неясными различиями мы, пользователи СУБД, сможем получить несколько отличных серверов баз данных!


Итак, мы совершили обзор событий прошедшего года, которые привели к появлению версии 1.5, и оценили ее возможности. С полной уверенностью можно сделать вывод, что развитие проекта перешло в качественно новую стадию по сравнению с ситуацией, имевшей место один-два года назад. Перечень новых возможностей в языке SQL, а также изменения в архитектуре и сопутствующее улучшение производительности действительно дают новой версии СУБД весьма неплохие шансы на рынке открытых систем. Постоянно растущая инфраструктура проекта, включающая в себя сторонние программные продукты, техническую поддержку и документацию, также способствует укреплению положения проекта в мире Open Source. Все это, включая планы по разработке версии 2.0, позволяет считать Firebird серьезным продуктом, способным быстро и качественно решать задачи, предъявляемые к системам такого класса.

Значения переменных по умолчанию

Сервер Yaffil расширяет синтаксис инструкции declare variable. Можно не указывать ключевое слово variable и указать инициализирующее значение переменной.

Пример:

declare k = 0;

---

---