Recovery Adapted from: Connolly, Thomas., et.al., 2002. Database System. Wokingham England: Addison-Wesley Publishing Company.

Presentasi berjudul: "Recovery Adapted from: Connolly, Thomas., et.al., 2002. Database System. Wokingham England: Addison-Wesley Publishing Company."— Transcript presentasi:

1 Recovery Adapted from: Connolly, Thomas., et.al., Database System. Wokingham England: Addison-Wesley Publishing Company

2 Model Transaksi Selama proses eksekusi transaksi, basis data secara temporer boleh jadi dalam keadaan status tidak konsisten Database recovery: proses mengembalikan basis data ke status benar bila terjadi kegagalan transaksi Merupakan layanan yang ada dalam DBMS

3 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

4 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

5 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

6 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

7 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: Record transaksi Record checkpoint. 7

8 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

9 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

10 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

11 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: 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

12 Teknik Recovery: Basis data tidak konsisten
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

13 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

14 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

15 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

16 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

17 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: Lakukan redo untuk transaksi antara start dan commit. Redo melaksanakan semua penulisan ke basis data menggunakan record log after-image dengan urutan sebagaimana urutan log. 17

18 Teknik recovery: deferred update (5)
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

19 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

20 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

21 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