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

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

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

Доступные системные временные таблицы

Название таблицы

Что содержит

TMPSATTACHMENTS

По записи на каждое соединение к базе данных

TMP$DATABASE

По записи на каждую базу данных, к которой вы подсоединились

TMP$POOL_BLOCKS

По записи на каждый блок памяти в каждом пуле

TMP$POOLS

По записи на каждый пул памяти

TMP$PROCEDURES

По записи на каждую выполненную в данном соединении процедуру

TMP$RELATIONS

По записи на каждую таблицу, к которой было обращение в данном соединении

TMPSSTATEMENTS

По записи на каждый выполняемый в данный момент запрос, для всех соединений

TMP$TRANSACTIONS

По записи на каждую активную (или в состоянии limbo) транзакцию

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

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

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 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.

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.

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

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

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

Были добавлены 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()

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

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

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

isc_get_client_version(),

isc_get_client_major_version(),

isc_get_client_minor_version().

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

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

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