The Database Environment

Recovery
Adapted from:
Connolly, Thomas., et.al., 2002. Database System.
Wokingham England: Addison-Wesley Publishing Company
1
MODEL TRANSAKSI
 Selama proses eksekusi transaksi, basis data secara temporer boleh
jadi dalam keadaan status tidak konsisten
 Database recover y: proses mengembalikan basis data ke status
benar bila terjadi kegagalan transaksi
 Merupakan layanan yang ada dalam DBMS
2
PENYEBAB KEGAGALAN
Penyebab kegagalan antara lain:
 System crash menyebabkan error pada hardware
atau software, isi memori utama menjadi hilang.
 Media failure, adanya crash pada head atau media
yg tak dapat dibaca  kehilangan data pada
memori sekunder.
 Application software error, seperti kesalahan logika
dalam program yg mengakses basisdata 
kegagalan transaksi.
 Bencana alam seperti kebakaran, banjir, gempa.
3
PENYEBAB KEGAGALAN
Penyebab kegagalan antara lain:
 Kecerobohan atau kerusakan data atau fasilitas
yang dilakukan operator atau pengguna secara
tidak sengaja.
 Sabotase: kerusakan data, fasilitas hardware atau
software yang dilakukan dengan sengaja.
Apapun penyebabnya, ada dua efek yg perlu
diperhatikan:
 hilangnya data dl memori utama termasuk buffer
basisdata.
 hilangnya data pada memori sekunder
4
FASILITAS RECOVERY
Sebuah DBMS harus mempunyai fasilitas recovery
berikut:
 Mekanisme backup, membuat salinan backup basis
data secara periodik.
 Fasilitas logging, merekam status transaksi dan
perubahan basis data dari waktu ke waktu.
 Fasilitas checkpoint, memberlakukan update basis
data yang menunjukkan kemajuan yang telah
dibuat secara permanen.
 Recovery manager, memungkinkan sistem
mengembalikan basis data ke status konsisten
sebelum terjadinya kegagalan.
5
MEKANISME BACKUP
 DBMS membuat salinan backup basis data dan log
file secara teratur pada interval waktu tertentu
tanpa harus menghentikan sistem.
 Salinan backup basis data dapat digunakan bila
basis data rusak atau hilang.
 Biasanya backup disimpan dalam offline-storage.
6
LOG FILE
 Untuk mengetahui track (jejak) transaksi basis
data, DBMS mengelola file khusus yang disebut log
atau journal
 Log atau journal berisi informasi tentang semua
update yang dilakukan terhadap basis data selama
proses transaksi berlangsung:
1. Record transaksi
2. Record checkpoint.
7
RECORD TRANSAKSI
Record transaksi terdiri atas:
 Identifier (pengenal) transaksi
 Jenis record log
(transaksi: start, insert, update, delete, abort, commit)
 Identifier item data yang berkaitan dengan aksi basis data
(operasi insert, delete, update)
 Before image item data, yaitu harga sebelum perubahan
dilakukan (oleh operasi update atau delete)
 After image item data, yaitu harga setelah perubahan
dilakukan (oleh update atau delete)
 Informasi pengelolaan log, seperti pointer ke record log
sebelum atau sesudah untuk suatu transaksi
8
CHECKPOINT
 Informasi dalam log file digunakan untuk
melakukan recovery basis data dari kegagalan.
 Namun dengan skema ini tidak dapat diketahui
kapan kegagalan muncul dan seberapa jauh
melangkah mundur dalam log untuk melacak di
mana transaksi harus diulang secara aman untuk
ditulis ke dalam basis data.
 Untuk membatasi jumlah pelacakan dan sekuen
proses yang dibutuhkan maka dilakukan teknik
dengan menggunakan checkpoint.
 Checkpoint adalah titik sinkronisasi antara basis
data dan file log transaksi. Semua buffer telah
ditulis ke memori sekunder.
9
CHECKPOINT
Checkpoint diperlukan untuk operasi berikut:
 Menulis semua record log dl memori utama ke
memori sekunder
 Menulis blok yg dimodifikasi dalam buffer bd ke
memori sekunder
 Menulis record checkpoint ke file log. Record ini
berisi identifier (pengenal) semua transaksi yang
aktiv pada checkpoint tersebut.
10
TEKNIK RECOVERY:
Basis data rusak parah
 Prosedur recovery yang digunakan bergantung pada
tingkat kerusakan basis data yang muncul.
 Ada dua kasus yang perlu dipertimbangkan yaitu:
1. Jika basis data telah rusak parah misalnya
karena disk head crash:
 lakukan restore salinan backup terakhir
 lakukan operasi update untuk transaksi yg
committed dengan menggunakan log file.
Tentu saja dengan asumsi bahwa log file
tidak rusak.
11
TEKNIK RECOVERY:
Basis data tidak konsisten
2. Jika basis data belum rusak secara fisik tetapi
menjadi tidak konsisten, misalnya karena sistem
crash selagi transaksi dieksekusi, maka:
 diperlukan undo (pembatalan) perubahan yang
menyebabkan basisdata tidak konsisten
 boleh jadi diperlukan redo beberapa transaksi
untuk menjamin update yang dilakukan telah
terekam pada memori sekunder.
12
TEKNIK RECOVERY:
Basis data tidak konsisten
 tidak diperlukan salinan backup basis data tetapi
me-restore basis data ke status konsisten dengan
menggunakan before- dan after-image yang
terekam dl log file.
 Untuk kasus (2) yaitu basis data tidak hilang tetapi
dalam status tidak konsisten, akan ditinjau teknik
recovery berikut:
• deferred update,
• immediate update, dan
• shadow paging.
13
TEKNIK RECOVERY:
DEFERRED UPDATE (1)
 Update tidak dilakukan sampai transaksi
mencapai titik commit
 Jika transaksi gagal sebelum mencapai titik
commit, basis data belum dimodifikasi dan karena
itu aksi undo tidak perlu dilakukan.
 Aksi redo mungkin diperlukan untuk meng-update
transaksi yg committed.
14
TEKNIK RECOVERY:
DEFERRED UPDATE (2)
Menggunakan log file untuk mencegah kegagalan sistem:
 Ketika transaksi dimulai, tulis record transaction start ke
dalam log.
 Ketika operasi penulisan dilakukan, tulis record log berisi
semua data sebelumnya. Jangan menulis ke buffer atau ke
dalam basis datanya.
 Ketika transaksi akan commit, tulis record transaction
commit ke dalam log, tulis semua record log transaksi ke
disk kemudian commit transaksi. Gunakan record log untuk
melaksanakan update aktual ke dalam basis data.
 Jika transaksi abort, abaikan record log transaksi & jangan
melakukan penulisan
15
TEKNIK RECOVERY:
DEFERRED UPDATE (3)
 Yang perlu diperhatikan adalah bahwa penulisan
record log ke disk dilakukan sebelum transaksi
benar-benar commit,
 Dengan demikian, jika sistem gagal, record log
tetap ada dan update dapat dilakukan kemudian.
16
TEKNIK RECOVERY:
DEFERRED UPDATE (4)
 Dalam hal terjadi kegagalan, file log digunakan
untuk mengidentifikasi transaksi mana yang gagal.
 Mulai dari entry terakhir dalam log file, lakukan
pelacakan mundur untuk menentukan checkpoint
yang paling akhir:
a. Lakukan redo untuk transaksi antara start dan
commit. Redo melaksanakan semua penulisan
ke basis data menggunakan record log afterimage dengan urutan sebagaimana urutan log.
17
TEKNIK RECOVERY:
DEFERRED UPDATE (5)
b. Transaksi antara start dan abort diabaikan karena
tidak ada penulisan ke dalam basis data sehingga
undo tidak dilakukan.
 Jika terjadi crash pada waktu proses recovery
dilakukan, record log digunakan lagi untuk
melakukan restore basis data.
18
TEKNIK RECOVERY:
IMMEDIATE UPDATE
 Update dilakukan tanpa menunggu transaksi
mencapai titik commit.
 Jika transaksi gagal sebelum mencapai titik
commit, perlu dilakukan aksi undo.
 Aksi redo mungkin diperlukan untuk meng-update
transaksi yg committed.
19
TEKNIK RECOVERY:
IMMEDIATE UPDATE
 gunakan log file untuk mencegah kegagalan sistem
dengan cara sbb:
 Ketika transaksi dimulai, tulis record transaction start ke dlm
log.
 Ketika operasi penulisan dilakukan, tulis record berisi data yang
diperlukan ke dalam file log.
 Sekali record log ditulis, tulis update ke dalam buffer basis data.
 Update ke bd ditulis ketika buffer dipindahkan ke memori
sekunder.
 Ketika transaksi commit, tulis record transaction commit ke dl
log.
20
TEKNIK RECOVERY:
IMMEDIATE UPDATE
 Yang penting di sini adalah apa yang disebut
dengan write-ahead log protocol, yaitu penulisan
record log dilakukan sebelum penulisan ke basis
data.
 Aturan ini menjamin bila ada transaksi yang tidak
commit maka proses undo dapat dilakukan.
21