Lewati ke isi
ORACLEDECK

Topik 10

Pemrosesan Konkuren dan Kendali

Keterserialan, protokol locking dua fase, timestamp ordering, dan kendali konkurensi terdistribusi.

Kemampuan akhir yang diharapkan. Memahami pemrosesan konkuren dan implementasinya dalam pengendalian proses pada basis data terdistribusi.

Masalah yang harus dicegah

MasalahContoh jadwalAkibat
Lost updater1[x] r2[x] w1[x] w2[x]Pembaruan T1 tertimpa T2 dan hilang tanpa jejak
Dirty readw1[x] r2[x] a1T2 membaca nilai yang kemudian dibatalkan
Unrepeatable readr1[x] w2[x] c2 r1[x]T1 membaca nilai berbeda untuk item yang sama
Phantomσ1[p] i2[p] σ1[p]Baris baru muncul di antara dua pembacaan dengan predikat sama

Keterserialan konflik

Sebuah jadwal disebut conflict-serializable bila graf presedensinya asiklik. Sisi Ti → Tj dibuat bila operasi Ti mendahului operasi Tj yang berkonflik — yaitu pada item data yang sama, dari transaksi berbeda, dan minimal salah satunya operasi tulis.

Lab Konkurensi membangun graf presedensi dari jadwal yang Anda ketik, mencari siklusnya, dan bila asiklik menunjukkan urutan serial yang setara.

Two-Phase Locking

Harga 2PL adalah deadlock. Peningkatan kunci S ke X saat transaksi lain juga memegang S menghasilkan deadlock peningkatan yang paling sering terjadi di praktik.

VarianAturanMenjamin
2PL dasarSetelah melepas satu kunci, transaksi tidak boleh meminta kunci baruSerializable, tetapi cascading abort masih mungkin
2PL ketat (strict)Semua kunci tulis dipegang sampai commit/abortSerializable + cascadeless
2PL tegas (rigorous)Semua kunci, baca maupun tulis, dipegang sampai commit/abortSerializable + strict; urutan commit = urutan serial

Timestamp Ordering

Setiap transaksi diberi cap waktu saat mulai. Operasi yang melanggar urutan cap waktu ditolak dan transaksinya di-rollback — tidak ada penantian, sehingga tidak ada deadlock.

OperasiSyaratBila dilanggar
read(x) oleh TTS(T) ≥ WTS(x)Rollback T — hendak membaca nilai yang sudah ditimpa transaksi lebih muda
write(x) oleh TTS(T) ≥ RTS(x)Rollback T — nilainya sudah dibaca transaksi lebih muda
write(x) oleh TTS(T) ≥ WTS(x)Abaikan tulisan (aturan tulis Thomas) — tulisan usang aman dibuang

Pada sistem terdistribusi, cap waktu harus unik lintas situs. Solusinya cap waktu majemuk <jam lokal, id situs>, sehingga dua situs tidak pernah menghasilkan cap waktu yang sama.

Replikasi memperumit konkurensi

Jika salinan data yang direplikasi diperbarui, perubahan itu harus segera disebarkan ke semua salinan. Bila salah satu situs pemegang salinan tidak terjangkau, transaksi tertunda sampai situs itu pulih. Semakin banyak salinan, semakin besar kemungkinan transaksi konkuren gagal.

  • Sinkron (eager) — semua salinan diperbarui dalam satu transaksi. Konsisten, tetapi rapuh dan lambat.
  • Asinkron (lazy) — salinan diperbarui setelah transaksi asli commit. Cepat, tetapi ada jendela ketidakkonsistenan mulai dari beberapa detik sampai beberapa jam.

Coba di terminal

Kueri di bawah memperagakan konsep topik ini pada data sungguhan. Tekan ▶ Jalankan untuk membukanya di Terminal SQL, lalu ubah sesuka hati — sesi terminal adalah salinan pribadi di peramban Anda.

Pembaruan hilang dicegah oleh kendala

Dua pembaruan beruntun pada nilai yang sama: tanpa penguncian, yang pertama bisa hilang. Di sini CHECK juga mencegah nilai di luar 0–100. akademik galat disengaja: ORA-02290

UPDATE nilai SET nilai = nilai + 10 WHERE nim = '11010013' AND kode_kul = 'IT0401';
SELECT nilai FROM nilai WHERE nim = '11010013' AND kode_kul = 'IT0401';

Isolasi: perubahan belum COMMIT

Sesi ini melihat perubahannya sendiri; sesi lain baru melihatnya setelah COMMIT. rumahsakit

UPDATE pasien SET penyakit = 'Sembuh' WHERE id_pasien = 2;
SELECT penyakit FROM pasien WHERE id_pasien = 2;
\status
ROLLBACK;

Jalankan sendiri

Sumber: Modul 1 (RPS pekan 10); Modul 6 bagian Transparansi Konkurensi