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

Что такое управление одновременным доступом?

Средства управления одновременным доступом - это набор функций, предоставляемых сервером баз данных для обеспечения одновременного доступа к данным и их изменения множеством пользователей. Реализация механизма блокирования в базе данных, вероятно, наиболее существенный фактор при определении степени параллелизма, обеспечиваемого приложением (если проще, масштабируемости). Как уже было сказано, есть множество видов блокировок. Это и блокировки транзакций (ТХ), максимально масштабируемые как по производительности, так и по количеству (неважно, одна блокировка в системе или миллион); и блокировки ТМ и ЯОД (применяемые, по возможности, в минимально ограничивающем режиме). Это и блокировки, используемые сервером Oracle в процессе управления доступом к общим структурам данных, - от очень эффективного и быстрого механизма защелок до более громоздкого, но полнофункционального механизма внутренних блокировок.

Но управление одновременным доступом связано не только с блокировками. СУБД может предоставлять и другие средства для обеспечения управляемого, но в значительной степени параллельного доступа к данным. Например, в Oracle имеется средство обеспечения многовариантного доступа (описанное в главе 1). Поскольку сервер Oracle использует многовариантный доступ для обеспечения согласованных по чтению представлений данных, мы получаем весьма приятный побочный эффект: сеанс, читающий данные, никогда не будет заблокирован сеансом, записывающим данные, т.е. запись не блокирует чтения. Это одно из фундаментальных отличий Oracle от остальных СУБД. Запрос на чтение в Oracle никогда не блокируется, он никогда не станет причиной взаимной блокировки с другим сеансом и никогда не даст результат, не существующий в базе данных.

Модель многовариантного доступа Oracle для обеспечения согласованности по чтению всегда применяется на уровне оператора (для каждого запроса), но может применяться и на уровне транзакции. В этом разделе я бы хотел продемонстрировать, как многовариантный доступ используется с различными уровнями изолированности транзакции, определяемыми стандартом SQL92.

Уровни изолированности транзакции

Стандарт ANSI/ISO SQL92 определяет четыре уровня изолированности транзакции, дающих разные результаты для одного и того же сценария транзакции. То есть выполняются одни и те же действия, одинаковым способом, с теми же данными, но, в зависимости от уровня изолированности транзакции, результат может быть различным. Эти

уровни изолированности определяются в терминах трех явлений , допускаемых или запрещаемых на данном уровне изолированности транзакции:

Грязное чтение (dirty read). Результат настолько же плох, как и название. Допус-

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

Неповторяемость при чтении (non-REPEATABLE READ). Это означает, что если строка читается в момент времени T1, а затем перечитывается в момент времени T2, то за этот период она может измениться. Строка может исчезнуть, может быть обновлена и т.д.

Чтение фантомов (phantom read). Это означает, что если выполнить запрос в момент времени T1, а затем выполнить его повторно в момент времени Т2, в базе данных могут появиться дополнительные строки, влияющие на результаты. От неповторяемости при чтении это явление отличается тем, что прочитанные данные не изменились, но критериям запроса стало удовлетворять больше данных, чем прежде.

Уровни изолированности SQL92 определяются как допускающие или разрешающие возникновение каждого из описанных выше явлений:

Сервер Oracle явно поддерживает уровни изолированности READ COMMITTED и SERIALIZABLE, как они определены стандартом. Однако это еще не все. В стандарте SQL92 была попытка установить уровни изолированности транзакции, обеспечивающие различную степень согласованности для запросов, выполняемых на каждом из уровней. REPEATABLE READ - уровень изолированности, по утверждению создателей, гарантирующий получение согласованных по чтению результатов запроса. При реализации в соответствии с их определением READ COMMITTED не дает согласованных результатов, а уровень изолированности READ UNCOMMITTED используется для не блокирующего чтения.

В Oracle уровень изолированности READ COMMITTED позволяет достичь согласованности запросов по чтению. (В других СУБД запросы в транзакции с уровнем READ COMMITTED могут возвращать результаты, никогда не существовавшие в базе данных.) Более того, Oracle поддерживает также то, для чего предназначался уровень изолиро-

ванности READ UNCOMMITTED. Грязное чтение применяется в качестве не блокирующего, т.е. запросы не блокируются при изменении данных и сами не блокируют изменения читаемых данных. Однако серверу Oracle для этого не нужно грязное чтение (он его и не поддерживает). Грязное чтение - это реализация не блокирующего чтения, которое вынуждены использовать другие СУБД.

Помимо четырех уровней изолированности транзакции, определенных в стандарте SQL92, Oracle обеспечивает еще один уровень - транзакции только для чтения. Транзакция только для чтения эквивалентна при чтении уровню изолированности REPEATABLE READ или SERIALIZABLE в SQL92. Такая транзакция видит только изменения, зафиксированные на момент ее начала, но в этом режиме не разрешена вставка, изменение и удаление данных (другие сеансы могут изменять данные, но транзакция только для чтения - нет). Используя этот режим, можно достичь уровней REPEATABLE READ и SERIALIZABLE READ без чтения фантомов.

Теперь давайте рассмотрим, как многовариантный доступ и согласованность по чтению соотносятся с перечисленными выше схемами изолированности и как другие СУБД, не поддерживающие многовариантного доступа, достигают тех же результатов. Это будет инструктаж для пользователей других СУБД и тех, кто верит, будто знает, что должны обеспечивать уровни изолированности. Также будет интересно посмотреть, как стандарт, SQL92, который, казалось бы, должен сглаживать различия между СУБД, фактически их допускает. Этот очень детальный стандарт может быть реализован множеством способов.

Уровень изолированности READ UNCOMMITTED

Уровень изолированности READ UNCOMMITTED разрешает грязное чтение. Сервер Oracle не использует грязного чтения, и не допускает его. Основное назначение уровня изолированности READ UNCOMMITTED - стандартное определение не блокирующего чтения. Как уже было показано, Oracle по умолчанию обеспечивает не блокирующее чтение. Надо создать специальные условия, чтобы оператор SELECT блокировал что-либо в базе данных (есть частный случай сомнительной распределенной транзакции, который рассматривается в главе 4). Каждый отдельный оператор, будь-то

SELECT, INSERT, UPDATE или DELETE, выполняется как согласованный по чтению.

Реализуемый сервером Oracle способ достижения согласованности по чтению б1л продемонстрирован в главе 1 на примере банковских счетов. Здесь мы снова вернемся к этому примеру, чтобы более детально описать, что происходит в СУБД Oracle при многовариантном доступе, а что - в других СУБД. Напомню, что в блоке данных предполагалось наличие одной строки таблицы.

Начнем с той же простой таблицы и запроса:

create table accounts (

account number number primary key, account balance number

select sum(account balance) from accounts;