TEKNIK RECOVERY
Oleh: I Gede Made Karma
Source:http://iqbalhabibie.staff.gunadarma.ac.id/Downloads/files/31240/4.4+REcovery.ppt
PENDAHULUAN
Konsep transaksi menyediakan suatu mekanisme untuk menggambarkan unit logika dari proses database.
Sistem pemrosesan transaksi merupakan sistem dengan database yang besar dan ribuan concurrent user yang mengeksekusi transaksi database.
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. Single-user DBMS kebanyakan terbatas pada
beberapa sistem mikro komputer, selain itu multiuser.
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;
Pada kasus ini semua operasi yang mengakses database di antara statemen begin-end dianggap sebagai sebuah transaksi.
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 operasinya dengan diagram transisinya :
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 direstore ke status yang konsisten ke waktu sebelum terjadi kegagalan.
11
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 yg tidak
disengaja disebabkan oleh operator atau
pengguna)
Sabotase, kerusakan pada data, fasilitas
perangkat lunak & keras yg disengaja
12
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 yg mengakses basis data menyebab kan satu atau lebih transaksi mengalami kegagalan
KONSEP RECOVERY
Untuk mengcover kesalahan atau kegagalan dari transaksi, sistem memaintain sebuah log untuk menjaga jalannya semua operasi yang mempengaruhi nilai dari item database. Informasi ini mungkin akan dibutuhkan untuk mengcover adanya kegagalan.
LOG disimpan di storage, dan secara berkala diback-up ke storage lainnya untuk menjaga dari kerusakan yang fatal.
14
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
15
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.
16
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.
KONSEP RECOVERY
Ada 2 teknik utama dalam melakukan recovery kesalahan transaksi :
1. Deferred update 2. Immediate 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 titik point
2. Sebuah transaksi tidak dapat mencapai titik point 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.
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
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). Entri [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) : use
2 lists of transactions maintained by the system; the committed transactions T since the last checkpoint (commit list), and the active transactions T’ (active list). REDO all the WRITE operations of the committed transactions from the log, in the order in
which they were written into the log. The transactions that are active and did not commit are effectively
canceled and must be resubmitted.
Recovery using Deferred Update in a Multi-user
environment = 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
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 copydari 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
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 Database
X' Y'
X dan Y: Shadow copies dari item data X` dan Y`: Current copies dari item data
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.
Page 5 (old) Page 1 Page 4 Page 2 (old) Page 3 Page 6 Page 2 (new) Page 5 (new) 1 2 3 4 5 6 Current Directory (after updating pages 2, 5)
Shadow Directory (not updated) 1 2 3 4 5 6
+/- 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
