Pertama-tama, select pernyataan tidak pernah mengunci apa pun di Oracle, cukup gunakan versi data terakhir yang tersedia secara konsisten. Ini bukan kasus untuk select ... for update yang mengunci data seperti update sejak Oracle 9i, tetapi tidak ada for update klausa dalam kueri dari pertanyaan.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Sesi #72 memegang kunci level tabel (TM) dengan tipe "Baris Eksklusif" (SX) dan ingin mendapatkan kunci "Berbagi Baris Eksklusif" (SSX) di meja yang sama. Sesi ini diblokir oleh Sesi #24 yang sudah memegang kunci level tabel dari jenis yang sama (SX) dan menunggu selama kunci SSX tersedia.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Ini (baris kedua) menunjukkan situasi yang persis sama, tetapi dalam arah yang berlawanan:Sesi #24 menunggu kunci SSX tersedia, tetapi diblokir oleh Sesi #72 yang telah menahan kunci SX di meja yang sama.
Jadi, Sesi #24 dan Sesi #72 saling menghalangi:terjadi kebuntuan.
Kedua jenis kunci (SX dan SSX) adalah kunci tingkat tabel.
Untuk memahami situasinya, saya sarankan untuk membaca artikel ini oleh Franck Pachot.
Di bawah ini adalah kutipan dari artikel ini, yang secara langsung relevan dengan situasi Anda (perhatikan bahwa singkatan SSX dan SRX setara):
Integritas referensial juga memperoleh kunci TM. Misalnya, masalah umum dengan kunci asing yang tidak diindeks mengarah ke kunci S pada tabel anak saat Anda mengeluarkan penghapusan, atau pembaruan pada kunci tersebut, pada tabel induk. Ini karena tanpa indeks, Oracle tidak memiliki satu pun sumber daya tingkat yang lebih rendah untuk dikunci untuk mencegah penyisipan bersamaan yang dapat melanggar integritas referensial.
Ketika kolom kunci asing adalah kolom utama dalam indeks biasa, maka entri indeks pertama dengan parentvalue dapat digunakan sebagai sumber daya tunggal dan dikunci dengan TXlock tingkat baris.
Dan bagaimana jika integritas referensial memiliki kaskade saat dihapus? Selain mode S, ada niat untuk memperbarui baris di tabel anak, seperti mode Baris X (RX). Di sinilah share rowexclusive (SRX) terjadi:S+RX=SRX.
Jadi, varian yang paling mungkin adalah Sesi #72 dan Sesi #24 menghapus beberapa baris di EMPLOYEE tabel pada saat yang sama, dan ada on delete cascade batasan untuk EMPSAL_EMP_ID sehubungan dengan tidak adanya indeks pada EMPLOYEE_SALARY tabel di mana EMPSAL_EMP_ID kolom dicantumkan terlebih dahulu.
