Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Борри Хелен

isql

Вы можете получить похожий вид статистики из заголовка базы данных в сессии isql при использовании команды SHOW DATABASE.

Многие инструменты администратора Firebird сторонних разработчиков создают эквивалентные отчеты.

Что может рассказать вам статистика

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

транзакций. Любой мусор с такого номера транзакции и выше не будет обрабатываться.

Если зазор между OAT и NEXT TRANSACTION определяет гораздо большее количество транзакций, чем подсчитываемое количество подключенных пользователей и их задач, вы можете быть уверенными, что большое количество мусора не будет обрабатываться сборщиком мусора. Если этот зазор будет увеличиваться, работа с базой данных будет все больше и больше замедляться. Серверы будут выдавать ошибку "Out of memory" (недостаточно памяти) или просто будут аварийно завершаться, потому что TSB расходует большой объем памяти или приводит к тому, что сервисы управления системной памятью используют слишком сильную фрагментации памяти. Дешевые серверы - особенно те, которые нагружены предоставлением дополнительных сервисов- даже могут не получить достаточно ресурсов для записи сообщения в протокол.

Если вам кажется, что зазоры между OIT и OAT или между OAT и NEXT TRANSACTION приводят к проблемам в вашей системе, вы можете многое узнать о воздействиях чистки базы данных и улучшения ваших приложений, если сохраните протоколы статистики.

! ! !

СОВЕТ. Для получения текстовых файлов простой статистики просто перенаправьте выход утилиты gstat -h в текстовый файл в соответствии с правилами вашей командной строки. В утилите isql используйте команду output <имя файла> для перенаправления результатов выполнения команды SHOW DATABASE.

. ! .

Пора дальше

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

ГЛАВА 26. Конфигурирование транзакций.

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

Параллельность

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

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

* будут согласованными в текущем представлении базы данных;

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

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

Факторы, влияющие на параллельность

Четырьмя параметрами конфигурации, влияющими на параллельность, являются:

* уровень изоляции;

* способ разрешения блокировок;

* способ доступа;

* резервирование таблиц.

На одном из уровней изоляции (READ COMMITTED) также рассматриваются текущие состояния версий записей.

Уровень изоляции

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

В Firebird уровень изоляции может быть:

* READ COMMITTED:

• RECORD_VERSION;

• NO RECORD_VERSION;

* SNAPSHOT;

* SNAPSHOT TABLE STABILITY.

Стандартные уровни изоляции

Стандарт SQL по изоляции транзакций "симпатизирует" механизму двухфазной блокировки, которую использует большинство реляционных СУБД для реализации изоляции. Это является его отличительной чертой по сравнению с большинством других стандартов. Он определяет изоляцию не столько в теоретических терминах, сколько в терминах феноменов, допускаемых каждым уровнем (или запрещаемых им). Феноменами, с которыми имеет дело стандарт, являются:

* "грязное" чтение (Dirty read): появляется, если транзакция способна читать неподтвержденные (ожидающие завершения) изменения, выполненные другими транзакциями;

* неповторяемое чтение (Non-repeatable read): появляется, если последующие чтения набора строк в рамках этой же транзакции могут отличаться от того, что было прочитано транзакцией в начале ее работы;

* фантомные строки (Phantom rows): появляется, если последующий набор строк, прочитанный транзакцией, отличается от набора, который был прочитан в начале работы транзакции. Фантомные явления появляются, если при последующем чтении появляются новые добавленные строки и/или исчезают удаленные строки, которые были подтверждены с момента первого чтения.