В том же (или в другом) сеансе мы затем удаляем все данные из таблицы. Более того, мы даже фиксируем (COMMIT) это удаление. Строк больше нет - не так ли? На самом деле их можно извлечь с помощью курсора Фактически, результирующее множество, возвращаемое командой OPEN, было предопределено в момент открытия курсора. Мы не прочитали при открытии курсора ни одного блока данных таблицы, но результат оказался жестко зафиксированным. Мы не сможем узнать этот результат, пока не извлечем данные, но с точки зрения нашего курсора результат этот неизменен. Дело не в том, что СУБД Oracle скопировала все эти данные в другое место при открытии курсора; данные сохранил оператор delete, поместив их в область данных под названием сегмент отката.

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

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

В запрашиваемой таблице хранятся балансы банковских счетов. Она имеет очень простую структуру:

create table accounts ( account number number primary key, account balance number

В реальной таблице счетов будут сотни тысяч строк, но для простоты мы будем рассматривать таблицу всего с четырьмя строками (более детально мы рассмотрим этот пример в главе 3):

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

select sum(account balance) from accounts;

Конечно, в данном примере ответ очевиден - 1250 $. Однако что произойдет, если мы прочитаем строку I, а при считывании строк 2 и 3 с одного из банкоматов будет вы-

полнена транзакция, переводящая 400 $ со счета 123 на счет 456? Наш запрос прочтет 500 $ в строке 4 и выдаст результат 1650 $, не так ли? Конечно, этого надо избежать, так как подобный результат ошибочен - никогда такого баланса по счетам в базе данных не было. Нужно понять, как СУБД Oracle избегает подобных ситуаций и чем отличаются используемые при этом методы от используемых во всех остальных СУБД.

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

Как уже б1ло сказано, вы не сможете в полном объеме использовать преимущества СУБД Oracle, если не понимаете концепцию многовариантности. В СУБД Oracle многовариантность используется для получения результатов, соответствующих моменту начала выполнения запроса, при этом не блокируется ни единой строки (пока транзакция по переводу денег изменяет строки 1 и 4, они будут заблокированы от других изменений, но не от чтения, выполняемого, например, нашим запросом SELECT SUM...)-Фактически в СУБД Oracle нет разделяемых блокировок чтения , типичных для других СУБД, - они в ней просто не нужны. Все устранимые препятствия для одновременного доступа были устранены.

Итак, как же СУБД Oracle получает корректный, согласованный результат (1250 $) при чтении, не блокируя данных, другими словами, не мешая одновременному доступу? Секрет - в механизме выполнения транзакций, используемом в СУБД Oracle. При любом изменении данных Oracle создает записи в двух разных местах. Одна запись попадает в журналы повторного выполнения, где Oracle хранит информацию, достаточную для повторного выполнения, или наката , транзакции. Для оператора вставки это будет вставляемая строка. Для оператора удаления это будет запрос на удаление строки в слоте X блока Y файла Z. И так далее. Другая запись - это запись отмены, помещаемая в сегмент отката. Если транзакция завершается неудачно и должна быть отменена, СУБД Oracle будет читать предварительный образ из сегмента отката, восстанавливая необходимые данные. Помимо отмены транзакций, СУБД Oracle использует сегменты отката для отмены изменений в блоках при их чтении, то есть для восстановления данных блока на момент начала выполнения запроса. Это позволяет читать данные несмотря на блокировку и получать корректные, согласованные результаты, не блокируя данные.

Итак, в нашем примере Oracle получает результат следующим образом:

Время Запрос

Транзакция по переводу со счета на счет

Л Читает строку 1, sum получает

значение 500 $

ТЗ Т4 Т5

Т7 Т8

Изменяет строку 1, устанавливает исключительную блокировку на строку 1, предотвращая другие изменения. В строке 1 теперь хранится значение 100 $

Читает строку 2, sum получает значение 750 $

Читает строку 3, sum получает значение 1150 $

Читает строку 4, определяет, что она была изменена. Выполняется откат блока до того состояния, которое он имел в момент времени Т1. Запрос затем прочитает значение 100 $ из этого блока

Выдает 1250 $ в качестве результата суммирования

Изменяет строку 4, устанавливает исключительную блокировку на строку 4, предотвращая другие изменения (но не чтение). В строке 4 теперь хранится значение 500 $.

Транзакция фиксируется

В момент времени Т6 СУБД Oracle фактически читает поверх блокировки, установленной транзакцией на строке 4. Именно так реализуется неблокируемое чтение: СУБД Oracle просто проверяет, изменились ли данные, игнорируя тот факт, что они в настоящий момент заблокированы (т.е. определенно изменены). Она извлечет старое значение из сегмента отката и перейдет к следующему блоку данных.

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

Это согласованное по чтению представление данных всегда выполняется на уровне оператора SQL, - результаты выполнения любого оператора SQL всегда согласованы на момент его начала. Именно это свойство позволяет получать предсказуемый набор данных в результате, например, следующих вставок:

for х in (select loop

from t)