Jika Anda dapat memperbarui pertanyaan Anda dengan grafik kebuntuan, itu akan menjadi informasi yang berguna. (Saat aplikasi Anda menemui jalan buntu, Oracle akan memunculkan ORA-00060, dan tracefile akan ditulis ke user_dump_dest.) Jika Anda melihat di file trace, Anda akan menemukan bagian yang disebut "Grafik Deadlock". Jika Anda dapat memposting itu, dan juga memposting pernyataan yang menyebabkan kebuntuan dan pernyataan lain yang terlibat dalam kebuntuan, maka kita dapat mulai menarik beberapa kesimpulan. (Semua informasi yang saya minta tersedia di file jejak.)
Seperti yang disebutkan Alessandro, mungkin saja sesi mengunci baris yang berbeda di tabel yang sama ke jalan buntu karena kunci asing yang tidak diindeks pada tabel anak dari hubungan induk/anak. Selain itu, Anda mungkin mengalami kebuntuan pada dua sesi yang memperbarui baris berbeda dari tabel yang sama, meskipun tabel tersebut bukan bagian dari hubungan induk/anak, jika, misalnya, tabel memiliki kekurangan entri ITL.
Sekali lagi, kirimkan informasi yang diminta di atas, dan saya yakin kami dapat menentukan akar penyebab kebuntuan Anda.
Ditambahkan pada 30/7/2012 *
Menambahkan yang berikut, sekarang setelah file pelacakan kebuntuan telah disediakan:Oke, pertama, berdasarkan konten file jejak, ini adalah kebuntuan sederhana karena sesi tumpang tindih/bertabrakan pada baris yang mereka coba kunci. Terlepas dari komentar Anda sebelumnya tentang kebuntuan yang berbeda baris, saya di sini untuk memberi tahu Anda bahwa kebuntuan khusus ini disebabkan oleh penguncian tingkat baris pada sama baris.
Fakta bahwa grafik kebuntuan menunjukkan mode penguncian adalah 'X' (eksklusif) dan mode menunggu kunci adalah 'X', memberi tahu saya bahwa ini adalah penguncian tingkat baris sederhana.
Dalam hal ini, SID 20 menjalankan "hapus dari RPT_TABLE.TEMP_TABLE_T1 di mana TEMP_T1_ID=:1" dan sudah kunci di rowid AAAPDIAAMAAAEfIAAA.
Sementara itu, SID 790 sedang menjalankan "RPT_TABLE.T1_UPDATE_StoredProc", sambil menahan kunci pada rowid AAAPDIAAMAAAEfGAAA.
Perhatikan dari bagian "Baris menunggu" dari file jejak, bahwa SID 20 sedang menunggu di baris yang dipegang SID 790 dan SID 790 sedang menunggu di baris yang dipegang SID 20. Ini adalah kebuntuan klasik.
Beberapa informasi tambahan:
-
Jenis enqueue adalah TX (lihat grafik kebuntuan), jadi, ini pasti tidak penguncian karena kunci asing yang tidak diindeks. Jika terkunci karena FK yang tidak diindeks, jenis enqueue adalah TM, bukan TX. (Setidaknya ada satu kasus lain di mana enqueue TM terlibat, dan itu bukan FK yang tidak terindeks. Jadi, jangan berasumsi bahwa enqueue TM selalu berarti FK yang tidak diindeks.)
-
Mode kunci sedang menunggu adalah 'X' (eksklusif), jadi ini adalah penguncian tingkat baris. Jika mode yang ditunggu adalah 'S' (dibagikan), maka mode tersebut tidak menjadi penguncian tingkat baris. Sebaliknya, itu bisa berupa kekurangan ITL atau penegakan PK atau Inggris Raya.
Semoga membantu!
