Tingkat isolasi transaksi

2.1 Baca tanpa komitmen

"Tingkat isolasi transaksi" mengacu pada tingkat perlindungan yang diberikan oleh mekanisme internal DBMS (yaitu, tidak memerlukan pemrograman khusus) dari semua atau beberapa jenis inkonsistensi data di atas yang terjadi selama eksekusi paralel transaksi. Standar SQL-92 mendefinisikan skala empat tingkat isolasi:

• Baca tanpa komitmen
• Baca berkomitmen
• Bacaan berulang
• Serializable

Yang pertama adalah yang terlemah, yang terakhir adalah yang terkuat, yang berikutnya mencakup semua yang sebelumnya.

Tingkat isolasi terendah (pertama). Jika beberapa transaksi paralel mencoba untuk memodifikasi baris tabel yang sama, maka baris terakhir akan memiliki nilai yang ditentukan oleh seluruh rangkaian transaksi yang berhasil diselesaikan. Dalam hal ini, dimungkinkan untuk membaca tidak hanya data yang tidak konsisten secara logis, tetapi juga data yang perubahannya belum direkam.

Cara umum untuk mengimplementasikan tingkat isolasi ini adalah dengan mengunci data saat perintah perubahan dijalankan, yang memastikan bahwa perintah modifikasi pada baris yang sama dijalankan secara paralel benar-benar dijalankan secara berurutan dan tidak ada perubahan yang hilang. Transaksi hanya baca tidak pernah diblokir di bawah tingkat isolasi ini.

2.2 Baca berkomitmen

Sebagian besar DBMS industri, khususnya Microsoft SQL Server, PostgreSQL dan Oracle, menggunakan level ini secara default. Pada tingkat ini, perlindungan terhadap draf, pembacaan "kotor" disediakan, namun, selama pengoperasian satu transaksi, transaksi lain dapat diselesaikan dengan sukses dan perubahan yang dibuat olehnya diperbaiki. Akibatnya, transaksi pertama akan bekerja dengan kumpulan data yang berbeda.

Penerapan pembacaan lengkap dapat didasarkan pada salah satu dari dua pendekatan: pemblokiran atau pembuatan versi.

Memblokir data yang dapat dibaca dan berubah.

Ini terdiri dari fakta bahwa transaksi penulisan memblokir data yang dapat diubah untuk membaca transaksi yang beroperasi pada tingkat komitmen baca atau lebih tinggi hingga selesai, sehingga mencegah pembacaan "kotor", dan data yang dikunci oleh transaksi pembacaan dilepaskan segera setelah operasi selesai. SELECT(dengan demikian, situasi "pembacaan yang tidak dapat diulang" dapat terjadi pada tingkat isolasi tertentu).

Menyimpan beberapa versi baris yang berubah secara paralel.

Setiap kali baris diubah, DBMS membuat versi baru dari baris ini, yang dengannya transaksi yang mengubah data terus bekerja, sementara transaksi "pembacaan" lainnya mengembalikan versi terakhir yang dikomit. Keuntungan dari pendekatan ini adalah lebih cepat karena mencegah pemblokiran. Namun, ini membutuhkan, dibandingkan dengan yang pertama, konsumsi RAM yang jauh lebih besar, yang dihabiskan untuk menyimpan versi baris.

Selain itu, ketika beberapa transaksi mengubah data secara paralel, ini dapat menciptakan situasi di mana beberapa transaksi bersamaan membuat perubahan yang tidak konsisten pada data yang sama (karena tidak ada kunci, tidak ada yang dapat mencegah hal ini terjadi). Kemudian transaksi yang dilakukan pertama kali akan menyimpan perubahannya di database utama, dan transaksi paralel yang tersisa tidak mungkin dilakukan (karena ini akan menyebabkan hilangnya pembaruan transaksi pertama). Satu-satunya hal yang dapat dilakukan DBMS dalam situasi seperti itu adalah mengembalikan sisa transaksi dan mengeluarkan pesan kesalahan "Catatan telah diubah".

Metode implementasi spesifik dipilih oleh pengembang DBMS, dan dalam beberapa kasus dapat disesuaikan. Jadi, secara default, MS SQL menggunakan kunci, tetapi (dalam versi 2005 dan lebih tinggi) saat mengatur READ_COMMITTED_SNAPSHOTparameter database, beralih ke strategi pembuatan versi, Oracle awalnya bekerja hanya sesuai dengan skema versi. Di Informix, Anda dapat mencegah konflik antara transaksi baca dan tulis dengan menyetel opsi konfigurasi USELASTCOMMITTED(sejak versi 11.1) yang menyebabkan transaksi baca menerima data terakhir yang dikomit.

2.3 Pembacaan berulang

Tingkat di mana transaksi membaca "tidak melihat" berubah menjadi data yang telah dibaca sebelumnya. Pada saat yang sama, tidak ada transaksi lain yang dapat mengubah data yang dibaca oleh transaksi saat ini hingga selesai.

Kunci dalam mode bersama diterapkan ke semua data yang dibaca oleh instruksi apa pun dalam transaksi dan ditahan hingga transaksi selesai. Ini mencegah transaksi lain mengubah baris yang dibaca oleh transaksi yang tertunda. Namun, transaksi lain dapat menyisipkan baris baru yang cocok dengan kondisi pencarian instruksi yang terdapat dalam transaksi saat ini. Saat pernyataan dimulai ulang oleh transaksi saat ini, baris baru akan diambil, menghasilkan pembacaan hantu.

Mengingat bahwa kunci bersama disimpan hingga akhir transaksi, daripada dilepaskan pada akhir setiap pernyataan, tingkat konkurensi lebih rendah daripada tingkat isolasi READ COMMITTED. Oleh karena itu, umumnya tidak disarankan untuk menggunakan ini dan tingkat transaksi yang lebih tinggi jika tidak perlu.

2.4 Serialisasi

Tingkat isolasi tertinggi; transaksi benar-benar terisolasi satu sama lain, masing-masing dijalankan seolah-olah tidak ada transaksi paralel. Hanya pada level inilah transaksi bersamaan tidak tunduk pada efek "pembacaan hantu".

2.5 Dukungan untuk isolasi transaksi dalam DBMS nyata

DBMS transaksional tidak selalu mendukung keempat level, dan mungkin juga memperkenalkan level tambahan. Ada juga berbagai nuansa dalam memberikan insulasi.

Jadi, pada prinsipnya, Oracle tidak mendukung level nol, karena penerapan transaksinya mengecualikan "pembacaan kotor", dan secara formal tidak mengizinkan pengaturan level pembacaan Berulang, yaitu hanya mendukung ( secara default) Read committeddan Serializable. Pada saat yang sama, pada tingkat perintah individu, itu benar-benar menjamin keterulangan baca (jika perintah SELECTdalam transaksi pertama memilih satu set baris dari database, dan saat ini transaksi paralel kedua mengubah beberapa baris ini, maka kumpulan hasil yang diterima oleh transaksi pertama akan berisi baris yang tidak berubah, seolah-olah tidak ada transaksi kedua). Oracle juga mendukung apa yang disebut READ-ONLYtransaksi, yang sesuai dengan Serializable, tetapi tidak dapat mengubah datanya sendiri.

Dan Microsoft SQL Server mendukung keempat tingkat isolasi transaksi standar, dan sebagai tambahan, tingkat SNAPSHOT, di mana transaksi melihat status data yang dilakukan sebelum diluncurkan, serta perubahan yang dilakukan dengan sendirinya, yaitu, berperilaku seperti jika diterima saat startup, snapshot dari data DB dan bekerja dengannya. Perbedaan dari Serialized adalah tidak ada kunci yang digunakan, tetapi akibatnya, melakukan perubahan mungkin tidak dapat dilakukan jika transaksi bersamaan telah mengubah data yang sama sebelumnya; dalam hal ini, transaksi kedua, saat mencoba mengeksekusi, COMMITakan memunculkan pesan kesalahan dan dibatalkan.