Ако можете да актуализирате въпроса си с графиката на застой, това би било полезна информация. (Когато приложението ви срещне блокиране, Oracle ще издигне ORA-00060 и файл за проследяване ще бъде записан в user_dump_dest.) Ако погледнете файла за проследяване, ще намерите секция, наречена „Графика на застой“. Ако можете да публикувате това и също така да публикувате изявлението, което е причинило безизходицата, и други изявления, участващи в задънената улица, тогава можем да започнем да правим някои заключения. (Цялата информация, която поисках, е налична във файла за проследяване.)
Както Алесандро спомена, е възможно сесиите, които заключват различни редове в една и съща таблица, да се блокират поради неиндексирани външни ключове в дъщерната таблица на връзка родител/подчинение. Също така е възможно да имате блокиране на две сесии, актуализиращи различни редове от една и съща таблица, дори ако таблицата не е част от връзка родител/дете, ако например таблицата има недостиг на ITL записи.
Отново, публикувайте поисканата по-горе информация и съм сигурен, че можем да определим основната причина за вашата задънена улица.
Добавено на 30.07.2012 г. **
Добавяйки следното, сега, след като файлът за проследяване на блокиране е предоставен:Добре, първо, въз основа на съдържанието на файла за проследяване, това е просто блокиране поради припокриване/сблъскване на сесиите в редовете, които се опитват да заключат. Въпреки предишните ви коментари за това, че блокирането е на различно редове, тук съм, за да ви кажа, че това конкретно блокиране се дължи на заключване на ниво ред на същото редове.
Фактът, че графиката за блокиране показва режима, в който се държи заключването, е „X“ (изключителен) и режимът, в който се чака заключването, е „X“, ми казва, че това е просто заключване на ниво ред.
В този случай SID 20 изпълнява „изтриване от RPT_TABLE.TEMP_TABLE_T1, където TEMP_T1_ID=:1“ и вече е заключване на rowid AAAPDIAAMAAAEfIAAA.
Междувременно SID 790 изпълнява „RPT_TABLE.T1_UPDATE_StoredProc“, докато вече държи заключване на rowid AAAPDIAAMAAAEfGAAA.
Забележете от секцията „Редове, чакащи“ на файла за проследяване, че SID 20 чака на реда, който SID 790 държи, а SID 790 чака на реда, който SID 20 държи. Това е класическа безизходица.
Малко допълнителна информация:
-
Типът на опашката е TX (вижте графиката за блокиране), така че това определено не заключване поради неиндексирани външни ключове. Ако се заключваше поради неиндексирани FK, типът на опашката щеше да бъде TM, а не TX. (Има поне още един случай, в който се включват TM опашки и това не са неиндексирани FK. Така че, не приемайте, че TM enqueue винаги означава неиндексирани FK.)
-
Режимът, в който се чака заключването, е „X“ (изключителен), така че това е заключване на ниво ред. Ако чаканият режим беше „S“ (споделен), тогава не да бъде заключване на ниво ред. По-скоро може да е недостиг на ITL или PK или правоприлагане в Обединеното кралство.
Надявам се това да помогне!
