Операторы DDL всегда дают вам неявное коммитирование или вы можете получить неявный откат?

Если вы находитесь на полпути через транзакцию и выполняете оператор DDL, например, обрезая таблицу, транзакция завершается.

Мне было интересно, всегда ли это так и по определению, или есть где-то скрытая настройка, которая откатывала бы транзакцию вместо того, чтобы совершать транзакции.

Спасибо.

Изменить, чтобы уточнить...

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

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

Ответ 1

Нет, он всегда будет зафиксирован.

Если вы хотите откат, вам придется сделать это до DDL.

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

Ответ 2

Технически DDL выполняет commit до того, как он выполнит и ПОСЛЕ выполнения.

Да, такая же ссылка из Cookie, но это другой аспект той же проблемы. Крайне важно понять это не только одно, то есть два, и они происходят как раз перед, так и сразу после.

Ответ 3

На самом деле это произойдет, если он МОЖЕТ. Если он не может успешно выполнить, DDL завершится с ошибкой. Один из способов остановить его совершение - это нарушение отложенного ограничения.

create table fred (id number);
alter table fred add constraint id_ck check (id >0) initially deferred;
insert into fred values (-1);
SQL> create table junk(val number);
create table junk(val number)
*
ERROR at line 1:
ORA-02091: transaction rolled back
ORA-02290: check constraint (GC_REF.ID_CK) violated
SQL> desc junk
ERROR:
ORA-04043: object junk does not exist

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

Ответ 4

A таблица обрезания или таблица изменений или таблица создания всегда вызывают фиксацию.

Почему вы хотите откат, когда вы делаете таблицу обрезания?

Ответ 5

Здесь - статья AskTom, которая может помочь. Из статьи:

"Мне было интересно, почему операторы DDL не выполняются внутри автономной транзакции (например, последовательности), поэтому они не повлияли бы на любую ожидающую транзакцию пользователя...

Вы можете уточнить?

Последующий отчет 24 июня 2003 г. - 7 утра США/восток:

что было бы "запутанным", как не так. во всяком случае, у вас есть атраны, поэтому, если хотите, вы можете. "

Итак, если вам действительно нужно, вы можете вставить свой DDL внутри автономной транзакции и делать то, что хотите.

EDIT: Итог заключается в том, что, если вы не перейдете на явные длины, чтобы "подорвать" Oracle, DDL собирается выполнить фиксацию. Тем не менее, если вам абсолютно необходимо, чтобы фиксация выполнялась в определенный момент, почему бы просто не выполнить ее явно?

Ответ 6

Операторы DDL всегда выполняют автоматическую фиксацию после выполнения.

Если вы хотите откат в случае сбоя (на стороне сервера), вы можете установить определенные флаги для указания сбоя и предпринять соответствующие действия.

например: если вы создали таблицу table1. и в то же время вы вставляете запись в другую таблицу.

но вставка не удалась по определенной причине (set flag = true). Тогда в этом случае вы не можете откат, так как оператор create является оператором ddl, поэтому вы можете отменить изменения в базе данных, отбросив таблицу (table1) в зависимости от значения флага по инструкции Drop.

Ответ 7

Я согласен с DCookie и Tom об автономной транзакции. Я тоже хотел бы сказать это.

Пример псевдокода:

Do some DML
Call autonomous function, that performs DDL
Do some more DML
rollback or commit all the DML - your choice

Я не вижу в этом ничего полезного. Если исходный DML и DDL касаются одной и той же таблицы/объекта, это не сработает. Вы будете спорить, когда пытаетесь выполнить DDL. Как и любые две транзакции, блокирующие друг друга. И если они независимые объекты, я думаю, я не понимаю, почему имеет место порядок выполнения.