Pokud byste mohli aktualizovat svou otázku pomocí grafu uváznutí, byla by to užitečná informace. (Když vaše aplikace narazí na uváznutí, Oracle vyvolá ORA-00060 a trasovací soubor bude zapsán do user_dump_dest.) Pokud se podíváte do trasovacího souboru, najdete sekci nazvanou "Graf mrtvého bodu". Pokud to můžete zveřejnit a také zveřejnit prohlášení, které způsobilo zablokování, a další prohlášení související s uváznutím, pak můžeme začít vyvozovat nějaké závěry. (Všechny informace, které jsem požadoval, jsou dostupné ve trasovacím souboru.)
Jak zmínil Alessandro, je možné, že relace zamykající různé řádky ve stejné tabulce uvíznou v důsledku neindexovaných cizích klíčů v podřízené tabulce vztahu rodič/dítě. Je také možné, že u dvou relací při aktualizaci různých řádků stejné tabulky dojde k uváznutí, i když tabulka není součástí vztahu rodič/dítě, pokud má například tabulka nedostatek záznamů ITL.
Znovu zveřejněte výše požadované informace a jsem si jist, že dokážeme určit hlavní příčinu vašeho uváznutí.
Přidáno 30.7.2012 **
Nyní, když byl dodán soubor trasování zablokování, přidejte následující:Dobře, za prvé, na základě obsahu souboru trasování se jedná o jednoduché zablokování kvůli překrývání/kolizi relací na řádcích, které se snaží uzamknout. Navzdory vašim předchozím poznámkám o tom, že zablokování je jiné řádky, jsem tu, abych vám řekl, že toto konkrétní zablokování je způsobeno uzamčením na úrovni řádku na stejném řádky.
Skutečnost, že graf uváznutí ukazuje režim, ve kterém je zámek držen, je 'X' (exkluzivní) a režim, ve kterém se čeká na zámek, je 'X', mi říká, že se jedná o jednoduché zamykání na úrovni řádku.
V tomto případě SID 20 provádí "delete from RPT_TABLE.TEMP_TABLE_T1 where TEMP_T1_ID=:1" a již má zámek na rowid AAAPDIAAMAAAEfIAAA.
Mezitím SID 790 provádí „RPT_TABLE.T1_UPDATE_StoredProc“, přičemž již drží zámek na rowid AAAPDIAAMAAAEfGAAA.
Všimněte si v části "Řádky čekající na" trasovacího souboru, že SID 20 čeká na řádku, který obsahuje SID 790, a SID 790 čeká na řádku, který má SID 20. Toto je klasická patová situace.
Některé další informace:
-
Typ fronty je TX (viz graf uváznutí), takže to rozhodně není zamykání kvůli neindexovaným cizím klíčům. Pokud by byl zamykaný kvůli neindexovaným FK, typ fronty by byl TM, nikoli TX. (Existuje alespoň jeden další případ, kdy se jedná o fronty TM, a nejde o neindexované FK. Nepředpokládejte tedy, že enqueue TM vždy znamená neindexované FK.)
-
Režim, na který se čeká na zámek, je 'X' (exkluzivní), takže se jedná o zamykání na úrovni řádku. Pokud by režim čekání byl „S“ (sdílený), pak by nebyl být zamykání na úrovni řady. Spíše by to mohl být nedostatek ITL nebo vymáhání PK nebo Spojeného království.
Doufám, že to pomůže!