Database Recovery

1
Database Recovery
The main reference of this presentation is the
textbook and PPT from Elmasri Navathe,
Fundamental of Database Systems, 4th edition,
2004, Chapter 19
2
Outline

• Konsep Recovery
• Teknik-Teknik Recovery

3
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!

4
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

5
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 ?

T1 T2 T3 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)
6

• One execution of T1, T2 and T3 as recorded in the
  log.
• A B C D
• 30 15 40 20

start_transaction, T3 read_item, T3,
C write_item, T3, B, 15, 12 12 start_transa
ction,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.
7
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

8
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

9
Teknik-Teknik Recovery

• Deferred Update
• Immediate Update
• Shadow Paging
• Physical Recovery
• Multidatabase recovery

10
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

11
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

12
Deferred Update in a single-user system
(a) T1 T2 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.
13
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

14
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.
15
Deferred Update with concurrent users
(a) T1 T2 T3 T4 read_item (A) read_item (B)
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)
(b) start_transaction, T1 write_item, T1, D,
20 commit, T1 checkpoint start_transacti
on, T4 write_item, T4, B, 15 write_item,
T4, A, 20 commit, T4 start_transaction
T2 write_item, T2, B, 12 start_transacti
on, 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.
16
/- 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

17
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

18
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

19
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.

20
/- RIU pd multi user

• Keuntungan
• Tidak membatasi concurency
• Kerugian
• Ada REDO UNDO
• Ada cascading rollback

21
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

22
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

23
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
24
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.
25
/- 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

26
Recovery dari Backup Physic

• Bila terjadi disk crash
• Basis data dan log di backup pada tape secara
  periodok
• Memakai mirror disk (untuk log file)

27
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 -gt koordinator
• Local recovery maneger
• Protokol yang digunakan disebut TWO PHASE COMMIT
  PROTOCOL

28
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

29
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

30
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