MANAGEMEN TRANSAKSI Ferdi Yusuf #1 Fakultas Teknik dan Ilmu Komputer, Jurusan Teknik Informatika, Universitas Komputer Indonesia JL. Dipatiukur No 112-116, Bandung 40132
[email protected]
Abstrak— Transaksi adalah sebuah unit eksekusi dari program yang mengakses dan memungkinkan update berbagai macam tipe data. Penulisan paper ilmiah ini bertujuan untuk mempelajari apa itu managamen transaksi yang ada pada suatu database . dalam paper ilmiah saya akan membahas tentang apa itu transaction,concurrency control, dan recovery system. Kata Kunci—Transaction, Concurrency Control, Recovery System, ACID, Blocking, Shadow Paging I. PENDAHULUAN Dengan perkembangan zaman yang makin pesat ini serta di ikuti dengan perkembangan teknologi yang makin pesat pula. Keperluan akan sebuah informasi adalah suatu hal yang penting. Dengan ada nya sebuah jaringan keperluan informasi setiap orang bisa di penuhi dengan mudah asal kita terhubung dengan sebuah jaringan. Dengaan ada nya jaringan itu pula setiap orang dapat mengakses suatu data dengan mudah. Kemudah pengaksesan data itu sejalan dengan makin banyak nya suatu transaksi yang terjadi . contoh transaksi yang terjadi yaitu seperti transaksi di mesin atm, transaksi pada suatu web site tertentu dan lain lain. Transaksi itu pasti berhubungan dengan data yaitu database. Makin banyak transaksi yang terjadi makin besar peluang terjadi nya kesalahan dalam transaksi tersebut. Keperluan akan suatu sistem database yang baik itu sudah menjadi sesuatu hal yang penting di zaman sekarang. Karena suatu sistem database yang baik itu adalah suatu sistem yang dapat menopang suatu transaksi yang baik. Oleh karena itu menambah pengetahuan tentang managemen transaksi sangat lah perlu untuk menopang para programer dalam membuat suatu sistem yang baik. II. MANAGEMEN TRANSAKSI Dalam managemen transaksi ini kita akan membahas beberapa materi seperti transaction, concurrency control, dan recovery system. A. Transaction Transaksi adalah sebuah unit eksekusi pada suatu program yang mengakses dan memungkinkan update berbagai macam tipe data. Transaksi itu sendiri terjadi di antar begin transaction dan end transaction. Dalam proses transaksi
kekonsistenan database itu sangat lah penting untuk menopang terjadi nya transaksi yang baik Ada beberapa hal yang mungkin terjadi pada saat kita melakukan suatu transaksi yaitu terjadi nya beberapa kegagalan yang mungkin terjadi karena berbagai faktor seperti ke gagalan sistem, kegagalan hardware dan lain lain nya. Dan juga terjadi nya transaksi yang di lakukan ber sama-sama atau biasa di sebut eksekusi konkuren. Agar itegritas data tetap terjaga dalam proses transaksi dan transaksi itu berjalan dengan baik maka di perlukan suatu sistem database yang baik yang dapat menjaga propertiproperti yang terdapat di dalam transaksi tersebut. Properti tersebut di kenal sebagai ACID. Properti ACID itu sebgai berikut : Atomicity : transaksi di lakukan sekali dan sifat nya atomik, artinya merupkan satu kesatuan tunggal yang tidak dapat di pisahkan . maka laksanakan taransaksi sampai selesai atau tidak sama sekali. Consistency : jika data sebelum transaksi konsisten maka selesai transaksi pundata harus tetap konsisten. Isolation : memastika bahwa secara bersamaan eksekusi transaksi terisolasi dari yang lain. Durability : begitu transaksi telah dilaksanakan makaperubahan yang di lakukan tidak akan hilang dan tetap terjaga sekali pun ada kegagalan sistem. B. Concurrency Control Concurrency control adalah sistem manajemen database (DBMS) konsep yang digunakan untuk mengatasi konflik dengan serentak mengakses atau mengubah data yang dapat dilakukan dengan sistem multi-user. Tiga contoh masalah penting yang terkait oleh concurrency, yaitu masalah Lost-Update, masalah Uncommitted Dependency, dan masalah Inconsistent Analysis. 1.
Lost-Update
3.
Inconsistent Analysis
Penjelasan : Transaksi T1 dan T2 mulai pada waktu yang hampir bersamaan, dan keduanya membaca saldo $100. T2 menambah balx $100 menjadi $200 dan menyimpan hasil perubahannya dalam database. Di sisi lain, transaksi T1 mengurangi copy dari balx $10 menjadi $90 dan menyimpan nilai ini dalam database, menimpa hasil update sebelumnya dan akhirnya menghilangkan $100 yang telah ditambahkan sebelumnya ke dalam saldo. Kehilangan update transaksi T2 dapat dihindari dengan mencegah T1 membaca nilai dari balx sampai update T2 telah selesai. 2.
Uncommited Dependency
Penjelasan: Transaksi T4 mengubah balx menjadi $200 namun T4 membatalkan transaksi sehingga balx harus dikembalikan ke nilai asalnya, yaitu $100. Namun, pada waktu itu, transaksi T3 telah membaca nilai baru balx ($200) dan menggunakan nilai ini sebagai dasar pengurangan $10, sehingga memberikan saldo yang keliru sebesar $190, yang seharusnya adalah $90. Nilai balx yang dibaca T3 disebut dirty data, yang berasal dari nama alternatifnya, yaitu masalah dirty read. Alasan rollback ini tidaklah penting. Masalahnya adalah transaksinya gagal (error), mungkin mengurangi rekening yang salah. Efeknya adalah asumsi T3 yang menganggap update T4 telah berhasil dijalankan, meskipun selanjutnya perubahannya dibatalkan. Masalah ini dihindari dengan mencegah T3 membaca balx sampai keputusan telah dibuat, yaitu commit atau membatalkan efek T4. Dua masalah di atas mengkonsentrasikan pada transaksi yang mengubah database dan campur tangan mereka bisa membuat database menjadi corrupt. Namun, transaksi yang hanya membaca database bisa juga memberikan hasil yang tidak akurat jika mereka diijinkan untuk membaca hasil bagian dari transaksi yang belum selesai yang secara bersamaan membaca database. Contohnya dijelaskan pada masalah inconsistent analysis.
Penjelasan: Masalah inconsistent analysis muncul ketika sebuah transaksi membaca beberapa nilai dari database tapi transaksi kedua mengubah beberapa darinya ketika eksekusi transaksi yang pertama. Contohnya, sebuah transaksi yang meringkas data pada sebuah database(contohnya, saldo total) akan mendapat hasil yang tidak akurat jika, ketika berjalan, transaksi lain sedang mengubah database. Pada contoh diatas, ringkasan transaksi T6 sedang berjalan secara bersamaan dengan transaksi T5. Transaksi T6 sedang menjumlahkan saldo rekening x ($100), rekening y ($50), dan rekening z($25). Namun, di tengah jalan, transaksi T5 telah mentransfer $10 dari balx ke balz, sehingga T6 sekarang mempunyai hasil yang salah (lebih besar $10). Serializability dan Recoverability Tujuan protokol concurrency control adalah untuk menjadwalkan transaksi sedemikian rupa sehingga dapat menghindar dari berbagai gangguan, dan juga mencegah tipetipe masalah yang digambarkan pada sesi sebelumnya. Satu solusi yang jelas adalah mengijinkan hanya satu transaksi yang berjalan dalam satu waktu. Satu transaksi berstatus commit sebelum transaksi berikutnya di ijinkan mulai. Namun, tujuan dari DBMS multi user juga untuk memaksimalkan derajat concurrency atau paralelisme dalam sebuah sistem, sehingga transaksi yang dapat berjalan tanpa mengganggu satu sama lain dapat berjalan secara paralel. Contohnya, transaksi yang mengakses bagian berbeda pada database dapat dijadwalkan bersama tanpa gangguan. Dalam bagian ini, kita memeriksa serializability sebagai sebuah cara untuk membantu mengidentifikasi eksekusi transaksi tersebut yang dijamin untuk memastikan konsistensi. Pertama, kita beri beberapa definisi. Schedule Schedule adalah sebuah urutan dari operasi-operasi oleh satu set transaksi yang jalan bersamaan yang menjaga urutan operasi pada setiap transaksi individual ( Connolly, 2005, p580 ). 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 transaksi yang mengganggu transaksi lainnya (Connolly, 2005, p580). NonSerial Schedule adalah sebuah schedule di mana operasi-operasi dari satu set concurrent transactions mengalami interleaved (Connolly, 2005, p580). 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.
Anggap schedule S1 yang ditunjukkan oleh gambar (a) di bawah mengandung operasi dari dua transaksi yang sedang berjalan secara bersamaan, yaitu T7 dan T8. Karena operasi tulis pada balx di T8 tidak konflik dengan operasi baca berikutnya pada baly di T7, kita dapat mengubah urutan operasinya untuk memproduksi schedule yang ekuivalen (S2) ditunjukkan oleh gambar (b). Jika kita sekarang juga mengubah urutan dari operasi yang tidak konflik berikut, kita memproduksi serial schedule yang ekuivalen (S3) ditunjukkan oleh gambar (c) di bawah.
Ubah urutan write(balx) di T8 dengan write(baly) di T7 Ubah urutan read(balx) di T8 dengan read(baly) di T7 Ubah urutan read(balx) di T8 dengan write(baly) di T7
Keterangan Gambar : (a) nonserial schedule S1 (b) nonserial schedule S2 (c) serial schedule S3, ekuivalen dengan S1 dan S2 Schedule S3 adalah sebuah schedule serial dan karena S1 dan S2 ekuivalen dengan S3, maka S1 dan S2 adalah serializable schedule. Recoverable schedule adalah sebuah schedule di mana, untuk setiap transaksi Ti dan Tj, jika Tj membaca sebuah item data yang sebelumnya ditulis oleh Ti, kemudian operasi commit dari Ti mendahului operasi commit Tj. Teknik Concurrency Control Ada dua teknik concurrency control utama yang mengijinkan transaksi untuk berjalan dengan aman dalam subjek paralel untuk constraint tertentu, yaitu locking dan metode timestamp tertentu. Locking dan timestamping adalah pendekatan konservatif karena mereka menyebabkan transaksi ditunda dalam kasus mereka konflik dengan transaksi lain pada beberapa waktu di masa yang akan datang. Metode optimistik, didasarkan pada premis bahwa konflik itu jarang ditemui, jadi mereka mengijinkan transaksi untuk lanjut tidak tersinkronisasi dan hanya mengecek konflik di bagian akhir, ketika transaksi melakukan operasi commit. Metode Locking Locking adalah sebuah prosedur yang digunakan untuk mengendalikan akses bersamaan ke data. Ketika sebuah transaksi sedang mengakses database, sebuah lock mungkin menolak akses ke transaksi lain untuk mencegah hasil yang salah ( Connolly, 2005, p587 ). Ada dua macam lock, yaitu shared lock dan exclusive lock yang harus digunakan sebelum melakukan akses membaca ataupun menulis terhadap database. Penggunaan lock ini adalah untuk menjaga konsistensi data didalam database. Jika sebuah transaksi mempunyai sebuah shared lock pada sebuah item data, transaksi tersebut dapat membaca item tapi tidak dapat mengubah datanya ( Connolly,
2005, p588 ). Jika sebuah transaksi mempunyai sebuah exclusive lock pada sebuah item data, transaksi tersebut dapat membaca dan mengubah item data ( Connolly, 2005, p588 ). Lock digunakan dengan cara sebagai berikut:
Transaksi apapun yang membutuhkan akses pada sebuah item data harus melakukan lock terhadap item tersebut, meminta shared lock untuk akses membaca saja atau sebuah exclusive lock untuk akses membaca dan menulis. Jika item belum dikunci oleh transaksi lain, lock tersebut akan dikabulkan Jika item sedang dikunci, DBMS menentukan apakah permintaan ini compatible dengan lock saat ini. Jika diminta shared lock pada sebuah item yang sudah mempunyai shared lock terpasang padanya, permintaan itu akan dikabulkan. Selain itu, transaksi harus menunggu sampai lock yang ada terlepas. Sebuah transaksi lanjut memegang lock sampai transaksi tersebut melepasnya baik pada waktu eksekusi ataupun pada waktu transaksi tersebut berakhir (abort atau commit). Efek operasi tulis akan terlihat pada transaksi lain hanya pada waktu exclusive lock telah dilepas.
Two Phase Locking adalah sebuah transaksi yang mengikuti protokol two-phase locking jika semua operasi locking mendahului operasi unlock pertama pada transaksi ( Connolly, 2005, p589 ). Aturan-aturannya adalah sebagai berikut :
algoritma telah ditemukan oleh Rosenkrantz. Algoritma pertama, Wait-Die, mengijinkan hanya transaksi yang lebih tua untuk menunggu yang lebih muda, jika tidak transaksi dibatalkan (die/mati) dan restart dengan timestamp yang sama, sehingga lama kelamaan transaksi tersebut akan menjadi transaksi aktif tertua dan tidak akan mati. Algoritma kedua, Wound-Wait, menggunakan pendekatan simetrikal. Hanya transaksi yang lebih muda yang dapat menunggu untuk yang lebih tua. Jika transaksi yang lebih tua meminta lock yang dipegang oleh transaksi yang lebih muda, transaksi yang lebih muda digagalkan. 3. Deadlock Detection Deadlock detection biasanya ditangani oleh konstruksi wait-for graph (WFG) yang menunjukkan ketergantungan transaksi, yaitu transaksi Ti tergantung pada Tj jika transaksi Tj memegang lock pada sebuah item data yang ditunggu oleh Ti. WFG adalah sebuah directed graph G = (N, E ) yang terdiri dari satu set node N dan satu set directed edge E, yang dikonstruksi sebagai berikut
Buat sebuah node untuk setiap transaksi. Buat sebuah directed edge Ti → Tj , jika transaksi Ti menunggu untuk melakukan lock sebuah item yang sedang di-lock oleh Tj.
Sebuah transaksi harus mendapatkan sebuah lock pada item sebelum beroperasi pada item tersebut. Lock tersebut bisa berupa baca atau tulis, tergantung dari tipe akses yang dibutuhkan Sebelum transaksi melepaskan sebuah lock, transaksi tersebut tidak akan pernah mendapatkan lock baru lainnya.
Deadlock Deadlock adalah jalan buntu yang dapat terjadi ketika dua atau lebih transaksi masing-masing menunggu lock yang sedang dipegang oleh transaksi lainnya untuk dilepas. Hanya ada satu cara untuk menghancurkan deadlock, yaitu abort satu atau lebih transaksi. Ada tiga cara untuk menangani deadlock, yaitu timeout, deadlock prevention dan deadlock detection and recovery. 1. Timeout Pendekatan sederhana pada pencegahan deadlock adalah berdasarkan lock timeout. Dengan pendekatan ini, sebuah transaksi yang meminta sebuah lock akan menunggu hanya sampai periode waktu tertentu yang didefinisikan sistem. 2. Deadlock Prevention Pendekatan lain untuk mencegah deadlock adalah untuk memesan transaksi menggunakan timestamp transaksi. Dua
Deadlock terjadi jika dan hanya jika WFG mengandung sebuah cycle. Gambar di atas menunjukkan WFG yang menunjukkan deadlock antara dua transaksi.
C. Recovery system Backup : proses secara periodik untuk mebuat duplikat dari database dan melakukan logging file (atau program) ke media penyimpanan eksternal. 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 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. Pendekatan update – in – place Pendekatan ini melibatkan pembaharuan sistem sebagaimana transaksi berjalan dan meniadakan pembaruanpembaruan 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. 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 hilang 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. • Ttulis semua blok buffer yang telah dimodifikasi ke disk. • Tulis record log ke penyimpan stabil. III. KESIMPULAN Dari penjawabaran materi tentang managemen transaksi di atas saya dapat menyimpulkan begitu banyak masalah yang mungkin terjadi pada suatu transaksi yang terjadi, baik itu karena kesalah hardware , kesalahan sistem atau yang lain nya
yang tidak terduga. Tapi dengan kita mempelajari managemen transaksi kita dapat menambah pengetahuan tentang apa saja yang mungkin terjadi padasaat transaksi , dengan ilmu yang kita dapat dari pembelajar tentang managemen transaksi kita sudah mulai bisa atau mulai memikirkan membuat suatu system database yang baik agar masalah masalah yang ada dapat di minimalisir atau bahkan di hilangkan dalam sebuah transaksi. Tetapi untuk membuat suatu sistem yang sangat sempurna itu sesuatu yang mustahil menurut saya karena perkembangan zaman akan ikut mengembangkan masalah masalah dalam transaksi jadi tetap belajar dan terus mengembangkan sistem database yang baik sesuai perkebangan zaman dan perkembangan akan permintaan pasar REFERENSI [1] Coronel, Carlos, Peter Rob. Database Systems, keenam ed. Thomson Course Technology, 2004. Thomson Course Technology, 2004. [2] Connolly,Thomas M,Carolyn E.Begg .(2005). Database Systems : A Practical Approach to Design, Implementation, and Management, fourth Edition. Addison Wesley Publishing Company Inc., USA.
