Шрифт:
Интервал:
Закладка:
Если зазор между 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): появляется, если последующий набор строк, прочитанный транзакцией, отличается от набора, который был прочитан в начале работы транзакции. Фантомные явления появляются, если при последующем чтении появляются новые добавленные строки и/или исчезают удаленные строки, которые были подтверждены с момента первого чтения.
В табл. 26.1 показаны определяемые в стандарте четыре уровня изоляции с явлениями, которые управляют их определениями.
READ UNCOMMITTED вовсе не поддерживается в Firebird, READ COMMITTED соответствует стандарту. На двух следующих уровнях этого уровня изоляции природа многоверсионной архитектуры превалирует над ограничениями двухфазной блокировки, предлагаемой стандартом. Отображение указанных в стандарте уровней REPEATABLE READ и SERIALIZABLE невозможно.
Таблица 26.1. Уровни изоляции и управление феноменами в стандарте SQL
Уровень изоляции
"Грязное"чтение
Неповторяемое чтение
Фантомы
READ UNCOMMITTED
Допустимо
Допустимо
Допустимо
READ COMMITTED
Недопустимо
Допустимо
Допустимо
REPEATABLE READ
Недопустимо
Недопустимо
Допустимо
SERIALIZABLE
Недопустимо
Недопустимо
Недопустимо
READ COMMITTEDСамым низким уровнем изоляции является READ COMMITTED. Только на этом уровне изоляции вид состояния базы данных, измененного в процессе выполнения транзакции, изменяется каждый раз, когда подтверждаются версии записей. Вновь подтвержденная версия записи заменяет ту версию, которая была видна при старте транзакции. Подтвержденные добавления, выполненные после старта транзакции, становятся видимыми для нее.
Уровень изоляции READ COMMITTED обеспечивает неповторяемое чтение и не избавляет от феномена фантомных строк. Это наиболее полезный уровень для операций реального времени над большим объемом данных, т. к. сокращается количество конфликтов данных, однако он не является подходящим для задач, которым нужен воспроизводимый вид.
Поскольку уровень изоляции READ COMMITTED имеет скоротечную природу, то транзакция (именно этого уровня) может быть сконфигурирована в соответствии с потребностями реагирования на подтверждение изменений и наличие ожидающих завершения изменений других транзакций.
* При установке RECORD_VERSION (флаг по умолчанию) сервер позволяет транзакции читать самую последнюю подтвержденную версию записи. Если транзакция имеет режим READ WRITE (чтение/запись), то она будет способна перезаписывать самую последнюю подтвержденную версию записи, если ее идентификатор (TID) более поздний, чем идентификатор транзакции, подтвердившей самую последнюю версию записи.
* При установке NO_RECORD_VERSION сервер эффективно имитирует поведение систем, которые используют двухфазную блокировку для управления параллельностью. Он блокирует для текущей транзакции чтение строки, если для нее существует изменение, ожидающее завершения. Разрешение ситуации зависит от установки разрешения блокировки.
• При задании WAIT транзакция будет ждать, когда другая транзакция либо подтвердит, либо отменит свои изменения. Эти изменения затем станут доступными, если другая транзакция их отменит или если идентификатор транзакции более поздний, чем идентификатор другой транзакции. Транзакция будет завершена аварийно по конфликту блокировки, если идентификатор другой транзакции будет более поздним.
При задании NOWAIT транзакция немедленно получит сообщение о конфликте блокировки.
! ! !
ПРИМЕЧАНИЕ. Транзакция READ COMMITTED может видеть все последние подтвержденные версии, которые позволяют читать установки этой транзакции, что подходит для операций добавления, изменения, удаления и выполнения. При этом любые выходные наборы, полученные в транзакции по оператору SELECT, должны получать измененный вид базы данных.
- Delphi. Учимся на примерах - Сергей Парижский - Программирование
- Сделай видеоигру один и не свихнись - Слава Грис - Программирование / Руководства
- Психбольница в руках пациентов - Алан Купер - Программирование