{"id":986,"date":"2017-09-16T12:11:20","date_gmt":"2017-09-16T05:11:20","guid":{"rendered":"http:\/\/binus.ac.id\/malang\/?p=986"},"modified":"2017-10-20T14:23:02","modified_gmt":"2017-10-20T07:23:02","slug":"serializability-dan-recoverability","status":"publish","type":"post","link":"https:\/\/binus.ac.id\/malang\/2017\/09\/serializability-dan-recoverability\/","title":{"rendered":"Serializability dan Recoverability \u00a0"},"content":{"rendered":"

\"\"<\/p>\n

Tujuan protokol\u00a0concurrency control<\/em>\u00a0adalah untuk menjadwalkan transaksi sedemikian rupa sehingga dapat menghindar dari berbagai gangguan, dan juga mencegah tipe-tipe masalah yang digambarkan pada sesi sebelumnya. Satu solusi yang jelas adalah mengijinkan hanya satu transaksi yang berjalan dalam satu waktu. Satu transaksi berstatus commit sebelum transaksi berikutnya diijinkan mulai. Namun, tujuan dari DBMS\u00a0multi user<\/em>\u00a0juga untuk memaksimalkan derajat\u00a0concurrency<\/em>\u00a0atau paralelisme dalam sebuah sistem, sehingga transaksi yang dapat berjalan tanpa mengganggu satu sama lain dapat berjalan secara paralel. Contohnya, transaksi yang mengakses bagian berbeda pada database dapat dijadwalkan bersama tanpa gangguan. Dalam bagian ini, kita memeriksa\u00a0serializability<\/em>\u00a0sebagai sebuah cara untuk membantu mengidentifikasi eksekusi transaksi tersebut yang dijamin untuk memastikan konsistensi. Pertama, kita beri beberapa definisi.<\/p>\n

<\/a>Schedule<\/em><\/strong><\/p>\n

Schedule adalah sebuah urutan dari operasi-operasi oleh satu set transaksi yang jalan bersamaan yang menjaga urutan operasi pada setiap transaksi individual ( Connolly, 2005, p580 ). Sebuah transaksi mencakup sebuah urutan operasi yang terdiri dari tindakan baca dan\/atau tulis pada database, diikuti oleh sebuah tindakan\u00a0commit<\/em>\u00a0atau\u00a0abort<\/em>. Sebuah\u00a0schedule\u00a0<\/em>S terdiri dari sebuah urutan operasi dari sekumpulan n transaksi T1, T2, \u2026 Tn, bergantung pada constraint yang dilindungi oleh urutan operasi untuk setiap transaksi pada\u00a0schedule<\/em>\u00a0tersebut. Jadi, untuk setiap transaksi Ti pada\u00a0schedule<\/em>\u00a0S, urutan operasi pada Ti harus sama dengan schedule S.\u00a0Serial Schedule<\/em>\u00a0adalah sebuah\u00a0schedule<\/em>\u00a0di mana operasi dari setiap transaksi dijalankan secara berurutan tanpa adanya tarnsaksi yang mengganggu transaksi lainnya (Connolly, 2005, p580).\u00a0NonSerial Schedule\u00a0<\/em>adalah sebuah\u00a0schedule\u00a0<\/em>di mana operasi-operasi dari satu set\u00a0concurrent transactions\u00a0<\/em>mengalami\u00a0interleaved\u00a0<\/em>(Connolly, 2005, p580). Pada sebuah\u00a0serial schedule<\/em>, transaksi dijalankan pada serial order. Contohnya, jika kita mempunyai dua transaksi T1 dan T2, serial ordernya akan menjadi T1 diikuti oleh T2, atau T2 diikuti oleh T1. Lalu, pada eksekusi serial tidak ada interferensi antara transaksi, karena hanya satu transaksi yang berjalan pada satu waktu. Tujuan\u00a0serializibility\u00a0<\/em>adalah untuk menemukan non\u00a0serial schedule\u00a0<\/em>yang mengijinkan transaksi untuk berjalan secara bersamaan tanpa mengganggu satu sama lain, dan kemudian memproduksi sebuah state database yang dapat diproduksi oleh sebuah eksekusi serial. Jika sebuah set transaksi berjalan secara bersamaan, bisa dikatakan bahwa\u00a0schedule (nonserial)<\/em>\u00a0adalah benar jika memproduksi hasil yang sama seperti beberapa eksekusi serial lainnya.\u00a0Schedule\u00a0<\/em>seperti itu disebut\u00a0serializable<\/em>. Untuk mencegah inkonsistensi dari transaksi yang mengganggu satu sama lain, penting untuk menjamin\u00a0serializability<\/em>\u00a0dari transaksi yang jalan bersamaan.<\/p>\n

Pada\u00a0serializability<\/em>, urutan operasi baca dan tulis itu penting. Berikut ini hal \u2013 hal yang perlu diperhatikan:<\/p>\n