statistics_level (пробела не должно быть).
План практически полностью совпадает с тем, что я уже выкладывал вначале:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Plan
MERGE STATEMENT ALL_ROWSCost: 93
19 MERGE CYBERCOM.B24_QUEUE
18 VIEW
17 NESTED LOOPS OUTER Cost: 93 Bytes: 37 Cardinality: 1
14 VIEW Cost: 93 Bytes: 22 Cardinality: 1
13 FILTER
1 TABLE ACCESS FULL TABLE CYBERCOM.B24_CACHE Cost: 3 Bytes: 22 Cardinality: 1
5 VIEW VIEW BILLING.index$_join$_013 Cost: 90 Bytes: 182 Cardinality: 14
4 HASH JOIN
2 INDEX RANGE SCAN INDEX BILLING.PAYMENT_CUSTOMER_IDX Cost: 3 Bytes: 182 Cardinality: 14
3 INDEX RANGE SCAN INDEX BILLING.PAYMENT_INPUT_MOMENT_IDX Cost: 428 Bytes: 182 Cardinality: 14
7 TABLE ACCESS BY INDEX ROWID TABLE BILLING.SERVICES Cost: 5 Bytes: 13 Cardinality: 1
6 INDEX RANGE SCAN INDEX BILLING.SERV_CUSTOMER_IDX Cost: 1 Cardinality: 5
12 TABLE ACCESS BY INDEX ROWID TABLE BILLING.BM_SERVICE_MONEY Cost: 15 008 Bytes: 928 Cardinality: 58
11 NESTED LOOPS Cost: 16 342 Bytes: 7 696 Cardinality: 296
9 TABLE ACCESS BY INDEX ROWID TABLE BILLING.SERVICES Cost: 5 Bytes: 50 Cardinality: 5
8 INDEX RANGE SCAN INDEX BILLING.SERV_CUSTOMER_IDX Cost: 1 Cardinality: 5
10 INDEX RANGE SCAN INDEX BILLING.SVRM_SERVICE_IDX Cost: 332 Cardinality: 71 133
16 TABLE ACCESS BY INDEX ROWID TABLE CYBERCOM.B24_QUEUE Cost: 0 Bytes: 15 Cardinality: 1
15 INDEX UNIQUE SCAN INDEX (UNIQUE) CYBERCOM.B24_QUEUE_PK Cost: 0 Cardinality: 1
Сессию, которая держит блокировку.
Тогда это явно не она. Это сессия, которая сейчас висит.
А сессии, которая держит блокировку, сейчас на сервере нет.
Если выполнение запроса прервать, то запрос со списком блокировок возвращает пустой результат.
В TOAD в разделе Locks блокировки тоже появляются только когда выполняется запрос с merge. Если его отменить, то и блокировка пропадает.
А как найти, что изначально вызывает блокировку?
В waits верхние три строчки занимают log file sync, db file seq. read и db file scatter read.
Это может быть лог (откат транзакции)?
Если в моем запросе закомментировать блок, связанный с BM_SERVICE_MONEY, то весь merge выполняется быстро (секунды за 3).
То есть запрос "висит" только если внутри using используется BM_SERVICE_MONEY.
Хотя в чистом виде подзапрос внутри using выполняется быстро.
Как такое может быть?
