Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизатор - своего рода "мозг" сервера, и степень его интеллектуальности может кардинально повлиять на скорость работы приложений. Неверно выбранный план может привести к увеличению времени выполнения запроса в тысячи раз. За время своей эволюции от версии 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 всегда объединяет индексы с учетом селективности.

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

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

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

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

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

В сервере 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 при своей инсталляции, поскольку не используют файловый кэш.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Индексы по выражениям (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) в вычисляемых выражениях, с их помощью можно выполнять эффективный поиск по практически любому условию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование явных планов в 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)

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

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

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

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

Улучшенный протокол локальных соединений (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.

Ограничение времени ожидания для транзакций (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), управляющую временем ожидания при запуске каждой транзакции индивидуально.

Инструкция 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 с

Выражения в EXCEPTION

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

Пример:

declare k = 0;

Тип данных BIGINT

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

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

В 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

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

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

Пример:

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

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

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

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

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

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

Использование переменной окружения 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" ( ... );

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

Файлы внешних таблиц могут располагаться ТОЛЬКО в одном из каталогов, разрешенных конфигурационным параметром 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"

Использование сервера 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. Не забудьте поместить этот файл в каталог, в котором находится исполнимый (.ехе) модуль программы.

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

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

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

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

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

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

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

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

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

Данный режим включается установкой параметра конфигурационного файла 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы влиять на состояние запросов, транзакций, соединений и т.д., нужно изменить столбец 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)

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

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

* 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'

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

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

Новый тип данных: 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 7 появились новые ключевые слова, связанные с вышеупомянутым типом BOOLEAN:

BOOLEAN, TRUE, FALSE, UNKNOWN

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

ROWS, TIES, PERCENT

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

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

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

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

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

Новые функции 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()

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

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

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

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

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

isc_get_client_version(),

isc_get_client_major_version(),

isc_get_client_minor_version().

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дистрибутив

Первое, на что стоит обратить внимание, это отличие в именах файлов. Исполняемый файл сервера теперь называется либо 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-провайдер, которые распространяются вместе с сервером или отдельно.

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

Здесь можно назвать сразу ряд новых возможностей, как-то: новые команды DDL (RECREATE