Transaksi DBMS

Semua berang-berang! Kami secara aktif memperluas berbagai kursus kami, dan sekarang kami senang untuk memperkenalkan yang baru: "DBMS Relasional" . Kursus ini dibuat oleh salah satu guru terkemuka kursus Administrator Linux - Alexey Tsykunov . Kalau tidak, semuanya akan seperti biasa: utilitas dan pelajaran terbuka , di mana Alex akan berbagi hal-hal berbeda yang tidak termasuk dalam kursus itu sendiri.

Ayo pergi!

Suatu transaksi dapat didefinisikan sebagai serangkaian tugas, yang pemenuhannya merupakan prasyarat untuk penyelesaian transaksi yang benar. Satu tugas adalah blok minimum perubahan data yang tidak dapat dipisahkan.

Ini adalah contoh transaksi sederhana. Misalkan seorang karyawan bank mentransfer 500 rupee dari akun A ke akun B. Transaksi kecil dan sederhana ini melibatkan beberapa tugas tingkat rendah.

Akun A

Open_Account(A) Old_Balance = A.balance New_Balance = Old_Balance - 500 A.balance = New_Balance Close_Account(A) 

Akun B

 Open_Account(B) Old_Balance = B.balance New_Balance = Old_Balance + 500 B.balance = New_Balance Close_Account(B) 

Properti ACID

Transaksi dalam sistem basis data harus memelihara Atomicity, Consistency, Isolasi, dan Durability - singkatnya ACID - untuk memastikan akurasi, kelengkapan, dan integritas data:

• Atomicity - properti ini menunjukkan bahwa transaksi harus dianggap sebagai unit atom, yaitu, apakah semua operasinya dilakukan, atau tidak satu pun. Seharusnya tidak ada status dalam database di mana transaksi diselesaikan sebagian. Negara-negara harus diatur baik sebelum dimulainya transaksi atau setelah penyelesaian / interupsi / kegagalan transaksi.
• Konsistensi - Properti ini menunjukkan bahwa database harus tetap dalam keadaan konsisten setelah transaksi apa pun. Tidak ada transaksi yang berdampak negatif pada data dalam database. Jika database dalam keadaan konsisten sebelum transaksi selesai, maka itu harus di dalamnya setelah selesai.
• Isolasi - dalam sistem basis data, di mana beberapa transaksi dilakukan secara bersamaan dan paralel, properti isolasi menunjukkan bahwa setiap transaksi akan dilakukan dan dilaksanakan seolah-olah itu adalah satu-satunya transaksi dalam sistem. Tidak ada transaksi yang mempengaruhi keberadaan transaksi lainnya.
• Ketahanan - properti ini menunjukkan bahwa database harus cukup stabil untuk menyimpan semua pembaruan terbaru, bahkan jika sistem membuat kesalahan atau reboot. Jika transaksi mengarah ke pembaruan fragmen data dalam database, maka perubahan ini harus terus disimpan dalam database. Jika transaksi dilakukan, tetapi sistem macet sebelum menulis data ke disk, data harus segera diperbarui setelah sistem dimulai ulang.

Serialisasi

Ketika beberapa transaksi dilakukan oleh sistem operasi dalam lingkungan multi-program, ada kemungkinan bahwa instruksi dari satu transaksi akan dicampur dengan instruksi dari yang lain.

• Jadwal adalah eksekusi kronologis dari serangkaian transaksi. Suatu jadwal dapat memiliki banyak transaksi, yang masing-masing terdiri dari beberapa instruksi / tugas.
• Jadwal berurutan adalah jadwal di mana transaksi diatur sehingga masing-masing transaksi diselesaikan secara bergantian. Jadwal disebut berurutan hanya karena pola eksekusi yang konsisten.

Dalam lingkungan multi-transaksional, jadwal berurutan dianggap sebagai tolok ukur. Urutan pelaksanaan instruksi dalam suatu transaksi tidak dapat diubah, tetapi eksekusi instruksi dari dua transaksi mungkin acak. Eksekusi tidak berbahaya ketika dua transaksi saling independen dan bekerja pada segmen data yang berbeda; tetapi jika mereka menggunakan data yang sama, hasilnya mungkin berbeda, yang dapat menyebabkan database menjadi tidak konsisten.

Untuk mengatasi masalah ini, kami mengizinkan eksekusi paralel dari jadwal transaksi dalam hal transaksi bersambung atau memiliki hubungan ekivalensi.

Jadwal Setara

Jadwal Setara dapat dari jenis berikut:

Kesetaraan hasil

Jika dua jadwal setelah eksekusi menghasilkan hasil yang sama, mereka dianggap setara dalam hasil. Hasil mungkin sama untuk beberapa nilai dan mungkin berbeda untuk set nilai lainnya. Karena itu, kesetaraan seperti itu biasanya tidak dianggap signifikan.

Kesetaraan presentasi

Dua jadwal dianggap setara dalam presentasi jika transaksi di masing-masing jadwal melakukan tindakan serupa dengan cara yang sama.

Sebagai contoh:

• Jika T membaca data asli dalam S1, maka T juga membaca data asli dalam S2.
• Jika T membaca nilai yang ditulis oleh J dalam S1, maka T juga membaca nilai yang ditulis oleh J dalam S2.
• Jika T selesai menulis nilai ke S1, maka T juga selesai menulis nilai ke S2.

Kesetaraan konflik

Dua jadwal akan konflik jika mereka memiliki properti berikut:

• Mereka termasuk dalam transaksi yang berbeda.
• Mereka mengakses data yang sama.
• Setidaknya salah satunya adalah operasi "tulis".

Dua jadwal dengan beberapa transaksi dengan operasi yang bertentangan dianggap setara dengan konflik hanya jika:

• Kedua jadwal berisi rangkaian transaksi yang sama.
• Urutan pasangan operasi yang saling bertentangan didukung di kedua jadwal.

Catatan - Jadwal yang ekuivalen dalam presentasi dapat diubah serial dalam presentasi, dan jadwal yang setara dengan konflik bisa disesuaikan dengan konflik. Semua jadwal konflik-serializable presentasi-serializable.

Status Transaksi

Transaksi dalam basis data dapat dalam status berikut:

• Aktif (Aktif) - dalam kondisi ini, transaksi mulai dijalankan. Ini adalah kondisi awal dari setiap transaksi.
• Berkomitmen Sebagian - Ketika transaksi menyelesaikan operasi terakhirnya, itu dianggap dalam kondisi sebagian sempurna.
• Gagal - Transaksi dianggap gagal jika salah satu pemeriksaan yang dilakukan oleh sistem pemulihan basis data gagal. Transaksi semacam itu tidak dapat dilanjutkan.
• Dibatalkan - jika beberapa verifikasi gagal dan transaksi masuk ke keadaan gagal, manajer pemulihan akan memutar kembali semua operasi penulisan dalam database untuk mengembalikannya ke keadaan semula sebelum transaksi dimulai.
  Transaksi dalam kondisi ini dianggap terputus. Modul pemulihan basis data dapat memilih satu dari dua operasi setelah transaksi terputus:
  
  
  • Mulai ulang transaksi;
  • Batalkan transaksi.
• Sempurna - jika transaksi telah berhasil menyelesaikan semua operasi, itu dianggap sempurna. Semua efeknya direkam secara permanen dalam sistem database.

AKHIR

Seperti biasa, kami menunggu komentar, pertanyaan yang bisa ditanyakan di sini dan dalam pelajaran terbuka dengan Alexei .