1 / 43

Teknik recovery

Teknik recovery. M.Iqbal Habibie. 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.

lesa
Download Presentation

Teknik recovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Teknik recovery M.IqbalHabibie

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

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

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

  5. TRANSAKSI • Satu cara untuk menspesifikasikan batasan transaksi adalah denganmembuat statemen begin transaction dan end transaction dalam programaplikasi; Pada kasus ini semua operasi yang mengakses database di antara statemen begin-end dianggap sebagai sebuah transaksi.

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

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

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

  9. STATUS TRANSAKSI & OPERASI TAMBAHAN

  10. 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 (bencanafisikyg natural), sepertikebakaran, air bah, gempa • Carelessness (kekurangtelitianataukerusakanpada data ataufasilitasygtidakdisengajadisebabkanoleh operator ataupengguna) • Sabotase, kerusakanpada data, fasilitasperangkatlunak & kerasygdisengaja

  12. PENYEBAB KEGAGALAN • System crash (kerusakansistem), akibatkesalahanpadaperangkatkerasataulunak, menyebabkankehilanganmemoriutama • Media failure (kegagalanpada media), seperti media tidakdapatdibaca, menyebabkankehilangansebagiandaripenyimpanansekunder • Application software error (kesalahanpadaperangkatlunakaplikasi, sepertikesalahanlogikaygmengakses basis data menyebabkansatuataulebihtransaksimengalamikegagalan

  13. 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 secaraperiodikterhadap basis data ygada • Fasilitas Logging Mencatattransaksi-transaksidanperubahan-perubahan yang terjaditerhadap basis data. DBMS memelihara file khusus yang disebut Log (Journal) yang menyediakaninformasimengenaiseluruhperubahan yang terjadipada basis data. • Fasilitas Checkpoint Mengizinkan update terhadap basis data yang akanmenjadi basis data yang permanen • Manager recovery Mengizinkansistemuntukmenyimpankembali basis data kekeadaansebelumterjadikegagalan

  15. TEKNIK RECOVERY • Prosedur recovery yang digunakantergantungdarikegagalan yang terjadipada basis data. Terdapat 2 kasuskerusakkan : 1. Jika basis data rusaksecarafisikseperti : disk head crash danmenghancurkan basis data, maka yang terpentingadalahmelakukanpenyimpanankembali backup basis data yang terakhirdanmengaplikasikankembalioperasi-operasi update transaksi yang telah commit denganmenggunakan log file. Denganasumsibahwa log file-nyatidakrusak.

  16. TEKNIK RECOVERY (lanj.) 2. Jika basis data tidakrusaksecarafisiktetapimenjaditidakkonsisten, sebagaicontoh : sistem crash sementaratransaksidieksekusi, maka yang perludilakukanadalahmembatalkanperubahan-perubahan yang menyebabkan basis data tidakkonsisten. Mengulangbeberapatransaksisangatdiperlukanjugauntukmeyakinkanbahwa perubahan2 yang dilakukantelahdisimpandidalam secondary storage. Di sinitidakperlumenggunakansalinan backup basis data, tetapidapat me-restore basis data kedalamkeadaan yang konsistendenganmenggunakan before dan after-image yang ditanganioleh log file.

  17. KONSEP RECOVERY Ada 2 teknik utama dalam melakukan recovery kesalahan transaksi : • Deferred update • Immediate update

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

  19. Deferred Update • Ide dari protocol update yang tertunda : • Sebuah transaksi tidak dapat merubah database pada disk hingga mencapai titik point • Sebuah transaksi tidak dapat mencapai titik point hingga semua operasi update disimpan dalam log dan ditulis ke disk

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

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

  22. 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)

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

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

  25. Recovery Deferred Update pada Multi-user • Kontrol konkurensi dan proses recovery berhubungan. Secara umum, semakin besar tingkat konkurensi dicapai, semakin banyak waktu untuk recovery.

  26. Recovery Deferred Update pada Multi-user • PROCEDURE RDU_M (WITH CHECKPOINT) : use 2 lists of transactionsmaintained by the system; the committed transactions T since the last checkpoint(commit list), and the active transactions T’ (active list). REDO all the WRITEoperations of the committed transactions from the log, in the order in which theywere written into the log. The transactions that are active and did not commit areeffectively canceled and must be resubmitted. • Recovery using Deferred Update in a Multi-user environment = RDU_M

  27. Recovery Deferred Update pada Multi-user

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

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

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

  31. 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)

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

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

  34. +/- 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

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

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

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

  38. +/- RIU pd multi user • Keuntungan • Tidak membatasi concurency • Kerugian • Ada REDO & UNDO • Ada cascading rollback

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

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

  41. 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 dan Y: Shadow copies dari item data X` dan Y`: Current copies dari item data

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

  43. +/- 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

More Related