Транзакция только для чтения остается активной (и в некоторой степени интересной), пока не будет подтверждена. При этом активная транзакция только для чтения, для которой рекомендуется уровень изоляции READ COMMITTED (см. главу 26), никогда не становится застрявшей и не влияет на систему обслуживания.
! ! !
ВНИМАНИЕ! Не путайте транзакцию только для чтения с транзакцией чтения/записи, которая выполняет передачу выходного набора пользовательскому интерфейсу от оператора SELECT. Даже если приложение делает выходной набор набором только для чтения, оператор SELECT внутри транзакции чтения/записи может стать - и часто бывает - причиной замедления работы системы.
. ! .
Версии записей отмененных транзакций вычищаются из базы данных, когда они обнаруживаются в процессе обычной обработки данных. Как правило, если к строке обращается оператор, то любая неинтересная старая версия записи, подходящая для удаления, будет отмечена для процесса сборки мусора.
Некоторые "закоулки" базы данных могут не посещаться операторами в течение длительного времени, следовательно, нет гарантии, что все версии записей, созданные в .отмененных транзакциях, будут отмечены и в итоге удалены. До тех пор, пока остаются старые версии записей, заинтересованная транзакция должна оставаться "интересной" для сохранения состояния базы данных.
! ! !
СОВЕТ. Полное сканирование базы данных (обычно при резервном копировании) выполнит сборку мусора, но не сможет изменить состояния транзакций. Это работа для "полной" сборки мусора, выполняемой при чистке (sweep) базы данных.
. ! .
Транзакции в отмененном (rolled back) состоянии не включены в сборку мусора. Они остаются заинтересованными, пока чистка базы данных не отметит их как "подтвержденные" и не освободит их для сборки мусора. В системах с низким уровнем конфликтов периодическая ручная чистка базы данных может быть единственно необходимой работой.
Некоторые системы, плохо спроектированные для работы с конфликтами, демонстрируют высокий уровень откатов транзакций и имеют тенденцию накапливать 'заинтересованные' транзакции быстрее, чем с ними могут справиться автоматические процедуры обслуживания базы данных. В подобных системах должна часто выполняться ручная чистка, если складывается впечатление, что автоматическая чистка не работает надлежащим образом.
Транзакции считаются "мертвыми", если они находятся в активном состоянии, но не существует связанного с ними контекста соединения. Обычно транзакции "умирают" в клиентских приложениях, которые не заботятся об их завершении перед отключением от базы данных. Умершие транзакции также являются частью обломков, оставленных после краха клиентских приложений или поломки сетевых соединений.
Сервер не может определить разницы между действительно активными транзакциями и умершими. Пока тайм-аут ожидания соединения работает, и регулярная сборка мусора своевременно убирает ненужные транзакции, умершие транзакции не создают проблем. При срабатывании тайм-аута соединения выполнится их откат, и в итоге этот мусор будет убран.
Частое большое накопление умерших транзакций может стать проблемой. Поскольку они не являются отмененными, слишком многие из них остаются заинтересованными на чрезмерно большой срок. В системе, где поведение пользователя, частые аварии программ, отключение питания или сетевые ошибки генерируют огромное количество умерших транзакций, мусор от умерших транзакций становится большой проблемой.
Зависшие транзакции (limbo transactions), подробно обсуждаемые в главе 26, появляются в результате сбоя двухфазной операции COMMIT для нескольких баз данных. Система распознает их как особый случай, требующий вмешательства человека, поскольку сам сервер не может определить, будет ли их подтверждение или откат влиять на согласованность данных в разных базах данных.
Единственный способ разрешить зависшие транзакции - это запустить для базы данных инструмент gfix с соответствующими переключателями для достижения желаемого результата. Утилита изменяет состояние транзакции либо на "подтвержденное", либо на "отмененное". С этого момента с ней осуществляется работа, как и с любой другой подтвержденной или отмененной транзакцией.
OIT и OAT должны постоянно изменяться
Совет "OIT и OAT должны постоянно изменяться" является ключевой фразой для решения всех проблем, связанных с производительностью базы данных. Время, потраченное на изучение цикла жизни транзакций в многоверсионной архитектуре Firebird, будет одним из лучших ваших вложений в дальнейшую работу с Firebird другими базами данных с открытыми текстами[93].
Для начала понимания взаимодействия между клиентскими процессами, которые "владеют" транзакциями, с одной стороны, и учетом транзакций, выполняемым в базе данных, с другой, будет полезным познакомиться с механизмом взаимодействия сервера и транзакций.
Внутренний образ состояния транзакции (Transaction State Bitmap, TSB) является таблицей, содержащей идентификаторы транзакций и их состояние, поддерживаемой сервером и инициализируемой при начальном подключении к базе данных. В логических терминах TSB содержит каждую транзакцию, найденную в инвентарных страницах транзакций, которая новее, чем OIT. Пока существуют подключения к базе данных, серверный процесс поддерживает TSB динамически, добавляя новые идентификаторы транзакций, изменяя состояние и удаляя идентификаторы, которые становятся неинтересными (т. е. будут подтверждены). Сервер записывает изменения в инвентарные страницы транзакций без повторного их чтения с диска.
На рис. 25.2 иллюстрируются эти шаги. Каждый раз, когда сервер обрабатывает запрос для транзакции, он читает заголовочную страницу базы данных, чтобы получить идентификатор для следующей транзакции. Изменяется TSB, и изменения записываются в инвентарные страницы базы данных.
"Движение вперед OIT (И/ИЛИ OAT)" - это термин Firebird, обозначающий увеличение значений OIT и OAT
В заголовочной странице базы данных, когда подтверждающиеся более старые транзакции исключаются из TSB, а новые транзакции, в свою очередь, становятся "старейшими". Обновление заголовочной страницы базы данных последними значениями OIT, OAT и следующей транзакции являются частью такой динамической экологии.
Если новая транзакция является транзакцией SNAPSHOT, она будет иметь свою собственную копию TSB для поддержания согласованного вида состояния базы данных, каким он был при ее старте. Транзакция READ COMMITTED всегда обращается к самому последнему "глобальному" TSB для получения доступа к версиям, подтвержденным после ее старта.
Рис. 25.2. Взаимодействие процесса клиент-сервер с TSB
Условия для изменения OIT и OAT
Каждый раз, когда сервер стартует другую транзакцию, он проверяет состояние идентификаторов транзакций, которые он хранит в TSB, удаляя те, чье состояние было изменено на "подтвержденное", и заново вычисляет значения OIT и OAT. Он сравнивает их с хранимыми значениями в странице базы данных и при необходимости включает их в данные, сопровождающие запись в заголовок базы данных идентификатора новой "следующей транзакции".
Значение OAT будет увеличиваться, если транзакции будут достаточно короткими, чтобы предохранять активные транзакции и мусор от самых новых транзакций - от нагромождения, OIT будет увеличиваться, пока клиентские процессы подтверждают свою работу в большей степени, нежели отменяют их или теряют в результате аварий. При этих условиях производительность базы данных будет хорошей.
Застрявшая OAT хуже, чем застрявшая OIT. В системе с хорошей производительностью разница между OAT и самой новой транзакцией должна приблизительно равняться
количеству запущенных клиентских процессов, умноженному на среднее количество выполняющихся транзакций в каждом процессе. Выполняйте чистку базы данных во внерабочее время или используйте автоматическую чистку или оба варианта.
93
Хорошо понимать цикл жизни транзакций в Firebird, если вы работаете и с другими реляционными СУБД, например, с PostgreSQL, которая имитирует многоверсионную архитектуру Firebird.