Setelah kita bahas tentang protokol transaksi konkuren, selanjutnya akan saya bahas tentang recoverability, serializability dan schedule. Cekidot . . .
Recoverability
Pemulihan Basis Data / Recovery sangat penting untuk menjaga konsistensi setelah terjadi kegagalan pada sistem. Recoverability adalah kemampuan untuk membangun kembali atau pemulihan layanan jika mengalami kesalahan atau kegagalan komponen.Tujuan dari pemulihan basis data ini adalah untuk mengembalikan Basis Data kekeadaan konsisten semula.
Seperti peralatan elektrik lainnya, komputer mudah terjadi kegagalan (Failure) atau kerusakan (crash). Beberapa penyebab kegagalan :
- Aliran Listrik Putus : Data / informasi yang ada di Volatile Storage akan hilang.
- Kesalahan Operator : Data yang dimasukan salah sehingga hasil dari eksekusi transaksi menjadi salah.
- Kesalahan Perangkat Lunak : Mengakibatkan eksekusi transaksi berjalan tidak normal.
- Kerusakan Disk (Disk Crush) : Informasi / data yang ada di dalam non volatile, storage bisa hilang.
Jenis - jenis Kegagalan yang sering dialami:
- Logical Eror : System / program berjalan tidak normal, contohnya Bad Input, OverFlow/eror, Data Not Found, Out of Memory.
- System Eror : System / pogram memasuki suatu kondisi yang tidak di harapkan, contoh : DeadLock.
- System Crush : Terjadi kerusakan pada sistem. contoh : Hardware mulfunction (ketidakberfungsian perangkat keras ). Terjadi kerusakan pada sektor atau kepala rekam baca sehingga data menjadi rusak.
Ada beberapa teknik dalam melakukan recovery:
- 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 UNDO untuk mencegah akibat dari kegagalan tersebut.
Ide dari protocol update yang tertunda :
- Sebuah transaksi tidak dapat merubah database pada disk hingga titik point
- Sebuah transaksi tidak dapat mencapai titik point hingga semua operasi
Update disimpan dalam log dan ditulis ke disk .Karena database tidak pernah ter-update ada 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 database di disk.
Keuntungan dari metode atau algoritma NO-UNDO/REDO adalah operasi transaksi yang tidak pernah dibutuhkan batal dilaksanakan, karena :
- Transaksi tidak mencatat setiap perubahan dalam database pada disk sampai mencapai point commit, yaitu sampai menyelesaikan eksekusi secara lengkap. Sehingga transaksi tidak pernah dirolled back karena kesalahan selama eksekusi transaksi.
- Transaksi tidak akan pernah membaca nilai yang ditulis oleh transaksi yang belum commit karena item tetap terkunci sampai transaksi mencapai titik commit.
- Immediate Update / perubahan langsung
Perubahan Di teknik ini, database akan diupdate oleh beberapa transaksi sebelum transaksi mencapai titik point. Operasi secara khusus disimpan di log pada disk dengan force-writing sebelum diaplikasikan ke database. Jika transaksi gagal setelah menyimpan beberapa perubahan pada database tetapi mencapai titik commit, efek dari operasi pada database harus undone (lepas/ buka); harus rolled back.
Jika transaksi mencapai commit sebelum semua perubahan ditulis ke database dikenal dengan algoritma UNDO/ REDO. Variasi dari algoritma ini adalah semua update disimpan dalam database sebelum sebuah transaksi mencapai commit (membutuhkan hanya UNDO), dikenal dengan algoritma UNDO/NO-REDO
- 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.
Serializability
Masalah utama pengeksekuasian transaksi secara bersamaan adalah integritas dan validitas data. Untuk kedua hal perlu adanya sebuah mekanisme tertentu.
Serializability adalah suatu aturan untuk menjadwalkan proses-proses transaksi yang dijalankan hampir bersamaan dengan tetap menjaga konsistensi data seolah-olah proses dari transaksi-transaksi tersebut dijalankan secara serial.
Cara menjaga serializability
- Lock Based Protocol
Merupakan suatu cara yang digunakan untuk tetap menjaga serializability pada data yang diakses oleh lebih dari suatu transaksi. Yaitu, apabila satu transaksi mengakses sebuah item data maka tidak akan ada transaksi yang dapat memodifikasi data tersebut.
Ada dua jenis mode penguncian dasar yang digunakan dalam mekanisme ini yaitu:
- Bersama (Shared). Jika sebuah transaksi Ti dapat melakukan penguncian dengan mode ini (dilambangkan dengan S) terhadap item data Q, maka Ti dapat membaca, tapi tidak dapat mengubah nilai Q tersebut.
- Tunggal (Exclusive). Jika sebuah transaksi Ti dapat melakukan penguncian dengan mode ini (dilambangkan dengan X) terhadap item data Q, maka Ti dapat membaca maupun mengubah nilai tersebut.
Hal yang harus diperhatikan :
- Setiap transaksi harus meminta lock apabila akan melakukan operasi/mengakses terhadap suatu data. Misalkan data Q, mode-lock yang diterapkan terhadap data Q harus sesuai dengan operasi yang akan dilakukan.
- Transaksi meminta lock terhadap suatu data, kepada concurrency control manager.
- Operasi terhadap Q dapat dilakukan transaksi T apabila concurrency control manager memberikan grant (hak istimewa) lock yang diminta.
- Two Phase Lock Protokol
Protocol ini menginginkan bahwa setiap transaksi yang akan menjalankan penguncian dan melepaskan penguncian harus melalui dua fase atau tahapan, yaitu:
- Fase Pertumbuhan (Growing Phase). Sebuah transaksi dapat melakukan sejumlah penguncian tetapi belum satupun melepaskan pengunciannya.
- Fase Pelepasan (Shrinking Phase). Sebuah transaksi dapat melepaskan sejumlah penguncian , tetapi belum melakukan penguncian yang baru.
Pada awalnya, sebuah transaksi akan berada dalam fase pertumbuhan. Transaksi tersebut akan melakukan penguncian sebanyak yang dibutuhkan. Ketika transaksi mulai melepaskan sebuah penguncian, ia akan mulai memasuki fase pelepasan, tanpa ada permintaan penguncian berikutnya.
Schedule
Schedule adalah sebuah urutan dari operasi-operasi oleh satu set transaksi yang jalan bersamaan yang menjaga urutan operasi pada setiap transaksi individual. Sebuah transaksi mencakup sebuah urutan operasi yang terdiri dari tindakan baca dan/atau tulis pada database, diikuti oleh sebuah tindakan commit atau abort.
Sebuah schedule S terdiri dari sebuah urutan operasi dari sekumpulan n transaksi T1, T2, … Tn, bergantung pada constraint yang dilindungi oleh urutan operasi untuk setiap transaksi pada schedule tersebut. Jadi, untuk setiap transaksi Ti pada schedule S, urutan operasi pada Ti harus sama dengan schedule S. Serial Schedule adalah sebuah schedule di mana operasi dari setiap transaksi dijalankan secara berurutan tanpa adanya tarnsaksi yang mengganggu transaksi lainnya. NonSerial Schedule adalah sebuah schedule di mana operasi-operasi dari satu set concurrent transactions mengalami interleaved. Pada sebuah serial schedule, transaksi dijalankan pada serial order. Contohnya, jika kita mempunyai dua transaksi T1 dan T2, serial ordernya akan menjadi T1 diikuti oleh T2, atau T2 diikuti oleh T1. Lalu, pada eksekusi serial tidak ada interferensi antara transaksi, karena hanya satu transaksi yang berjalan pada satu waktu. Tujuan serializibility adalah untuk menemukan non serial schedule yang mengijinkan transaksi untuk berjalan secara bersamaan tanpa mengganggu satu sama lain, dan kemudian memproduksi sebuah state database yang dapat diproduksi oleh sebuah eksekusi serial. Jika sebuah set transaksi berjalan secara bersamaan, bisa dikatakan bahwa schedule (nonserial) adalah benar jika memproduksi hasil yang sama seperti beberapa eksekusi serial lainnya. Schedule seperti itu disebut serializable. Untuk mencegah inkonsistensi dari transaksi yang mengganggu satu sama lain, penting untuk menjamin serializability dari transaksi yang jalan bersamaan.
Pada serializability, urutan operasi baca dan tulis itu penting. Berikut ini hal – hal yang perlu diperhatikan:
- Jika dua transaksi hanya membaca satu item data yang sama, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting.
- Jika dua transaksi melakukan operasi membaca ataupun menulis pada item data yang berbeda, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting.
- Jika satu transaksi menulis sebuah item data dan transaksi lain baik membaca ataupun menulis pada item data yang sama, maka urutan eksekusi itu menjadi penting.