2.1 Membaca tanpa komitmen
"Tahap pengasingan transaksi" merujuk kepada tahap perlindungan yang disediakan oleh mekanisme dalaman DBMS (iaitu, tidak memerlukan pengaturcaraan khas) daripada semua atau beberapa jenis ketidakkonsistenan data di atas yang berlaku semasa pelaksanaan transaksi selari. Standard SQL-92 mentakrifkan skala empat tahap pengasingan:
- Baca tanpa komitmen
- Baca komited
- Bacaan berulang
- Boleh disiri
Yang pertama adalah yang paling lemah, yang terakhir adalah yang paling kuat, setiap yang berikutnya termasuk semua yang sebelumnya.
Tahap pengasingan terendah (pertama). Jika beberapa urus niaga selari cuba mengubah suai baris jadual yang sama, maka baris terakhir akan mempunyai nilai yang ditentukan oleh keseluruhan set transaksi yang berjaya diselesaikan. Dalam kes ini, adalah mungkin untuk membaca bukan sahaja data yang tidak konsisten secara logik, tetapi juga data yang perubahannya belum direkodkan.
Cara biasa untuk melaksanakan tahap pengasingan ini adalah dengan mengunci data semasa arahan perubahan sedang dilaksanakan, yang memastikan arahan pengubahsuaian pada baris yang sama dijalankan secara selari sebenarnya dilaksanakan secara berurutan dan tiada perubahan yang hilang. Urus niaga baca sahaja tidak pernah disekat di bawah tahap pengasingan ini.
2.2 Baca komited
Kebanyakan DBMS industri, khususnya Microsoft SQL Server, PostgreSQL dan Oracle, menggunakan tahap ini secara lalai. Pada tahap ini, perlindungan terhadap draf, bacaan "kotor" disediakan, bagaimanapun, semasa operasi satu transaksi, satu lagi boleh berjaya diselesaikan dan perubahan yang dibuat olehnya ditetapkan. Akibatnya, transaksi pertama akan berfungsi dengan set data yang berbeza.
Pelaksanaan bacaan lengkap boleh berdasarkan salah satu daripada dua pendekatan: menyekat atau membuat versi.
Menyekat data yang boleh dibaca dan boleh diubah.
Ia terdiri daripada fakta bahawa transaksi menulis menyekat data boleh ubah untuk membaca transaksi yang beroperasi pada tahap komited baca atau lebih tinggi sehingga ia selesai, dengan itu menghalang bacaan "kotor", dan data yang dikunci oleh transaksi membaca dikeluarkan serta-merta selepas operasi selesai. SELECT( oleh itu, situasi "bacaan tidak boleh berulang" boleh berlaku pada tahap pengasingan tertentu).
Menyimpan berbilang versi baris yang berubah secara selari.
Setiap kali baris ditukar, DBMS mencipta versi baharu baris ini, yang dengannya transaksi yang menukar data terus berfungsi, manakala sebarang transaksi "membaca" lain mengembalikan versi komitmen terakhir. Kelebihan pendekatan ini ialah ia lebih pantas kerana ia menghalang penyekatan. Walau bagaimanapun, ia memerlukan, berbanding dengan yang pertama, penggunaan RAM yang jauh lebih besar, yang dibelanjakan untuk menyimpan versi baris.
Di samping itu, apabila berbilang transaksi menukar data secara selari, ia boleh mewujudkan situasi di mana beberapa transaksi serentak membuat perubahan yang tidak konsisten pada data yang sama (memandangkan tiada kunci, tiada apa yang akan menghalang perkara ini daripada berlaku). Kemudian urus niaga yang melakukan terlebih dahulu akan menyimpan perubahannya dalam pangkalan data utama, dan urus niaga selari yang selebihnya akan mustahil untuk dilakukan (kerana ini akan menyebabkan kehilangan kemas kini transaksi pertama). Satu-satunya perkara yang boleh dilakukan oleh DBMS dalam keadaan sedemikian adalah untuk melancarkan urus niaga yang lain dan mengeluarkan mesej ralat "Rekod telah diubah".
Kaedah pelaksanaan khusus dipilih oleh pembangun DBMS, dan dalam beberapa kes ia boleh disesuaikan. Jadi, secara lalai, MS SQL menggunakan kunci, tetapi (dalam versi 2005 dan lebih tinggi) apabila menetapkan READ_COMMITTED_SNAPSHOTparameter pangkalan data, ia beralih kepada strategi versi, Oracle pada mulanya hanya berfungsi mengikut skema versi. Dalam Informix, anda boleh menghalang konflik antara transaksi baca dan tulis dengan menetapkan pilihan konfigurasi USELASTCOMMITTED(setakat versi 11.1) yang menyebabkan transaksi baca menerima data komited terkini.
2.3 Bacaan berulang
Tahap di mana transaksi membaca "tidak melihat" berubah kepada data yang telah dibacanya sebelum ini. Pada masa yang sama, tiada transaksi lain boleh menukar data yang dibaca oleh transaksi semasa sehingga ia tamat.
Kunci dalam mod kongsi digunakan pada semua data yang dibaca oleh mana-mana arahan dalam transaksi dan ditahan sehingga transaksi selesai. Ini menghalang transaksi lain daripada mengubah suai baris yang dibaca oleh transaksi yang belum selesai. Walau bagaimanapun, urus niaga lain boleh memasukkan baris baharu yang sepadan dengan syarat carian untuk arahan yang terkandung dalam urus niaga semasa. Apabila penyata dimulakan semula oleh transaksi semasa, baris baharu akan diambil, menghasilkan bacaan hantu.
Memandangkan kunci kongsi dipegang sehingga akhir urus niaga, dan bukannya dikeluarkan pada penghujung setiap penyata, tahap keselarasan adalah lebih rendah daripada tahap pengasingan READ COMMITTED. Oleh itu, secara amnya tidak disyorkan untuk menggunakan ini dan tahap transaksi yang lebih tinggi secara tidak perlu.
2.4 Boleh disiri
Tahap pengasingan tertinggi; urus niaga benar-benar terpencil antara satu sama lain, setiap satu dilaksanakan seolah-olah tiada urus niaga selari. Hanya pada tahap ini transaksi serentak tidak tertakluk kepada kesan "baca hantu".
2.5 Sokongan untuk pengasingan transaksi dalam DBMS sebenar
DBMS transaksi tidak selalu menyokong keempat-empat peringkat, dan mungkin juga memperkenalkan yang tambahan. Terdapat juga pelbagai nuansa dalam menyediakan penebat.
Jadi, pada dasarnya, Oracle tidak menyokong tahap sifar, kerana pelaksanaan urus niaganya tidak termasuk "bacaan kotor", dan secara rasmi tidak membenarkan menetapkan tahap Bacaan Boleh Diulang, iaitu, ia hanya menyokong ( secara lalai) Read committeddan Serializable. Pada masa yang sama, pada tahap perintah individu, ia sebenarnya menjamin kebolehulangan bacaan (jika perintah SELECTdalam transaksi pertama memilih satu set baris daripada pangkalan data, dan pada masa ini transaksi kedua selari mengubah beberapa baris ini, maka set hasil yang diterima oleh transaksi pertama akan mengandungi baris yang tidak berubah, seolah-olah tiada transaksi kedua). Oracle juga menyokong transaksi yang dipanggil READ-ONLY, yang sepadan dengan Serializable, tetapi tidak boleh mengubah data itu sendiri.
Dan Microsoft SQL Server menyokong keempat-empat tahap pengasingan transaksi standard, dan tambahan pula, tahap SNAPSHOT, di mana transaksi melihat keadaan data yang telah dilakukan sebelum ia dilancarkan, serta perubahan yang dibuat dengan sendirinya, iaitu, ia berkelakuan sebagai jika ia diterima pada permulaan, petikan data DB dan berfungsi dengannya. Perbezaan daripada Bersiri ialah tiada kunci digunakan, tetapi akibatnya, melakukan perubahan mungkin tidak dapat dilakukan jika transaksi serentak telah menukar data yang sama sebelum ini; dalam kes ini, transaksi kedua, apabila cuba untuk melaksanakan, COMMITakan menimbulkan mesej ralat dan dibatalkan.