Mengapa transaksi yang tidak terikat harus dibatalkan dalam urutan terbalik?

19

Saya memiliki log basis data tempat beberapa transaksi menang (dilakukan sebelum crash) dan beberapa kehilangan (belum dilakukan). Kami belajar di kelas bahwa tindakan yang kalah harus dibatalkan.

Apakah ada alasan untuk melakukan ini mundur? Adakah yang bisa memberikan contoh sederhana log di mana forward undo akan memberikan hasil yang salah?

concurrency databases

— prjctdth
sumber

Bukankah seharusnya pertanyaan ini diajukan di situs web lain yang lebih spesifik?

— nbro

35

Transaksi asli:

Sisipkan catatan . $r$
Memperbarui beberapa bidang dari . $f$ $r$

Teruskan dibatalkan:

Hapus catatan . $r$
Balikkan pembaruan ke - oh tunggu, tidak ada lagi! Ini menyebabkan kesalahan. $r$ $r$

— DylanSp
sumber

Apakah hal-hal yang perlu secara fisik dibatalkan secara individual dalam urutan terbalik jika sistem dapat mengetahui keadaan apa yang perlu digulirkan kembali dan dapat menerapkan semua perubahan yang diperlukan sebelum memproses hal lain?

— supercat

11

Membatalkan perubahan dalam urutan terbalik membuatnya mudah. Mengapa Anda berusaha mempersulit diri sendiri?

— gnasher729

1

Tidak, sistem tidak akan melakukan segalanya tetapi masih akan mencari tahu dalam urutan mundur.

— Evil

3

Dalam banyak sistem database dunia nyata melakukannya tidak dalam urutan terbalik bahkan tidak akan mungkin karena kendala utama pada tabel.

— SeanR

11

Untuk menambah jawaban DylanSp, mencoba memperbarui bidang dalam catatan yang tidak ada akan gagal, tetapi hasilnya akan tetap menjadi hasil yang diharapkan: catatan r tidak ada.

Namun, pertimbangkan situasi di mana penghapusan catatan sebenarnya akan gagal:

Masukkan Pesanan O.
Masukkan Orderline L.

Mari kita asumsikan, bukan secara tidak realistis, bahwa setiap OrderLine harus terkait dengan suatu Pesanan.

Sekarang memutar kembali transaksi yang dimulai dengan menghapus Order akan gagal karena itu akan melanggar aturan bisnis kami.

Jadi setelah

Hapus Pesanan O. (GAGAL)
Hapus Ordeline L. (SUKSES)

Kami mungkin berakhir dengan Pesanan yang ada (tanpa Batas Pesanan).

Tentu saja, dalam hal ini kita bisa menggunakan penghapusan cascading, tetapi itu berarti langkah 2 akan gagal (tanpa dampak). Lebih buruk lagi, mungkin perilaku yang tidak diinginkan untuk menerapkan penghapusan cascading pada pesanan.

— Oerkelens
sumber

Oke ini masuk akal. Terima kasih atas bantuan Anda

— prjctdth

Apakah pantas mengasumsikan bahwa kendala tidak dilanggar sebelum atau setelah transaksi dalam keadaan "normal"? Secara normal, maksud saya transaksi tidak akan gagal jika hanya satu orang yang menggunakan database. Jika ini benar, mengapa penting untuk tidak memperkenalkan pelanggaran kendala selama proses pembatalan? Tampaknya kendala dapat dimatikan pada awal pembatalan dan diaktifkan setelah operasi selesai.

— Noctis Skytower

2

@NoctisSkytower Mematikan kendala selama operasi I / O normal menjadikannya tidak berguna. Mereka ada karena suatu alasan. Contoh saya dengan jelas menggambarkan bagaimana kendala dapat dipenuhi dalam keadaan normal, namun dilanggar selama rollback. Mematikan kendala saat roll back adalah masalah yang tidak perlu, dan memperbaiki masalah yang salah. Masalahnya bukan kendala, masalahnya adalah pelanggaran dengan mencoba memutar kembali secara tidak benar.

— Oerkelens

Ya, itu masuk akal, tetapi mengapa memeriksa kendala saat rollback? Dengan asumsi rollback dirancang untuk dijamin selesai tanpa masalah, mengapa tidak perlu membuang waktu memeriksa kendala jika diketahui mereka tidak akan dilanggar pada saat rollback selesai? BTW, itu harus menjadi jaminan karena jika rollback gagal, DB tampaknya akan perlu roll-forward yang tidak bisa dilakukan.

— Noctis Skytower

1

@NoctisSkytower seharusnya tidak mungkin bagi DB untuk berada dalam keadaan di mana kendala dilanggar, bahkan jika itu adalah keadaan sementara. Jika seluruh rollback adalah atom, maka tidak masalah urutan apa yang terjadi karena tidak ada urutan, itu adalah instruksi tunggal yang "terjadi sekaligus". jika ada dua atau lebih transaksi yang digulirkan kembali secara terpisah dalam suatu urutan, maka adalah wajib bahwa urutannya sedemikian rupa sehingga setiap pengamat yang membaca data di tengah hanya dapat melihat situasi di mana semua kendala menahan.

— Peteris

6

Mari kita analogikan: katakanlah Anda pergi makan malam.

Kenakan kaus kaki.
Kenakan sepatu.
Berdiri.
Berjalan ke pintu.

Maka Anda mendapat panggilan telepon. Paket makan malam dibatalkan.

Lepaskan kaus kaki.
Lepaskan sepatu.
Duduk.
Berjalan menjauh dari pintu.

Ada yang salah di sana. Anda mungkin tersandung dan melukai diri sendiri. Atau lebih mungkin, Anda akan menyadari bahwa beberapa tindakan tidak dapat diurungkan hingga tindakan selanjutnya dibatalkan terlebih dahulu.

Membatalkan hal terakhir yang Anda lakukan akan mengembalikan Anda ke posisi semula ketika langkah berikutnya hingga langkah terakhir terjadi. Kemudian Anda membatalkan langkah itu dan ulangi, bergerak mundur sampai tidak ada yang tersisa. Di sisi lain membalikkan langkah pertama mungkin tidak dapat diberikan mengingat negara mengikuti langkah selanjutnya.

Secara matematis berbicara: tindakan mungkin tidak bolak-balik, jadi setiap kali itu penting langkah mana yang Anda lakukan pertama atau kedua, urutan di mana Anda membatalkan langkah akan penting.

— Joel
sumber

3

Ini benar karena transaksi dibangun di atas satu sama lain dan hasil transaksi sangat tergantung pada situasi sebelum dilakukan.

Mari kita lihat transaksi keuangan:

(pada awalnya, sebelum transaksi asaya berhutang 100 USD)

a berutang saya 100 USD (sekarang total utang 200)
amenerima diskon 10% dari jumlah utangnya. (sekarang total utang 180)

Katakanlah saya ingin membatalkan dua transaksi.

Jika kami membatalkan yang pertama, kami akan berakhir dengan:

utang lebih rendah 100 (sekarang punya utang 80)
membatalkan diskon 10% (sekarang punya hutang 80 / 0,9 = 88)

Ini salah, kita harus kembali ke utang 100. Itu benar jika kita membatalkan transaksi dalam urutan terbalik.

batalkan diskon - sekarang utangnya 200
lebih rendah utang 100 - sekarang utang adalah 100

— penghitung uang
sumber

2

Asumsikan ada tabel T dengan satu kolom saja.

Asumsikan bahwa "batalkan log" adalah file database yang berisi transaksi yang tidak dikomit, dan bahwa "redo log" adalah file database yang berisi transaksi yang tidak berkomitmen dan berkomitmen yang belum diterapkan ke file data.

At 8:00 A.M., Transaction 100 inserts rows with values 101, 102 and 103 into table T. At 8:10 A.M., Transaction 100 is committed and the commit for transaction 100 completes. At 8:15 A.M., Transaction 200 updates row 101 to 201, 102 to 202 and 103 to 203. At 8:20 A.M., Transaction 200 has not been committed and remains in the undo log of the database. At 8:25 A.M., Transaction 300 increments each row by 50, changing row 201 to 251, 202 to 252, and 203 to 253. At 8:30 A.M., Transaction 300 has not been committed and remains in the undo log of the database. At 8:35 A.M., The instance providing access to the database crashes.



At 8:40 A.M., The instance is restarted, and the database files are
              opened as the instance is started:

              The committed values in T are still 101, 102 and 103.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, if they are written into the "redo
              log" of the database, there is a need to "roll back"
              the transactions AFTER the "redo log" is applied.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, they are in the "undo log"
              of the database.

              The undo log of the database is used BOTH to (1) roll
              back a transaction that is deliberately rolled 
              back in the memory structure of the database instance, 
              and also (2) during the instance recovery at 8:40 A.M.


At 8:41 A.M., The redo log has been applied, and the T table
              contains values 251, 252 and 253 in the instance memory.

              The undo log has not yet been applied.

At 8:42 A.M., The undo log is applied in the reverse order: Uncommitted transaction 300 is undone, and Uncommitted transaction 200 is undone.

Mengapa KEDUA transaksi yang dilakukan dan tidak dikomit dituliskan ke file redo log? Alasan untuk ini adalah untuk menyediakan pemulihan point-in-time.

Ini berarti bahwa isi file "redo log" TIDAK konsisten dengan transaksi. Untuk alasan ini, setiap kali redo log digunakan untuk menerapkan transaksi yang dilakukan pada file data, "undo log" HARUS JUGA digunakan untuk memutar kembali transaksi yang tidak dikomit.

Mengapa transaksi dalam "batalkan log" dibatalkan dengan urutan terbalik? Transaksi 300 telah menambahkan 50 ke nilai yang ada dari setiap kolom dari setiap baris. Oleh karena itu, jika transaksi 200 dibatalkan pertama kali, nilainya akan berubah dari 251, 252 dan 253 ke 201, 202 dan 203. Jika transaksi 300 kemudian dibatalkan kembali, nilainya akan menjadi 151, 152 dan 153 - yang tidak cocok nilai-nilai komitmen asli.

REFERENSI:

https://asktom.oracle.com/pls/asktom/f?p=100:11*::::P11_QUESTION_ID:1670195800346464273

— AB
sumber

0

Itu tidak benar secara inheren. Rollback cukup menerapkan kembali blok yang di-cache dalam undo log sehingga kondisi akhir sama dengan keadaan awal. Karena log ditulis dalam urutan ke depan saya membuat rollback saya juga berlaku dalam urutan ke depan. Urutan apa pun karena rollback akan mencoba lagi sampai file log ditandai sebagai diselesaikan.

— Joshua
sumber