TRANSACTION RECOVERY

Transaksi adalah urutan dari operasi database ketika mengakses ke database. Transaksi direpresentasikan pada kejadian nyata. Transaksi harus merupakan unit logim dari suatu pekerjaan.Tak ada bagian dari transaksi yang dapat melakukan hal tersebut sendiri. Baik semua bagian berhasil dieksekusi ataupun transaksi tersebut dibatalkan. Transaksi mengambil database dari satu konsisten status ke status yang lain. Konsisten status database adalah ketika semua integrity constraint dari data telah terpenuhi.

Transaksi memiliki 4 bagian utama :

1. Atomisitas (semua bagian dari transaksi dapat dieksekusi meskipun transaksi dibatalkan)

2. Konsistensi (Kekonsistensian database dapat terjaga)

3. Isolasi (data yang diguanakan oleh satu transaksi tidak dapat diakses oleh transaksi lainnya transaksi pertama tersebut selesai)

4. Daya tahan (Perubahan yang dibuat oleh transaksi tidak dapat roll back ketika telah mengalami commit )

5. Sebagai tambahan, jadwal transaksi memerlukan cirri seriabilitas (hasil dari konkurensi suatu transaksi sama ketika transaksi tersebut dieksekusi pada serial order)

Sebelum dilanjutkan, mari kita membahas empat konsep penting yang mempengaruhi proses recovery :

1. Write-ahead-log protocol memastikan bahwa log transaksi slalu ditulis sebelum data dalam database ter-update. Dalam kasus kegagalan, database dapat terlambat untuk direcovery pada status yang konsisten. Gunakan data yang ada di transaction log.

2. Redudant transaction logs (bebertapa duplikat dari transaction log) memastikan bahwa kegagalan physical disk tidak akan merusak kemampuan DBMS untuk melakukan recovery data.

3. Database Buffer adalah area penyimpanan sementara dalam memory utama yang digunakan untuk mempercepat kerja disk. Untuk meningkatkan waktu proses, software DBMS ,membaca data dari physical disk dan menyimpan duplikat dari data ke buffer di memory utama. Ketika transaksi mengupdate data, hal inisecara otomatis juga mengupdate kopian dari data yang ada dalam buffer karena proses tersebut cukup lebih cepat daripada pengaksesan physical disk dalam setiap waktu. Kemudian, semua buffer yang mengandung update data yang dituis pada physical disk selama operasi tunggal, demikianlah proses penyiimpanan secara signifik.

4. Database checkpoints adalah operasi dimana DBMS menuliskan semua pembaruan pada buffer ke disk. Selama hal ini terjadi, DBMS tidak mengeksekusi permintaan lainnya.Operasi checkpoints juga terdaftar dalam transaction log. Hasil dari operasi ini adalah physical database dan transaction log akan menjadi sinkron. Sinkronisasi ini dibutuhkan karena peng-update-an operasi akan meng-update kopian dari dat6a dalam buffer dan bukan pada physical database. Checkpoints secara otomatis dijadwalkan oleh DBMS beberapa waktu tiap jam.

Proses recovery database melibatkan pembawaan database ke status konsisten setelah mengalami kegagalan. Prosedur transaction recovery umumnya digunakan untuk deffered-write dan write-through technique.

Ketika prosedur recovery menggunakan deffered-write technique (differed update), operasi transaksi tidak secara tiba-tiba mengupdate physical database. Malah hanya transaction log yang di-update. Database secara fisik mengalami pembaruan hanya setelah transaksi mengalami commit, menggunakan informasi dari transaction log. Jika transaksi gagal sebelum mengalami commit, tidak ada perubahan (roolback atau undo) yang perlu dilakukan pada database karena database tidak pernah ter-update. Proses recovery untuk pemulaian dan transaksi commit (sebelum gagal) :

1. Mengidentifikasi checkpoint trakhir yang ada dalam transaction log. Ini adalah waktu terakhir dari transaksdi data secara fisik ayng disimpan dalam disk.

2. Untuk transaksi yang dimulai dan telah dicommit sebelum checkpoint terakhir, tidak membutuhkan operasi apapun kaena dta telah tersimpan.

3. Untuk transaksi yang melakukan operasi commit setelah checkpoint terakhir, DBMS menggunakan transaction log record untuk melakukan operasi redo dan update database, menggunakan nilai ‘after’ dalam transaction log . Perubahan dibuat dalam bentuk ascending, dari yang terlama ke yang terbaru.

4. Untuk operasi-operasi yang menggunakan operasi ROLLBACK setelah checkpoint terakhir atau tidak melakukan operasi (COMMIT ataupun ROLLBACK) sebelum kegagalan terjadi. Tidak ada hal yang eprlu dilakuakn karena database tidak mengalami peng-update-an.

Ketika prosedur recovery menggunakan write-through technique (immediate update), database langsung mengalami peng-update-an oleh operasi transaksi selama eksekusi, bahkan sebelum transaksi memperoleh perintah commit.Jika transaksi gagal sebelum commit, ROOLBACK atau operasi undo perlu dilakukan untuk mengembalikan database ke status konsisten. Pada kasus ini, operasi ROOLBACK akan sigunakan oleh nilai ‘after’ transaction log. Adapun langkah dari recovery:

1. Mengidentifikasi checkpoint terakhir di dalam transaction log. Dalam hal ini waktu terakhir transaksi data dimana secara fisik data disimpan.

2. Untuk transaksi yang dimulai dan mengalami commit sebelum checkpoint terakhir, tidak perlu melkaukan operasi apaun karena data telah tersimpan.

3. Untuk transaksi yang telah mnengalami commit setelah checkpoint terakhir, DBMS me-redo transaksi,menggunakan nilai ‘after’ dari transaction log. Perubahann akan ditampilkan secara ascending, dari terlama ke yang terbaru.

4. Untuk transaksi lain yang telah mengalami operasi ROLLBACK setelah chechpoint terakhir atau tidak melakukan operasi apapun (ROLLBACK atau COMMIT) sebelum kegagalan terjadi, DBMS menggunakan transcation log record untuk melakukan ROLLBACKa atu operasi undo, Menggunakan nilai ‘before’ pada transaction log. Perubahan ditampilkan dalam bentuk simpanan, dari yang terbaru ke yang terlama.