Database Management Systems Bab 9 Overview Manajemen Transaksi (Chap Database Management Systems Bab 9 Overview Manajemen Transaksi (Chap. 16 – Ramakrishnan)

Pokok Bahasan Empat properti apa dari transaksi yang dijamin oleh DBMS ? Mengapa DBMS melakukan “interleave” dari transaksi-transaksi yang dijalankan ? Kriteria kebenaran apa yang harus diberlakukan untuk “interlaeaved execution” ? Anomali apa saja yang dapat ditimbulkan oleh “interleaving transactions” ? Bagaimana DBMS menggunakan mekanisme “locks” guna menjamin “interleaving” yang benar ? Apa dampak dari mekanisme “locking” pada kinerja DBMS ? Perintah SQL apa yang memungkinkan programmers untuk memilih karakteristik transaksi sesuai dengan yang diinginkan dan juga untuk mengurangi overhead yang ditimbulkan oleh mekanisme “locking” ? Bagaimana DBMS menjamin “transaction atomicy & recovery” dari terjadinya “system crashes” ?

Transaksi Eksekusi secara konkuren terhadap sejumlah program (yang dijalankan user) merupakan aspek yang essensial guna memperoleh kinerja DBMS yang baik Hal ini dikarenakan akses disk dilakukan dalam frekuensi yang sering, tetapi dengan kecepatan yang relatif lambat, sehingga penting untuk menjaga agar CPU tetap sibuk bekerja pada sejumlah program secara konkuren Sebuah program bisa jadi melibatkan banyak operasi terhadap data yang di-retrieve dari database. Tetapi, untuk ini DBMS hanya memperhatikan mengenai data apa yang dibaca/ditulis dari/ke database. Sebuah transaksi merupakan cara pandang abstraksi dari DBMS terhadap program yang dijalankan oleh user, yang pada dasarnya dipandang sebagai suatu urutan dari proses baca (reads) dan tulis (writes).

Properti ACID DBMS harus menjamin 4 properti dasar dari transaksi guna memelihara data akibat adanya akses konkuren dan kegagalan sistem, yaitu: Setiap transaksi harus dijalankan secara Atomic (yaitu, semua tindakan terkit harus dilakukan atau tidak sama sekali). Setiap transaksi harus mempertahankan Consistency dari database (yaitu, setiap traksaksi seolah-oleh dijalankan sendirian tanpa ada eksekusi konkuren dari transaksi yang lain). Setiap transaksi harus dijalankan dalam kondisi Isolation (yaitu, setiap transaksi harus diisolasi/diproteksi dari pengaruh-pengaruh penjadualan secara konkuren dari transaksi-transaksi lainnya; termasuk seandainya DBMS harus menjalankan tindakan-tindakan dari berbagai transaksi secara bergantian guna meningkatkan kinerjanya). Begitu DBMS telah berhasil menyelesaikan suatu transaksi, pengaruh dari penyelesaian itu harus tetap terjadi walaupun seandainya sistem mengalami kegagalan (crash) sebelum semua perubahan-perubahan yang seharusnya terjadi direfleksikan pada disk) . Sifat/properti ini disebut Durability.

Transaksi dan Penjadualan DBMS melihat sebuah transaksi sebagai satu urutan (atau satu daftar) actions/tindakan) (yaitu, read/baca dan write/tulis dari objek-objek database) Sebagai tambahan terhadap tindakan pembacaan dan penulisan, setiap transaksi juga HARUS menyatakan sebagai tindakan akhirnya berupa commit (terselesaikan dengan sukses) atau abort (berhenti atau membatalkan/undo semua tindakan yang telah diselesaikan sebelumnya) Suatu penjadualan berisikan satu daftar tindakan-tindakan (reading, writing, aborting, atau committing) dari sekumpulan transaksi, dimana urutan dua buah tindakan dari sebuah transaksi T yang muncul dalam suatu penjadualan harus sama dengan urutan yang tampak dalam T. Contoh: T1: R(A), W(A) R(C), W(C) T2: R(B), W(B)

Concurrency dalam DBMS Pada saat users menyerahkan sejumlah transaksi, maka users boleh beranggapan bahwa setiap transaksi dijalankan secara sendiri-sendiri. Concurrency dijalankan oleh DBMS dengan cara melakukan tindakan-tindakan (reads/writes dari objek-objek database) dari berbagai transaksi secara bergantian (interleaving). Setiap transaksi harus meninggalkan database dalam keadaan yang konsisten bilamana database berada dalam keadaan yang konsisten pada saat transaksi mulai dijalankan. DBMS akan memaksa beberapa integrity constraints (ICs) sesuai dengan ICs yang dideklarasi dalam CREATE TABLE statements. Selain itu, DBMS benar-benar tidak mengerti makna dari data. (misalnya, DBMS tidak paham bagaimana bunga bank untuk suatu rekening harus dihitung). Issue penting: Pengaruh interleaving berbagai transaksi, dan persoalan crashes dari sistem.

Tujuan Concurrent Execution Meningkatkan system throughput (jumlah rerata transaksi yang dapat diselesaikan dalam suatu kurun waktu tertentu) Aktivitas I/O dpt dilakukan secara paralel dengan aktivitas CPU Menumpangtindihkan (overlapping) aktivitas I/O dan aktivitas CPU dapat mengurangi jumlah akses disk dan waktu nganggur (idle time) dari processors. Meningkatkan response time ( rerata waktu yang diperlukan untuk menyelesaikan sebuah transaksi) Proses penggiliran (interleaving) dari transaksi yang pendek dengan transaksi yang panjang biasanya memungkinkan transaksi yang pendek untuk diselesaikan dengan lebih cepat. Dalam proses eksekusi secara serial, suatu transaksi yang pendek dapat mengalami kemacetan di belakang suatu transaksi yang panjang. Kemacetan semacam ini dapat menimbulkan terjadinya penundaan (delay) yang tidak dapat diprediksi.

Atomicity dari Transactions Sebuah transaksi dapat menyatakan commit setelah menyelesaikan semua tindakan-tidakan yang harus dilakukan, atau dapat menggugurkan abort (atau digugurkan oleh DBMS) setelah melakukan beberapa tindakan. Satu properti yang sangat penting yang dijamin oleh DBMS utk semua transaksi adalah bahwasanya setiap transaksi bersifat atomic. Artinya, user boleh beranggapan bahwa sebuah transaction (Xact) selalu menjalankan semua tindakan-tindakannya dalam satu langkah, atau tidak menjalankan tindakan apapun. DBMS mencatat semua tindakan-tindakan yang dilakukannya dalam sebuah log sehingga DBMS dapat melakukan undo tindakan-tindakan dari Xacts yang digugurkan.

Contoh Perhatikan dua buah Xacts berikut: T1: BEGIN A=A+100, B=B-100 END T2: BEGIN A=1.06*A, B=1.06*B END Secara intuitif, Xact pertama sedang melakukan transfer $100 dari rekening B ke rekening A. Sedang Xact kedua sedang melakukan penambahan bunga pada masing-masing rekening sebesar 6%. Tidak ada jaminan bahwa T1 akan dijalankan sebelum T2 atau sebaliknya, jika keduanya diserahkan secara bersama-sama. Namun, pengaruh akhir yang ditimbulkannya HARUS sama dengan pengaruh seandainya kedua Xacts tersebut dijalankan secara serial dalam urutan sembarang.

Conroh (Lanjutan) Perhatikan suatu interleaving (schedule) berikut: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Skedul di atas OK. Tetapi bgm dengan yang berikut: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Pandangan DBMS terhadap skedul kedua di atas: T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B)

Menjadualkan Transactions Serial schedule: Skedul yang tidak meng-interleave tindakan-tindakan dari Xacts yang berbeda. Equivalent schedules: Untuk sembarang keadaan database, pengaruh (pada satu set objek dalam database) eksekusi skedul pertama identik dengan pengaruh eksekusi skedul kedua. Serializable schedule: Skedul yang ekivalen dengan beberapa eksekusi Xacts secara serial . (Catatan: Jika setiap transaksi mempertahankan konsistensi, maka setiap serializable schedule juga dijamin akan mempertahankan konsistensi. )

Serializability Sebuah serializable schedule pada satu set committed Xacts S adalah sebuah skedul yang pengaruhnya pada sembarang nilai database yang konsisten dijamin identik dengan beberapa complete serial schedule pada S. T1: R(A), W(A) R(B), W(B) C T2: R(A), W(A) R(B), W(B), C Eksekusi Xacts secara serial dalam urutan-urutan yang berbeda dpt memberikan hasil-hasil yang berbeda, tetapi semuanya harus dapat diterima. T1: R(A), W(A) R(B), W(B) C T2: R(A) W(A), R(B), W(B) C

Anomali pada Interleaved Execution Terdapat 3 cara utama dimana sebuah skedul yang melibatkan dua Xacts yang commited dan mempertahankan konsistensi dapat berjalan melawan database yang konsisten dan meninggalkannya dalam keadaan yang inkonsiten. Dua buah tindakan pada objek data yang sama dikatakan bertentangan satu sama lain (conflick) jika paling tidak salah satu diantaranya berupa tindakan menulis (write) . Ketiga situasi anomali (dlm bentuk urutan T1 dan T2 Xacts): Write-Read (WR) conflict, T2 membaca sebuah objek data yang sebelumnya ditulis oleh T1 Read-Write (RW) conflict, T2 menulis sebuah objek data yang sebelumnya dibaca oleh T1 Write-Write (WW) conflict, T2 menulis sebuah objek data yang sebelumnya ditulis oleh T1

Anomali (Lanjutan) Unrepeatable Reads (RW Conflicts): Membaca Data yang Uncommitted (WR Conflicts, “dirty reads”): T1: R(A), W(A), R(B), W(B), C T2: R(A), W(A), R(B), W(B), C Unrepeatable Reads (RW Conflicts): T1: R(A), W(A), C T2: R(A), W(A), C Overwriting Data yang Umcommitted (WW Conflicts): T1: W(A), W(B), C T2: W(A), W(B), C Skedul yang melibatkan Xacts yang digugurkan (aborted) (unrecoverable schedule): T1: R(A), W(A), R(B), W(B), Abort T2: R(A), W(A), C

Lock-Based Concurrency Control Protokol Strict Two-phase Locking (Strict 2PL): Setiap Xact harus memperoleh S (shared) lock pada objek sebelum pembacaan, dan X (exclusive) lock pada objek sebelum penulisan. Semua locks yang dipegang oleh sebuah transaksi dilepas pada saat transaksi terselesaikan Jika sebuah Xact memegang sebuah X lock pada suatu objek, maka tidak boleh terdapat Xact yang lain yang dapat memperoleh lock (S atau X) pada objek tersebut. Protokol Strict 2PL hanya membolehkan skedul-skedul yang bersifat serial (serializable schedules).

Contoh Lock-Based CC Pembacaan Uncommitted Data (dari contoh sebelumnya): T1: R(A), W(A), R(B), W(B), C T2: R(A), W(A), R(B), W(B), C Skedul menggunakan “Strict 2PL” dengan eksekusi serial: T1: X(A), R(A), W(A), X(B), R(B), W(B), C T2: X(A), R(A), W(A), X(B), R(B), W(B), C Pertama, T1 memperoleh exclusive lock pada objek A dan baru kemudian melakukan pembacaan dan penulisan pada A. T2 juga mengajukan permintaan lock pada objek A, tetapi tidak akan diberikan hingga T1 melepas exclusive lock pada objek A (DBMS menunda permintaan T2).

Contoh Lock-Based CC (Lanjutan Secara umum, tindakan-tindakan pada beberapa transaksi yang berbeda dapat dibuat interleaved satu dengan yang lain: T1: S(A), R(A) X(C), R(C), W(C), C T2: S(A), R(A), X(B), R(B), W(B), C

Keadaan Deadlock Penggunaan lock-based concurrency control dapat menimbulkan terjadinya “deadlock” (suatu siklus Xacts yang sedang menunggu locks untuk dilepas): T1: X(A) X(B) T2: X(B) X(A) T1 mengajukan permin-taan exclusive lock pada B dan diantrikan T2 mengajukan permin-taan exclusive lock pada A dan diantrikan DBMS harus “mencegah” atau “mendeteksi dan memulih-kan kembali” (cara yang lebih umum) keadaan deadlock Cara yang paling sederhana untuk mengidentifikasi dead-lock adalah dengan menggunakan mekanisme “timeout”.

Menggugurkan Transaksi Jika sebuah transaksi Ti digugurkan, semua tindakannya hrs dibatalkan (undo). Demikian juga, jika Tj membaca sebuah objek yang terakhir ditulis oleh Ti, maka Tj harus juga digugurkan (cascade aborts)! Kebanyakan sistem menghindari cascading aborts dengan cara melepas sebuah lock transaksi hanya pada saat tindakan commit dilakukan. Jika Ti menulis sebuah objek, maka Tj dpt membaca objek tsb hanya setelah Ti menyatakan commit. Untuk membatalkan (undo) tindakan-tindakan dari sebuah transaksi yang digugurkan, DBMS menyimpan log yang berisi rekaman dari setiap tindakan penulisan. Mekanisme ini juga digunakan untuk memulihkan kembali dari terjadinya system crashes: semua Xacts yang aktif pada saat terjadinya crash digugurkan pada dilakukan back up dari sistem.

Log Tindakan-tindakan yang direkam dalam log: Ti writes an object: nilai lama dan nilai baru dari objek. Record dari log hrs disimpan ke disk sebelum terjadi pergantian halaman (page) ! Ti commits/aborts: record dari log yang mengindikasikan tindakan commit/abort. Records dari log dihubungkan satu sama lain berdasarkan Xact id, sehingga mudah untuk membatalkan (undo) suatu Xact tertentu. Log biasanya digandakan dan diarsipkan pada “stable storage”. Semua aktifitas yang terkait dengan log (termasuk, semua aktifitas yang terkait dengan pengendalian konkurensi seperti lock/unlock, penanganan deadlocks dll.) ditangani secara transparan oleh DBMS.

Kinerja dari Mekanisme Locking Skema yang didasarkan pada sistem “lock” didesain utk mengatasi konflik antar Xacts dan menggunakan dua mekanisme dasar: blocking dan aborting. Xacts yang terblok boleh jadi memegang beberapa lock yang memaksa Xacts lainnya untuk menunggu Proses pengguguran (dan proses menjalankan kembali) sebuah Xact merupakan tindakan sia-sia (waste time) terhadap pekerjaan yang telah dilakukan sebelumnya Keadaan deadlock, jika benar-benar terjadi, dapat menimbul-kan terjadinya pemblokan Xacts yang serius Overhead dari locking utamanya berasal dari “delays” karena terjadinya blocking, sebab dalam praktek, #Xacts yang terlibat dalam deadlock kurang dari 1% selain proses pengguguran (aborts) juga relatif jarang terjadi. Blocking delays mempengaruhi throughput. Throughput naik secara proporsional terhadap #active-Xacts Terjadinya blocking delays yang berlebihan yang diikuti oleh #active-Xacts yang berlebihan dapat menimbulkan terjadinya systems trash

Dukungan SQL: Creating & Terminating Xacts Sebuah Xact secara otomatis dimulai pada saat seorang user menjalankan statement yang mengakses database atau catalogs, seperti SELECT query, UPDATE command, dan CREATE TABLE statement. Sebuah Xact dpt dihentikan dengan menggunakan perintah COMMIT atau ROLLBACK (SQL keyword untuk abort). SQL-1999 menyediakan 2 fitur baru guna mendukung berbagai aplikasi yang melibatkan long-running Xacts (atau yang menjalankan beberapa Xacts satu per satu): Perintah “Save point” memungkinkan long-running Xact utk mendefinisikan sekumpulan urutan save points: SAVEPOINT(save-point name) Perintah “Roll back” dpt dignakan untuk menyatakan suatu “save point” ke mana roll back harus dilakukan: ROLLBACK TO SAVEPOINT (save-point name)

Dukungan SQL : Apa yang seharusnya di-Locked Perhatikan query berikut: SELECT S.rating, MIN(S.age) FROM Sailors S WHERE S.rating = 8 Dengan asumsi bahwa: Query di atas dijalankan sebagai bagian dari Xact T1 Statement SQL yang merubah nilai “age” utk seorang sailor dengan “rating = 8” dijalankan sebagai bagian dari Xact T2 “Objects” apa yang seharusnya di-locked oleh DBMS pada saat DBMS mengesksekusi Xacts di atas? Beberapa kemungkinan dapat dilakukan: Lock keseluruhan tabel: set shared lock pd keseluruhan tabel Sailors utk T1 dan set exclusive lock pd Sailors utk T2  menghasilkan low concurrency ! Lakukan row-level locks: set shared lock pd setiap baris dengan rating = 8 utk T1 dan set exclusive lock hanya pd baris-baris yang mengalami perubahan untuk T2  memberikan kinerja yang lebih baik (tindakan read-only Xacts lainnya yang tidak melibatkan baris-baris dengan nilai rating=8 dpt diproses tanpa harus menunggu T1 atau T2)

Dukungan SQL : Apa yang seharusnya di-Locked (Lanjutan) Dari contoh sebelumnya, perhatikan (tambahan ke T1 & T2): SQL statement yang menyisipkan sailor baru dengan rating = 8 dan dijalankan sebagai bagian dari Xact T3 (melanggar asumsi bhw database harus berisikan sejumlah objek yang tetap dalam database, tetapi situasi seperti ini dapat terjadi dalam praktek) Situasi di atas dpt menimbulkan terjadinya persoalan phantom, yaitu sebuah Xact melakukan retrieving sekumpulan objek (i.e., sekumpulan tuples) dua kali dan memberikan hasil yang bebeda, walaupun Xact tidak melakukan perubahan apapun pada tuples tersebut. Walaupun DBMS dpt men-set shared locks pada setiap baris Sailors eksisting dengan nilai rating=8 untuk T1, tetapi hal tsb tidak dapat mencegah Xact T3 untuk menciptakan baris baru dengan rating=8 dan men-set exclusive lock pada baris tersebut. Utk mencegah terjadinya phantom, DBMS harus melakukan locks semua baris-baris yang mungkin dengan rating=8 utk kepentingan T1 (yaitu, lock keseluruhan tabel dengan biaya concurrency yang rendah).

Dukungan SQL: Karakteristik Transaksi Utk memungkinkan programmers melakukan pengendalian terhadap locking overhead yang diakibatkan oleh Xacts, SQL membolehkan programmers untuk menspesifikasikan 3 karakteristik dari sebuah Xact: diagnostics size, access mode, dan isolation level. Diagnostics size menentukan jumlah kondisi-kondisi error yang dapat dicatat (tidak dibahas lebih lanjut). Jika access mode adalah READ ONLY  Xact tidak diperbolehkan untuk merubah database: Perintah INSERT, DELETE, UPDATE dan CREATE tidak dapat dijalankan. Xacts dengan access mode READ ONLY, hanya shared locks yang perlu diperoleh, sehingga dapat meningkatkan tingkat concurrency.

Dukungan SQL: Karakteristik Transaksi (Lanjutan) Isolation level mengendalikan perluasan kemana sebuah Xact di-expose bagi tindakan-tindakan dari Xacts lainnya yang berjalan secara konkuren. Dengan memilih sala satu dari 4 kemungkinan isolation level settings, user dpt memperoleh tingkat konkurensi yang lebih tinggi dengan peningkatan biaya Xact’s exposure pada perubahan-perubahah Xacts’ yang uncommitted lainnya (lihat tabel di bawah) : Level Dirty Read Unrepeatable Read Phantom READ UNCOMMITTED Maybe READ COMMITTED No REPEATABLE READ SERIALIZABLE (highest degree)

Pengantar Crash Recovery Recovery Manager dari DBMS bertanggung jawab untuk menjamin properti transaksi berikut: Atomicy dengan cara membatalkan (undo) tindakan-tindakan dari Xacts yang tidak commit Durability dengan menjamin bahwa semua tindakan Xacts yang uncommitted dapat menyelematkan system crashes dan kegagalan media Transaction Manager dari DBMS bertanggung jawab untuk mengendalikan eksekusi dari Xacts: Locks harus diperoleh (dan dilepas pada beberapa saat yang akan datang) sebelum pembacaan dan penulisan objek selama eksekusi normal Sistem hrs mempertimbangkan bhw selagi melakukan tindakan penulisan suatu page ke disk, crash dpt terjadi; sehingga beberapa tindakan harus diambil selama proses “restart” setelah terjadinya “crash” untuk menjamin bahwa tindakan penulisan terkini (the most recent write) suatu page dpt diselesaikan dengan sukses

Pencurian Frames & Pemaksaan Pages Pendekatan pencurian (steal) digunakan bilamana perubahan-perubahan pada suatu objek dalam buffer pool oleh sebuah transaksi T diperbolehkan untuk dituliskan ke disk sebelum T melakukan tindakan commit. Pendekatakan pemaksaan (force) digunakan bilamana sebuah transaksi melakukan tindakan commit, dimana semua perubahan yang dilakukan terhadap object dalam buffer pool dengan segera dipaksa dituliskan ke disk Dari sudut pandang implementasi dari recovery manager, kebnyakan sistem menggunakan pendekatan “steal, no-force”. Dalam pendekatan ini: Jika sebuah frame berstatus dirty dan dipilih untuk diganti, maka page yang dikandungnya dituliskan ke disk walau jika Xact yang diubah masih berstatus aktif (steal), dan Pages dalam buffer pool yang diubah oleh Xact dipaksa dituliskan ke disk bilamana Xact melakukan tindakan commit (no-force)

Recovery-Related Steps selama Eksekusi Normal Recovery manager dari DBMS hrs memelihara “log” dari semua perubahan-perubahan yang dilakukan terhadap database selama eksekusi normal dari Xacts utk memungkinkan recovery manager melakukan tugasnya pada saat kegagalan terjadi. Log hrs disimpan pada stable storage, yang dijamin utk menyelematkan crashes dan kegagalan media Stable storage dpt diimplementasikan dengan memelihara multiple copies dari informasi (mungkin dalam lokasi-lokasi yang berbeda) pada peralatan non-volatile seperti disks atau tapes Log entries yang menjelaskan perubahan database ditulis sebelum perubahan dilakukan (Write-Ahead Log, WAL property) Jumlah pekerjaan yang dilibatkan selama proses recovery proporsional dg perubahan-perubahan yang dibuat oleh committed Xacts yang belum dituliskan ke disk pada saat crash terjadi. Waktu yang diperlukan untuk melakukan recovery dapat dikurangi dengan: Secara periodik DBMS memaksa menuliskan buffer pages ke disk selama eksekusi normal menggunakan background process Menggunakan metode checkpointing (lihat Ramakrishnan, Chap. 18), yang akan menyimpan informasi mengenai active Xacts dan dirty buffer pool pages

Memulihkan Kembali dari Crash Terdapat 3 fase dalamalgoritma recovery Aries : Analysis: Scan the log forward (dari checkpoint terkini) utk mengidentifikasi semua Xacts yang aktif, dan semua dirty pages dalam buffer pool pada saat crash terjadi. Redo: Redoes semua tindakan updates pada dirty pages dalam buffer pool, sesuai dengan kebutuhan, utk menjamin bahwa semua “logged updates” telah dilakukan dan dituliskan ke disk. Undo: Semua tindakan penulisan dari Xacts yang aktif pada saat terjadi crash dibatalkan (undo) (dengan menyimpan kembali nilai sebelum update, yang ada dalam log record untuk update), dengan catra bekerja dalam arah backwards dalam log. (Kehati-hatian harus dilakukan untuk menangani kasus crash yang terjadi selama proses recovery berlangsung !)

Rangkuman Concurrency control dan recovery merupakan fungsi-fungsi yang sangat penting yang harus disediakan oleh sebuah are DBMS. Users perlu memahami mengenai concurrency. Sistem secara otomatis akan menyisipkan permintaan lock/unlock dan menskedul tindakan-tindakan dari beberapa Xacts yang berbeda sedemikian rupa sehingga eksekusi yang dihasilkan ekivalen dengan eksekusi Xacts secara satu per satu dalam urutan tertentu. Write-ahead logging (WAL) digunakan untuk membatalkan (undo) tindakan-tindakan transaksi yang digugurkan dan untuk menyimpan kembali (restore) sistem pada keadaan yang konsisten setelah terjadinya crash. Keadaan yang konsisten (consistent state) : Hanya pengaruh-pengaruh dari “commited Xacts” yang terlihat.