Download Transaksi - hhimawan

Transaksi
 Konsep Transaksi
 Status transaksi
 Penerapan Atomisitas dand Durabilitas
 Eksekusi konkuren
 Serializability
 Recoverability
 Penerapan Isolasi
 Definisi transaksi dalam SQL
1
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
2
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.
3
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.
4
 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.
5
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.
6
Status Transaksi
7
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 .
8
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
9
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
10
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
Select * from t;
w1
w2
*update t set id=1
Transaksi B
Select * from t;
w3
Where id = 2;
w4
Transaksi A kehilangan perubahan saat w4
11
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. Arena belum save selalu ada
kemungkinan perubahan tersebut akan di-undo (redo)
Transaksi A
waktu Transaksi B
w1
Select * from t;
Update t set dept_id=1;
w2
w3
rollback;
Transaksi A dependent ke uncommitted change saat w2
Transaksi A
waktu Transaksi B
w1
Update t set dept_id=11;
Update t set dept_id=1;
w2
w3
rollback;
A mengubah uncommitted change saat w2, kehilangan saat w3,
12
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.
13
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.
14
 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.
15
 Berikut adalah penjadwalan secara konkuren yang
tidak menghasilkan jumlah A dan B dengan benar.
16
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).
17
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).
2. li = read(Q), lj = write(Q).
3. li = write(Q), lj = read(Q).
4. li = write(Q), lj = write(Q).
li dan lj tidak konflik.
Konflik.
Konflik.
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.
18
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
read(Q)
T4
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 >.
19
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.
20
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.
21
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.
22
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.
23
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.
24
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
25
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.
26
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
27
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 berturutturut mungkin mendapatkan nilai yang berbeda (tetapi
committed).
 Read uncommitted — kejadian pembacan record yang tidak
commit.
28
Schedule 2 -- A Serial Schedule in Which
T2 is Followed by T1
29
Schedule 5 -- Schedule 3 After Swapping A
Pair of Instructions
30
Schedule 6 -- A Serial Schedule That is
Equivalent to Schedule 3
31
Schedule 7
32
Precedence Graph for
(a) Schedule 1 and (b) Schedule 2
33