А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Вариант сервера с классической архитектурой для платформы Win32 несколько отличается от аналогичных дистрибутивов для UNIX-систем. Главная особенность - это единый пакет, включающий в себя SS и CS сборки сервера, причем оба варианта скомпонованы статически. Это позволило избежать реализации кода сервера в библиотеке, разделяемой всеми процессами, и обеспечить четкое разделение клиентской и серверной подсистем. Результатом этого стала независимость стандартных инструментов командной строки (isql, gbak, gfix и т. д.) от дистрибутива сервера, а также возможность смены архитектуры установленного сервера "на лету", т. е. без переустановки дистрибутива.
Далее, версия сервера для платформы Win32 теперь использует другой ключ реестра (HKLMSoftwareFirebirdSQLFirebird). В случае отсутствия данного ключа сервер все равно будет работоспособен, его базовая директория при этом будет определяться физическим расположением файлов сервера. Следовательно, в простейшем случае (при запуске сервера как приложения, т. е. с ключом командной строки "-а") установка вообще не требуется - достаточно просто скопировать файлы сервера в отдельный каталог и запустить его.
Теперь можно иметь возможность запуска сервера Firebird параллельно с сервером IB/FBI на одном компьютере, а также запуска нескольких копий сервера (все это при условии работы на разных портах, что настраивается перед запуском сервера).
Помимо собственно СУБД, проект Firebird включает также драйверы ODBC. JCA-JDBC (Туре 4) и .NET-провайдер, которые распространяются вместе с сервером или отдельно.
Реализация языка 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 лавы.
Расширение механизма событий
Механизм оповещения о событиях (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.
Такая возможность позволяет максимально гибко реализовать "интеллектуальное" обновление данных в клиентском приложении, внешнюю репликацию и ряд других задач.
Производительность
В разработке новой версии были предприняты некоторые шаги по повышению быстродейивия сервера. Во-первых, небольшой прирост производительности дала переработка некоторых подсистем сервера, в частности оптимизация менеджера памяти.
Был улучшен алгоритм работы оптимизатора запросов, в частности в следующих направлениях:
* использование индексов в подзапросах с агрегатами,
* игнорирование "плохих" индексов, т. е. индексов, использование которых может привести лишь к замедлению выполнения запроса;
* более качественный анализ селективности индексов при построении плана;
* оптимальное построение плана в случае доступности одно- и многосегментных индексов;
* более совершенное использование индексов в условиях типа "OR", особенно в случае сложных предикатов (в частности, сложных неявных соединений).
Кроме этого, были внесены изменения в код сервера, приводящие к эффективному использованию оперативной памяти в процессе сортировки (режим использования памяти настраивается через файл конфигурации). Реализована также новая стратегия работы сортировщика, оптимизированная для некоторых видов запросов, требующих неполной выборки данных.
Известно, что текущая реализация архитектуры SS имеет ряд серьезных недостатков, одним из которых является блокирование сервера долго выполняющимися запросами, что приводит к практической невозможности работы в этот момент других пользователей. Эта проблема была частично решена в версии 1.5 путем доработки внутреннего планировщика потоков, базирующейся на более гибком управлении интервалами работы потоков и их приоритетами. В результате заметно улучшена реакция сервера при одновременной работе нескольких пользователей с высокой нагрузкой.
Было добавлено несколько новых системных индексов (т. е. индексов на системные таблицы), что позволило более быстро выполнять запросы к метаданным в случае сложной схемы и, следовательно, более оперативно заполнять кэш метаданных при первом обращении к ним.
Все вышесказанное привело к заметному увеличению производительности. Например, выполнение серии промышленных тестов TPC-R (уже упоминавшейся в этой книге) показало почти трехкратное превосходство новой версии по сравнению с линией 1.0. Разумеется, это не значит, что выполнение абсолютно всех 5апросов будет осуществляться быстрее, но позволяет рассчитывать на улучшение производительности в ряде случаев
