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

Sweeping. В InterBase это процесс, который собирает и освобождает старые и ненужные версии записей в базе данных. Этот процесс запускается при достижении порогового значения (известного как Sweeping Interval) и является следствием \nioi оиериюнной ар\шек1\ры InieiBase-сервера В других коммерческих СУБД uiKoio процесса не!. Процесс Sweeping может быть явно вызван с помощью у шли! администрирования InterBase. Sweeping - это сборка "мусора", выполняемая для каждой таблицы в базе данных.

System tables (системные таблицы). Реляционные СУБД самодостаточны. Это означает, что данные о структуре пользовательских таблиц также хранятся в таблицах. Эти таблицы, которые хранят данные о данных (метаданные или схему данных), создаются автоматически и называются системными таблицами. Они содержат информацию в том числе и о самих себе, что похоже на попытку выяснить, что был раньше - курица или яйцо. По соглашению названия системных.таблиц и их полей начинаются с префикса RDBS. Однако что действительно отличает системные объекты от остальных, так это особый флаг, распознаваемый InterBase'oM. который хранится в специальном поле в системных таблицах, - в этих таблицах хранится информация о различных объектах базы данных (таблицах, процедурах, генераторах и т. д.).

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

Transaction log (лог транзакций). Обычная реляционная СУБД (и некоторые объектно-ориентированные СУБД) использует отдельный файл, в котором хранится история транзакций. Когда происходит какая-либо поломка, сервер при запуске читает этот файл и определяет, какие изменения в базе данных нужно подтвердить, а какие отменить. InterBase не пользуется такими приспособлениями, потому что в случае возникновения поломки многоверсионная архитектура сервера (см. MGA) позволит начать работу сервера немедленно, а от ненужных версий записей, оставшихся от неподтвержденных транзакций, избавляться при следующей операции чтения-изменения этих данных.

Transaction zero. Все пользовательские транзакции могут только видеть подтвержденные данные или сообщить об ошибке, если новейшая версия записи была создана в рамках другой транзакции, но еще не подтверждена. Но существует транзакция №0, которая запускается сервером. Эта транзакция запущена в особом состоянии предварительной завершенности, поэтому она может видеть все изменения, произведенные в рамках всех транзакций, и завершенных, и подтвержденных, и все версии записей. Это необходимо, например, для осуществления условий ссылочной целостности (смотрите referential integrity) и для обслуживания индексов Оак как индексы отлеживают все версии во всех нолях, на которые они распространяются).

UDF. Сокращение для User Defined Function (определенные пользователем функции). В InterBase имеется небольшое количество встроенных функций, которые определяются стандартом SQL. Для расширения функциональности разработчик может писать функции, вызываемые InterBase-сервером таким образом, что они могут использоваться как встроенные. Библиотека FreeUDFLib служит демонстрацией возможностей UDF, также предоставляя набор очень полезных и часто требующихся функций.

Unique key (уникальный ключ). Значение, которое идентифицирует каждую мнись u\upic/M в ыблице и оыичас! ее oi осыльныч записей Сдедившедьио, юлько одно значение уникальною ключа используется для каждой записи. Простейшим типом уникального ключа является поле, значения которого не могут повторяться, как идентификатор (табельный номер) работника внутри компании. Часто одно поле не удовлетворяет условиям уникальности, поэтому нужно использовать комбинацию полей. Если не существует подходящей для уникального ключа комбинации, то используют суррогатный ключ (см. Surrogate key). Когда объявляется уникальный ключ в InterBase, то автоматически создается соответствующий индекс, причем всегда в порядке возрастания.

Y-Valve. Внутри InterBase имеет несколько "серверов", и когда происходит подсоединение, то InterBase должен решить, какой из серверов использовать для конкретной базы данных. Алгоритм для определения нужного сервера называется Y-valve (по определению Стива Тентона (Steve Tendon)). Помимо прочего Y- Valve должен определить, использовать ли прямой доступ к базе данных (локальная база данных) или подсоединиться к удаленному InterBase-серверу (в InterBase Classic-архитектуры) и какую версию использовать для чтения данной ODS (в случае, когда один и тот же InterBase-сервер может читать разные версии ODS).

GUID (Global Unique Identifier) - глобальный уникальный идентификатор. Под GUID обычно понимается 128-битовое уникапьное значение, которое получается с помощью механизма генерации GUID на основе текущей даты и времени, а также системных номеров процессора и материнской платы. Механизм GUID позволяет получить огромное количество уникальных идентификаторов. Поломч GUID можем быть использован для уникальной идентификации различных объектов (например, СОМ-серверов).

V4_LOCK_MEM_SIZE 98304

ANY_LOCK_MEM_SIZE 98304

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

Во всех версиях InterBase, исключая те, которые исполняются под управлением ОС VMS, конфликты распределения ресурсов разрешаются с помощью таблицы блокировок, которую ведет InterBase (только при употребление VMS InterBase пользуется его менеджером блокировок). В архитектуре Classic таблица блокировок находится в совместно используемой всеми серверными процессами памяти. В архитектуре SuperServer таблица блокировок является частью самого серверного процесса.

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

Изменение размера таблицы блокировок может повлиять:

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

* на число одновременных транзакций. Каждая транзакция имеет блокировку, которая ее идентифицирует. Блокировка используется для синхронизации транзакций, а также для того, чтобы распознать случаи, когда транзакция завершилась без подтверждения (commit) или отката (rollback).

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

V4_LOCK_SEM_COUNT 32

ANY_LOCK_SEM_COUNT 32

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

Операционная система

Количество семафоров по умолчанию

EPSON SEMAPHORES

10

М88К SEMAPHORES

10

UNIXWARE SEMAPHORES

10

NCR3000 SEMAPHORES

25

SCO_UN1X SEMAPHORES

25

sgi SEMAPHORES

25

IMP SEMAPHORES

25

DELTA SEMAPHORES

25

Ultrix SEMAPHORES

25

DGUX SEMAPHORES

25

DECOSF SEMAPHORES

16

Other UNIX

32

Семафоры используются для блокировок и сообщений о событиях. Теоретически InterBase должен использовать очень маленькое количество семафоров - 32 должно быть более чем достаточно.

Если в файле протокола InterBase InterBase.log вы видите сообщение об ошибке "semaphores are exhausted", то следует увеличить количество семафоров.