Базы данных Oracle - статьи
Блокировки, моды изоляции и прочие скучные предметы
Заголовок раздела не случаен, ибо у многих одно лишь упоминание о перечисленных темах вызывает неудержимую зевоту. В этом нет ровным счетом ничего предосудительного (если конечно зевота не переходит плавно в последующий сон на рабочем месте), ибо, скажем, разработчик приложений имеет право задаться вопросом, зачем собственно ему нужно разбираться, а тем более заботиться обо всей этой нудной внутренней кухне СУБД. К сожалению, разобраться все-таки стоит, ибо любая многопользовательская СУБД по сравнению с “персональной” содержит достаточно много подводных камней, а отсутствие адекватного учета всех этих факторов в приложении - особенно если оно работает не с Oracle, а с другой СУБД - может привести к весьма неприятным сюрпризам.
Oracle всегда славился - и заслуженно - за свою способность практически одинаково эффективно обслуживать любое количество одновременно работающих пользователей (естественно при наличии достаточных аппаратных ресурсов сервера), не проявляя склонности к выраженной (а тем более скачкообразной) деградации производительности системы при увеличении этого числа. Такое - надо сказать, совсем не частое - свойство обусловлено целым рядом архитектурных решений, и не в последнюю очередь хорошо выверенным механизмом блокировок. Oracle устроен так, что в принципе - за исключением некоторых весьма специфических случаев - разработчик приложений может не заботиться об эффектах многопользовательского режима работы. Сервер сам обеспечивает все необходимые блокировки (хотя конечно позволяет выполнять их и “вручную”), причем осуществляет их всегда на минимально возможном уровне: скажем при изменении записи только эта запись и будет заблокирована от изменений другими пользователями (до завершения транзакции). Такой принцип “бескомпромиссно минимального уровня блокировок” порой подвергается критике за то, что он, как утверждается, “требует большого количества ресурсов для своей реализации”. Подобное утверждение справедливо лишь в том случае, когда блокировки в системе реализуются неким внешним по отношению к ней механизмом (неким “менеджером блокировок”), использующим свои внутренние (а потому критичные по использованию ресурсов) структуры для учета и управления всеми активными и потенциальными блокировками. В Oracle же необходимость обеспечения блокировок учитывается уже в организации хранения данных, а сам этот механизм является неотъемлемой частью ядра сервера, “переплетаясь” со всеми его внутренними алгоритмами.
Однако это еще далеко не все. Если роль блокировок при изменении данных более или менее понятна и не вызывает обычно недоуменных вопросов, то гораздо сложнее бывает понять, какова же эта роль, и чем чреваты связанные с ней эффекты при выполнении операций чтения.
