Программирование >>  Oracle 

1 ... 49 50 51 [ 52 ] 53 54 55 ... 469


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


READ

UNCOMMmtD

Блокирование при чтении

COMMITTED

(Другие СУБД)

REPUTABLE READ

SERALIZABLE

READ COMMITTED

Многовариантный доступ

Нет*

SERIALIZABLE

(Oracle)

При использовании selectfor update nowait

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




Транзакции

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

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

Транзакции базы данных обладают свойствами, сокращенно называемыми ACID (Atomicity, Consistency, Isolation, Durability). Вот что означают эти свойства:

Неделимость (Atomicity). Транзакция либо выполняется полностью, либо не выполняется.

Согласованность (Consistency). Транзакция переводит базу данных из одного согласованного состояния в другое.

Изолированность (Isolation). Результаты транзакции становятся доступны для других транзакций только после ее фиксации.

Продолжительность (Durability). После фиксации транзакции изменения становятся постоянными.



Транзакции в Oracle обладают всеми перечисленными выше характеристиками. В этой главе мы опишем влияние неделимости на выполнение операторов в СУБД Oracle. Будут рассмотрены операторы управления транзакцией, такие как COMMIT, SAVEPOINT и ROLLBACK, и то, как в транзакции обеспечивается выполнение требований целостности. Мы также постараемся выяснить, почему приобретаются плохие привычки в работе с транзакциями при разработке приложений для других СУБД. Разберемся с распределенными транзакциями и двухэтапной фиксацией. Наконец, рассмотрим реальные проблемы, возникающие при использовании и журнализации транзакций, а также выясним, какую роль могут играть сегменты отката.

Операторы управления транзакцией

В СУБД Oracle нет оператора начать транзакцию . Транзакция неявно начинается с первого же оператора, изменяющего данные (установившего блокировку ТХ). Операторы COMMIT или ROLLBACK явно завершают транзакции. Всегда завершайте транзакции явно с помощью оператора COMMIT или ROLLBACK, иначе решение о том, фиксировать или откатывать, автоматически примет используемое инструментальное средство или среда. При обычном в1ходе из сеанса SQL*Plus без фиксации или отката эта утилита предполагает, что нужна фиксация, и автоматически ее выполняет. При завершении же программы на языке Pro*C по умолчанию выполняется откат.

Транзакции в Oracle неделимы: либо фиксируется (делается постоянным) результат выполнения каждого из операторов, составляющих транзакцию, либо результаты выполнения всех операторов откатываются. Эта защита распространяется и на отдельные операторы. Оператор либо завершается полностью успешно, либо полностью откатывается. Обратите внимание: я написал, что оператор откатывается. Сбой в одном операторе не вызывает автоматического отката ранее выполненных операторов. Их результаты сохраняются и должны быть зафиксированы или отменены пользователем. Прежде чем разбираться детально, что означает свойство неделимости для оператора и транзакции, рассмотрим операторы управления транзакциями.

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

ROLLBACK. В простейшем случае выполняется просто оператор ROLLBACK.

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



1 ... 49 50 51 [ 52 ] 53 54 55 ... 469

© 2006 - 2024 pmbk.ru. Генерация страницы: 0.001
При копировании материалов приветствуются ссылки.
Яндекс.Метрика