Tingkat isolasi transaksi di SQL Server dan hubungannya dengan pembacaan kotor, pembacaan yang tidak dapat diulang, pembacaan hantu, dll. (argumen kode dan urutan waktu)
Memahami masalah yang mungkin timbul dalam kasus akses bersamaan ke database, kita dapat terus memahami konsep tingkat isolasi database, dalam istilah awam: bagaimana Anda ingin mengisolasi transaksi bersamaan, dan sejauh mana? Misalnya, jika pembacaan kotor dapat ditoleransi, atau jika Anda tidak ingin transaksi bersamaan memiliki pembacaan kotor, maka ini dapat diatur ke tingkat isolasi untuk membuat isolasi antara transaksi bersamaan longgar atau parah.
Semakin tinggi tingkat isolasi, semakin kecil kemungkinan membaca data kotor atau data yang tidak lengkap, tetapi semakin parah penurunan kinerja dalam sistem konkurensi tinggi. Semakin rendah tingkat isolasi, semakin besar peningkatan kinerja dalam sistem bersamaan, tetapi data itu sendiri mungkin tidak lengkap.
Di SQL Server 2012, Anda dapat mengatur tingkat isolasi transaksi (dari rendah ke tinggi) menggunakan sintaks ini:
TETAPKAN TINGKAT ISOLASI TRANSAKSI { BACA TIDAK BERKOMITMEN | BACA BERKOMITMEN | BACAAN YANG DAPAT DIULANG | CUPLIKAN | DAPAT DISERIALKAN } [ ; ] Pertama, buat skrip pengujian baru, buat database, dan sisipkan data pengujian, sebagai berikut:
Membuat jendela baru A, buka transaksi, lakukan operasi pembaruan, dan tunggu 10 detik sebelum melakukan komitmen, kodenya adalah sebagai berikut:
Membuat jendela baru B, atur transaksi READ UNCOMMITTED (uncommit read, level terendah, masalah mudahnya adalah dirty reading, karena dapat membaca data yang dimodifikasi oleh transaksi lain tetapi tidak dilakukan.) Ini melakukan hal yang sama seperti pengaturan (NOLOCK) pada tabel objek pernyataan SELECT dalam transaksi. Kueri data, kodenya adalah sebagai berikut:
Membuat jendela baru C, langsung kueri data, sebagai berikut:
Pada gilirannya,Jalankan jendela A, B, dan C, dan temukan bahwa saat memperbarui data, jendela B dapat segera mengembalikan data (Ada kemungkinan pembacaannya adalah data kotor), Jendela C perlu menunggu jendela A selesai dieksekusiakan mengembalikan data, seperti yang ditunjukkan pada gambar di bawah ini:
(Jendela B)
(Jendela C)
(Akhir)
|