Transaksi Konsep Transaksi Status transaksi Penerapan Atomisitas dand Durabilitas Eksekusi konkuren Serializability Recoverability Penerapan Isolasi Definisi transaksi dalam SQL

Konsep Transaksi Sebuah transaksi adalah sebuah unit dari eksekusi program yang mampu mengakses dan mengupdate berbagai data. Sebuah transaksi akan berhadapan dengan konsistensi database. Selama eksekusi transaksi database mungkin dalam kondisi inkonsisten. Setelah transaksi selesai, database harus kembali konsisten. Dua hal pokok yang mungkin terjadi: Kerusakan dari beberapa hal seperti kerusakan hardware dan kerusakan sistem Eksekusi konkurensi dari transaksi berganda

Untuk menjamin integritas data, sistem database harus bersifat : Properti AKID Untuk menjamin integritas data, sistem database harus bersifat : Atomik. Dimana semua operasi-operasi dalam transaksi dapat bekerja secara utuh atau tidak sama sekali. Konsisten. Eksekusi transaksi dapat menjamin konsistensi database. Isolasi. Pada sejumlah transaksi yang terjadi secara bersamaan, setiap transaksi tidak boleh terpengaruh dengan transaksi yang lain. Hasil transaksi sementara harus terlindung dari eksekusi transaksi yang lain. Maksudnya, untuk setiap pasangan transaksi Ti dan Tj, menunjukkan kepada Ti bahwa transaksi lain Tj, menyelesaikan eksekusi sebelum Ti mulai, atau Tj mulai eksekusi setelah Ti selesai. Durabel (bertahan/permanen). Setelah sebuah transaksi berakhir dengan sukses, perubahan yang terjadi pada sebuah database harus tetap bertahan, meskipun terjadi kerusakan sistem.

Contoh pada transfer uang Transaksi pengiriman 50 dari rekening A ke rekening B: 1. read(A) 2. A := A – 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B) Konsistensi yang dibutuhkan – jumlah A dan B tidak terubah oleh eksekusi transaksi. Keatomikan yang diperlukan — jika transaksi terhenti setelah tahap ke 3 sebelum tahap ke 6, sistem harus menjamin bahwa perubahan pada database tidak terjadi samasekali, sebab jika tidak maka ketidak konsistenan akan terjadi.

Kebutuhan akan daya tahan — seorang user dapat menyelesaikan sebuah transaksi secara lengkap (mis., transfer 50 telah diterima), perubahan nilai pada database harus tetap bertahan, bahkan jika kemudian terjadi crash. Kebutuhan akan keterisolasian — jika diantara langkah ke 3 dan 6, ada transaksi lain mengakses database yang akan diubah, maka akan terjadi ketidak konsistenan data (jumlah A + B akan lebih sedikit dari yang seharusnya). Dapat dijamin bila transaksi akan terjadi secara serial, dimana yang satu berjalan setelah yang lainnya. Bagaimanapun juga eksekusi transaksi secara bersamaan tetap lebih menguntungkan.

Status Transaksi Aktif, adalah status awal; sebuah transksi akan ada dalam status ini selama eksekusi berlangsung Selesai sebagian, keadaan yang dicapai transaksi tepat setelah instruksi terakhir dalam transksi selesai dikerjakan. Gagal, kedaan dimana eksekusi belum dapat dikerjakan secara utuh (terhenti). Batal, setelah transaksi batal terjadi dan database dikembalikan nilai-nilainya seperti sebelum transaksi. Dua pilihan setelah pembatalan: Memulai kembali transaksi – hanya jika tidak ada kesalahan lojik Hentikan transaksi Berhasil (Committed), keadaan setelah transaksi berjalan lengkap.

Status Transaksi

Penerapan Atomik dan Durabel Pengelolaan pemulihan sistem database diterapkan untuk mendukung sifat atomik dan ketetapan. Skema database – bayangan : Asumsikan bahwa hanya satu transaksi yang aktif pada satu waktu. Sebuah db_pointer selalu menunjukkan konsistensi saat ini dari salinan database. Semua update dilakukan pada sebuah salinan database, dan db_pointer adalah yang membuat pengubahan spada salinan hanya setelah transaksi berhasil sebagian dan seluruh halaman yang di update akan ditulis dalam disk. Dalam kasus terjadinya kegagalan transaksi, kopian data lama yang ditunjuk db_pointer dapat digunakan, dan kopian database dihapus .

Skema database bayangan: Asumsikan bahwa penulisan tidak gagal Sangat bermanfaat untuk pengolah teks, tetapi tidak efisien untuk database yang besar: eksekusi sebuah transaksi tunggal membutuhkan copian database saat ini

Eksekusi Konkuren Banyak transaksi dapat dijalankan secara bersamaan dalam sebuah sistem. Keuntungannya: Meningkatkan kinerja prosesor dan disk penyimpanan, untk melakukan transaksi yang lebih baik: sau transaksi dapat menggunakan CPU sementara yang lain membaca atau menulis dalam penyimpan Mengurangi rata-rata waktu tunggu transaksi: transaksi yang singkat tidak perlu menunggu transaksi lain yang lebih panjang. Skema pengendalian konkurensi – mekanisme untuk mendapatkan isolasi, mis., untuk mengendalikan interaksi antara transaksi konkuren dalam hubungannya menjaga konsistensi database

Tiga masalah konkurensi Lost update Transaksi A retrieve nilai t saat w1. Transaksi B retrieve nilai t saat w2. Transaksi B mengubah nilai satu atau record tanpa melihat efek transaksi A. Transaksi B overwrite nilai-nilai hasil transaksi A sehingga adalah mungkin transaksi A tidak melihat efek perubahan yang dilakukan A Transaksi A Waktu Transaksi B Select * from t; w1 w2 *update t set id=1 Where id = 2; w3 w4 Update t set id = 3 where id = 2; Transaksi A kehilangan perubahan saat w4

Uncommitted dependency Transaksi A waktu Transaksi B w1 Masalah muncul jika transaksi diijinkan retrieve record-record yang telah diubah nilainya oleh transaksi lain yang belum save. Karena belum save selalu ada kemungkinan perubahan tersebut akan di-undo (redo) Transaksi A waktu Transaksi B w1 Update t set dept_id=1; Select * from t; w2 w3 rollback; Transaksi A dependent ke uncommitted change saat w2 Transaksi A waktu Transaksi B w1 Update t set dept_id=1; Update t set dept_id=11; w2 w3 rollback; A mengubah uncommitted change saat w2, kehilangan saat w3,

Penjadwalan Penjadwalan – urutan yang menunjukkan kronologi transaksi yang mana dalam transaksi konkuren di eksekusi Sebuah jadwal untuk sekelompok transaksi harus patuh pada semua instruksi dari transaksi-transaksi tersebut Harus menjaga urutan instruksi yang mana yang ditampilkan pada transaksi tunggal.

Contoh Penjadwalan Transaksi T1 transfer 50 dari A ke B, dan transaksi T2 transfer 10% dari saldo rekening A ke rekening B. Berikut adalah jadwalnya secara serial, dimana T1 diikuti oleh T2.

Baik di Skedul 1 dan 2 jumlah dari A dan B benar. Transaksi T1 dan T2 dijalankan secara berselang seling. Penjadwalan berikut bukan penjadwalan serial, tetapi equivalent dengan Jadwal 1. Baik di Skedul 1 dan 2 jumlah dari A dan B benar.

Berikut adalah penjadwalan secara konkuren yang tidak menghasilkan jumlah A dan B dengan benar.

Serializability Asumsi dasar – Setiap transaksi menjaga konsistensi database. Eksekusi secara serial dari sekumpulan transaksi menjamin konsistensi database. Sebuah (mungkin konkuren) jadwal adalah serializable jika hasilnya sama dengan jadwal serial. Ada dua cara yang dapat dipilih untuk mengetahui ekivalensi antara sebuah skedul konkuren dengan skedul serial: 1. conflict serializability 2. view serializability Kita hanya akan fokus pada instruksi read dan write, dan kita asumsikan bahwa semua operasi terhadap sebuah data yang terjadi diantara operasi read dand write tersebut hanya berlangsung di dalam memori utama (buffer).

Conflict Serializability Instruksi li dan lj dari transaksi Ti dan Tj berdekatan, conflict jika dan hanya jika ada item data Q yang diakses keduanya li dan lj, dan salah satu dari instruksi adalah melakukan operasi write terhadap Q. 1. li = read(Q), lj = read(Q). li dan lj tidak konflik. 2. li = read(Q), lj = write(Q). Konflik. 3. li = write(Q), lj = read(Q). Konflik. 4. li = write(Q), lj = write(Q). Konflik.1 Konflik antara li dan lj berhubungan dengan urutan (logical) diantaranya. Jika li dan lj adalah berurutan jadwalnya dan tidak konflik, hasilnya akan sama meskipun jadwalnya di balik.

Conflict Serializability Jika skedul S dapat ditransformasikan menjadi skedul S´ dengan melakukan serangkaian pertukaran instruksi-instruksi yang tidak memiliki konflik, maka dikatakan bahwa S dan S´ adalah conflict equivalent (memiliki kesamaan konflik) Dikatakan bahwa skedul S adalah conflict serializable jika conflict equivalent adalah skedul serial Contoh skedul yang tidak conflict serializable: T3 T4 read(Q) write(Q) write(Q) Kita tidak dapat mempertukarkan instruksi yang ada pada transaksi T3 dan T4. Oleh sebab itu, skedul tidak memiliki kesamaan konflik dengan skedul serial baik yang urutannya < T3, T4 >, atau yang urutannya < T4, T3 >.

Conflict Serializability Skedul berikut dapat ditransformasikan menjadi sebuah skedul serial dimana T2 diikuti T1, dengan mempertukarkan instruksi yang tidak konflik. Dengan begitu skedul adalah conflict serializable.

View Serializability S and S´ adalah dua skedul yang sama. S dand S´ adalah view equivalent jika memenuhi tiga kondisi berikut : 1. Untuk setiap item data Q, jika transaksi Ti membaca nilai awal dari Q pada skedul S, maka transaksi Ti pada skedul S´, juga harus membaca nilai awal dari Q. 2. Untuk setiap item data Q jika transaksi Ti menjalankan operasi read(Q) dalam skedul S, untuk nilai Q yang dihasilkan transaksi Tj (jika ada), maka transaksi Ti harus ada di skedul S´ yang juga membaca nilai Q yang dihasilkan transaksi Tj . 3. Untuk setiap item data Q, jika transaksi menjalankan operasi write(Q) terakhir pada skedul S, pada skedul S´ juga harus menjalankan operasi write(Q) terakhir.

View Serializability Sebuah skedul S adalah view serializable karena sama dengan skedul serial. Setiap skedul conflict serializable adalah juga view serializable. Skedul berikut — adalah skedul yang view-serializable tetapi tidak conflict serializable. Setiap skedul view serializable yang tidak conflict serializable mempunyai blind writes.

Contoh lain Serializability Skedul berikut memberikan hasil yang sama dengan skedul serial < T1, T5 >, yang juga bukan conflict equivalent atau view equivalent. Untuk membedakan beberapa persamaan membutuhkan analisis operasi selain read dan write.

Pemulihan kembali (Recoverability) Akibat kegagalan transaksi dibutuhkan pengalamatan dimana operasi konkuren berlangsung. Skedul Recoverable — jika sebuah transaksi Tj membaca item data sebelum ditulis oleh transaksi Ti , kesepakatan operasi Ti ditunjukkan sebelum kesepakatan operasi Tj. Skedul berikut tidak recoverable jika T9 segera sepakat setelah read Jika T8 dibatalkan, T9 akan membaca data yang tidak konsisten. Dengan demikian database harus yakin bahwa skedul adalah recoverable.

Recoverability Rollback – terjadi jika sebuah transaksi tunggal gagal. Sehubungan dengan skedul berikut dimana tidak ada transaksi yang comitt. JIka T10 gagal, T11 dan T12 harus di roll back. Dapat membatalkan hasil yang sudah ada

Penerapan Isolasi Skedul harus dibuat conflict atau view serializable, dan recoverable, untuk menjamin konsistensi database, dan penumpukan lebih baik. Kebijakan bahwa hanya satu transaksi yang diperkenankan jalan dalam satu waktu akan menghasilkan antrian, tetapi tingkat konkurennya rendah. Skema pengendalian konkurensi membandingkan antara nilai konkurensi yang dapat terjadi dengan biaya yang muncul sebagai akaibatnya. Bebrapa skema hanya menggunakan prinsip skedul conflict-serializable, sementara yang lain skedul view-serializable yang tidak conflict-serializable.

Definisi Transaksi dalam SQL Perlunya identifikasi terhadap adanya blok transaksi pada operasi database, maka DML harus pula memiliki perintah untuk mengidentifikasi transaksi.. dalam SQL, awal transaksi diidentifikasi secara implisit. Tetapi identifikasi akhir harus dinyatakan secara eksplisit dengan salah satu perintah berikut : Commit work atau commit saja, yang berfungsi mengubah transaksi dari status partial-committed ke status committed, sehingga transaksi dapat dianggap berakhir dan siap memulai transaksi baru. Rollback work atau rollback saja yang menyebabkan terjadinya pembatalan transaksi (aborted). Tingkat spesifikasi konsistensi SQL-92: Serializable — default Repeatable read Read committed Read uncommitted

Levels of Consistency in SQL-92 Serializable — default Repeatable read — hanya record yang commit yang akan dibaca, pembacaan ulang pada record yang sama harus menghasilkan nilai sama. Read committed — hanya record yang commit yang akan dibaca, tetapi pembacaan yang pembacaan record berturut-turut mungkin mendapatkan nilai yang berbeda (tetapi committed). Read uncommitted — kejadian pembacan record yang tidak commit.

Schedule 2 -- A Serial Schedule in Which T2 is Followed by T1

Schedule 5 -- Schedule 3 After Swapping A Pair of Instructions

Schedule 6 -- A Serial Schedule That is Equivalent to Schedule 3

Schedule 7

Precedence Graph for (a) Schedule 1 and (b) Schedule 2