# Database Recovery Department of Computers Science Faculity Mathematics and Natural Science University of Pakuan Bogor 2011.

## Presentasi berjudul: "Database Recovery Department of Computers Science Faculity Mathematics and Natural Science University of Pakuan Bogor 2011."— Transcript presentasi:

Database Recovery Department of Computers Science Faculity Mathematics and Natural Science University of Pakuan Bogor 2011

Slide 5-2 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Outline Konsep Recovery Teknik-Teknik Recovery

Slide 5-3 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Konsep Recovery Bila terjadi kegagalan pada transaksi basis data, maka basis data dikembalikan ke status lampau terdekat sebelum terjadi kegagalan Untuk melakukan ini perlu disimpan informasi tentang perubahan terhadap data selama pelaksanaan transaksi di luar basis data itu sendiri. PERLU LOG!

Slide 5-4 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Rollback Mengembalikan harga suatu data item yang telah diubah oleh operasi- operasi dari transaksi ke harga sebelumnya. Informasi pada log digunakan untuk mendapatkan harga lama dari data yang harus di rollback

Slide 5-5 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Cascading Rollback Bila transaksi T3 di rollback, maka transaksi T2 yang membaca nilai dari data item B yang ditulis oleh T3 juga harus di rollback Contoh  T1T2T3 read_item (A) read_item (B) read_item (C) read_item (D) write_item (B) write_item (B) write_item (D) read_item (D) read_item (A) write_item (A)write_item (A)

Slide 5-6 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 One execution of T1, T2 and T3 as recorded in the log. AB C D 3015 40 20 [start_transaction, T3] [read_item, T3, C] *[write_item, T3, B, 15, 12]12 [start_transaction,T2] [read_item, T2, B] **[write_item, T2, B, 12, 18]18 [start_transaction,T1] [read_item, T1, A] [read_item, T1, D] [write_item, T1, D, 20, 25] 25 [read_item, T2, D] **[write_item, T2, D, 25, 26] 26 [read_item, T3, A] ---- system crash ---- * T3 is rolled back because it did not reach its commit point. ** T2 is rolled back because it reads the value of item B written by T3.

Slide 5-7 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Catatan Hanya operasi write_item yang perlu diundo Operasi read_item dicatat di log untuk menentukan apakah ada cascading rollback Bila suatu transaksi hanya boleh membaca data yang ditulis oleh transaksi yang telah mencapai titik commit, maka cascading rollback tidak akan terjadi

Slide 5-8 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Catatan Jika tidak pernah ada cascading rollback, maka jumlah informasi yang harus ditulis pada file log juga akan berkurang. Informasi yang perlu ditulis antara lain: [start_transaction, T] [write_item, T, B, 20, 50] [commit, T]

Slide 5-9 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Teknik-Teknik Recovery Deferred Update Immediate Update Shadow Paging Physical Recovery Multidatabase recovery

Slide 5-10 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Deferred Update • Menunda update yang sesungguhnya ke basis data sampai transaksi menyelesaikan eksekusinya dengan sukses dan mencapai titik commit. • Selama eksekusi masih berlangsung update hanya dicatat pada system log dan transaction workspace. • Setelah transaksi commit dan log sudah dituliskan ke disk, maka update dituliskan ke basis data

Slide 5-11 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 RDU untuk single user Mulai dari entry terakhir pada log, baca mundur sampai ke awal dari log Buat list dari transaksi yang sudah commit dan yang belum commit Lakukan operasi REDO dari semua operasi write_item dari transaksi yg sudah commit, dengan urutan seperti tertulis pada log Abaikan semua operasi dari transaksi yang belum commit  implicit rollback Transaksi yg belum commit akan diresubmit kembali ke sistem

Slide 5-12 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Deferred Update in a single- user system (a) T1T2 read_item (A)read_item (B) read_item (D)write_item (B) write_item (D)read_item (D) write_item (A) (b) [start_transaction, T1] [write_item, T1, D, 20] [commit T1] [start_transaction, T1] [write_item, T2, B, 10] [write_item, T2, D, 25]  system crash The [write_item, …] operations of T1 are redone. T2 log entries are ignored by the recovery manager.

Slide 5-13 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 RDU untuk Multiuser Sama seperti single user, hanya harus menggunakan two-phase locking protocol, dan untuk mencegah deadlock semua lock harus didapatkan sebelum transaksi dimulai, dan baru dilepas setelah transaksi mencapai titik commit. Ditambahkan juga checkpoint

Slide 5-14 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Deferred Update with concurrent users This environment requires some concurrency control mechanism to guarantee isolation property of transactions. In a system recovery transactions which were recorded in the log after the last checkpoint were redone. The recovery manager may scan some of the transactions recorded before the checkpoint to get the AFIMs. Recovery in a concurrent users environment.

Slide 5-15 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Deferred Update with concurrent users (b)[start_transaction, T1] [write_item, T1, D, 20] [commit, T1] [checkpoint] [start_transaction, T4] [write_item, T4, B, 15] [write_item, T4, A, 20] [commit, T4] [start_transaction T2] [write_item, T2, B, 12] [start_transaction, T3] [write_item, T3, A, 30] [write_item, T2, D, 25]  system crash T2 and T3 are ignored because they did not reach their commit points. T4 is redone because its commit point is after the last checkpoint. (a) T1T2T3T4 read_item (A)read_item (B) read_item (D)write_item (B) write_item (A)write_item (B) write_item (D)read_item (D) read_item (C)read_item (A) write_item (D) write_item (C)write_item (A)

Slide 5-16 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 +/- RDU pd multiuser Keuntungan Transaksi tidak perlu di rollback Tidak ada cascading rollback Kekurangan Bila tanpa checkpoint, proses REDO bisa panjang Dengan two-phase locking dan mendapatkan semua lock sebelum mulai transaksi akan membatasi concurrency

Slide 5-17 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Recovery berdasarkan Immediate Update (RIU) Update dilakukan langsung pada basis data tanpa menunggu transaksi mencapai titik commit Operasi tetap harus dituliskan ke log (pada disk) sebelum update dilakukan pada basis data  Write-Ahead Logging protocol

Slide 5-18 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 RIU untuk single user Buat list semua transaksi yang sudah commit dan list transaksi yang belum commit UNDO semua operasi write_item dari transaksi yang belum commit REDO semua operasi write_item dari transaksi yang sudah commit sesuai dengan urutan yang tertulis pada log Dapat ditambahkan checkpoint

Slide 5-19 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 RIU untuk multiuser Buat list dari transaksi yg sudah commit dan belum commit setelah checkpoint terakhir ditulis Buat list transaksi yg sudah commit yang membaca data item dari transaksi yang belum commit untuk cascading rollback UNDO semua transaksi yg belum commit dan transaksi yang harus di-rollback REDO semua operasi write_item yang berasal dari transaksi yang sudah commit.

Slide 5-20 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 +/- RIU pd multi user Keuntungan Tidak membatasi concurency Kerugian Ada REDO & UNDO Ada cascading rollback

Slide 5-21 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Recovery dengan Shadow Paging Basis data terdiri dari sejumlah fixed-size disk Buat page table di memory dengan jumlah entry yang sama dengan jumlah disk page Shadow page table adalah copy dari current page table yang disimpan di disk Selama transaksi berlangsung current page table diupdate, sedangkan shadow page table tidak dimodifikasi

Slide 5-22 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Recovery dengan Shadow Paging Bila operasi write_item dilaksanakan, maka copy dari basis data yang akan dimodifikasi dbuat Current page table dimodifikasi utnuk menunjuk pada disk page yang baru, sedangkan shadow page lama tetap menunjuk pada disk blok yang lama Bila proses commit sukses, maka shadow page table akan dihapus Bila proses commit gagal, maka status basis data sebelum transaksi bisa diperoleh dari shadow page table

Slide 5-23 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Shadow Paging The AFIM does not overwrite its BFIM but recorded at another place on the disk. Thus, at any time a data item has AFIM and BFIM (Shadow copy of the data item) at two different places on the disk. X and Y: Shadow copies of data items X` and Y`: Current copies of data items

Slide 5-24 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Shadow Paging To manage access of data items by concurrent transactions two directories (current and shadow) are used. The directory arrangement is illustrated below. Here a page is a data item.

Slide 5-25 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 +/- Shadow paging Keuntungan Proses UNDO sangat sederhana Tidak perlu REDO Bisa memakai log, checkpoint Kerugian Update pada basis data akan mengubah lokasi database page pada disk, hingga sukar untuk mengatur agar beberapa page selalu berdekatan Bila page table besar, maka overhead untuk membuat shadow page table juga besar

Slide 5-26 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Recovery dari Backup Physic Bila terjadi disk crash Basis data dan log di backup pada tape secara periodok Memakai mirror disk (untuk log file)

Slide 5-27 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Recovery pada multidatabase system Transaksi multidatabse adalah transaksi yang mengakses data item pada lebih dari satu basis data, dan masing-masing basis data mungkin diimplementasikan pada DBMS yang berbeda Perlu dua recovery manager: Global recovery manager -> koordinator Local recovery maneger Protokol yang digunakan disebut TWO PHASE COMMIT PROTOCOL

Slide 5-28 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Recovery in multidatabase system To maintain the atomicity of a multidatabase transaction is necessary to have a two-level recovery mechanism: Global recovery mechanism (coordinator)  usually follow two- phased commit protocol (2CP) Local recovery manager

Slide 5-29 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Two-Phased Commit Protocol Phase 1: Semua basis data yang terlibat pada suatu transaksi memberi signal pada koordinator bahwa bagian transaksi multidatabase pada basis data ybs. sudah selesai. Koordinator memberi message “prepare to commit” pada semua basis data yang terlibat Masing-masing basis data yang menerima message akan memaksa menuliskan semua log ke disk dan mengirim signal “OK” atau “NOT OK” ke koordinator. Bila tidak ada signal dianggap “NOT OK”

Slide 5-30 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by ILKOM UNPAK, 2009 Two-Phased Commit Protocol Phase 2: Jika semua basis data yang terlibat mengirim signal “OK”, maka koordinator akan mengirim signal “COMMIT”, karena semua efek lokal telah disimpan pada log masing-masing, maka perubahan ke basis data dapat dibuat permanen Jika salah satu basis data mengirim message “NOT OK” maka koordinator akan mengirim message untuk merollback efek lokal transaksi pada semua basis data yang terlibat

Presentasi serupa