Backup dan Recovery Basis Data

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.

Jenis-jenis kerusakan/kegagalan pada DBMS

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

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.

       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

l  tidak hanya meliputi data pada level pemakai akhir/ enduser

l  tetapi juga bisa mencakup bagian-bagian penting dari basis data secara keseluruhan, seperti file-file kontrol (meta data) ataupun file-file log.

Ditinjau dari objeknya, backup dapat dikelompokkan kedalam:

1. Backup fisik (physical backup)

l  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)

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

Berdasarkan waktu pelaksanaan atau strateginya, ada dua jenis operasi backup yang dapat kita pilih , yaitu:

1. Backup Statis, di mana backup dilakukan dengan terlebih dahulu menonaktifkan basis data secara keseluruhan.
2. Backup Dinamis, di mana backup dilakukan tanpa penonaktifan basis data sehingga user tetap bisa bekerja.

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.

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

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

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.

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

RECOVERY

l  Operasi recovery adalah operasi untuk mengembalikan kondisi database sebelum terjadi kesalahan atau kerusakan.

l  Jenis-jenis operasi recovery:

l  RECOVERY BERBASIS FILE LOG

l  RECOVERY BERBASIS TIME LINE

l  RECOVERY BERBASIS SHADOW PAGE

RECOVERY BERBASIS FILE LOG

l  File log merupakan sarana yang umum digunakan untuk merekam terjadinya perubahan-perubahan terhadap basis data.

l  File log ini berisi record-record log yang berkolerasi dengan semua operasi perubahan pada basis data.

l  Terdapat  beberapa jenis record-record log yang nantinya akan terlibat dalam mekanisme recovery.

l  Sebuah record log untuk menunjukkan sebuah operasi penulisan ke basis data, akan memiliki field-field seperti berikut ini:

l  Pengidentifikasi Transaksi (Transaction identifier), yang merupakan nilai unik untuk mengidentifikasi transaksi yang menjalankan operasi write.

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

l  Nilai lama (old value), yang merupakan nilai item data sebelum operasi write dijalankan.

l  Nilai baru (new value), yang merupakan nilai item data setelah operasi write dijalankan.

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.

Beberapa jenis-jenis record file log yang menunjukkan operasi-operasi penting terhadap basis data:

¨  < T_i start> menunjukan adanya sebuah transaksi T_i telah dimulai.

¨  < T_i , X_j , V₁ , V₂ > yang menunjukkan transaksi T_i telah menjalankan operasi write terhadap item data X_j. X_j mula-mula bernilai V₁ sebelum operasi tersebut dan kemudian bernilai V₂ setelah operasi write tersebut.

¨  < T_i commit > yang menunjukkan transaksi T_i  telah direkam sempurna (di-commit)

¨  < T_i abort > yang menunjukkan transaksi T_i  telah dibatalkan.

¨  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)

Incremental Log With Deferred Updates

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

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

l  Teknik ini hanya membutuhkan nilai baru (New Value) dari item yang terlibat dalam operasi write.

l  Ilustrasi transfer dari rekening A ke rekening B sebesar Rp. 100000,- dan penarikan dari rekening C sebesar Rp. 200000,-

T₀ :          read(A)

A ß A – 100000

write(A)

read(B)

B ß B + 100000

write(B)
 T₁ :          read(C)

C ß C – 200000

write(C)

¨  Transaksi-transaksi tersebut dieksekusi secara serial dengan urutan T₀ baru kemudian T₁ dan nilai saldo awal untuk rekening A, B, dan C berturut-turut adalah 1 juta, 2 juta, dan 500 ribu rupiah.

Log                                             Basis data

< T₀ start > 

< T_0, A, 900000 >
< T_0, B, 2100000 >
< T₀ commit >                                      A = 900000 
                                                   B =  2100000 
< T₁ start >                                     
< T_1, C, 300000 >< T₁ commit >                     C = 300000

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

Log Basis data

< T₀ start >                                         

< T_0, A, 900000 >

< T_0, B, 2100000 >  

< T₀ commit >

                                                                                A = 900000

                                                                                B =  2100000

 

< T₀ start >                                         

< T_0, C, 300000 >

< T₀ commit >

                                                                                C = 300000

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.

¨  Ilustrasi:

Log                                 Basis data                                                                   

< T₀ start >                                         

< T_0, A, 1000000 , 900000 >             A = 900000

< T_0, B, 2000000 , 2100000 >            B =  2100000

                                                                                               

                                                                                               

< T₀ commit >

< T₀ start >                                         

< T_0, C, 500000, 300000 >            C = 300000

                                                                                               

< T₀ commit >

Jika terjadi kegagalan sistem, skema recovery ini memakai dua prosedur berikut ini:

Undo(T_i), yang merekam kembali nilai semua item data yang diubah  oleh transaksi T_i ke nilai awalnya.

Redo(T_i), yang membuat semua nilai item data yang diubah oleh transaksi T_i ke nilai barunya.

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 T_i harus dikembalikan ke kondisi awalnya (undo) jika dalam file log terdapat record < T_i start > dan tidak ada record < T_i commit >

¨  Transaksi T_i harus dituntaskan (redo) jika dalam file log terdapat record < T_i start > dan record < T_i commit >