5 sesi7a manajemen transaksi

Transaksi

Transaksi

 Konsep Transaksi

 Status transaksi

 Penerapan Atomisitas dand Durabilitas

 Eksekusi konkuren

 Serializability

 Recoverability

 Penerapan Isolasi

Konsep Transaksi

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

Properti AKID

Properti AKID

 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 T_i dan T_j, menunjukkan kepada T_i bahwa transaksi lain T_j,

menyelesaikan eksekusi sebelum T_i mulai, atau T_j mulai eksekusi setelah T_i 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

Contoh pada transfer uang

 Transaksi pengiriman 50 dari rekening A ke rekening B:

1. read(A)

 Konsistensi yang dibutuhkan – jumlah A dan B tidak terubah oleh eksekusi transaksi.

 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.

Status Transaksi

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

Status Transaksi

Penerapan Atomik dan Durabel

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.

 Asumsikan bahwa penulisan tidak gagal

 Sangat bermanfaat untuk pengolah teks, tetapi tidak efisien untuk database yang besar: eksekusi sebuah transaksi

Eksekusi Konkuren

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

Tiga masalah konkurensi

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 Select * from t;

*update t set id=1 Where id = 2;

w3

w4 Update t set id = 3

where id = 2;

 _{Uncommitted dependency}

 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

Penjadwalan

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

Contoh Penjadwalan

Contoh Penjadwalan

 Transaksi T1 dan T2 dijalankan secara berselang seling.

Penjadwalan berikut bukan penjadwalan serial, tetapi

Serializability

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

Conflict Serializability

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

Conflict Serializability

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:

T₃ T₄

read(Q)

write(Q) write(Q)

Kita tidak dapat mempertukarkan instruksi yang ada pada transaksi T3 dan T4. Oleh sebab itu, skedul tidak memiliki

Conflict Serializability

Conflict Serializability

 Skedul berikut dapat ditransformasikan menjadi sebuah skedul serial dimana T2 diikuti T1, dengan mempertukarkan

View Serializability

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 T_i membaca nilai awal dari Q pada skedul S, maka transaksi T_i pada skedul S´, juga harus membaca nilai awal dari Q.

2. Untuk setiap item data Q jika transaksi T_i menjalankan operasi read(Q) dalam skedul S, untuk nilai Q yang dihasilkan transaksi T_j (jika ada), maka transaksi T_i harus ada di skedul S´ yang juga

membaca nilai Q yang dihasilkan transaksi T_j .

View Serializability

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.

Contoh lain Serializability

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

Pemulihan kembali (Recoverability)

Pemulihan kembali (Recoverability)

 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.

Recoverability

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.

Penerapan Isolasi

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.

Definisi Transaksi dalam SQL

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.

 Te tapi 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

Levels of Consistency in SQL-92

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).

Schedule 2 -- A Serial Schedule in Which

Schedule 2 -- A Serial Schedule in Which

T

T

2

Schedule 5 -- Schedule 3 After Swapping A Pair

Schedule 5 -- Schedule 3 After Swapping A Pair

of Instructions

Schedule 6 -- A Serial Schedule That is

Schedule 6 -- A Serial Schedule That is

Equivalent to Schedule 3

Schedule 7

Precedence Graph for

Precedence Graph for

(a) Schedule 1 and (b) Schedule 2