Я больше скажу - есть спец запросы которые вообще не парсятся оптимизатором (емнип у них текст запроса будет как table_blablabla)

Забыл как они называются

Ща с телефона просто лёжа в кроватке. Посплю - скажу

Их можете увидеть в v$open_cursor

а если копнуть глубже, что там происходит? ну вот мы делаем update.
прочитали блок. нашли строку. записали себя в ITL блока. попытались изменить строку, нашли transaction id, которая ее поменяла, транзакция еще активна.
дальше наш апдейт через recursive sql по transaction id находит блокирующую сессию и обходит граф блокировок, чтобы проверить, нет ли в нем самого себя?

🤝

Я так понимаю тут сплошь теоретики с опытом 20+ лет
Сами потестите и получите тайминг меньше 600мс - тогда учите
Обычно на это уходит 1-3 секунды
Только что перепроверил в 19.12 - ничего нового

дык ить дай свой тест кейс

тест кейс на дедлоки?
вы серьезно?
create table t2(id number(1));
Table created.

Elapsed: 00:00:00.03


SQL> update t2 set id=3 where id=1;

1 row updated.

Elapsed: 00:00:00.00
SQL> update t2 set id=5 where id=2;
update t2 set id=5 where id=2
                        *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource


Elapsed: 00:00:09.16
SQL> update t2 set id=5 where id=2;
update t2 set id=5 where id=2
                        *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource


Elapsed: 00:00:06.16
SQL> /
update t2 set id=5 where id=2
                        *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource


Elapsed: 00:00:03.16
SQL> .
SQL> /
update t2 set id=5 where id=2
                        *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource


Elapsed: 00:00:03.17
SQL> /


/




/
update t2 set id=5 where id=2
                        *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource


Elapsed: 00:00:06.16
SQL> SQL> SQL> update t2 set id=5 where id=2
                        *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource


Elapsed: 00:00:03.18

Во-первых, хз что ты делаешь - у тебя пропущена блокировка тех строк на которые лочатся, собственно строк вставленных даже не показано, во-вторых как ты видишь никаких 600мс, в третьих, у тебя сессия сама проверяет на дедлок (читай как трассировать enqueue)

Покажи как надо

Есть известный таймаут в 3 секунды для сложных блокировок(например ТМ и внешние ключи) - сессия сама проверяет раз в 3 секунды

10:46:24 SQL> insert into t2 values (01);

1 row created.

Elapsed: 00:00:00.00
10:46:35 SQL> insert into t2 values (02);

1 row created.

Elapsed: 00:00:00.01
10:46:42 SQL> commit;

Commit complete.

Elapsed: 00:00:00.00

вот строки если что

как я вижу везде больше секунды

event 10704?

Доброго дня.
Помогите плиз разрулить согласованность данных.
Есть функция confirm_document в которую передается ид документа. Данная функция запускается из сервиса asp net core и может запускаться параллельно (пачкой задач) с одним и тем же ИД. Мне нужно что бы апдейт прошел СТРОГО один раз, но оно все равно проскакивает несколько.
https://pastebin.com/29cHnjFW

update documents set status = 2 where id = :p_id and status = 1?

ну и return sql%rowcount

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