Transaksi dan Kawalan Keselarasan: DBMS

Transaksi dalam Sistem Pengurusan DB (DBMS)

Takrif:

transaksi dalam sistem pengurusan pangkalan data (DBMS) ialah urutan operasi yang dilakukan sebagai unit kerja logik tunggal. Transaksi boleh melibatkan membaca, memasukkan, mengemas kini atau memadam data dalam pangkalan data. Ciri utama urus niaga ialah ia bersifat atom, bermakna semua operasi dalam urus niaga berjaya diselesaikan atau tiada satu pun daripadanya digunakan pada pangkalan data sama sekali.

---

Sifat Utama Transaksi: Sifat ACID

Transaksi mesti mematuhi sifat ACID untuk memastikan ketekalan dan kebolehpercayaan pangkalan data. Ciri-ciri ini ialah:

1. Atomicity:

   • Atomicity memastikan bahawa transaksi dianggap sebagai satu unit kerja yang tidak boleh dibahagikan. Sama ada semua operasi dalam urus niaga dilaksanakan, atau tidak. Jika mana-mana bahagian urus niaga gagal, keseluruhan transaksi akan ditarik balik, memastikan pangkalan data kekal dalam keadaan konsisten.
   • Contoh: Jika transaksi melibatkan pemindahan wang dari Akaun A ke Akaun B, atomicity memastikan sama ada keseluruhan pemindahan selesai (wang ditolak daripada A dan ditambah kepada B) atau tiada apa yang dilakukan (tiada wang dipindahkan jika ada kegagalan).

2. Ketekalan:

   • Konsistensi memastikan transaksi memindahkan pangkalan data dari satu keadaan sah ke keadaan yang lain. Sebarang transaksi tidak boleh melanggar kekangan integriti pangkalan data (seperti kunci utama, kunci asing, dsb.). Selepas transaksi dilakukan, pangkalan data hendaklah sentiasa berada dalam keadaan yang konsisten.
   • Contoh: Selepas memindahkan wang antara dua akaun bank, jumlah baki dalam kedua-dua akaun hendaklah kekal malar. Jika peraturan ketekalan pangkalan data dilanggar, transaksi akan ditarik balik.

3. Pengasingan:

   • Pengasingan memastikan bahawa operasi transaksi disembunyikan daripada transaksi lain semasa ia dilaksanakan. Walaupun berbilang urus niaga berlaku serentak, setiap urus niaga seharusnya tidak mengetahui operasi yang lain. Ini menghalang bacaan kotor, bacaan tidak boleh diulang dan bacaan hantu.
   • Contoh: Jika dua pengguna memindahkan wang dari akaun bank yang sama secara serentak, pengasingan memastikan satu transaksi tidak mengganggu yang lain, menghalang ralat seperti pengeluaran berganda.

4. Ketahanan:

   • Ketahanan menjamin bahawa setelah transaksi dilakukan, perubahannya adalah kekal, walaupun dalam kes ranap sistem. Selepas komit berjaya, perubahan yang dibuat oleh transaksi disimpan ke pangkalan data dan ia tidak hilang.
   • Contoh: Jika pengguna telah berjaya membuat pesanan, perubahan dalam pangkalan data (seperti kemas kini stok dan penempatan pesanan) harus berterusan, walaupun terdapat kegagalan kuasa secara tiba-tiba sejurus selepas komit.

---

Jenis Transaksi

1. Transaksi Mudah:

   • Ini melibatkan satu operasi seperti membaca atau menulis data. Contohnya, pertanyaan baca mudah atau pertanyaan kemas kini boleh menjadi sebahagian daripada transaksi.

2. Transaksi Kompleks:

   • Ini melibatkan berbilang operasi, termasuk bacaan, kemas kini, sisipan dan pemadaman. Transaksi yang kompleks boleh menjadi urutan operasi yang direka bentuk untuk melengkapkan proses perniagaan, seperti memindahkan wang dari satu akaun ke akaun yang lain, yang melibatkan menyemak baki akaun, menolak daripada satu dan menambah kepada yang lain.

---

Kitaran Hayat Transaksi

Transaksi biasa mengikut langkah berikut:

1. Mulakan Transaksi:

   • Ini menandakan permulaan transaksi. Ini menunjukkan bahawa transaksi baharu akan dilakukan.

2. Lakukan Operasi:

   • Transaksi melakukan satu siri operasi pangkalan data, seperti memilih, memasukkan, mengemas kini atau memadam rekod. Operasi ini dilaksanakan secara berurutan sebagai sebahagian daripada transaksi.

3. Komit Transaksi:

   • Selepas semua operasi selesai, transaksi dilakukan. Ini bermakna semua perubahan yang dibuat oleh transaksi disimpan secara kekal ke pangkalan data. Setelah dilakukan, transaksi tidak boleh ditarik balik.

4. Urus niaga Balik:

   • Jika terdapat ralat atau kegagalan semasa pelaksanaan transaksi (seperti pelanggaran kekangan), urus niaga akan ditarik balik. Ini bermakna semua perubahan yang dibuat oleh transaksi dibuat asal dan pangkalan data kembali kepada keadaan asalnya.

5. Tamatkan Transaksi:

   • Selepas sama ada komit atau tarik balik, urus niaga tamat. Ini menandakan bahawa kitaran hayat transaksi telah selesai.

---

Negeri Transaksi

Sesuatu urus niaga mesti berada dalam salah satu daripada keadaan berikut semasa kitaran hayatnya:

1. Aktif:

   • Keadaan awal transaksi. Urus niaga kekal dalam keadaan ini semasa ia melaksanakan dan menjalankan operasi.

2. Sebahagiannya Komited:

   • Keadaan ini berlaku selepas penyata akhir transaksi telah dilaksanakan. Pada ketika ini, urus niaga telah menyelesaikan semua operasi tetapi belum lagi komited kepada pangkalan data.

3. Gagal:

   • Transaksi memasuki keadaan gagal apabila didapati bahawa pelaksanaan biasa tidak dapat diteruskan lagi, biasanya disebabkan masalah seperti pelanggaran kekangan atau kegagalan sistem.

4. Digugurkan:

   • Selepas urus niaga telah digulung semula dan pangkalan data telah dipulihkan kepada keadaannya sebelum permulaan urus niaga, ia memasuki keadaan dibatalkan.

5. Komited:

   • Transaksi memasuki keadaan komit selepas semua operasi berjaya diselesaikan dan perubahannya telah digunakan secara kekal pada pangkalan data.

6. Ditamatkan:

   • Sesuatu urus niaga dianggap ditamatkan jika ia telah dilakukan atau digugurkan. Apabila transaksi telah mencapai keadaan komited atau digugurkan, transaksi itu tidak boleh dimulakan semula.

---

Jadual dalam DBMS

jadual ialah jujukan operasi daripada berbilang transaksi yang dilaksanakan dalam susunan tertentu. Jadual menentukan susunan pelaksanaan operasi baca dan tulis untuk berbilang transaksi. Matlamat utama adalah untuk menentukan cara transaksi serentak berinteraksi dan memastikan pangkalan data kekal dalam keadaan yang konsisten.

Jadual boleh menjadi bersiri atau bukan bersiri.

---

Jenis Jadual

1. Jadual Siri:
   • Jadual bersiri ialah jadual di mana transaksi dilaksanakan satu demi satu tanpa sebarang jelingan. Ini bermakna bahawa operasi satu transaksi selesai sepenuhnya sebelum transaksi seterusnya bermula.
   • Dalam jadual bersiri, tiada konkurensi dan jadual itu bersamaan dengan melaksanakan urus niaga secara berurutan.

Contoh Jadual Bersiri:

• Transaksi 1: T1: Baca(A); Tulis(A); komited
• Transaksi 2: T2: Baca(B); Tulis(B); komited
• Urus niaga dilaksanakan satu demi satu, dan tiada pertindihan dalam operasi.

1. Jadual Bukan Bersiri:
   • Jadual bukan bersiri membenarkan operasi daripada berbilang urus niaga untuk bersambung. Dalam jenis jadual ini, urus niaga dilaksanakan secara serentak, bermakna operasi mereka bercampur bersama.
   • Jadual bukan bersiri boleh membawa kepada hasil yang berbeza bergantung pada susunan operasi dilaksanakan, dan ini memerlukan pengurusan yang teliti untuk mengekalkan sifat ACID.

Contoh Jadual Bukan Bersiri:

• T1: Baca(A); Tulis(A);
• T2: Baca(B); Tulis(B);
• T1: Komited;
• T2: Komited;
• Operasi urus niaga T1 dan T2 dijalin.

---

Kebolehbersirilan

Kebolehserian bersiri ialah konsep memastikan bahawa hasil daripada melaksanakan berbilang urus niaga secara serentak adalah sama seolah-olah urus niaga itu dilaksanakan secara bersiri (satu demi satu). Jadual dikatakan boleh bersiri jika ia bersamaan dengan jadual bersiri dari segi kesannya pada pangkalan data.

Kepentingan:

Matlamat kebolehbersirian adalah untuk memastikan transaksi serentak tidak menyebabkan konflik atau anomali (seperti bacaan kotor, kemas kini hilang, dll.) dan pangkalan data kekal dalam keadaan yang konsisten.

Terdapat dua jenis kebolehsirilan utama:

1. Kebolehsirilan Konflik:
   • Jadual boleh bersiri konflik jika ia boleh diubah menjadi jadual bersiri dengan menukar operasi tidak bercanggah. Dua operasi dianggap bercanggah jika ia daripada urus niaga yang berbeza, akses item data yang sama dan sekurang-kurangnya satu daripadanya ialah operasi tulis.
   • Operasi Konflik:
     • konflik baca-tulis berlaku apabila satu transaksi membaca item data yang ditulis oleh transaksi lain.
     • Percanggahan tulis-tulis berlaku apabila dua transaksi kedua-duanya menulis pada item data yang sama.

Contoh Kebolehsirilan Konflik:

• Jadual:
  • T1: Tulis(A);
  • T2: Tulis(B);
  • T1: Baca(B);
  • T2: Baca(A);
• Jadual ini boleh disusun semula kepada jadual bersiri dan boleh bersiri konflik.

1. Lihat kebolehsirilan:
   • Jadual boleh dilihat bersiri jika ia bersamaan dengan jadual bersiri dari segi hasil akhir, iaitu, bacaan dan tulis yang sama berlaku dan urus niaga disiri dengan betul. Walau bagaimanapun, dalam melihat kebolehsirilan, operasi tidak semestinya perlu ditukar seperti dalam kebolehsirilan konflik.

---

Setara Konflik, Boleh Bersiri Konflik

• Setara Konflik:

  • Dua jadual dikatakan setara konflik jika ia mengandungi operasi yang sama, operasi berada dalam susunan yang sama dan susunan operasi yang bercanggah dikekalkan. Ini bermakna persilangan transaksi dalam kedua-dua jadual menghasilkan hasil yang sama, memastikan ia adalah setara dengan konflik.

• Konflik Boleh Bersiri:

  • Jadual adalah konflik boleh bersiri jika urus niaganya boleh disusun semula untuk membentuk jadual bersiri, mengekalkan susunan konflik. Secara ringkas, jadual boleh bersiri konflik jika transaksi boleh disiri tanpa melanggar ketekalan data, iaitu, mengekalkan susunan operasi bercanggah.

---

Contoh Jadual Kebolehsirilan Konflik dan Setara Konflik

Mari kita pertimbangkan urus niaga berikut dan operasinya:

• Transaksi T1: Baca(A); Tulis(A); komited
• Transaksi T2: Baca(A); Tulis(A); komited

Jadual 1:

T1: Read(A);
T2: Read(A);
T1: Write(A);
T2: Write(A);
T1: Commit;
T2: Commit;

Jadual 2:

T2: Read(A);
T1: Read(A);
T2: Write(A);
T1: Write(A);
T1: Commit;
T2: Commit;

Semakan Kebolehsirilan Konflik:

• Jadual 1 dan Jadual 2 adalah setara konflik kerana susunan operasi bercanggah (Baca/Tulis pada A) dikekalkan. Kedua-dua jadual boleh diubah menjadi jadual bersiri:
  • T1: Baca(A); Tulis(A); Komitmen;
  • T2: Baca(A); Tulis(A); Komitmen;
• Oleh itu, kedua-dua jadual adalah konflik boleh bersiri.

---

Pengasingan Transaksi dan Atomiti

Selain sifat asas urus niaga, seperti sifat ACID, mengurus kegagalan urus niaga merupakan aspek penting dalam mengekalkan ketekalan dan kebolehpercayaan pangkalan data. Apabila urus niaga dilaksanakan serentak, pangkalan data mesti memastikan bahawa sebarang kegagalan semasa urus niaga tidak merosakkan keadaan pangkalan data, dan atomicity dan konsistensi pangkalan data dipelihara. Bahagian ini membincangkan cara pengendalian kegagalan memberi kesan kepada pengasingan transaksi dan atomicity dalam DBMS.

---

Atomiti dan Pengendalian Kegagalan

Atomicity ialah hak milik transaksi yang memastikan ia dianggap sebagai satu unit kerja yang tidak boleh dibahagikan. Ini bermakna urus niaga sama ada selesai sepenuhnya atau tidak dilaksanakan sama sekali. Jika mana-mana bahagian urus niaga gagal, keseluruhan transaksi mesti digulung semula untuk memastikan tiada perubahan separa digunakan pada pangkalan data.

Apabila transaksi gagal, sebarang kesan yang mungkin ada pada pangkalan data mesti dibuat asal, supaya pangkalan data boleh kembali kepada keadaannya sebelum transaksi dimulakan. Dalam sistem yang membenarkan pelaksanaan urus niaga serentak, jika transaksi T1 gagal, semua urus niaga yang bergantung pada T1 (iaitu, sebarang transaksi T2 yang telah membaca atau menulis data yang terjejas oleh T1) juga mesti digugurkan untuk mengekalkan atomisitas pangkalan data. Jika transaksi bergantung pada transaksi lain yang gagal, ia tidak seharusnya meninggalkan perubahan separa atau data tidak konsisten.

Untuk mengelakkan ketidakkonsistenan semasa pelaksanaan transaksi, adalah penting untuk mengurus jadual yang menentukan susunan operasi transaksi, terutamanya apabila transaksi gagal. Jenis jadual tertentu perlu dihadkan untuk memastikan kegagalan dapat diuruskan dengan betul.

---

Jadual Boleh Dipulihkan

Satu jadual boleh pulih ialah jadual di mana transaksi T2 hanya dilakukan selepas transaksi T1 yang bergantung padanya dilakukan. Dalam istilah yang lebih mudah, jika transaksi T2 membaca data yang ditulis oleh transaksi T1, T1 mesti melakukan sebelum T2 melakukannya. Ini memastikan bahawa T2 tidak melakukan perubahan berdasarkan urus niaga tanpa komitmen, menghalang senario di mana pengembalian T1 memerlukan pengembalian T2 juga.

Jadual yang melanggar peraturan ini dipanggil jadual tidak boleh pulih. Contohnya, jika T2 melakukan selepas membaca data yang ditulis oleh T1, tetapi T1 gagal dan digulung semula, pangkalan data tidak boleh dipulihkan kepada keadaan yang konsisten kerana komit T2 bergantung pada perubahan T1 yang tidak komited. Dalam keadaan ini, membuat asal T2 menjadi mustahil, membawa kepada ketidakkonsistenan data.

Contoh Jadual Tidak Boleh Dipulihkan:
Dalam jadual yang tidak boleh dipulihkan, katakan:

• Transaksi T6 menulis data ke item A.
• Transaksi T7 membaca nilai A yang ditulis oleh T6 dan melakukan serta-merta.

Jika T6 gagal sebelum ia melakukan, T7 bergantung pada perubahan tidak komited yang dibuat oleh T6. Memandangkan T7 telah pun komited, kami tidak boleh melancarkan T7, membawa kepada situasi di mana mustahil untuk pulih daripada kegagalan T6. Ini mengakibatkan jadual tidak boleh dipulihkan.

Untuk jadual boleh dipulihkan, T7 sepatutnya menangguhkan komitnya sehingga selepas T6 komit, memastikan T7 tidak bergantung pada data tidak komited daripada T6.

---

Jadual Tanpa Lata

Walaupun jadual boleh dipulihkan, ia masih boleh membawa kepada isu semasa pemulihan kegagalan transaksi, terutamanya apabila pemulangan bertingkat berlaku. Kembali bertingkat merujuk kepada situasi di mana kegagalan satu urus niaga membawa kepada tindak balas berantai penarikan balik untuk urus niaga bergantung yang lain. Keadaan ini berlaku apabila urus niaga membaca data yang ditulis oleh urus niaga lain yang tidak terikat.

Sebagai contoh, pertimbangkan senario di mana:

• Transaksi T8 menulis nilai pada item data A, yang dibaca oleh transaksi T9.
• Transaksi T9 menulis nilai kepada A, yang kemudiannya dibaca oleh transaksi T10.
• Jika T8 gagal, T9, yang bergantung pada T8, juga perlu digulung semula. T10, yang bergantung pada T9, juga mesti digulung semula. Ini menghasilkan kesan gulung balik bertingkat, membuat asal kerja berbilang transaksi tanpa perlu.

Pemulihan bertubi-tubi adalah tidak diingini kerana ia membawa kepada pembatalan sejumlah besar kerja, walaupun hanya satu transaksi yang gagal. Untuk mengelakkan penggulingan berlatarkan, kami boleh menggunakan jadual tanpa lata. Jadual tanpa lata ialah jadual di mana transaksi tidak membaca data yang ditulis oleh transaksi yang belum dilakukan.

Secara rasmi, jadual tanpa lata ialah satu di mana, untuk mana-mana dua transaksi T1 dan T2, jika T2 membaca item data yang ditulis oleh T1, maka T1 mesti telah melakukan sebelum T2 membaca item data. Ini memastikan bahawa tiada urus niaga boleh bergantung pada data yang tidak dikomitkan dan tiada pemulangan bertingkat.

Setiap jadual tanpa lata juga merupakan jadual boleh pulih. Ini bermakna jadual tanpa lata bukan sahaja menghalang rollback berlatarkan tetapi juga memastikan bahawa pangkalan data boleh pulih dengan betul sekiranya berlaku kegagalan transaksi.

Contoh Jadual Tanpa Lata:
Pertimbangkan perkara berikut:

• Transaksi T8 menulis A, dan T9 membaca A.
• Dalam jadual tanpa cascade, T9 hanya boleh membaca A selepas T8 telah melakukan.

Ini menjamin bahawa T9 tidak membaca data daripada T8 melainkan T8 telah berjaya diselesaikan, memastikan tiada pemulangan semula T9 diperlukan jika T8 gagal.

---

Tahap Pengasingan Transaksi

Transaksi pengasingan memastikan transaksi serentak tidak mengganggu antara satu sama lain dengan cara yang melanggar ketekalan pangkalan data. Tahap pengasingan urus niaga mentakrifkan tahap urus niaga itu diasingkan daripada urus niaga lain.

Terdapat tahap pengasingan yang berbeza, yang terdiri daripada pengasingan rendah hingga tinggi:

1. Baca Tanpa Komitmen:

   • Tahap pengasingan ini membolehkan transaksi membaca data yang ditulis oleh transaksi lain yang tidak terikat. Tahap ini boleh mengakibatkan isu seperti bacaan kotor, yang mana transaksi membaca data yang mungkin akan ditarik balik kemudian, yang membawa kepada hasil yang tidak konsisten.

2. Komited Baca:

   • Transaksi pada tahap ini hanya boleh membaca data yang telah dilakukan oleh transaksi lain. Walaupun ini menghalang bacaan kotor, ia masih boleh membawa kepada bacaan tidak boleh berulang, di mana transaksi membaca data yang sama dua kali dan mendapat hasil yang berbeza kerana transaksi lain telah mengubah suai data dalam masa yang sama.

3. Bacaan Boleh Diulang:

   • Tahap ini menghalang kedua-dua bacaan kotor dan bacaan tidak boleh berulang. Walau bagaimanapun, ia masih membenarkan bacaan hantu, di mana transaksi mungkin menghadapi set baris yang berbeza jika transaksi lain memasukkan atau memadam rekod.

4. Boleh bersiri:

   • Ini adalah tahap pengasingan tertinggi. Ia memastikan bahawa hasil urus niaga serentak adalah sama seperti urus niaga itu dilaksanakan secara bersiri, satu demi satu. Ini menghalang bacaan kotor, bacaan tidak boleh diulang dan bacaan hantu, tetapi boleh memberi kesan prestasi kerana sifatnya yang ketat.

Tahap pengasingan yang dipilih untuk pangkalan data atau urus niaga mempengaruhi keseimbangan antara ketekalan data dan prestasi, dengan tahap pengasingan yang lebih tinggi secara amnya membawa kepada prestasi yang lebih perlahan disebabkan oleh sekatan yang lebih besar pada konkurensi.

---

Kawalan Konkurensi dalam DBMS

Kawalan konkurensi ialah aspek kritikal sistem pengurusan pangkalan data (DBMS) yang memastikan pelaksanaan transaksi yang betul sambil membenarkan berbilang transaksi dilaksanakan secara serentak. Matlamat kawalan konkurensi adalah untuk mengekalkan ketekalan pangkalan data dan integriti dalam menghadapi senario interleaving dan kegagalan transaksi. Bahagian ini merangkumi Protokol Berasaskan Kunci, termasuk pelbagai mod kunci, mekanisme Protokol Penguncian Dua Fasa, Pengendalian Deadlock dan Protokol Berasaskan Cap Masa .

Protokol Berasaskan Kunci

Mengunci ialah mekanisme asas yang digunakan dalam DBMS untuk mengelakkan konflik antara melaksanakan transaksi serentak. Kunci digunakan pada item data untuk mengawal akses, memastikan berbilang transaksi tidak melanggar integriti pangkalan data. Dalam kawalan serentak berasaskan kunci, urus niaga memperoleh kunci pada item data sebelum melakukan operasi pada item data dan lepaskan kunci setelah operasi selesai.

Jenis Kunci

Terdapat pelbagai mod di mana item data mungkin dikunci. Dalam bahagian ini, kami mengehadkan perhatian kami kepada dua mod asas:

1. Kunci Dikongsi (S):
   • Transaksi memegang kunci kongsi pada item data apabila ia hanya perlu membaca item tersebut.
   • Berbilang transaksi boleh memegang kunci kongsi pada item data yang sama secara serentak. Ini membolehkan pembacaan serentak item data oleh transaksi yang berbeza.
   • Kunci kongsi tidak membenarkan transaksi mengubah suai item data.

Contoh:

• Transaksi T1 memegang kunci kongsi pada item A dan membaca A.
• Transaksi T2 memegang kunci kongsi pada item A dan membaca A.
• Kedua-duanya boleh membaca data tetapi tidak boleh menulis kepada A.

1. Kunci Eksklusif (X):
   • Transaksi memegang kunci eksklusif pada item data apabila ia perlu membaca dan menulis item tersebut.
   • Hanya satu transaksi boleh memegang kunci eksklusif pada item data tertentu pada bila-bila masa. Jika transaksi mempunyai kunci eksklusif, tiada transaksi lain boleh memperoleh kunci kongsi atau eksklusif pada item data yang sama.

Contoh:

• Transaksi T1 memegang kunci eksklusif pada item A dan menulis kepadanya.
• Semasa T1 memegang kunci eksklusif pada A, tiada transaksi lain boleh membaca atau menulis kepada A.

Pemberian Kunci

Kunci diberikan berdasarkan protokol yang dipatuhi oleh sistem dan protokol berasaskan kunci yang berbeza boleh mengawal cara kunci diminta dan diberikan semasa pelaksanaan transaksi. Protokol ini membantu mengelakkan konflik seperti kemas kini yang hilang, ketidakkonsistenan sementara dan data tidak terikat diakses oleh transaksi lain.

---

Protokol Mengunci Dua Fasa (2PL)

Protokol Mengunci Dua Fasa ialah protokol yang digunakan secara meluas untuk memastikan kebolehan bersiri — harta yang menjamin transaksi dilaksanakan dengan cara yang hasilnya sama dengan melaksanakannya satu demi satu. yang lain (secara bersiri). Penguncian Dua Fasa memastikan kebolehbersirilan dengan menguatkuasakan dua fasa semasa pelaksanaan transaksi:

1. Fasa Pertumbuhan:

   • Dalam fasa ini, transaksi boleh memperoleh kunci tetapi tidak boleh melepaskan sebarang kunci.
   • Urus niaga boleh meminta sebarang bilangan kunci, tetapi sebaik sahaja ia melepaskan kunci, ia tidak boleh memperoleh sebarang kunci baharu. Fasa ini tamat apabila operasi buka kunci pertama dilakukan.

2. Fasa Pengecutan:

   • Dalam fasa ini, transaksi boleh melepaskan kunci tetapi tidak boleh memperoleh sebarang kunci baharu.
   • Sebaik sahaja transaksi mula melepaskan kunci, ia tidak boleh mengunci sebarang item data tambahan. Fasa ini tamat apabila urus niaga sama ada melakukan atau membatalkan.

Protokol Penguncian Dua Fasa menjamin kebolehan bersiri kerana ia menghalang kitaran dalam graf penguncian, memastikan susunan pelaksanaan mengikut urutan ketat yang boleh disirikan.

Contoh:

• Transaksi T1 dan T2 perlu mengemas kini item data A dan B. Menggunakan 2PL, kedua-dua transaksi akan memperoleh kunci yang diperlukan dalam fasa pertumbuhan dan hanya melepaskannya selepas mereka menyelesaikan operasinya (dalam fasa mengecut).

---

Pengendalian kebuntuan

Kebuntuan berlaku apabila dua atau lebih transaksi sedang menunggu antara satu sama lain untuk melepaskan kunci, yang membawa kepada situasi di mana tiada satu pun daripada mereka boleh meneruskan. Ini mewujudkan kitaran urus niaga menunggu yang tidak boleh diselesaikan melainkan satu atau lebih transaksi ditarik balik.

Pencegahan kebuntuan

Teknik pencegahan kebuntuan direka untuk mengelakkan berlakunya kebuntuan dengan mengenakan sekatan ke atas tingkah laku transaksi. Satu strategi biasa untuk mengelakkan kebuntuan ialah penggunaan cap masa untuk mengutamakan transaksi.

Skim Pencegahan Kebuntuan Berasaskan Cap Masa

Terdapat dua skim pencegahan kebuntuan yang menonjol yang menggunakan cap masa:

1. Skim Tunggu-Mati:
   • Ini adalah bukan preemptive teknik pencegahan kebuntuan.
   • Jika transaksi Ti meminta item data yang dipegang oleh Tj, Ti dibenarkan menunggu hanya jika cap masanya lebih kecil daripada Tj (iaitu, Ti lebih tua daripada Tj).
   • Jika cap masa Ti lebih besar daripada cap masa Tj, Ti akan digulung semula (iaitu, Ti "mati").

Contoh:

• Jika transaksi T14, T15 dan T16 masing-masing mempunyai cap masa 5, 10 dan 15:
  • Jika T14 meminta item data yang dipegang oleh T15, T14 akan menunggu kerana T14 lebih lama.
  • Jika T16 meminta item data yang dipegang oleh T15, T16 akan ditarik balik kerana T16 lebih muda daripada T15.

1. Skim Luka-Tunggu:
   • Ini ialah teknik pencegahan kebuntuan preemptive.
   • Jika transaksi Ti meminta item data yang dipegang oleh Tj, Ti dibenarkan menunggu hanya jika cap masanya lebih besar daripada Tj (iaitu, Ti lebih muda daripada Tj).
   • Jika cap masa Ti lebih kecil daripada cap masa Tj, Ti mendahului Tj dan Tj digulung semula (iaitu, Tj "diluka" oleh Ti).

Contoh:

• Jika transaksi T14, T15 dan T16 masing-masing mempunyai cap masa 5, 10 dan 15:
  • Jika T14 meminta item data yang dipegang oleh T15, T14 akan mendahului T15, menyebabkan T15 ditarik balik.
  • Jika T16 meminta item data yang dipegang oleh T15, T16 akan menunggu kerana ia lebih muda daripada T15.

---

Protokol Berasaskan Cap Masa

Selain protokol berasaskan kunci, protokol berasaskan cap masa juga mengurus konkurensi dalam pangkalan data. Protokol ini menggunakan cap masa untuk memesan transaksi dan menyelesaikan konflik, memastikan sistem berkelakuan seolah-olah transaksi dilaksanakan secara bersiri.

Cap masa dan Peranannya

Cop masa ialah nilai berangka yang diberikan kepada urus niaga apabila ia dibuat. cap masa transaksi menentukan keutamaannya — nilai cap masa yang lebih rendah menunjukkan transaksi yang lebih lama dan nilai yang lebih tinggi menunjukkan transaksi yang lebih baharu.

1. W-cap (Q):

   • Ini menandakan cap masa terbesar bagi mana-mana transaksi yang telah berjaya melaksanakan operasi tulis pada item data Q.
   • Ia membantu mengenal pasti transaksi terakhir yang mengubah suai item data.

2. R-cap masa(Q):

   • Ini menandakan cap masa terbesar bagi mana-mana transaksi yang telah berjaya melaksanakan operasi baca pada item data Q.
   • Ia membantu mengenal pasti transaksi terakhir yang membaca item data.

Protokol Pesanan Cap Masa

Protokol Pesanan Cap Masa memastikan kebolehsirilan dengan menguatkuasakan jumlah pesanan pada urus niaga berdasarkan cap masa mereka. Protokol memerlukan bahawa:

• Jika transaksi Ti menulis item data Q, dan transaksi lain Tj membaca atau menulis Q, Ti mesti mempunyai cap masa yang lebih kecil daripada Tj.
• Begitu juga, jika Ti membaca item data Q, dan Tj menulis Q, Ti mesti mempunyai cap masa yang lebih kecil daripada Tj.

Protokol ini menyelesaikan konflik berdasarkan cap masa transaksi dan bukannya kunci.

Contoh:

• Transaksi T1 dengan cap masa 10 menulis item data A.
• Transaksi T2 dengan cap masa 12 membaca item data A.
• Protokol pesanan cap masa memastikan bahawa operasi tulis T1 berlaku sebelum operasi baca T2, mengekalkan susunan transaksi yang betul.

Atas ialah kandungan terperinci Transaksi dan Kawalan Keselarasan: DBMS. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!