Manajemen Transaksi & Kontrol Konkurensi Pertemuan Minggu Ke-12

Kompetensi Khusus Mahasiswa mampu menerapkan keamanan dan administrasi database menggunakan MySQL (C3)

Transaksi Dalam istilah database, transaksi adalah aksi membaca dari atau menulis ke database. Transaksi dapat mencakup: Pernyataan SELECT untuk menampilkan isi tabel Pernyataan UPDATE untuk mengubah nilai atribut dalam tabel Pernyataan INSERT untuk menambah baris ke 1 atau lebih tabel Kombinasi dari pernyataan SELECT, UPDATE, & INSERT Jadi transaksi adalah pekerjaan yang harus sepenuhnya diselesaikan atau dibatalkan. Transaksi yang berhasil tetap menghasilkan kondisi database yang konsisten (dimana semua batasan integritas data terpenuhi). Transaksi database biasanya dibentuk oleh 2 atau lebih permintaan database berupa pernyataan SQL dalam program aplikasi. Jika salah satu permintaan dari transaksi gagal dieksekusi maka database akan berada dalam kondisi tidak konsisten & tidak dapat digunakan untuk transaksi berikutnya. DBMS yang mendukung manajemen transaksi akan membalikkan database ke kondisi konsisten sebelumnya.

Properti Transaksi Atomicity: semua operasi (permintaan SQL) dari transaksi harus diselesaikan; jika tidak maka transaksi dibatalkan. Consistency: ketika transaksi diselesaikan, database harus dalam kondisi konsisten; jika ada bagian transaksi yang melanggar batasan integritas maka seluruh transaksi dibatalkan. Isolation: data yang digunakan selama eksekusi transaksi tidak dapat digunakan oleh transaksi kedua sampai transaksi pertama selesai. Berguna dalam database multiuser karena beberapa user dapat mengakses & mengupdate database pada waktu yang sama. Durability: memastikan bahwa ketika perubahan transaksi dilakukan & dicommit, maka tidak dapat dibatalkan atau dihilangkan, bahkan ketika terjadi kegagalan sistem. Serializability: memastikan bahwa jadwal untuk eksekusi konkurensi dari transaksi menghasilkan hasil yang konsisten. Penting dalam database multiuser & terdistribusi dimana terdapat beberapa transaksi yang dieksekusi sekaligus.

Manajemen Transaksi dengan SQL ANSI (The American National Standards Institute) mendefinisikan standar yang mengawal transaksi database SQL. Standar tersebut menyebutkan ketika serangkaian transaksi diberikan oleh user atau program aplikasi, maka urutan tersebut harus dieksekusi terus sampai salah satu dari 4 kejadian berikut ini muncul: Adanya pernyataan COMMIT yang mengakhiri transaksi SQL. Adanya pernyataan ROLLBACK yang membatalkan semua perubahan & database dibalikkan ke kondisi konsisten sebelumnya. Akhir dari program tercapai dimana semua perubahan tersimpan dalam database (sama dengan COMMIT). Program diberhentikan dimana semua perubahan dibatalkan & database dibalikkan ke kondisi konsisten sebelumnya (sama dengan ROLLBACK).

Log Transaksi DBMS menggunakan log transaksi untuk menelusuri semua transaksi yang mengupdate database. DBMS menggunakan informasi yang tersimpan dalam log ini untuk pemulihan yang dipicu oleh perintah ROLLBACK, program diberhentikan, atau kegagalan sistem seperti terputusnya jaringan atau tabrakan disk.

Log transaksi menyimpan: Record untuk awal transaksi. Untuk tiap komponen transaksi (pernyataan SQL): Jenis operasi yang dijalankan (INSERT, UPDATE, DELETE). Nama objek yang dipengaruhi oleh transaksi (nama tabel). Nilai sebelum & sesudah untuk field yang diupdate. Pointer ke entri log transaksi sebelumnya & selanjutnya untuk transaksi yang sama. Akhir dari transaksi (COMMIT). Walaupun penggunaan log transaksi meningkatkan overhead pemrosesan dari DBMS, tetapi sebanding dengan kemampuannya untuk memulihkan database yang korup.

Log Transaksi

Kontrol Konkurensi Kontrol konkurensi adalah pengaturan dari eksekusi transaksi yang berkelanjutan dalam sistem database multiuser. Tujuan dari kontrol konkurensi adalah untuk memastikan serializability dari transaksi dalam lingkungan multiuser. Tiga masalah utama: lost updates, uncommitted data, & inconsistent retrievals.

Lost Updates Muncul ketika 2 transaksi konkuren, T1 & T2 mengupdate elemen data yang sama & salah satu update hilang (ditimpa oleh transaksi lain). Contoh ilustrasi pada tabel PRODUCT: Asumsikan nilai produk (PROD_QOH) adalah 35. Terdapat 2 transaksi, T1 & T2, muncul & mengupdate nilai PROD_QOH. T1 menambah 100 unit sementara T2 mengurangi 30 unit ke nilai PROD_QOH.

Eksekusi Berurutan dari 2 Transaksi Masalah Lost Updates

Uncommitted Data Muncul ketika 2 transaksi, T1 & T2, dieksekusi secara bersamaan & transaksi pertama (T1) dibalikkan setelah transaksi kedua (T2) mengakses data yang tidak dicommit – sehingga melanggar properti isolation dari transaksi.

Eksekusi yang Benar dari 2 Transaksi Masalah Uncommitted Data

Inconsistent Retrievals Muncul ketika transaksi mengakses data sebelum & sesudah 1 atau lebih transaksi lain yang selesai menggunakan data tersebut. Contoh jika transaksi TI menghitung fungsi summary (aggregate) pada serangkaian data sementara transaksi lain (T2) mengupdate data yang sama. Masalahnya transaksi mungkin membaca beberapa data sebelum diubah & beberapa data setelah diubah, sehingga menghasilkan hasil yang salah.

Pengambilan Data selama Update Masalah Inconsistent Retrievals

Scheduler Scheduler adalah proses DBMS khusus yang membuat urutan eksekusi operasi dalam transaksi konkuren. Scheduler meng-interleave eksekusi dari operasi database untuk memastikan serializability & isolation dari transaksi. Untuk menentukan urutan yang benar, scheduler melakukan aksinya berdasarkan algoritma kontrol konkurensi, seperti metode locking atau timestamping.

Matriks Operasi Database yang Bertentangan Hasil Operasi Read No conflict Write Conflict

Kontrol Konkurensi dengan Metode Locking Lock menjamin penggunaan item data secara eksklusif untuk transaksi yang sedang berjalan. Transaksi mengunci data yang diakses; lock akan dilepas ketika transaksi selesai sehingga transaksi lain dapat mengunci item data untuk digunakan. Penggunaan lock berdasarkan asumsi bahwa konflik antar transaksi mungkin muncul disebut dengan pessimistic locking. Semua informasi lock ditangani oleh lock manager, yang bertanggung jawab untuk memberikan & mengatur lock yang digunakan oleh transaksi.

Lock granularity menandakan tingkat dari penggunaan lock, yang tdd: Database  seluruh database dikunci, sehingga mencegah penggunaan tabel dalam database oleh transaksi T2 sementara transaksi T1 dieksekusi. Sesuai untuk proses batch, tetapi tidak sesuai untuk DBMS multiuser. Tabel  seluruh tabel dikunci, mencegah akses ke baris oleh transaksi T2 sementara transaksi T1 sedang menggunakan tabel. Akan tetapi, 2 transaksi dapat mengakses database yang sama selama mereka mengakses tabel yang berbeda. Tidak sesuai untuk DBMS multiuser. Halaman  DBMS mengunci seluruh diskpage. Diskpage atau page atau diskblock, yang dapat dideskripsikan sebagai bagian yang dapat dialamatkan langsung dari disk. Paling banyak digunakan untuk DBMS multiuser.

Baris  DBMS mengizinkan transaksi konkuren untuk mengakses baris yang berbeda dari tabel yang sama walaupun baris tersebut berada di halaman yang sama. Membutuhkan overhead yang tinggi karena kunci diberikan untuk tiap baris. Field  transaksi konkuren dapat mengakses baris yang sama selama mereka menggunakan field (atribut) yang berbeda dalam baris tersebut. Paling fleksibel untuk akses data multiuser tetapi jarang diimplementasikan dalam DBMS karena membutuhkan overhead yang sangat tinggi.

Lock Tingkat Database

Lock Tingkat Tabel

Lock Tingkat Halaman

Lock Tingkat Baris

Selain tingkat locking, DBMS dapat menggunakan beberapa jenis lock: Binary  memiliki 2 kondisi yaitu locked atau unlocked. Setiap transaksi akan mengunci objek yang digunakan & melepas objek tersebut setelah transaksi berakhir. Shared/ Exclusive  shared lock diberikan ketika transaksi ingin membaca data dari database & tidak ada exclusive lock pada item data tersebut. Sementara exclusive lock diberikan ketika transaksi ingin mengupdate atau menulis item data & item data tidak dikunci oleh transaksi lain. Jadi lock memiliki 3 kondisi yaitu unlocked, shared (read), & exclusive (write). Mutual exclusive rule : hanya 1 transaksi pada 1 waktu yang dapat melakukan exclusive lock pada objek.

Contoh Binary Lock

Lock dapat menyebabkan 2 masalah berikut: Walaupun penggunaan shared lock memberikan akses data yang lebih efisien, tapi shared/ exclusive lock meningkatkan overhead lock manager untuk alasan berikut: Jenis lock harus diketahui sebelum lock diberikan. Terdapat 3 operasi lock: READ_LOCK untuk memeriksa jenis lock, WRITE_LOCK untuk mengunci, & UNLOCK untuk melepas kunci. Adanya izin untuk mengupgrade lock dari shared ke exclusive & mendowngrade dari exclusive ke shared. Lock dapat menyebabkan 2 masalah berikut: Jadwal transaksi mungkin tidak serializable  dapat diatasi dengan two-phase locking. Terjadi deadlock yang muncul ketika 2 transaksi menunggu satu sama lain untuk melepas kunci data  dapat diatasi dengan teknik deteksi & pencegahan deadlock.

Two Phase Locking Mendefinisikan bagaimana transaksi memperoleh & melepaskan kunci. Menjamin serializability tetapi tidak mencegah deadlock. Terdiri dari 2 tahap yaitu: Growing phase  transaksi memperoleh semua kunci yang diperlukan tanpa melepas kunci data apapun. Setelah semua kunci diperoleh, transaksi berada dalam posisi terkunci. Shrinking phase  transaksi melepaskan semua kunci & tidak dapat memperoleh kunci baru. Dikendalikan oleh aturan berikut: Dua transaksi tidak dapat memiliki kunci yang saling bertentangan. Tidak ada operasi unlock yang dapat mendahului operasi lock dalam transaksi yang sama. Tidak ada data yang diproses sampai semua kunci diperoleh – yaitu sampai transaksi berada dalam posisi terkunci.

Protokol Two Phase Locking

Teknik Pengendalian Deadlock Deadlock prevention  transaksi yang meminta kunci baru dibatalkan ketika terdapat kemungkinan terjadinya deadlock. Jika transaksi dibatalkan, semua perubahan yang dilakukannya akan dibalikkan & semua kunci akan dilepas. Transaksi ini kemudian dijadwalkan ulang untuk eksekusi. Direkomendasikan jika kemungkinan terjadinya deadlock tinggi. Deadlock detection  DBMS menguji database secara berkala untuk deadlock. Jika deadlock ditemukan, maka transaksi korban dibatalkan & transaksi lain dilanjutkan. Direkomendasikan jika kemungkinan terjadinya deadlock rendah. Deadlock avoidance  transaksi harus mendapatkan semua kunci yang dibutuhkan sebelum dieksekusi. Teknik ini menghindari pembatalan dari transaksi yang bertentangan dengan mendapatkan lock agar berhasil. Direkomendasikan jika waktu respon rendah pada daftar prioritas sistem.

Proses Terjadinya Deadlock

Kontrol Konkurensi dengan Metode Timestamping Pendekatan timestamping memberikan timestamp unik untuk tiap transaksi. Nilai timestamp menghasilkan urutan dimana transaksi diberikan ke DBMS. Timestamp harus memiliki 2 properti: Keunikan memastikan tidak ada nilai timestamp yang sama. Monotonicity memastikan nilai timestamp selalu meningkat. Semua operasi database (baca & tulis) dalam transaksi yang sama harus memiliki timestamp yang sama. DBMS mengeksekusi operasi yang bertentangan dalam urutan timestamp, sehingga memastikan serializability dari transaksi. Jika 2 transaksi bertentangan, satu dihentikan, dibalikkan, dijadwal ulang, & diberikan nilai timestamp baru. Kekurangannya dalah tiap nilai yang disimpan dalam database membutuhkan 2 field timestamp tambahan: 1 untuk terakhir kali field dibaca & 1 untuk update terakhir. Timestamp juga meningkatkan kebutuhan memori & overhead pemrosesan database.

Skema Wait/ Die & Wound/ Wait Dalam skema wait/ die: Jika transaksi yang meminta kunci adalah yang tertua dari 2 transaksi, maka ia akan menunggu (wait) sampai transaksi lain selesai & kunci dilepas. Jika transaksi yang meminta kunci adalah yang termuda dari 2 transaksi, maka ia akan dibatalkan (die) & dijadwalkan ulang menggunakan timestamp yang sama. Singkatnya, transaksi yang lebih tua menunggu yang lebih muda untuk selesai & melepas kuncinya. Dalam skema wound/ wait: Jika transaksi yang meminta kunci adalah yang tertua dari 2 transaksi, maka ia akan mendahului (wound) transaksi yang lebih muda dengan membatalkannya. Jika transaksi yang meminta kunci adalah yang termuda dari 2 transaksi, maka ia akan menunggu sampai transaksi lain selesai & kunci dilepas. Singkatnya, transaksi yang lebih tua membatalkan & menjadwalkan ulang transaksi yang lebih muda.

Skema Wait/ Die & Wound/ Wait

Kontrol Konkurensi dengan Metode Optimistik Metode optimistik berdasarkan pada asumsi bahwa kebanyakan operasi database tidak bertentangan. Pendekatan ini tidak membutuhkan teknik locking atau timestamp. Akan tetapi, transaksi dieksekusi tanpa larangan sampai dicommit. Pendekatan ini melalui 2 atau 3 tahap: Selama tahap read, transaksi membaca database, mengeksekusi komputasi yang dibutuhkan, & membuat update salinan pribadi dari nilai database. Semua operasi update dari transaksi dicatat dalam sebuah file update sementara, yang tidak diakses oleh transaksi yang tersisa. Selama tahap validation, transaksi divalidasi untuk memastikan bahwa perubahan yang dibuat tidak mempengaruhi integritas & konsistensi dari database. Jika uji validasi positif, transaksi lanjut ke tahap write. Jika uji validasi negatif, transaksi diulang & perubahan dibuang. Selama tahap write, perubahan disimpan secara permanen ke database.

Manajemen Pemulihan Database Pemulihan database mengembalikan database ke kondisi konsisten sebelumnya. Teknik pemulihan berdasarkan pada properti transaksi atomic: semua porsi dari transaksi harus diperlakukan sebagai unit kerja tunggal dimana semua operasi diaplikasikan & diselesaikan untuk menghasilkan database yang konsisten. Berikut beberapa contoh kejadian yang dapat menghentikan kerja database: Kegagalan hardware/ software Insiden yang disengaja atau tidak disengaja oleh manusia Bencana alam

Pemulihan Transaksi Berikut 4 konsep yang mempengaruhi proses pemulihan Write-ahead-log protocol: memastikan log transaksi selalu ditulis sebelum data database diupdate. Jika terjadi kegagalan, maka database dapat dipulihkan menggunakan data dalam log transaksi. Redundant transaction logs (beberapa salinan dari log transaksi): memastikan kegagalan disk fisik tidak mengganggu kemampuan DBMS untuk memulihkan data. Database buffers: area penyimpanan sementara dalam memori utama yang digunakan untuk mempercepat operasi disk. Database checkpoints: operasi dimana DBMS menulis semua buffer yang diperbaharui ke disk. DBMS tidak mengeksekusi permintaan lainnya ketika ini terjadi. Operasi checkpoint juga didaftarkan dalam log transaksi. Hasilnya, database fisik & log transaksi akan sinkron.

Prosedur pemulihan transaksi menggunakan teknik deferred-write atau write-through. Teknik deferred-write (deferred update) tidak mengupdate operasi transaksi secara langsung ke database fisik tetapi hanya mengupdate log transaksi. Database akan diupdate setelah transaksi mencapai posisi commit, menggunakan informasi dari log transaksi. Sebaliknya jika transaksi dibatalkan sebelum mencapai posisi commit, maka tidak ada perubahan yang dibalikkan karena database belum diupdate. Teknik write-through (immediate update) mengupdate operasi transaksi langsung ke database selama eksekusi transaksi, bahkan sebelum transaksi mencapai posisi commit. Jika transaksi dibatalkan sebelum mencapai posisi commit, maka operasi ROLLBACK atau undo dilakukan untuk mengembalikan database ke kondisi konsisten. Operasi ROLLBACK menggunakan nilai sebelum pada log transaksi.

Contoh Log Transaksi untuk Pemulihan Transaksi

Review Materi Mahasiswa mengerjakan tugas yang ada di portal.