Я и ёжик
Member
Откуда: СПб
Сообщений: 1511
|
| yuniki | 1) Получается Oracle не использует 2PL для блокирования при изменнеиях - Почему так? А это ясно видно при журналированиии Tomom Кайтом в автономной транзакции - если бы это было не так, то то у нас журнал бы не подвисал на ожидании, а прежде , чем начал бы работать тригер журналирования, ВСЕ записи исходного предикатного множества были бы заблокированы.
|
Искать в каком месте, какой “журнал бы не подвисал на ожидании" не имею сейчас возможности, но Вы по-моему неправильно понимаете 2PL. 2PL требует, что бы блокировки сначала ставились, а потом ( в конце транзакции) снимались. Нет требования , что бы они ВСЕ ставились сразу, что и невозможно, транзакция может состоять из нескольких операторов, выполняя один нельзя знать , что надо блокировать выполняя другой, да и в рамках выполнения одного оператора нельзя поставить ВСЕ блокировки СРАЗУ. 2PL требует что бы выставленная блокировка снималось в конце транзакции , а не в середине, т.е. чтобы не было внутри транзакций цепочек блокировок типа "постановка-снятие-постановка-снятие...".
| yuniki | 2) Нигде при обсуждении причин мини-отката не нашел ответа на вопрос: Почему нельзя в случае, если очередная строка при сканировании перестает попадать в исходное на начало UPDATE оператора предикатное множество, просто взять и пропустить ее и идти дальше - разве это как-то нарушит совместность данных ?
|
Потому, что это не соответствует никакому последовательному расписанию транзакций. Если Вы дочитаете книгу Бернштайна, которую Вам рекомендовали tengizk и Merle_, до момента обсуждения неблокирующих шедулеров транзакций, то увидите, что для шедулера с упорядочиванием по меткам времени, если изменяющая транзакция натыкается на данные, которые были изменены после её начала, она должна быть откачена ( иначе будет нарушение сериализуемости). На уровне изоляции Oracle Serializable ( т.е. SNAPSHOT в теории, поскольку в Oracle нет "честного" Serializable) так и происходит, выдается ошибка ORA-8177 ( can't serialize). Oracle уровень изоляции Read Commited, является некоторым гибридом между теоретическим Read Committed и Snapshot, с некоторой натяжкой его можно назвать Snapshot-м на уровне отдельного оператора. Т.е. если оператор натыкается на данные, измененные после его начала, то он должен быть откачен, если откачен один оператор, то вроде бы должна быть откачена и вся транзакция, но это было бы несколько дороговато, поэтому Oracle после отката оператора пытается его выполнить снова (перезапуск). Натяжка заключается в том , что откат и перезапуск осуществляется не всегда, а только при некоторых условиях. Почему так сделано и правильно ли это, здесь долго ломали копья vc123 с одной стороны и кто-то из DBGroup Consulting c Fucker-ом, но остались при своём.
Если Бернштайн слишком объемен и сложен, можно посмотреть сначала что-нибудь типа - Гектор Гарсиа-Молина Джеффри Ульман и Дженнифер Уидом "Системы баз данных. Полный курс", у них хорошие главы посвященные управлению параллельным исполнением заданий, там рассмотрены и блокировочные шедулеры и некоторые неблокировочные шедулеры транзакций. Книга по-моему ещё лежит в книжных магазинах. |