1 / 36

Basis Data Lanjut

Bab 5 – Pemrosesan Transaksi konsep dan teori Universitas Al Azhar Indonesia Endang R. Nizar 28 Mar 2011. Basis Data Lanjut. T o p i k. Konsep Dasar Transaksi Pemrosesan Transaksi Penjadwalan ( scheduling ) Conflict serializability View serializability.

adeola
Télécharger la présentation

Basis Data Lanjut

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Bab 5 – PemrosesanTransaksikonsepdanteori Universitas Al Azhar Indonesia Endang R. Nizar 28 Mar 2011 Basis Data Lanjut

  2. T o p i k • KonsepDasarTransaksi • PemrosesanTransaksi • Penjadwalan (scheduling) • Conflict serializability • View serializability

  3. Review:Struktursistem basis data secaramenyeluruh

  4. Komponenmanajer basis data (Database Manager) Program object code Query processor Catalog manager Menguji hak user Menentukan strategi optimal untuk melaksanakan query Menguji operasi apakah memenuhi integrity constraint Bila user mempunyai hak akses, kendali diserahkan ke command processor Database manager Authorization control Menjamin tidak terjadi konflik dalam hal concurency Integrity checker Command processor Query optimizer Melaksanakan transaksi Menjamin basis data tetap dalam kondisi yang konsisten dalam failure Mentransfer data antara main memory dan secondary storage Transaction manager Scheduler Data manager Buffer manager Recovery manager Access method File manager Database & system catalog System buffer

  5. KonsepTransaksi • Sistem Basis Data  Single-user vs Multi-user • Single-user – hanyadapatmelayani 1 penggunapadasatusaat. • Multi-user – banyakpenggunadapatmemanfaatkanbasisdatapadasatusaatsecarabersamaan. • Contoh: bank, reservasitiketpesawat, pasarswalayan, bursa saham, dll. • Multi-user dimungkinkankarenaadanyakonsep multiprogramming: • Single CPU bekerjasecarainterleaving • Multiple CPU memungkinkanparallel processing

  6. KonsepTransaksi • Transaksiadalahsatuaneksekusi program yang mengaksesdanmungkinmemodifikasiberbagaidata item. • Contoh: transaksiuntuk transfer $50 dariakun A keakun B: 1. read(A) 2. A := A – 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B) • Duamasalah yang harusditangani: • Berbagaikemungkinankegagalan, sepertikegagalanhardwareatausystem crashes. • Eksekusibeberapatransaksisecarabersamaan.

  7. KonsepTransaksiContoh: transfer uang … (1) • KebutuhanAtomicity • Bilatransaksigagalsetelahlangkah 3 dansebelumlangkah 6  uangakan ‘hilang’  basis data tidakkonsisten • Sistemharusmenjaminbahwaeksekusitransaksi yang tidaktuntastidakbolehdirefleksikankedalam basis data. • KebutuhanDurability— bilapenggunasudahdiberinotifikasibahwatransaksisudahlengkap, makaperubahanolehtransaksiituharustersimpanmeskipunkemudianterjadikegagalansoftware ataupunhardware. • transaksiuntuk transfer $50 dariakun A keakun B : • 1. read(A) • 2. A := A – 50 • 3. write(A) • 4. read(B) • 5. B := B + 50 • 6. write(B)

  8. KonsepTransaksiContoh: transfer uang … (2) • KebutuhanConsistency: • Jumlahakun A + B tidakbolehberubahdenganadanyaeksekusitransaksitersebut • Pengertianconsistencysecaraumum: • Eksplisit: integritasconstraintssepertiprimary keysdanforeign keys • Implisit: contohintegrity constraints – menjaga total balancedarisemuaakun • Transaksiharusmelihat basis data yang konsisten. • Selamaeksekusitransaksi, mungkin basis data untuksementaraberadadalamkeadaantidakkonsisten. • Bilaeksekusitransaksiselesai, maka basis data harusberadadalamkeadaan yang konsisten. • Logikatransaksi yang salahdapatmenyebabkanketidakkonsistenan basis data. • transaksiuntuk transfer $50 dariakun A keakun B : • 1. read(A) • 2. A := A – 50 • 3. write(A) • 4. read(B) • 5. B := B + 50 • 6. write(B)

  9. KonsepTransaksiContoh: transfer uang … (3) • KebutuhanIsolation — bilaantaralangkah 3 dan 6, adatransaksi lain T2 yang diijinkanuntukmengakses basis data yang sedangpartially updated,maka T2 akanmelihat basis data yang tidakkonsisten. • Isolasidapatdijaminbilasemuatransaksidijalankansecara serial. • transaksiuntuk transfer $50 dariakun A keakun B: • T1 T2 • 1. read(A) • 2. A := A – 50 • write(A) • read(A), read(B), print(A+B) • 4. read(B) • 5. B := B + 50 • 6. write(B)

  10. KonsepTransaksiProperti ACID • Untukmenjagaintegritas data, DBMS harusmenjamin: • Atomicity– semuaoperasidalamtransaksiharusdilaksanakanatautidakdilaksanakansamasekali. • Consistency– operasitransaksidalamisolasimenjaminbasisdatatetapkonsisten. • Isolation– meskipunbeberapatransaksidapatdilaksanakansecarabersama, setiaptransaksitidaktahukeberadaantransaksi lain danhasiltransaksiantara (intermediate result) harustidakdiketahuiolehtransaksi lain. • Durability– sesudahtransaksiselesaidengansukses, perubahan yang terjadiharusbersifatmenetap, meskipunterjadikegagalansistem.

  11. KonsepTransaksiPemrosesanTransaksi • Untukmenjaminkonsistensidibutuhkan: • Pengendalianeksekusibersama (concurrency) • Mekanismarecovery A A B B C CPU1 D CPU2 waktu t2 t3 t4 t1 Parallel processing Interleaved processing

  12. KonsepTransaksiPemrosesanTransaksi • Transaksiadalaheksekusi program yang membentuksuatu unit logikalpemrosesanbasisdata yang dilaksanakansecaralengkapatautidaksamasekali • Mencakupoperasiinsert, delete, modify, retrieve • Bilaoperasidalamtransaksihanyamencakupretrievetanpamerubah data, makadisebutread-only transaction • Pembatastransaksi: BEGIN TRANSACTION … … END TRANSACTION Semuaoperasidiantarakeduapembatasitudisebutsatutransaksi • Operasi yang biasaterlibatdalamtransaksiadalah; read_item (X) write_item (X)

  13. KonsepTransaksiPemrosesanTransaksi • Langkah-langkahdalamread_item(X): • Temukan address dariblok disk yang mengandung item X. • Copy isiblok disk kedalam buffer dalam main memory. • Copy item X dari buffer kevariabel program bernama X. • Langkah-langkahdalamwrite_item(X): • Temukan address dariblok disk yang mengandung item X. • Copy isiblok disk kedalam buffer dalam main memory. • Copy item X darivariabel program bernama X kelokasi yang benardalam buffer. • Simpanblok yang sudahdiubahisinyakedalam disk.

  14. KonsepTransaksiEksekusibersama (concurrent) • Beberapatransaksidimungkinkanuntukberjalanbersamaandalamsuatusistem. Keuntungan: • Meningkatkanutilisasiprosesordan disk, menujutransaksi throughput lebihbaik; 1 transaksidapatmenggunakan CPU sementaratransaksi lain menuliskedalam disk • Menekan rata-rata wakturesponuntuktransaksi; transaksipendektidakperlumenunggu lama sebelumsuatutransaksi yang panjang • Skemapengendalianconcurrency – mekanismauntukmencapaiisolasi. • Untukmengendalikaninteraksiantartransaksi yang bersamaan agar konsistensibasisdatatidakterganggu.

  15. KonsepTransaksiMengapaperlupengendalianeksekusibersama • Masalahlost update – terjadibila 2 transaksimengakses data item yang samasementaraoperasiinterleaveddapatmengakibatkannilaiakhir data item tidakbenar. waktu Nilai item (X) salahkarenaperubahanoleh T1 ‘hilang’ (overwritten)

  16. KonsepTransaksiMengapaperlupengendalianeksekusibersama • Masalahtemporary update (dirty read) – terjadibila 1 transaksimerubah data item dankemudiantransaksitersebutgagal (harusroll back), sementara item yang sudahberubahsudahdigunakanolehtransaksi lain sebelumiadikembalikankekondisisemula. waktu Transaksi T1gagaldanharusdikembalikankekondisisemula, sementara T2sudahmembacanilaitemporary item X yang salah

  17. KonsepTransaksiMengapaperlupengendalianeksekusibersama • Masalahincorrect summary– terjadibilasuatutransaksimelakukanfungsiagregatsementaratransaksi lain merubahsebagiantupel. waktu Transaksi T3membaca X setelah X – N danmembaca Y sebelum Y + N; summarysalah

  18. KonsepTransaksiOperasidalampemrosesantransaksi • Operasi yang berhubungandengantransaksi: • BEGIN TRANSACTION – menandaiawaleksekusitransaksi • READatauWRITE – menunjukkanoperasibaca/tulis yang dieksekusisebagaibagiantransaksi • END TRANSACTION – menandaiakhireksekusitransaksi • COMMIT TRANSACTION – menunjukkantransaksiselesaidengansuksessehinggasetiapperubahandapatdisimpansecarapermanendalambasisdatadantidakada undo (committed) • ROLLBACK (atauABORT) – menunjukkantransaksitidakselesaidengansuksessehinggasetiapperubahanharusdikembalikankekondisiawalatauundo

  19. Active – kondisiawal, transaksitetapdikondisiiniselamaeksekusi Partially committed – setelahperintahterakhirdilaksanakan Committed – setelahtransaksiselesaidilaksanakandengansukses. Failed – setelah diketahui bahwa eksekusi normal tidak dapat dilanjutkan Aborted – setelah transaksi di-rollback dan basisdata dikembalikan ke posisi sebelum transaksi dimulai. END TRANSACTION partially committed COMMIT committed BEGIN TRANSACTION active ABORT failed terminated ABORT KonsepTransaksiKondisiTransaksi (transaction states)

  20. Penjadwalan (scheduling) • Schedule – serangkaianinstruksi yang menunjukkanurutankronologitransaksi yang dieksekusibersamaan (concurrent transactions) • Jadwaldarisekumpulantransaksiharusmencakupsemuainstruksidalamtransaksi yang terlibat. • Tetapmenjagaurutaninstruksisesuaitransaksi individual. • Transaksi yang suksesdieksekusisecaralengkapakanmempunyaiinstruksicommit sebagaiperintahterakhirnya • By defaultdiasumsikansetiaptransaksiakanmengeksekusiinstruksicommit sebagailangkahterakhir. • Transaksi yang gagalmelaksanakaneksekusisecaralengkapakanmempunyaiinstruksiabort sebagailangkahterakhir.

  21. Penjadwalan (scheduling) • Contoh: • T1 mentransfer $50 dari A ke B dan T2 mentransfer 10% darisaldo A ke B. Schedule 1 – serial schedule Schedule 2 – serial schedule

  22. Penjadwalan (scheduling) Schedule 3 – non-serial schedule, tapiekivalendengan Schedule 1 Schedule 4 – non-serial schedule, denganoperasiinterleaving jumlahA + B tidakterjaga

  23. Penjadwalan (scheduling) • Jikaeksekusiconcurrentdiserahkansepenuhnyakepadasistemoperasi, adabanyakkemungkinanjadwal yang dilaksanakansistem, termasukjadwal yang menyebabkanketidak-konsistenanbasisdata. • Komponenconcurrency-controldalam DBMS bertugasmenjagapelaksanaanjadwal agar ekivalendenganjadwal serial danmenghasilkankondisibasisdata yang konsisten.

  24. Serializability • Asumsidasar – setiaptransaksimenjagakonsistensibasisdata. • Setiapeksekusi serial daritransaksimenjagakonsistensibasisdata. • Suatujadwal (bisaconcurrent) disebutserializablebilaiaekivalendengan serial schedule. Bentuk lain dari serial schedule antara lain: • Conflict serializability • View serializability • Dalamcontoh-contohberikutnya jadwaldisederhana-kanhanyamenyangkutinstruksiread_itemdanwrite_itemkarenaoperasiantarakeduanyabisaberupaoperasiapapun.

  25. Conflict serializability • Instruksi IidanIjdaritransaksi TidanTj – akanterjadikonflikjikadanhanyajikaada item Q yang diaksesoleh IidanIjdansetidaknyaadasatuinstruksi Q menulis • Ii = read(Q), Ij = read(Q) tidakadakonflik, tidakterpengaruhurutan • Ii = read(Q), Ij = write(Q) konflik urutaneksekusiIidanIjmenjadipenting • Ii = write(Q), Ij = read(Q) konflik • Ii = write(Q), Ij = write(Q) konflik • Secaraintuitif, konflikantara IidanIjmengakibatkanlogikalurutansementara. Jika IidanIjberurutandalam schedule dantidakkonflik, makahasilnyaakankonsistenmeskipunurutannyadiubah. • Schedule S dan S’ disebutconflict equivalent jika S dapatditransformasike S’ melaluiswappingurutaninstruksi yang tidakmenimbulkankonflik. • S disebutconflict serializablejika S adalahconflict equivalentterhadapsekelompokserial schedule.

  26. Schedule 3dapatditransformasike Schedule 1, urutan schedule dimana T2 mengikuti T1 denganurutanswap yang tidakmenyebabkankonflik. Sehingga Schedule 3 adalahconflict serializable. Schedule 5 – conflict serializableterhadap Schedule 1 Schedule 6 – conflict serializableterhadap Schedule 3 Conflict serializability Write_item(A) pada T2tidakkonflikdenganread_item(B) pada T1 instruksibisadi-swap

  27. Conflict serializability • Schedule 7 – contoh schedule yang tidak conflict serializable: • Instruksidiatastidakdapatdi-swapuntukmendapaturutanserial schedule <T3, T4> atauurutanserial schedule <T4, T3>.

  28. Pengujian conflict serializability – precedence graph • Untuk setiap transaksi Ti yang berpartisipasi dalam schedule S, buat node berlabel Ti dalam precedence graph. • Untuk setiap operasi dalam S di mana Tj mengeksekusi read_item(X) setelah Ti mengeksekusi write_item(X), buat garis yang menghubungkan Ti Tj • Untuk setiap operasi dalam S di mana Tj mengeksekusi write_item(X) setelah Ti mengeksekusi read_item(X), buat garis yang menghubungkan Ti Tj • Untuk setiap operasi dalam S di mana Tj mengeksekusi write_item(X) setelah Ti mengeksekusi write_item(X), buat garis yang menghubungkan Ti Tj • Schedule S disebut serializable jika dan hanya jika dalam precedence graph tidak terdapat lingkaran tertutup (cycle)

  29. Contoh pengujian conflict serializability schedule • S: r1(X), r2(X), w1(X), r1(Y), w2(X), w1(Y) X Non-serializable schedule T1 T2 X A serializable schedule gives the benefits of concurrent execution without giving up any correctness.

  30. View Serializability • S dan S’ adalah 2 schedule dengankumpulantransaksi yang sama. S dan S’ disebutview equivalent jikamemenuhi 3 kondisidibawahini: • Untuksetiap data item Q, jikatransaksi Timembacanilaiawal Q dalam schedule S, makatransaksi Tidalam schedule S’, jugaharusmembacanilaiawal Q. • Untuksetiap data item Q dalam Timengeksekusiread_item(Q) dalam S, dannilaiitudiproduksiolehtransaksiTj (jikaada), makatransaksi Ti dalam S’ jugaharusmembacanilai Q yang diproduksiTj. • Untuksetiap data item Q, transaksi (jikaada) yang melakukanwrite_item(Q) terakhirdalam Schedule S harusmelakukanwrite_item(Q) terakhirdi Schedule S’.

  31. View Serializability • Dalamcontohterdahulu – • Schedule 1 tidakview equivalent terhadap Schedule 2, • Schedule 1 adalahview equivalent terhadap Schedule 3, • Schedule S adalahview serializablejikaia view equivalent terhadapsuatu serial schedule. Schedule 3 Schedule 1 Schedule 2

  32. View Serializability • Schedule 9 – adalahview serializable, karenaiaview equivalent terhadap serial schedule <T3,T4,T6> karenainstruksiread_itemdilakukanoleh T3padakedua schedule dan T6 yang melakukanwrite_itemterakhir, adadikedua schedule. • Setiapview serializable yang bukanconflict serializablemempunyaiblind writes. • Setiap schedule yang conflict serializablejugamerupakanview serializable, tapibelumtentusebaliknya. Schedule 9

  33. Recoverability • Penting untuk menangani dampak dari kegagalan transaksi concurrent yang sedang berjalan. • Jika Ti gagal karena sesuatu hal, sistem harus melakukan undo untuk menjaga properti atomicity. • Pada sistem yang menyediakan eksekusi concurrent, perlu dijamin bahwa • Transaksi Tj yang memiliki ketergantungan terhadap Ti harus dihentikan. • Semua nilai harus dikembalikan ke kondisi awal.

  34. Recoverability • Recoverability schedule – terjadi jika transaksi Tj membaca data item yang sebelumnya ditulis oleh transaksi Ti, sementara operasi commit Ti muncul sebelum operasi commit Tj. • Schedule 11 tidak recoverable jika T9 di-commit langsung sesudah read_item. • Jika T8 harus batal (abort), T9 mungkin sudah membaca (dan mungkin sudah dikirim ke pengguna) basisdata dalam kondisi tidak konsisten. Maka basisdata harus menjamin bahwa schedule bersifat recoverable.

  35. Recoverability • Cascading rollback – kegagalansebuahtransaksi yang menyebabkansekelompoktransaksidikembalikankekondisiasal(rollback) secaraberjenjang. Contohscheduledimana T10gagaldimana T11dan T12harusdi-rollback – bilabelumadatransaksi yang di-commit, sehingga schedule recoverable. • Tidakterlaludisukaikarenadapatmenimbulkanundountuksejumlahtransaksi yang signifikan.

  36. Penerapan isolasi • Schedule harus conflict serializable atau view serializable, dan recoverable, untuk menjamin konsistensi basisdata, dan tidak mengandung jenjang (cascade). • Untuk mencapai kondisi di atas, bisa diterapkan kebijakan untuk me-lock basisdata sementara suatu transaksi berjalan  menyebabkan kinerja rendah.

More Related