Backup dan Recovery.

Presentasi berjudul: "Backup dan Recovery."— Transcript presentasi:

1 Backup dan Recovery

2 OVERVIEW Beberapa panyebab kerusakan atau kegagalan transaksi/operasi adalah: Aliran listrik putus, yang dapat mengakibatkan hilangnya informasi yang ada di memori utama dan register. Kesalahan operator (human error), dimana operator (manusia) melakukan kesalahan operasi yang tidak disengaja. Kesalahan perangkat lunak, yang dapat mengakibatkan hasil pengolahan (akhir/antara) menjadi tidak benar, informasi yang disajikan ke user salah, dan basis data menjadi tidak konsisten. Disk rusak, yang dapat mengakibatkan hilangnya informasi atau rusaknya basis data yang ada di dalam disk. Pada bab ini akan dibahas dua jenis operasi terhadap basis data dengan fungsi yang berlawanan tapi memiliki ketergantungan satu sama lain.

3 Jenis-jenis kerusakan/kegagalan pada DBMS
Kegagalan Transaksi (Transaction Failure) Ada beberapa jenis kesalahan/ error yang dapat menyebabkan sebuah transaksi menjadi gagal: Kesalahan logika (Logical Error), di mana program/ sistem tidak dapat melanjutkan eksekusi normalnya karena adanya kondisi internal tertentu seperti masukan yang salah/ rusak, data tidak tersedia, nilai data diluar batas domain yang diperbolehkan (overflow), logika program yang tidak tepat (bugs) atau batas sumber daya sistem (resource) seperti memori habis. Kesalahan sistem (System Error), dimana program/ sistem telah memasuki kondisi yang tidak diharapkan seperti terjadinya deadlock , sebagai hasil dari tidak tereksekusinya program/ sistem secara normal.

4 2. Kerusakan sistem (System Crash)
Hardware macet (hang), menyebabkan isi media penyimpanan sementara (volatile storage) hilang. 3. Kegagalan/ kerusakan Disk (Disk Failure) Adanya/ terjadinya bad sector atau disk macet pada saat berlangsungnya operasi I/O ke disk.

5 BACKUP Disamping menunjukkan salah satu jenis operasi yang penting dalam sebuah sistem basis data, istilah backup dapat pula merujuk pada objek dari operasi tersebut. Sebagai objek, backup adalah salinan dari data. Data di sini tidak hanya meliputi data pada level pemakai akhir/ enduser tetapi juga bisa mencakup bagian-bagian penting dari basis data secara keseluruhan, seperti file-file kontrol (meta data) ataupun file-file log.

6 Ditinjau dari objeknya, backup dapat dikelompokkan kedalam:
1. Backup fisik (physical backup) Adalah salinan fisik file-file basis data seperti tabel-tabel data, file kontrol, file log. Backup fisik dapat dihasilkan dari pengeksekusian program utilitas yang disediakan oleh DBMS yang bersangkutan ataupun program utilitas yang disediakan oleh sistem operasi (Operating System) dimana DBMS itu berada. 2. Backup lojik (logical backup) Backup lojik kita dapatkan dari pembentukan file-file /objek yang berisi perintah (bisa berupa teks bahasa SQL ataupun perintah biner) yang jika dieksekusi dapat mengembalikan basis data ke kondisi semula. Backup lojik hanya dapat dihasilkan dari pengeksekusian program utilitas khusus yang disediakan oleh DBMS yang bersangkutan.

7 Berdasarkan waktu pelaksanaan atau strateginya, ada dua jenis operasi backup yang dapat kita pilih , yaitu: Backup Statis, di mana backup dilakukan dengan terlebih dahulu menonaktifkan basis data secara keseluruhan. Backup Dinamis, di mana backup dilakukan tanpa penonaktifan basis data sehingga user tetap bisa bekerja.

8 Remote Backup DBMS yang tersentralisasi maupun client-server hanya menekankan pada pembendaan lokasi pemrosesan tetapi lokasi data tetap pada satu lokasi saja. Kondisi ini akan menimbulkan masalah jika suatu saat terjadi kebakaran, bencana alam, aksi terorisme, dll.

9 Sebuah alternatif adalah dengan menjalankan pengolahan transaksi pada sebuah situs yang disebut sebagai situs utama/ primer, tetapi dengan memiliki sebuah situs untuk backup jarak jauh (remote backup), dimana semua data disitus utama direplikasi. Situs remote backup ini harus disinkronisasi dengan situs primer begitu terjadi perubahan pada situs primer yaitu dengan mengupayakan sinkronisasi dengan mengirimkan semua record log dari situs primer ke remote backup.

10 Berikut ini adalah contoh dari arsitektur adanya situs remote backup bagi sebuah situs primer:

11 Ketika situs primer mengalami kerusakan maka situs remote backup akan segera mengambil alih pemrosesan. Beberapa isu yang perlu kita perhatikan pada saat merancang sebuah sistem dengan remote backup adalah: Pendeteksian kerusakan Kerusakan saluran komunikasi dapat saja menyebabkan situs remote backup berkesimpulan bahwa telah terjadi kerusakan pada situs primer. Untuk menghindari problem ini kita harus menerapkan beberapa saluran (link) komunikasi yang independen antara kedua situs. Pemindahan kontrol Ketika situs primer mengalami kerusakan, situs backup akan mengambil alih pemrosesan dan menjadi situs primer yang baru.

12 Waktu untuk pemulihan Konfigurasi hot-spare dapat membuat proses pengalihan kontrol menjadi lebih cepat (hampir instant). Pada konfigurasi ini, situs remote backup secara terus menerus memproses isi file log untuk aksi redo begitu record file log tersebut diterima dan kemudian menerapkannya secara lokal. Waktu untuk commit Sebuah transaksi harus tidak dinyatakan ter-commit sebelum record-record log-nya telah diterima situs backup-nya.

13 RECOVERY Operasi recovery adalah operasi untuk mengembalikan kondisi database sebelum terjadi kesalahan atau kerusakan. Jenis-jenis operasi recovery: RECOVERY BERBASIS FILE LOG RECOVERY BERBASIS TIME LINE RECOVERY BERBASIS SHADOW PAGE

14 RECOVERY BERBASIS FILE LOG
File log merupakan sarana yang umum digunakan untuk merekam terjadinya perubahan-perubahan terhadap basis data. File log ini berisi record-record log yang berkolerasi dengan semua operasi perubahan pada basis data. Terdapat beberapa jenis record-record log yang nantinya akan terlibat dalam mekanisme recovery.

15 Sebuah record log untuk menunjukkan sebuah operasi penulisan ke basis data, akan memiliki field-field seperti berikut ini: Pengidentifikasi Transaksi (Transaction identifier), yang merupakan nilai unik untuk mengidentifikasi transaksi yang menjalankan operasi write. Pengidentifikasi data (Data-item identifier), yang merupakan nilai unik untuk identifikasi item data yang ditulis. Umumnya nilai ini juga menunjukkan lokasi fisik disk dari item data tersebut. Nilai lama (old value), yang merupakan nilai item data sebelum operasi write dijalankan. Nilai baru (new value), yang merupakan nilai item data setelah operasi write dijalankan.

16 Sebuah record log untuk menunjukkan sebuah operasi penulisan ke basis data, akan memiliki field-field seperti berikut ini: Pengidentifikasi Transaksi (Transaction identifier), yang merupakan nilai unik untuk mengidentifikasi transaksi yang menjalankan operasi write. Pengidentifikasi data (Data-item identifier), yang merupakan nilai unik untuk identifikasi item data yang ditulis. Umumnya nilai ini juga menunjukkan lokasi fisik disk dari item data tersebut. Nilai lama (old value), yang merupakan nilai item data sebelum operasi write dijalankan. Nilai baru (new value), yang merupakan nilai item data setelah operasi write dijalankan.

17 Beberapa jenis-jenis record file log yang menunjukkan operasi-operasi penting terhadap basis data:
< Ti start> menunjukan adanya sebuah transaksi Ti telah dimulai. < Ti , Xj , V1 , V2 > yang menunjukkan transaksi Ti telah menjalankan operasi write terhadap item data Xj. Xj mula-mula bernilai V1 sebelum operasi tersebut dan kemudian bernilai V2 setelah operasi write tersebut. < Ti commit > yang menunjukkan transaksi Ti telah direkam sempurna (di-commit) < Ti abort > yang menunjukkan transaksi Ti telah dibatalkan.

18 Teknik-teknik recovery berbasis log file
Teknik File Log dengan Penundaan Pengubahan (Incremental Log With Deferred Updates) Teknik File Log dengan Pengubahan Langsung (Incremental Log With Immediate Updates)

19 Incremental Log With Deferred Updates
Teknik ini menjamin keatomikan transaksi dengan merekam semua perubahan basis data ke dalam file log, tetapi menunda eksekusi semua operasi penulisan (write) dalam sebuah transaksi hingga transaksi tersebut barada dalam keadaan ter-commit secara parsial. Ketika sebuah transaksi telah ter-commit secara parsial, informasi pada file log yang berhubungan dengan transaksi tersebut akan digunakan untuk mengeksekusi operasi write yang tertunda. Jika sistem tersebut macet (crash) sebelum transaksi selesai dikerjakan, atau jika transaksi tersebut dibatalkan, maka informasi dalam file log ini dengan mudah dapat diabaikan. Teknik ini hanya membutuhkan nilai baru (New Value) dari item yang terlibat dalam operasi write.

20 Ilustrasi transfer dari rekening A ke rekening B sebesar Rp
Ilustrasi transfer dari rekening A ke rekening B sebesar Rp ,- dan penarikan dari rekening C sebesar Rp ,- T0 : read(A) A  A – write(A) read(B) B  B write(B) T1 : read(C) C  C – write(C)

21 Transaksi-transaksi tersebut dieksekusi secara serial dengan urutan T0 baru kemudian T1 dan nilai saldo awal untuk rekening A, B, dan C berturut-turut adalah 1 juta, 2 juta, dan 500 ribu rupiah. Log Basis data < T0 start > < T0, A, > < T0, B, > < T0 commit > A = B = < T0, C, > C =

22 Skema recovery ini menjalankan sebuah prosedur recovery jika ada kegagalan sistem, yaitu operasi Redo (Ti), yang membuat semua nilai item data yang diubah transaksi Ti ke nilai-nilai yang baru.

23 X Log Basis data < T0 start > < T0, A, 900000 >
< T0, B, > < T0 commit > A = B = < T0, C, > C = X CRASH

24 Incremental Log With Immediate Updates
Mekanisme recovery dengan pengubahan segera/langsung membuat tindakan-tindakan perubahan ke basis data di dalam transaksi langsung dilakukan terhadap basis data tersebut kendati transaksi tersebut masih berlangsung. Perubahan ke basis data untuk transaksi yang sedang aktif semacam ini disebut dengan perubahan tak sempurna (uncommitted modifications). Membutuhkan nilai baru dan nilai lama.

25 Ilustrasi: Log Basis data < T0 start > < T0, A, , > < T0, B, , > A = B = < T0 commit > < T0, C, > C =

26 Jika terjadi kegagalan sistem, skema recovery ini memakai dua prosedur berikut ini:
Undo(Ti), yang merekam kembali nilai semua item data yang diubah oleh transaksi Ti ke nilai awalnya. Redo(Ti), yang membuat semua nilai item data yang diubah oleh transaksi Ti ke nilai barunya.

27 Setelah terjadi kegagalan sistem/ basis data, skema recovery ini akan melihat isi dari file log untuk mengetahui transaksi mana saja yang akan diulangi dan transaksi mana saja yang akan dibatalkan. Keduanya dapat diketahui dengan menggunakan aturan sebagai berikut: Transaksi Ti harus dikembalikan ke kondisi awalnya (undo) jika dalam file log terdapat record < Ti start > dan tidak ada record < Ti commit > Transaksi Ti harus dituntaskan (redo) jika dalam file log terdapat record < Ti start > dan record < Ti commit >