Backup & Recovery

Sistem recovery basis data Komponen dalam RDBMS yang digunakan untuk mengembalikan basis data ke kondisi yang benar (consistent state) jika terjadi system failure (kegagalan sistem) PENYEBAB KEGAGALAN : Natural physical disasters bencana fisik yg natural, seperti kebakaran, air bah, gempa Carelessness / human error Kekurang telitian atau kerusakan pada data atau fasilitas yg tidak disengaja disebabkan oleh operator atau pengguna Sabotase, kerusakan pada data, fasilitas perangkat lunak & keras yg disengaja

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 data base menyebab kan satu atau lebih transaksi mengalami kegagalan, basis data menjadi tdk konsisten)

Jenis kerusakan & jenis media penyimpanan 1. Kegagalan Transaksi (Transaction error) a. Kesalahan Logika (Logical Error) input salah, data not found, overflow, memori habis b. Kesalahan Sistem (System Error) Deadlock 2. Kerusakan Sistem (System Crash) Hardware macet (hang), data pada memori sementara hilang 3. Kerusakan pada Disk (Disk Failure) Bad sector / disk macet pada saat operasi I/O

Jenis Media Penyimpanan : 1. Media Penyimpanan Sementara (Volatile Storage) RAM, Cache, Register 2. Media Penyimpanan Permanen (Non Volatile Storage) Tape, Disk 3. Media Penyimpanan Stabil (Stable Storage) Diperlukan suatu mekanisme untuk menjamin basis data konsisten dan keatomikan transaksi walaupun terjadi kegagalan/kerusakan.  Recovery

Operasi dasar ke media penyimpanan Basis data secara permanen tersimpan pada media permanen disk. Ruang penyimpanan pada disk dipilah berdasarkan Blok yang disebut dengan Blok data. Operasi database : disisipkan pada program aplikasi atau langsung dibuat interaktif dengan bahasa query misal SQL. Dalam program aplikasi , transaksi diawali dengan statement begin transaction dan end transaction

PemulihAN TRANSAKSI Transaksi merupakan unit logika dari proses database yang mencakup satu atau lebih operasi pengaksesan database – meliputi insert, delete, modifikasi atau operasi retrieve. Sebuah program aplikasi dapat berisi lebih dari satu transaksi Read-only transaction. Transaksi dalam database hanya mengambil (retrieve) data, tidak melakukan update Diagram transisi transaksi : 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

DIAGRAM KEADAAN TRANSAKSI 1. Begin transaction : keadaan awal transaksi 2. Partially Committed : keadaan setelah suatu pernyataan berhasil dilaksanakan 3. Committed: keadaan setelah transaksi berhasil dijalankan 4. Failed : keadaan setelah suatu pernyataan gagal melaksanakan tugas, kemudian keadaan dipulihkan pada keadaan sebelum transaksi (ABORT) 5. Terminated: keadaan transaksi berakhir (disetujui atau di batalkan)

FASILITAS RECOVERY PADA DBMS Mekanisme backup melakukan backup secara periodik terhadap data base yg ada Fasilitas Logging Mencatat transaksi dan perubahan-perubahan yang terjadi terhadap data base. DBMS memelihara file khusus yang disebut Log (Journal) yang menyediakan informasi mengenai seluruh perubahan yang terjadi pada data base. Fasilitas Checkpoint Mengizinkan update terhadap data base yang akan menjadi data base yang permanen Manager recovery Mengizinkan sistem untuk menyimpan kembali data base ke keadaan sebelum terjadi kegagalan

LOGING Untuk mengcover kegagalan dari transaksi, sistem mempunyai catatan yang disebut dengan log file untuk menjaga jalannya semua operasi yang mempengaruhi nilai dari item database. Informasi ini mungkin akan dibutuhkan untuk mengcover adanya kegagalan. Log file disimpan di storage, dan secara berkala di back- up ke storage lainnya untuk menjaga dari kerusakan yang fatal. Log file adalah komponen yang penting dalam data base. Bila terjadi system failure, log file diperlukan untuk mengembalikan data base ke consistent state. Struktur log file menyerupai relasi ( tabel ) yang terdiri dari sejumlah field (kolom) dan sejumlah record (baris)

Field-field dalam log file terdiri dari: Nama Keterangan LSN (Log Sequence Number) tanda pengenal (identifier) tiap log record TransactionID berfungsi sebagai identifier suatu transaksi Operation jenis operasi dari transaksi yang bisa berupa: start, commit, abort, insert, update, atau delete Database nama data base yang akan dimodifikasi Table nama tabel yang akan dimodifikasi Field field apa saja yang akan dimodifikasi dari tabel yang bersangkutan. OldRecordID, berisi kode record lama sebelum dimodifikasi. Kode record diperoleh dari sistem storage management yang berperan dalam menyimpan data base secara fisikal. NewRecordID kode record baru setelah dimodifikasi. BeforeImage nilai field sebelum operasi dijalankan AfterImage nilai field setelah operasi dijalankan pPtr, pointer menunjuk ke log record yang berisi operasi sebelumnya dari transaksi yang sama

strategi recovery Restore dari backup. - Jika terjadi kerusakan ke sebagian data base, misalnya disk crash, metode recovery yang digunakan adalah merestore copy sebelumnya dari data base yang sudah diback-up ke storage khusus (biasanya tape) Membangun kembali status dengan redo operasi dari transaksi yang commit dari log backed-up sampai waktu dimana terjadi kegagalan Undo Operasi Jika data base tidak secara fisik rusak tetapi hanya menjadi tidak konsisten karena adanya kesalahan (system crash, system error, local error, concurrency control),

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

DEFERRED/TUNDA UPDATE Update tidak dilakukan secara langsung pada data base, tetapi update dilakukan setelah transaksi menyelesaikan eksekusinya dengan sukses dan mencapai titik commit. Sebelum mencapai commit semua transaksi yang di update disimpan pada buffer local hanya dicatat pada system log dan transaction workspace. Setelah transaksi commit dan log sudah dituliskan ke disk, maka update dituliskan ke data base

Karena data base 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 data base di disk.

contoh mekanisme deferred update : 1. START  2. INSERT A  3. UPDATE B  4. DELETE A  5. COMMIT Untuk langkah 1, proses yang terjadi adalah:

Pada langkah 2, proses yang terjadi adalah:

Pada langkah 4, proses yang terjadi adalah:

Keuntungan & kekurangan deferred update Lebih aman karena operasi tidak langsung mengubah data base sebelum transaksi di-commit, sehingga bila terjadi system failure atau transaksi abort, data base tetap dalam consistent state. Teknik deferred update menuntut kapasitas temporary database yang lebih besar karena harus menyimpan semua blok data base yang dimodifikasi dalam temporary database hingga commit.

Recovery Berdasarkan Immediate Update (RIU) Update dilakukan langsung pada data base tanpa menunggu transaksi mencapai titik commit Operasi tetap harus dituliskan ke log (pada disk) sebelum update dilakukan pada data base  Write- Ahead Logging protocol

Langkah-langkah teknik immediate update dengan algoritma UNDO/NO-REDO adalah: 1) Ketika transaksi mulai, tulis sebuah record START ke log file. 2) Setiap operasi transaksi diterima, log record berisi data yg relevan akan ditambahkan ke dalam log file. 3) Temporary database akan meng-copy blok data base yang mengandung data yang diperlukan bila blok tersebut belum ada. 4) Jalankan operasi transaksi terhadap blok data base dalam temporary database. 5) Langsung salin kembali blok data base yang telah termodifikasi dari temporary database ke data base. 6) Ketika transaksi commit, semua modifikasi terhadap data base diselesaikan sebelum COMMIT TRANSACTION ditambahkan ke log file.

Contoh mekanisme immediate updATE 1. START 2. INSERT A  3. UPDATE B  4. DELETE A 5.COMMIT Untuk langkah 1 START, proses yang terjadi adalah:

Pada langkah 2 INSERT , proses yang terjadi adalah:

Pada langkah 3 UPDATE, proses yang terjadi adalah:

Pada langkah 4 DELETE , proses yang terjadi adalah:

Pada langkah 5 COMMIT, proses yang terjadi adalah:

Keuntungan & kekurangan IMMEDIATE update Efek dari operasi langsung tercatat pada database - Bila seorang pengguna telah mengcommit suatu transaksi tapi ternyata terjadi kegagalan saat pemrosesan, maka seluruh transaksi dianggap gagal karena record commit belum tercatat di log. - Perpindahan blok database dari dan ke temporary database akan lebih dinamis (cepat berubah). Akibatnya penggunaan disk I/O akan lebih boros. Hal ini akan menurunkan kinerja sistem.

PEMULIHAN SISTEM Penyebab : gangguan pada sistem (misal : mati listrik). Data pada RAM hilang dan ada transaksi yg tidak selesai, transaksi harus dibatalkan pada saat sistem diaktifkan kembali (UNDO) dan transaksi yang commit harus dijamin telah ditulis (proses REDO)

PEMULIHAN MEDIA Penyebab : kegagalan media (disk rusak) Memuat kembali (RESTORE) backup database,