Recovery : merupakan upaya untuk mengembalikan basis data ke keadaaan yang dianggap benar setelah terjadinya suatu kegagalan.

1.  Pemulihan terhadap kegagalan transaksi

2.  Pemulihan terhadap kegagalan system

3.  Pemulihan terhadap kegagalan media

Jenis – jenis kegagalan :

1.      Kegagalan system

Kegagalan yang mempengaruhi semua transaksi yang sedang berjalan tetapi tidak merusak database secara fisik.

Contoh : system error, software error

2.      Kegagalan media

Kegagalan yang merusak database dan semua transaksi yang sedang berjalan pada saat itu.

Contoh : head crash

Berbagai kemungkinan yang harus diantisipasi :

•         Gangguan Listrik

•         Kerusakan Disk

•         Kesalahan Perangkat Lunak

•         Pengaksesan oleh orang yang tidak berhak

•         Dua Pengguna/ lebih mengubah data yang sama

3.   Fasilitas recovery

Fasilitas recovery didalam DBMS :

•         Back up mechanism

Membuat back up database dan log file secara periodik

•         Looging facility

Mencatat semua transaksi yang sedang berjalan

•         Checkpoint facility

Synchronization point antara database dengan transaksi log file

•         Recovery manager

Mengijinkan system untuk merestore database kekondisi yang tepat

Sejumlah control yang disediakan oleh DMBS :

•         Pemulihan (recovery)

•         Pengamanan (security)

•         Integritas (integrity)

•         Konkurensi (concurency)

Teknik Pemulihan :                                       

1.      defered upate / perubahan yang ditunda :

Perubahan pada basis data tidak akan berlangsung sampai transaksi ada pada poin disetujui (COMMIT). Jika terjadi kegagalan maka tidak akan terjadi perubahan, tetapi  diperlukan operasi redo untuk mencegah akibat dari kegagalan tersebut.

2.      Immediate Upadte / perubahan langsung :

Perubahan pada basis data akan segera tanpa harus menunggu sebuah transaksi tersebut disetujui. Jika terjadi kegagalan diperlukan operasi UNDO untuk melihat apakah ada transaksi yang telah disetujui sebelum terjadi kegagalan.

3.      Shadow Paging :

Menggunakan page bayangan dimana pada prosesnya terdiri dari 2 tabel yang sama, yang satu menjadi tabel transaksi dan yang lain digunakan sebagai cadangan. Ketika transaksi mulai berlangsung kedua tabel ini sama dan selama berlangsung tabel transaksi yang menyimpan semua perubahan ke database, tabel bayangan akan digunakan jika terjadi kesalahan. Keuntungannya adalah tidak membutuhkan REDO atau UNDO, kelemahannya membuat terjadinya fragmentasi.

Pemulihan Transaksi

Sebuah transaksi adalah suatu kesatuan prosedur di dalam program yang mungkin memperbaharui data pada sejumlah tabel. Sebuah transaksi dikatakan telah disetujui (committed) kalau seluruh rangkaian proses dalam transaksi tersebut berhasil dilaksanakan. Dalam prakteknya, bisa saja sesuatu proses di dalam sebuah transaksi gagal dilaksanakan.

Keterangan :

a. mulai   : menyatakan keadaan awal

b. disetujui sebagian : keadaan setelah suatu pernyataan berhasil dilaksanakan

c. gagal : menyatakan keadaan setelah suatu pernyataan gagal melaksanakan tugas

d. batal : keadaan setelah transaksi dibatalkan. Setelah dibatalkan, keadaan dipulihkan  seperti keadaan awal transaksi.

e. disetujui  : keadaan setelah transaksi berhasil dijalankan

f. berakhir  : terjadi setelah transaksi disetujui atau dibatalkan

System mempunyai catatan yang disebut log atau jurnal pada disk, yang dijadikan pedoman untuk membatalkan suatu pengubahan basisdata prosedur konsep pencatatan pada log:

Baca (X, xi) menyatakan prosedur untuk membaca item X dan nilainya berupa xi.

Tulis (Y, yi) menyatakan prosedur untuk menulis item Y dan nilainya berupa yi.

Contoh catatan log :

mulai>  : ditulis ke dalam log sebelum Ti  dimulai

: pengubahan item X dengan nilai baru xi

: ditulis ke dalam log saat transaksi disetujui

Log Basis Data

Pernyataan pada SQL :

COMMIT  : menyetujui pengubahan data secara permanen dan membawa ke

keadaan  akhir

ROLLBACK  : membatalkan pengubahan data dan membawa ke keadaan akhir

Terdapat dua metode dasar, yaitu :

1.      pendekatan update-in-place.

2.   pendekatan deferred-update

Transaksi pada dasarnya melibatkan empat aksi, yaitu :

1. update – membaca dan memodifikasi sistem.

2. read – hanya membaca sistem.

3. commit – membuat permanent seluruh modifikasi terhadap sistem.

4. abort – membatalkan aksi-aksi yang telah dilakukan.

1.      Pendekatan update – in – place

Pendekatan ini melibatkan pembaharuan sistem sebagaimana transaksi berjalan dan meniadakan pembaruan-pembaruan jika transaksi dibatalkan. Implementasi aksi-aksi transaksi pada pendekatan ini adalah :

1.   Update – merekam  undo terhadap record (contoh nilai lama objek yang  diperbarui) di file log undo dan memperbarui sistem.

2.   Read – membaca nilai objek disistem.

3.   Commit – mengabaikan file log undo.

4.  Abort – menggunkan record-rekord undo di file log undo untuk mengembalikan   system ke kondisi semula sebelum transaksi dengan membalik operasi-operasi yang telah dilakukan.

2.     Pendekatan deferred – update

Melibatkan penyimpanan pembaruan-pembaruan transaksi saat dijalankan dan menggunakan pembaruan-pembaruan yang disimpan untuk memperbarui system saat transaksi di – commit. Implementasi aksi-aksi transaksi pada pendekatan ini adalah :

1. Update – merekam rekor redo ( contoh nilai baru dari objek yang sedang diperbarui) di file log redo (juga disebut intention list).

2.    Read – menggabungkan file log redo dan system untuk menentukan nilai objek.

3.  Commit – memperbarui system dengan menerapkan file log redo secara berurut (dimulai dengan opersi pertama yang dilakukan transaksi).

4.      Abort – mengabaikan file log redo dan transaksi.

   Shadow paging

•         Untuk pemeliharaan suatu transaksi digunakan 2 buah table page yaitu table page baru (current page) dan table page bayangan (shadow page)

•         Pada saat start kedua table page mempunyai isi yang sama

•         Table page bayangan tidak berubah selama waktu transaksi

•         Semua pengupdatean transaksi dituliskan ke table page baru

•         Pada saat hamper commit, isi table page bayangan di hapus dan isi table page baru dimasukkan ke dalam table page bayangan

•         Bila transaksi gagal maka table page harus dihapus

•         Dibandingkan menggunakan log file, menggunakan shadow paging lebih cepat karena tidak perlu redo atau undo, tetapi memerlukan data fragmentation dan garbage collection.

Pemulihan Sistem 

Karena gangguan sistem, hang, listrik terputus alirannya. Kegagalan pada system menyebabkan data yang berada dalam RAM hilang.

Implikasi :

Transaksi tidak selesai  : dibatalkan pada saat system aktif (prosesnya bisa disebut Undo).

Transaksi yang telah berakhir  (disetujui)  :ditulis ke basis data (prosesnya biasa disebut Redo).

Pemulihan Media

Pemulihan karena kegagalan media dengan cara mengambil atau memuat kembali salinan basis data (backup) atau Pemulihan dengan cara restore dari backup Bagian tak terpisah dari sistem basisdata adalah skema pemulihan (recovery). Pemulihhan bertanggung-jawab terhadap pendeteksian kegagalan dan mengembalikan basis data ke keadaan konsisten sebelum terjadinyya kegagalan. Kegagalan media (misalnya disk rusak) dan proses pemulihannya Kegagalan disebabkan penyimpanan permanent adalah jarang terjadi. Meskipun demikian perlu dipersiapkan untuk mengatasi kejadian kegagalan ini. Teknik utama untuk mengatasi ini adalah backup atau dump.

Kegagalan pada media disebabkan data di disk hhilang karena terkorupsi sewaktu sistem crash atau penulisan acak atau karena rusaknya head dari disk. Kalau kejadian ini berlangsung , kita dapat memperoleh data dari penyimpanan stabil (yang berpeluang kecil gagal karena dilakukan secara mirrored disks, atau mempunyai banyak kopian dibanyak lokasi jaringan).Data yang disimpan dipenyimpanan stabil adalah data itu sendiri dan file log. Kapan arsip yang konnsisten sulit dilakukan karena berarti harus menghentikan semua transaksi untuk perekaman kopian arsip. Pendekatan yang lebih baik adalah teknik “fuzzy dump” yaitu perekaman dilakukan secara asinkron selagi aktivitas transaksi berlangsung dilakukan secara konkuren sebagai aktivitas background. Skema dasar untuk mengatasai adalah backup seluruh isi basisdata ke penyimpan stabil (stabile storage) secara periodic. Penyimpan stabil adalah penyimpan yang tak pernah kehilangan isinya. Transfer blok antara memori dan penyimpan disk dapat menghasilkan beberapa kemungkinan hasil berikut :

Ø  sukses seluruhnya

Ø  informasi yang ditransfer tiba dengan selamat ditujuan

Ø  terjadi kegagalan persial

kegagalan. terjadi ditengah-tengah transfer dan blok tujuan memuat informasi yang salah.

Ø  terjadi kegagalan total

kegagalan terjadi diawal transfer sehingga blok tujuan tidak berubah. Sistem harus dapat mendeteksi terjadinya kegagalan transfer data dan melakukan prosedur pemulihan untuk mengembalikan blok ke keadaan konsisten . untuk melakukan hal ini, system harus mengelola dua blok fisik untuk tiap blok basisdata logik. Operasi penulisan sebagai berikut :

1.    Tulis informasi ke blok fisik pertama.

2.  Saat penulisan pertama sukses secara lengkap, tulis informasi yang sama ke blok fisik kedua.

3.  Penlisan dinyatakan sukses secara hanya setelah penulisan kedua sukses secara lengkap.

Prosedur pemulihan

Selama pemulihan , masing-masing pasangan blok fisik diperiksa. Jika keduanya sama dan tidak terdeteksi kesalahan , maka tak ada aksi yang dilakukan. Jika salah satu blok terdeteksi kesalahan, maka gantikan isisnya dengan blok yang tak terdeteksi kesalahan. Jika kedua blok tak terdeteksi kesalahan tapi berada maka gantikan blok pertama dengan nilai blok kedua.

Pemulihan berbasis log

Bentuk yang palingn sering digunakan untuk merekam mamodifikasi yang dilakukan terhadap basisdata adalah log. Rekaman log mendeskripsikan satu penulisan ke basisdata dan memiliki field-field berikut :

1. nama transaksi

nama transaksi untuk yang melakukan operasi penulisan.

2. nama item data

nama item data unik yang ditulis.

3. nilai nama

nilai ite data sebelum penulisan.

4. nilai baru

nilai item data yang seharusnya terjadi setelah penulisan.

Prosedur pemulihan

Setelah kegagalan maka basisdata dikembalikan ke keadaan terakhir yang di backup. Kemudian barisan transaksi stelah backup terakhir yang tercatat dilog dieksekusi ulang.

Pemulihan dengan checkpoint

Saat terjadi kegagalan system, maka diperlukan mengkonsultasi log untuk menetukan transaksi-transaksi yang perlu dijalankan kembali dan transaksi-trsansaksi yang perlu dijalankan kembali dan transaksi-transaksi yang tak perlu dijalankan ulang. Seluruh log perlu ditelusuri untuk menetukan hal ini. Terdapat dua kesulitan dengan pendekatan ini :

•  Proses pencairan memerlukan banyak waktu.

•  Kebanyakan transaksi yang perlu dilakukan telah dituliskan ke basisdata.

Meskipun menjalankan ulang transaksi-transaksi itu tidak merusak, tapi pemulihan menjadi lebih lama. Meruduksi overhead ini diperlukan checkpoint. System mengelolah log menggunakan salah satu teknik-teknik diatas. Sistem secara periodik membuat checkpoint sebagai berikut :

•  Tulis semua rekaman log yang saat itu berada dimemori utama kepenyimpan

stabil.

•  Tulis semua blok buffer yang telah dimodifikasi ke disk.

•  Tulis record log ke penyimpan stabil.

Cara Melakukan Recovery Database

1. Automatic Recovery

Automatic Recovery yaitu proses recovery yang dilakukan secara otomatis. Hal ini

adalah pilihan termudah untuk melakukan recovery database, karena hampir tidak

membutuhkan campur tangan pemakainya. Anda bisa melakukan hal ini dengan

mengikuti langkah-langkah berikut ini :

• Buka Recovery Manager. Kotak dialog Recovery Manager

• Dari kotakdialog tersebut, klik pushbutton Automatic Recovery.

• Jika database tidak aktif dan Anda ingin menampilkan dan memodifikasi nama file struktur database, maka Anda bisa memilih tombol File, sehingga kotak dialog Database Files muncul di layar.

• Jika databae Anda tidak aktif dan Anda ingin menampilkan dan mengubah parameter-parameter database yang akan berefek mulai dari database dibuka sampai proses recovery.

• Pilih tombol Recovery.

2. Memulihkan Database dengan Full Backup

Jika hal ini yang memang Anda lakukan, maka Oracle akan melakukan proses

recovery database dengan menggunakan file-file hasil full backup. Untuk melakukan

hal ini, Anda bisa mengikuti langkah-langkah berikut ini :

• Buka Recovery Manager, sehingga kotak dialog Recovery Manager tampak dilayar.

• Dari kotak dialog tersebut, pilih pushbutton Restore From Full Database Backup.

• Jika database tidak aktif dan Anda ingin menampilkan dan memodifikasi nama file struktur database, maka Anda bisa memilih tombol File sehingga kotak dialog Database Files muncul di layar.

• Jika database Anda tidak aktif dan Anda ingin menampilkan serta merubah parameter-parameter database yang akan berefek jika database dimulai sampai proses recovery, pilih tombol Parameters sehingga di layar Anda tampak kotak dialog Edit Database Parameter. Lakukan pengeditan terhadap parameter-parameter tersebut jika memang Anda menghendakinya. Jika sudah, klik tombol OK.

• Pilih Tombol Recovery sehingga di layar akan tampak kotak dialog

• Dari kotak dialog tersebut, pilih push button Restore From tape, atau Restore From Disk.

• Jika Anda merestore dari tape, pilih device dari daftar drop downnya. Jika Anda merestore dari disk, pilih direktori yang akan Anda gunakan untuk merestore database, dengan menggunakan tombol Browse atau mengetikkan direktori pathnya di dalam bagian Direktory.

• Pilih file backup dari daftar file Backup. Pilih klausa "<latest backup>" untuk menggunakan hasil backup yang terakhir atau menurut tanggal tertentu. Jika database tidak dijalankan, Anda akan diminta untuk memasukkan password database.

• Masukkan password Anda, dan jika sudah, klik tombol OK.

• Jika semua sudah selesai, pilih OK.