peng konkurensi

39
1 PENGONTROLAN KONKURENSI & RECOVERY Bertalya Program SARMAG, Universitas Gunadarma 2008

Upload: unsika

Post on 30-Jun-2015

322 views

Category:

Documents


8 download

TRANSCRIPT

Page 1: Peng konkurensi

1

PENGONTROLAN KONKURENSI & RECOVERY

Bertalya

Program SARMAG, Universitas Gunadarma2008

Page 2: Peng konkurensi

2

ALASAN PENGONTROLAN KONKURENSI

Lebih dari satu pengguna (pada DBMS terpusat) dapat melakukan operasi pada basis data secara simultan

Jika tidak dikontrol, hal ini dapat menyebab kan interferensi satu sama lain sehingga basis data menjadi tidak konsisten

Untuk mencegahnya, DBMS mengimple-mentasikan pengontrolan konkurensi

Page 3: Peng konkurensi

3

TRANSAKSI

Merupakan suatu aksi atau serangkaian aksi, dilakukan oleh seorang pengguna atau program aplikasi, yang mengakses atau mengubah konten basis data

Mentransformasikan basis data dari suatu keadaan konsisten ke yg lain.

Contoh: Perintah INSERT atau UPDATE Serangkaian operasi pada basis data

Page 4: Peng konkurensi

4

DUA OUTCOME DARI TRANSAKSI

1. COMMITJika operasi berjalan sukses, maka transaksi disebut commited ,basis data mencapai kondisi konsisten yg

baru

Page 5: Peng konkurensi

5

DUA OUTCOME DARI TRANSAKSI (lanj.)

2. ABORTJika operasi berjalan tidak sukses, maka

transaksi disebut aborted (gagal)

Jika transaksi gagal maka basis data kembali ke keadaan konsisten sebelum transaksi dimulai.

Disebut roll back atau undone

Page 6: Peng konkurensi

6

PERNYATAAN TRANSAKSI DALAM DBMS

BEGIN TRANSACTION

COMMIT

ROLLBACK

Page 7: Peng konkurensi

7

PROPERTI TRANSAKSI (ACID)

ATOMICITYProperti ‘semua atau tidak sama sekali’.Transaksi dilaksanakan keseluruhan atau tidak dilaksanakan sama sekali.

CONSISTENCYTransaksi harus mentransformasikan basis data dari kondisi konsisten ke kondisi konsisten lain

Page 8: Peng konkurensi

8

PROPERTI TRANSAKSI (ACID) (lanj.)

INDEPENDENCETransaksi dieksekusi berdiri sendiri.Efek dari transaksi yg tidak selesai tidak terlihat pada transaksi lain.

DURABILITYEfek transaksi yg sukses secara permanen disimpan dalam basis data.

Page 9: Peng konkurensi

9

DEF. PENGONTROLAN KONKURENSI

Proses pengelolaan operasi pada basis data secara simultan tanpa saling berinterferensi satu sama lain

Pengaksesan konkuren yg hanya membaca data, tidak akan saling ber-interferensi, tetapi apabila ada yg mengupdate data, akan saling berinterferensi & menyebabkan terjadi ketidakkonsistenan.

Page 10: Peng konkurensi

10

3 MASALAH KONKURENSI

1. Lost update (modifikasi yg hilang)Masalah operasi update yg sukses dari seorang pengguna kemudian ditimpali oleh operasi update dari pengguna lain

2. Uncommited dependency (ketergantung an yg tidak sukses/modifikasi sementara)

Masalah terjadi saat suatu transaksi membaca data dari transaksi lain yg belum dicommit

3. Inconsistent analysisMasalah terjadi saat satu transaksi membaca beberapa nilai tetapi transaksi kedua pd waktu sama memodifikasi nilai tersebut.

Page 11: Peng konkurensi

11

MASALAH MODIFIKASI YANG HILANG

Page 12: Peng konkurensi

12

MASALAH MODIFIKASI SEMENTARA

Page 13: Peng konkurensi

13

MASALAH ANALISIS YG TIDAK KONSISTEN

Page 14: Peng konkurensi

14

OBJEKTIF PENGONTROLAN KONKURENSI

Penjadualan transaksi untuk mencegah adanya saling interferensi.

Hanya satu transaksi dieksekusi pada satu waktu : satu transaksi di-commit sebelum transaksi lain diperkenankan untuk mulai.

Transaksi dapat dilakukan pada sistem paralel, dengan cara penjadualan bersama.

Page 15: Peng konkurensi

15

SERIALIZABILITY Schedule atau jadual merupakan urutan dari

operasi read & write secara bersamaan pada sekumpulan transaksi yg konkuren.

Serial schedule merupakan jadual dimana operasi2 setiap transaksi dieksekusi secara berurutan tanpa terselip operasi dari transaksi lain

Nonserial schedule merupakan jadual dimana operasi2 dari sekumpulan transaksi konkuren dapat saling menyelip.

Serializable berarti jika jadual (nonserial) menghasilkan hasil yg sama seperti halnya jadual serial lainnya

Page 16: Peng konkurensi

16

SERIALIZABILITY (lanj.)

Urutan operasi sangat penting Jika 2 transaksi hanya melakukan operasi read

data, maka tidak terjadi konflik & urutan operasi tidak penting

Jika 2 transaksi melakukan operasi read & write pada data yg berbeda, maka tidak terjadi konflik & urutan operasi tidak penting

Jika satu transaksi melakukan operasi write data & yg lain melakukan operasi read & write pada data yg sama, maka urutan eksekusi sangat penting

Page 17: Peng konkurensi

17

METODE UNTUK MENJAMIN SERIALIZABILITY

1. LOCKING 2. TIMESTAMPING

Keduanya konservatif (pesimistik) karena transaksi ditunda untuk mencegah konflik dg transaksi lain di waktu kemudian.

METODE OPTIMISTICBerasumsi bhw konflik jarang terjadi sehingga proses tetap berjalan & pengecekan dilakukan pada saat transaksi sudah di-commit

Page 18: Peng konkurensi

18

METODE LOCKING

Prosedur untuk mengontrol pengaksesan data secara konkuren.

Apabila satu transaksi mengakses basis data, suatu lock (kunci) akan menolak pengaksesan transaksi lain utk mencegah modifikasi yg tidak benar

Page 19: Peng konkurensi

19

2 KUNCI

1. Kunci READ / S (digunakan bersama)Jika transaksi mempunyai kunci read terhadap suatu data, maka dia dapat melakukan operasi read tetapi tidak dapat melakukan operasi update terhadap data tsb.

2. Kunci WRITE / X (eksklusif)Jika transaksi mempunyai kunci write terhadap suatu data, maka dia dapat melakukan operasi read maupun operasi update terhadap data tsb.

Page 20: Peng konkurensi

20

ATURAN LOCKING

Transaksi yg akan mengakses suatu data harus terlebih dahulu menguncinya, meminta kunci S jika hanya melakukan read data saja atau kunci X jika untuk melakukan operasi read & write.

Jika data tsb belum dikunci oleh transaksi apapun, maka kunci diperkenankan.

Page 21: Peng konkurensi

21

ATURAN LOCKING (lanj.)

Jika data tsb telah dikunci, maka DBMS menentukan apakah kunci yg diminta sesuai dg yg ada. Jika kunci read yg diminta sama dengan kunci read yg telah ada, maka permintaan diperkenankan, selain itu maka transaksi harus menunggu (wait) sampai kunci write dilepaskan.

Transaksi terus menahan suatu kunci sampai dilepaskan secara eksplisit selama eksekusi atau telah selesai.

Page 22: Peng konkurensi

22

Matriks LOCKING

Page 23: Peng konkurensi

23

PROTOKOL TWO-PHASE LOCKING (2PL)

Protokol untuk menjamin serializability

Suatu transaksi mengikuti protokol Two-phase locking jika semua operasi penguncian mendahului operasi membuka kunci terlebih dahulu dalam suatu transaksi.

Page 24: Peng konkurensi

24

Phase 1: Growing PhaseTransaksi dapat memperoleh kunci Transaksi tidak boleh melepaskan kunci

Phase 2: Shrinking PhaseTransaksi boleh melepaskan kunciTransaksi tidak dapat memperoleh kunci

Page 25: Peng konkurensi

25

2PL UNTUK MASALAH KEHILANGAN MODIFIKASI

Page 26: Peng konkurensi

26

2PL UNTUK MASALAH MODIFIKASI SEMENTARA

Page 27: Peng konkurensi

27

2PL UNTUK MASALAH ANALISIS YANG TIDAK KONSISTEN

Page 28: Peng konkurensi

28

DEADLOCK

Suatu situasi dimana dua atau lebih transaksi masing2 menunggu (wait) suatu kunci yg ditahan oleh transaksi lain, untuk dilepaskan.

2 teknik menangani deadlock1. deadlock prevention, DBMS mengamati transaksi

apakah menimbulkan deadlock & tidak akan membiarkan deadlock terjadi

2. Deadlock prevention and recovery, DBMS membiarkan terjadi deadlock, mengenalinya lalu menanganinya.

Page 29: Peng konkurensi

29

TRANSAKSI DEADLOCK

Page 30: Peng konkurensi

30

METODE TIMESTAMPING

Timestamp, merupakan suatu identifikasi unik dibuat DBMS yg mengindikasikan waktu mulai relatif dari suatu transaksi.

Dengan waktu sistem atau penambahan pada kounter logik setiap waktu transaksi mulai.

Suatu protokol yg menyusun transaksi2 secara global, dimana transaksi yg tertua, transaksi dg timestamp terkecil, mendapat prioritas utama dari konflik transaksi tsb.

Page 31: Peng konkurensi

31

METODE OPTIMISTIC

Berbasis pada asumsi bahwa pada lingkungan tertentu, jarang terjadi konflik, sehingga lebih efisien membiarkan transaksi dieksekusi.

Kemudian pada saat akan di-commit, diidentifikasi apakah akan timbul konflik, jika ya maka transaksi harus di rollback atau di proses ulang.

Page 32: Peng konkurensi

32

PENGONTROLAN RECOVERY

Recovery basis data merupakan suatu proses penyimpanan kembali basis data pada keadaan yang benar sebelum terjadi kegagalan(failure).

Page 33: Peng konkurensi

33

PENYEBAB KEGAGALAN

System crash (kerusakan sistem), akibat kesalahan pada perangkat keras atau lunak, menyebabkan kehilangan memori utama

Media failure (kegagalan pada media), seperti media tidak dapat dibaca, menyebabkan kehilangan sebagian dari penyimpanan sekunder

Application software error (kesalahan pada perangkat lunak aplikasi, seperti kesalahan logika yg mengakses basis data menyebab kan satu atau lebih transaksi mengalami kegagalan

Page 34: Peng konkurensi

34

AKIBAT YG TIMBUL KRN KESALAHAN (lanj.)

Natural physical disasters (bencana fisik yg natural), seperti kebakaran, air bah, gempa

Carelessness (kekurangtelitian atau kerusakan pada data atau fasilitas yg tidak disengaja disebabkan oleh operator atau pengguna

Sabotase, kerusakan pada data, fasilitas perangkat lunak & keras yg disengaja

Page 35: Peng konkurensi

35

FASILITAS RECOVERY PADA DBMS Mekanisme backup

melakukan backup secara periodik terhadap basis data yang ada

Fasilitas LoggingMencatat transaksi-transaksi dan perubahan-perubahan yang terjadi terhadap basis data. DBMS memelihara file khusus yang disebut Log (Journal) yang menyediakan informasi mengenai seluruh perubahan yang terjadi pada basis data.

Fasilitas Checkpoint Mengizinkan update terhadap basis data yang akan menjadi basis data yang permanen

Manager recoveryMengizinkan sistem untuk menyimpan kembali basis data ke keadaan sebelum terjadi kegagalan

Page 36: Peng konkurensi

36

TEKNIK RECOVERY

Prosedur recovery yang digunakan tergantung dari kegagalan yang terjadi pada basis data. Terdapat 2 kasus kerusakkan :

1. Jika basis data rusak secara fisik seperti : disk head crash dan menghancurkan basis data, maka yang terpenting adalah melakukan menyimpan kembali backup basis data yang terakhir dan mengaplikasikan kembali operasi-operasi update transaksi yang telah commit dengan menggunakan log file. Dengan asumsi bahwa log file-nya tidak rusak.

Page 37: Peng konkurensi

37

TEKNIK RECOVERY (lanj.)

2. Jika basis data tidak rusak secara fisik tetapi menjadi tidak konsisten, sebagai contoh : sistem crash sementara transaksi dieksekusi, maka yang perlu dilakukan adalah membatalkan perubahan-perubahan yang menyebabkan basis data tidak konsisten. Mengulang beberapa transaksi

sangat diperlukan juga untuk meyakinkan bahwa perubahan2 yang dilakukan telah disimpan di dalam secondory storage.

Di sini tidak perlu menggunakan salinan backup basis data, tetapi dapat me-restore basis data ke dalam keadaan yang konsisten dengan menggunakan before- dan after-image yang ditangani oleh log file.

Page 38: Peng konkurensi

38

TEKNIK RECOVERY (lanj.)

Teknik recovery berikut ini dilakukan terhadap situasi dimana basis data tidak rusak tetapi basis data dalam keadaan yang tidak konsisten.

1. Deferred UpdateUpdate tidak dituliskan ke basis data sampai sebuah transaksi dalam keadaan commit. Jika transaksi gagal sebelum mencapai keadaan ini, transaksi ini tidak akan memodifikasi basis data dan juga tidak ada perubahan2 yang perlu dilakukan.

Page 39: Peng konkurensi

39

Penulisan dilakukan secara initial hanya terhadap log dan log record yang digunakan untuk actual update terhadap basis data. Jika sistem gagal, sistem akan menguji log dan menentukan transaksi mana yang perlu dikerja kan ulang, tetapi tidak perlu membatalkan semua transaksi.

2. Immediate UpdateUpdate diaplikasikan terhadap basis data tanpa harus menunggu transaksi dalam keadaan commit. Update dapat dilakukan terhadap basis data setiap saat setelah log record ditulis. Log dapat digunakan untuk membatalkan dan mengulang kembali transaksi pada saat terjadi kegagalan.