Sistem Manajemen Basis Data

Dr. Lily Wulandari

PERTEMUAN 3

TEKNIK RECOVERY
PENDAHULUAN
DBMS adalah
 single-user jika paling banyak satu user yang
dapat menggunakan sistem satu saat, dan
 multiuser jika banyak user dapat
menggunakan sistem, dan kemudian
mengakses database – bersamaan.
TRANSAKSI
 Transaksi merupakan unit logika dari proses
database yang mencakup satu atau lebih
operasi pengaksesan database – meliputi
insert, delete, modifikasi atau operasi
retrieve.
 Operasi database ini dapat disisipkan dalam
suatu program aplikasi atau dapat langsung
dibuat interaktif dengan bahasa query level
tinggi misal SQL.
TRANSAKSI
 Satu cara untuk menspesifikasikan
batasan transaksi adalah dengan
membuat statemen begin transaction
dan end transaction dalam program
aplikasi;
TRANSAKSI
 Sebuah program aplikasi dapat berisi
lebih dari satu transaksi jika berisi
beberapa batasan transaksi.
 Jika operasi database dalam suatu
transaksi tidak meng-update database
tetapi hanya mengambil (retrieve) data,
transaksinya disebut dengan read-only
transaction.
STATUS TRANSAKSI &
OPERASI TAMBAHAN
Suatu transaksi adalah unit terkecil dari kerja
yang dapat diselesaikan atau tidak dapat
diselesaikan. Beberapa operasi dengan
diagram transisinya sbb :
 BEGIN_TRANSACTION : memulai transaksi
 READ or WRITE : operasi baca atau tulis dari
item database yang dieksekusi sebagai
bagian dari transaksi
 END_TRANSACTION : operasi transaksi
READ atau WRITE selesai dilakukan
STATUS TRANSAKSI &
OPERASI TAMBAHAN
 COMMIT_TRANSACTION : transaksi
berakhir sukses sehingga semua perubahan
(update) yang dilakukan melalui transaksi
dapat dimasukkan ke database dan akan
diselesaikan
 ROLLBACK (or ABORT) : transaksi berakhir
dengan tidak sukses sehingga semua
perubahan atau efek transaksi yang
diaplikasikan ke database tidak dapat
diselesaikan.
STATUS TRANSAKSI &
OPERASI TAMBAHAN
KONSEP RECOVERY
 Recovery basis data merupakan suatu
proses penyimpanan kembali basis data
pada keadaan yang benar sebelum terjadi
kegagalan(failure).
 Recovery dari suatu kegagalan transaksi
biasanya berarti database di-restore ke status
yang konsisten ke waktu sebelum terjadi
kegagalan.
KONSEP RECOVERY
 Untuk menangani kesalahan atau kegagalan
dari transaksi, sistem memelihara sebuah log
untuk menjaga jalannya semua operasi yang
mempengaruhi nilai dari item database.
Informasi ini akan dibutuhkan untuk
menangani adanya kegagalan.
 LOG disimpan di storage, dan secara berkala
diback-up ke storage lainnya untuk menjaga
dari kerusakan yang fatal.
PENYEBAB KEGAGALAN

 System crash (kerusakan sistem), akibat kesalahan

pada perangkat keras atau lunak, menyebabkan
kehilangan memori utama

 Media failure (kegagalan pada media), seperti

media tidak dapat dibaca, menyebabkan kehilangan
sebagian dari penyimpanan sekunder

 Application software error (kesalahan pada

perangkat lunak aplikasi), seperti kesalahan logika
mengakses basis data yang menyebabkan satu atau
lebih transaksi mengalami kegagalan
12
AKIBAT YG TIMBUL KRN KESALAHAN
(lanj.)

 Natural physical disasters (bencana fisik yg

natural), seperti kebakaran, air bah, gempa
 Carelessness (kekurangtelitian atau
kerusakan pada data atau fasilitas yang tidak
disengaja disebabkan oleh operator atau
pengguna)
 Sabotase, kerusakan pada data, fasilitas
perangkat lunak & keras yg disengaja
13
 FASILITAS RECOVERY PADA DBMS

 Mekanisme backup
melakukan backup secara periodik terhadap basis data yg ada
 Fasilitas Logging
Mencatat transaksi-transaksi dan perubahan-perubahan yang
terjadi terhadap basis data. DBMS memelihara file khusus
yang disebut Log (Journal) yang menyediakan informasi
mengenai seluruh perubahan yang terjadi pada basis data.
 Fasilitas Checkpoint
Mengizinkan update terhadap basis data yang akan
menjadi basis data yang permanen
 Manager recovery
Mengizinkan sistem untuk menyimpan kembali basis data
ke keadaan sebelum terjadi kegagalan
14
TEKNIK RECOVERY

 Prosedur recovery yang digunakan tergantung dari

kegagalan yang terjadi pada basis data. Terdapat 2
kasus kerusakkan :
1. Jika basis data rusak secara fisik seperti : disk head
crash dan menghancurkan basis data, maka yang
terpenting adalah melakukan penyimpanan kembali
backup basis data yang terakhir dan mengaplikasikan
kembali operasi-operasi update transaksi yang telah
commit dengan menggunakan log file. Dengan asumsi
bahwa log file-nya tidak rusak.

15
TEKNIK RECOVERY (lanj.)

2. Jika basis data tidak rusak secara fisik tetapi menjadi tidak
konsisten, sebagai contoh : sistem crash sementara transaksi
dieksekusi, maka yang perlu dilakukan adalah
membatalkan perubahan-perubahan yang menyebabkan
basis data tidak konsisten. Mengulang beberapa transaksi
sangat diperlukan juga untuk meyakinkan bahwa perubahan2
yang dilakukan telah disimpan di dalam secondary storage.

Di sini tidak perlu menggunakan salinan backup basis data,

tetapi dapat me-restore basis data ke dalam keadaan yang
konsisten dengan menggunakan before dan after-image yang
ditangani oleh log file.

16
KONSEP RECOVERY
Ada 2 teknik utama dalam melakukan recovery
kesalahan transaksi :
1. Deferred update
2. Immediate update
Deferred/Tunda 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
Deferred Update
 Ide dari protocol update yang tertunda :
1. Sebuah transaksi tidak dapat merubah
database pada disk hingga mencapai
checkpoint
2. Sebuah transaksi tidak dapat mencapai
checkpoint hingga semua operasi update
disimpan dalam log dan ditulis ke disk
Deferred Update
 Karena database tidak pernah ter-update
pada disk hingga transaksi mencapai commit,
operasi UNDO tidak diperlukan.
 Operasi ini dikenal dengan algoritma
recovery NO UNDO/ REDO.
 REDO dibutuhkan saat sistem gagal setelah
transaksi mencapai commit tetapi sebelum
perubahan disimpan pada database di disk.
Recovery Deferred Update 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 di-resubmit
kembali ke sistem
Recovery Deferred Update pada
Single-user
 Contoh
(a) operasi read dan write dari 2 buah transaksi

T1 T2
read_item(A) read_item(B)
read_item(D) write_item(B)
write_item(D) read_item(D)
write_item(D)
Recovery Deferred Update pada
Single-user
(b) log sistem saat terjadi crash
[start_transaction,T1]
[write_item,T1,D,20]
[commit,T1]
[start_transaction,T2]
[write_item,T2,B,10]
[write_item,T2,D,25] system crash
Recovery Deferred Update pada
Single-user
 Kegagalan pertama terjadi pada eksekusi
transaksi T2 (gambar b). Proses recovery akan
redo [write_item,T1,D,20] pada log dengan me-
reset nilai dari item D menjadi 20 (nilai barunya).
Entry [write_item,T2,…] pada log akan ditiadakan
oleh proses recovery karena T2 tidak commit.
 Jika kegagalan kedua terjadi selama recovery
dari kegagalan pertama, proses recovery yang
sama diulang dari awal hingga akhir dengan hasil
yang sama.
Recovery Deferred Update pada
Multi-user
 Kontrol konkurensi dan proses recovery
berhubungan. Secara umum, semakin
besar tingkat konkurensi dicapai,
semakin banyak waktu untuk recovery.
Recovery Deferred Update pada
Multi-user
 PROCEDURE RDU_M (WITH CHECKPOINT) :
gunakan 2 daftar transaksi yang dikelola oleh sistem;
transaksi T commit T sejak checkpoint terakhir
(daftar commit), dan transaksi aktif T‘ (daftar aktif).
Redo semua operasi WRITE dari transaksi yang
commit dari log, dalam urutan yang ditulis ke dalam
log. Transaksi yang aktif dan tidak commit secara
efektif dibatalkan dan harus di-submite kembali.
 Recovery menggunakan Deferred Update dalam
lingkungan multi-user = RDU_M
Recovery Deferred Update pada
Multi-user
Recovery Deferred Update pada
Multi-user
 Transaksi T1 mencapai commit saat t1,
dimana T3 dan T4 belum. Sebelum terjadi
sistem crash pada t2 , T3 dan T2 commit
tetapi tidak untuk T4 dan T5.
 Berdasarkan prosedur RDU_M, tidak
dibutuhkan operasi REDO write_item dari
transaksi T1 – atau transaksi commit lainnya
sebelum waktu checkpoint yang terakhir dari
t1.
Recovery Deferred Update pada
Multi-user
 Operasi write_item dari T2 dan T3 harus
diulang karena kedua transaksi mencapai titik
commit setelah checkpoint yang terakhir.
 Log bersifat force-written sebelum suatu
transaksi commit.
 Transaksi T4 dan T5 diabaikan, secara efektif
ditunda atau rolled back karena operasi
write_item disimpan dalam database karena
deferred update.
Recovery Deferred Update pada
Multi-user
 Keuntungan dari metode atau algoritma NO-
UNDO/REDO adalah operasi transaksi tidak pernah
dibutuhkan untuk tidak jadi dilaksanakan, karena :
1. Transaksi tidak mencatat setiap perubahan dalam
database pada disk sampai mencapai point commit,
yaitu sampai menyelesaikan eksekusi secara
lengkap. Sehingga transaksi tidak pernah dirolled
back karena kesalahan selama eksekusi transaksi.
2. Transaksi tidak akan pernah membaca nilai yang
ditulis oleh transaksi yang belum commit karena item
tetap terkunci sampai transaksi mencapai titik
commit.
Recovery Deferred Update pada
Multi-user
Contoh
(c) operasi read dan write dari 4 buah transaksi

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)
Recovery Deferred Update pada
Multi-user
(d) log sistem saat terjadi crash
[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
Recovery Deferred Update pada
Multi-user
 T2 dan T3 diabaikan karena mereka tidak
mencapai commit points mereka.
 T4 adalah redone karena commit point-nya
setelah system checkpoint terakhir.
+/- 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
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
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
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.
+/- RIU pd multi user
 Keuntungan
 Tidak membatasi concurency
 Kerugian
 Ada REDO & UNDO
 Ada cascading rollback
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
Recovery dengan Shadow Paging
 Bila operasi write_item dilaksanakan, maka copy
dari basis data yang akan dimodifikasi dibuat
 Current page table dimodifikasi untuk 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
Shadow Paging

Untuk mengatur akses item data dengan konkuren dua

direktori transaksi (current dan shadow) yang digunakan.
Susunan direktori digambarkan di bawah ini. Halaman
berikut merupakan item data.
Current Directory Shadow Directory
(after updating pages 2, 5) (not updated)
Page 5 (old)
1 Page 1 1
2 Page 4 2
3 Page 2 (old) 3
4 Page 3 4
5 Page 6 5
6 Page 2 (new) 6
Page 5 (new)
+/- 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
 Checkpoints
 Dalam hal kegagalan, manajer pemulihan
mensyaratkan bahwa seluruh log diperiksa
untuk memproses pemulihan → memakan
waktu.
Cara cepat untuk membatasi jumlah log untuk memindai pada proses recovery
dapat dicapai dengan menggunakan checkpoints.

 Sebuah catatan [checkpoint] ditulis ke log

secara berkala pada saat sistem menulis ke
database pada disk semua buffer DBMS yang
telah dimodifikasi.
Checkpoints
 Oleh karena itu, semua transaksi dengan
entry [commit, T] dalam log sebelum entry
[checkpoint] tidak perlu melakukan kembali
proses WRITE dalam kasus crash.
Karena semua pembaruan mereka telah tercatat dalam DB
pada disk selama proses checkpoint.
 Recovery Manager harus memutuskan pada
interval yang mana untuk mengambil sebuah
checkpoint .
Checkpoints
 Interval diukur dalam waktu, katakanlah
setiap m menit.
 Atau interval diukur dalam jumlah transaksi
yang dilakukan sejak checkpoint terakhir,
misalnya transaksi t.
- M & t adalah parameter sistem
Checkpoints
 Proses checkpoint adalah sebagai berikut
1. Suspend/menunda eksekusi transaksi
sementara.
2. Memaksa menulis semua buffer memori
utama yang telah dimodifikasi ke disk.
3. Menulis catatan [checkpoint] ke log, dan
memaksa-menulis log ke disk.
4. Lanjutkan mengeksekusi transaksi.
Checkpoints
 Waktu yang dibutuhkan untuk memaksa-menulis
semua buffer memori yang dimodifikasi dapat
menunda proses transaksi.
Karena langkah 1.
 Gunakan checkpointing fuzzy untuk mengurangi
keterlambatan ini.
- Sistem dapat melanjutkan proses transaksi setelah
catatan [checkpoint] tertulis ke log tanpa harus
menunggu langkah 2 sampai akhir.
–
Checkpoints
- Namun, sampai langkah 2 selesai,
catatan [chekpoint] sebelumnya harus
tetap berlaku.
Sistem ini menjaga pointer ke checkpoint yang valid yang
menunjuk ke [checkpoint] sebelumnya mencatat log

- Setelah dilakukan step 2, pointer diubah

untuk menunjuk ke checkpoint baru
dalam log.
Cascading Rollback
 Cascading rollback terjadi dalam sistem
database ketika transaksi (T1) menyebabkan
kegagalan dan rollback harus dilakukan.
Transaksi lain tergantung pada tindakan T1
juga harus di-rollback karena kegagalan T1,
sehingga menyebabkan efek cascading.
Artinya, kegagalan satu transaksi yang
menyebabkan banyak kegagalan lain.
Teknik pemulihan database yang praktis
menjamin cascadeless rollback, karena itu
rollback Cascading bukan hasil yang
diinginkan.
Shadow Paging
AFIM tidak menimpa BFIMnya tetapi disimpan pada tempat
lain di disk. Sehingga, setiap saat sebuah item data memiliki
AFIM dan BFIM (Shadow copy dari item data) pada dua
tempat yang berbeda di disk.

X Y
X' Y'

Database

X dan Y: Shadow copies dari item data

X` dan Y`: Current copies dari item data