Resume Transaksi dalam Sistem Basis Data

TRANSAKSI 

Transaksi adalah satu atau beberapa aksi program aplikasi yang mengakses/mengubah isi basis data.

Transaksi adalah bagian dari pengeksekusian sebuah program yang melakukan pengaksesan basis data dan bahkan juga melakukan serangkaian perubahan data.  DBMS yang kita gunakan harus menjamin bahwa setiap transaksi harus dapat dikerjakan secara utuh atau tidak sama sekali.  Tidak boleh ada transaksi yang hanya dikerjakan sebagian, karena dapat menyebabkan inkonsistensi basis data.  Untuk itu transaksi selalu merubah basis data dari satu kondisi konsisten ke kondisi konsisten lain.

Untuk menjamin integritas data, kita membutuhkan perawatan (maintain) system database dengan cara mengikuti sifat transaksinya itu sendiri, yaitu:

·         Atomicity (Atomik). Semua operasi transaksi harus dilaksanakan secara tepat dalam database atau tidak sama sekali.

·         Consistency (Konsistensi).  Pengksekusian sebuah transaksi dalam isolasi (yaitu, ketika tidak adanya pengeksekusian transaksi lain saat bersamaan) menjaga konsistensi database.

·         Isolation (Isolasi), jika pada sebuah system basis data terdapat sejumlah transaksi yang dilaksanakan secara bersamaan, maka semua transaksi yang dilaksanakan pada saat yang bersamaan tersebut harus dapat dimulai dan bisa berakhir.

·         Durability (Daya Tahan).  Setelah transaksi lengkap berhasil, perubahan-perubahan telah dibuat untuk kelangsungan database, meskipun nantinya terdapat kesalahan system.

Sifat-sifat ini sering disingkat dan disebut dengan sifat ACID.

Untuk dapat memahami lebih baik sifat ACID dan yang dibutuhkannya, maka ingatlah sebuah system perbankan sederhana yang memiliki beberapa rekening dan kumpulan transaksi yang mengakses dan mengupdapte rekening-rekening tersebut.

Untuk waktu yang sedang terjadi, kita asumsikan bahwa database disimpan secara permanen di disk, tetapi beberapa bagian secara sementara terdapat di main memory.

Transaksi untuk mengakses data menggunakan dua operasi, yaitu:

1.      read(X), mentransfer data item X dari database ke buffer local milik  transaksi yang mengeksekusi operasi read.

2.      write(X), mentransfer data item X dari buffer local transaksi yang mengeksekusi operasi write ke database

Dalam system database sesungguhnya, operasi write tidak perlu menghasilkan update data dengan segera pada disk;  operasi write bisa jadi secara sementara disimpan dalam memori dan nantinya dieksekusi di disk.  Tetapi  untuk sekarang, kita boleh menganggap bahwa operasi write mengupdate dengan segera (langsung).

Misalnya Ti merupakan transaksi untuk mentransfer $50 dari rekening A ke rekening B.  Transaksi ini dapat didefinisikan menjadi:

Ti: read(A);

A := A-50;

Write(A);

Read(B);

B := B + 50;

Write(B);

(…begitu juga dengan gambaran akumulasi untuk B)

Sekarang kita pertimbangkan setiap kebutuhan ACID untuk transaksi di atas.

·         Consistency:

Consistency dibutuhkan di sini karena jumlah A dan B dirubah oleh peneksekusian transaksi. Tanpa consistency, uang dapat diciptakan atau dihilangkan oleh transaksi.  Hal ini dapat dibuktikan dengan mudah, jika database consistent sebelum pengeksekusian transaksi, database menyisakan consistent setelah pengeksekusian transaksi.

·         Atomicity:

Misalnya sebelum pengeksekusian transaksi Ti, nilai rekening A dan B adalah berturut-turut $1000 dan $2000.  Anggap bahwa selama pengeksekusian transaksi Ti, kegagalan terjadi mencegah Ti dari pengeksekusian yang lengkap.  Contoh kegagalan-kegagalan tersebut meliputi power failure, hardware failure, software failure.  Selanjutnya, misalnya kegagalan terjadi setelah operasi write(A) tetapi sebelum operasi write(B).  Pada contoh ini, nilai rekening A dan B digambarkan dalam database adalah $950 dan $2000.  Kegagalan ini mengakibatkan system menghilangkan $50.  Istimewanya, kita catat bahwa jumlah A + B tidak lama dipertahankan. Jadi, karena kegagalan ini, keadaan system tidak lagi mencerminkan keadaan database yang sebenarnya.  Kita nyatakan sebagai keadaan inconsistent.

Kita harus menjamin bahwa semua inconsitensi tidak nampak dalam system database.  Catatan, bagaimanapun, system tersebut harus dalam keadaan insonsisten.  Meskipun jika transaksi Ti dieksekusi lengkap, tetap ada nilai untuk rekening A $950 dan B $2000, yang menjelaskan keadaan inskonsisten.  Keadaan ini, bagaimanapun akhirnya digantikan oleh keadaan konsisten dimana rekening A adalah $950 dan B $2050.  Jadi,jika transaksi tidak pernah dimulai atau dijamin sampai lengkap, keadaan yang inkonsisten tidak akan terlihat kecuali selama pengeksekusian transaksi .

Itulah alasan dari dibutuhkannya sifat atomicity: jika sifat atomicity itu ada, maka seluruh aksi transaksi digambarkan dalam database atau tidak satupun.  Ide dasar disamping menjamin atomicity adalah: System database (pada disk) terus mengikuti  nilai lama terhadap setiap data yang melakukan sebuah transaksi write, dan jika transaksi tidak sempurna, system database mengembalikan nilai lama untuk membuat seolah-olah transaksi tidak pernah dieksekusi.

·         Durability:

Sekali pengeksekusian transaksi lengkap berhasil, dan user yang menjalankan transaksi telah diberitahukan bahwa transaksi dana telah berlangsung, maka harus menjadi masalah kalau seandainya tidak ada  kegagalan system tetapi terjadi kehilangan data yang berkaitan dengan transaksi dana tersebut.

Sifat durability menjamin bahwa, sekali transaksi lengkap berhasil, maka seluruh peng-update-an pada database berlangsung, walaupun nantinya terdapat kegagalan pada system setelah pengeksekusian transaksi lengkap.  Kita asumsikan sekarang bahwa kegagalan system komputer bisa menghasilkan hilangnya data di memory, tetapi data yang tersimpan di disk tidak pernah hilang. 

·         Isolation:

Sekalipun consistency dan atomicity dipastikan untuk setiap transaksi, jika beberapa transaksi dieksekusi secara bersamaan, maka operasi-operasinya mungkin menyisip di beberapa tempat yang tidak diharapkan sehingga menghasilkan keadaan inkonsisten.

Contohnya, seperti yang telah kita ketahui di awal, database inkonsisten untuk sementara waktu saat transaksi transfer dana dari A ke B dieksekusi, dengan mengurangi total yang tertulis untuk A dan menambahkan total kemudian untuk B.  Jika transaksi kedua yang berjalan bersamaan membaca A dan B pada point selanjutnya dan menghitung A + B, maka hal ini akan menimbulkan nilai inkonsisten.  Selanjutnya, jika transaksi kedua kemudian membentuk peng-update-an pada A dan B berdasarkan nilai yang terbaca, maka database mungkin keliru dalam keadaan inkonsisten sejak saat kedua transaksi telah lengkap.

Cara untuk menghindari masalah pengeksekusian transaksi secara bersamaan adalah mengeksekusi transaksi secara serial, yaitu satu demi satu.  Tetapi, pengeksekusian transaksi yang bersamaan memberikan keuntungan unjuk kerja yang berarti.  Solusi lain telah dikembangkan, dengan memperbolehkan multi transaksi dieksekusi secara bersamaan.

Sifat Isolation transaksi menjamin bahwa pengeksekusian transaksi secara bersamaan menghasilkan keadaan system yang sama dengan keadaan yang diperoleh transaksi tersebut saat mengeksekusi banyak perintah dalam satu waktu.  Menjamin sifat isolation merupakan tanggung jawab komponen system database yang disebut dengan komponen pengontrol concurrency (concurrency-control component).

2.  Keadaan Transaksi

Telah disinggung sebelumnya bahwa transaksi tidak selalu lengkap berhasil dieksekusi (digagalkan).  Jika kita menjamin sifat atomicity, transaksi yang digagalkan harus tidak mempunyai efek pada keadaan database.  Jadi, setiap perubahan yang dibuat oleh penggagalan transaksi harus tidak diselesaikan.  Sekali perubahan disebabkan oleh penggagalan transaksi tidak diselesaikan, maka kita katakan transaksi tersebut telah rolled back. Ini merupakan bagian yang ditangani oleh pola (rencana) recovery untuk mengatur transaksi gagal.

Transaksi yang sempurna disebut dengan commited.  Transaksi commited yang melakukan update merubah database ke dalam keadaan konsisten yang baru, yang harus tetap begitu jika terdapat sebuah system yang gagal.

Sekali transaksi telah commited, kita tidak dapat meng-undo-nya dengan cara mengagalkan.  Satu-satunya cara untuk meng-undo transaksi yang commited adalah mengeksekusi transaksi compensating.  Misalnya, jika sebuah transaksi menambahkan  $20 ke sebuah rekening, maka transaksi compensating akan mengurangkan $20 dari rekening tersebut.  Namun, hal ini tidak selalu bisa diciptakan.  Karena, tanggung jawab penulisan dan pengeksekusian transaksi diserahkan kepada user bukan ditangani system database.

Kita perlu lebih teliti mengenai apa yang kita maksud dengan successful completion dari transaksi.  Oleh karena itu kita buat model transaksi abstract sederhana.  Sebuah transaksi harus ada dalam salah satu keadaan berikut:

·         Active, keadaan awal; transaksi berada dalam keadaan ini saat dieksekusi.

·         Partially committed, setelah statemen akhir dieksekusi

·         Failed, setelah diketahui bahwa eksekusi normal tidak dapat lebih lama diproses.

·         Aborted, setelah transaksi dikembalikan dan database dipulihkan ke keadaan sebelumnya pada awal transaksi.

·         Commited, setelah lengkap sukses.

Diagram keadaan yang berhubungan dengan keberadaan transaksi:

Transaksi dimulai dalam keadaan active.  Saat selesai dengan statemen terakhirnya, transaksi memasuki keadaan partially committed.  Pada point ini, transaksi telah melengkapi transaksi pengeksekusian, tetapi masih memungkinkan untuk digagalkan, karena hasil sebenarnya masih ada di main memory, dan begitu  terjadi gagal hardware (hardware failure) bisa menghindari transaksi yang benar-benar sukses.

System database kemudian cukup menulis informasi ke disk, jika terjadi kegagalan update yang dibentuk oleh transaksi dapat dibuat kembali saat system restart setelah gagal.  Saat informasi terakhir ditulis, transaksi memasuki keadaan committed.

Transaksi memasuki keadaan failed setelah system memutuskan bahwa transaksi tidak dapat diproses lebih lama lagi dengan eksekusi normal (contoh, karena error hardware atau logic).  Seperti transaksi harus dikembalikan.  Kemudian, memasuki keadaan aborted.  Pada saat ini, system mempunyai dua pilihan:

·         Dapat me-restart transaksi, tetapi hanya jika transaksi digagalkan karena hardware atau software error sehingga tidak dibuat melewati transaksi logika internal.  Sebuah transaksi yang di-restart ulang dianggap membuat transaksi baru.

·         Dapat mematikan transaksi.  Ini biasanya dilakukan karena beberapa logika internal error sehingga dapat dikoreksi hanya dengan menuliskan kembali program aplikasi, atau karena input jelek, atau karena data yang diharapkan tidak ditemukan di dalam database.

Note:

Jenis Kegagalan:

1.      Logical Error, disebabkan kesalahan input, data yang tidak ditemukan, overflow, batas maksimum sumber terlampaui.

2.      System Errot, system memasuki keadaan yang tidak diharapkan misalnya deadlock.

3.      System Crash, kegagalan pada hardware (mis. CPU) yang menyebabkan hilangnya informasi pada volatile storage (MM).

4.      Disk failure, hilangnya informasi dalam suatu blok karena head crash atau kegagalan pada saat transfer data.

Kita harus hati-hati saat berurusan dengan penulisan eksternal yang tampak (observable external writes), seperti menulis ke terminal atau printer.  Sekali penulisan terjadi, penulisan tidak dapat dihapus, karena penulisan dianggap external oleh database.  Kebanyakan system membolehkan penulisan seperti itu berlangsung hanya setelah transaksi telah memasuki keadaan committed.  Jika system gagal setelah transaksi masuk ke keadaan committed, tetapi sebelum transaksi bisa melengkapi penulisan eksternal, system database akan menghasilkan penulisan eksternal (menggunakan data di penyimpanan nonvolatile) saat system direstart.

Menangani penulisan eksternal dapat lebih sulit dalam beberapa situasi.  Contohnya aksi eksternal mengeluarkan uang di atm dan system gagal sebelum uang dikeluarkan (kita asumsikan uang dapat dikeluarkan secara otomatis).  Hal ini membuat tidak masuk akal untuk mengeluarkan uang saat system restart, karena user barangkali telah meninggalkan mesin.  Dalam kasus demikian transaksi konpensasi (ganti rugi), seperti menyimpan kembali ke rekening user, perlu untuk dieksekusi saat system direstart.

Untuk aplikasi yang pasti, diharapkan memperbolehkan transaksi aktif untuk menamplikan data user, terutama untuk transaksi dengan durasi lama yang berjalankan sampai beberapa menit atau jam.  Sayangnya, kita tidak dapat memberikan output dari data yang tampak kecuali kita mau berkompromi dengan atomicity transaksi.  Kebanyakan system transaksi sekarang menjamin atomicity dan oleh karena itu form ini dilarang berinteraksi dengan user.

Pada DBMS dikenal 4 level isolasi, diantaranya sebagai berikut :

·         READ UNCOMMITED
Pada level ini perintah SELECT yang dilaksanakan tanpa melalui mekanisme penguncian atau locking. Dengan demikian level isolasi ini memungkinkan pembacaan pada data yang belum di commit, artinya adalah data yang sedang dilakukan UPDATE oleh suatu transaksi dan belum mencapai proses COMMIT, data tersebut dapat dibaca oleh transaksi yang lainya.

·         READ COMMITED
Pada level ini membuat suatu record yang sudah di COMMIT bisa segera di baca oleh transaksi yang lainya, maka dari itu setiap perintah SELECT yang sama akan menghasilan data yang berbeda.

·         REPEATABLE READ
Suatu transaksi yang belum mencapai COMMIT tidak bisa membaca perubahan apapun yang dilakukan oleh transaksi lainya, dengan cara ini pembacaan data dengan menggunakan SELECT yang sama akan menapilkan hasil yang sama. dengan kata lain suatu perubahan akan terjadi ketika salah satu transaksi melakukan COMMIT.

·         SERIALIZABLE
Level ini merupakan level transaksi yang paling tinggi, pada level ini database akan mengunci tiap-tiap baris yang dibaca, maka transaksi lainya tidak boleh memodifikasi data itu sampai transaksi telah selesai atau COMMIT.

Di database MySQL untuk memberi level transaksi bisa dilakukan dengan cara berikut,

1 2	SET TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED |REPEATABLE READ | SERIALIZABLE}

Pada satu proses transaksi kita mengenal beberapa bagian yang dibutuhkan untuk melakukan sebuah proses transaki yaitu :

START TRANSACTION
Marupakan awal dari blok perintah untuk melakukan transakasi

COMMIT
Melakukan perubahan secara permanent pada tabel di suatu proses transaksi.

ROLLBACK
Perintah ini jika dijalankan maka suatu perubahan secara keseluruhan dalam blok transakasi dibatalkan.

SAVEPOINT savepoint_name
Menciptakan suatu savepoint yang nantinya jika salah satu bagian transaksi dibatalkan maka bisa kembali ke titik SAVEPOINT.

ROLLBACK TO SAVEPOINT savepoint_name
Melaksanakan suatu rollback semua statemen yang telah dieksekusi dan bisa dikembalikan ke titik dimana savepoint tersebut telah diciptakan. Dengan cara ini, anda dapat mengulang mundur hanya bagian dari suatu transaksi.