t02060030220124090pert15-16 - t0206

Transaction ManagementSession 15 - 16

Course Name : Database SystemYear : 2012

3

Chapter 22

Transaction Management

Pearson Education © 2009

4

Chapter 22 - Objectives

Function and importance of transactions. Properties of transactions. Concurrency Control

– Meaning of serializability.– How locking can ensure serializability.– Deadlock and how it can be resolved.– How timestamping can ensure

serializability.– Optimistic concurrency control.– Granularity of locking.


5

Chapter 22 - Objectives

Recovery Control– Some causes of database failure.– Purpose of transaction log file.– Purpose of checkpointing.– How to recover following database

failure. Alternative models for long duration transactions.


6

Transaction Support

Transaction

Sebuah aksi atau serangkaian aksi, yang dilakukan oleh user atau aplikasi yang mengakses atau mengubah isi dari database.

Atau dapat juga dikatakan sebagai unit kerja logical (Logical unit of work) dari suatu database

Program aplikasi merupakan serangkaian transaksi tanpa pengolahan database didalamnya.

Transaksi selalu merubah database dari satu stata konsisten ke stata lainnya, walaupun konsistensi data dapat terganggu selama transaksi berjalan.


7

Example Transaction


8

Example Transaction Contoh implementasi transaksi, misalkan transaksi transfer

uang sebesar $50 dari rekening A ke rekening B, maka transaksi tersebut dapat didefinisikan sebagai berikut :

1.read(A)2.A := A – 503.write(A)4.read(B)5.B := B + 506.write(B)


9

Transaction Support Akan mempunyai dua outcomes:

Sukses – transaksi dikatakan commited dan database mencapai stata baru/stata berikutnya.Gagal – transaksi dikatakan aborted, dan database harus dikembalikan ke stata tetap sebelum dilakukannya transaksi. Transaksi seperti ini disebut roll back atau undone

Transaksi yang committed tidak dapat digagalkan. Transaksi yang digagalkan akan dilakukan rollback

yang dapat diproses ulang (restarted) diwaktu mendatang


10

State Transition Diagram for Transaction


11

Properties of Transactions

4 sifat dasar dari transaksi (ACID, Haerder and Reuter, 1983) :

Atomicity(keutuhan)Transaksi merupakan unit yang tidak terlihat yang harus dilakukan secara keseluruhan atau tidak sama sekali.

Consistency (Ketetapan) Transaksi harus mengubah database dari satu stata konsisten ke stata lainnya/ berikutnya.

Isolation (Pemisahan)Transaksi dieksekusi secara terpisah dari yang satu dengan yang lainnya.

Durability (Daya tahan)Secara permanen direkam kedalam database dan tidak akan hilang dikarenakan kegagalan berikutnya.


12

DBMS Transaction Subsystem


13

Concurrency Control

Process of managing simultaneous operations on the database without having them interfere with one another.

Merupakan proses pengaturan operasi yang simultan pada database tanpa menyebabkan saling mempengaruhi antara satu dengan yang lain.

Akses konkuren tidak akan bermasalah jika user hanya melakukan pembacaan data saja, gangguan akan terjadi jika dua atau lebih user mengakses database secara simultan dan sedikitnya melakukan satu perubahan (update), maka dapat menyebabkan ketidak-konsistenan (inconsistencies)


14

Need for Concurrency Control

Terdapat 3 Masalah akibat concurrency :

Masalah kehilangan modifikasi (Lost Updates Problem)

Masalah modifikasi sementara (Uncommitted Dependency Problem)

Masalah analisa yang tidak konsisten (Inconsistent Analysis Problem)


15

Lost Update Problem

Update yang dilakukan oleh user pertama diubah oleh user yang lain.

Contoh diatas menerangkan hilangnya modifikasi yang dilakukan oleh T2. Kehilangan modifikasi ini dapat diatasi dengan mencegah T1 melakukan pembacaan data sebelum perubahan T2 selesai dilaksanakan.


16

Lost Update Problem

Successfully completed update is overridden by another user.

T1 withdrawing £10 from an account with balx, initially £100.

T2 depositing £100 into same account. Serially, final balance would be £190.


17

Lost Update Problem

Loss of T2’s update avoided by preventing T1 from reading balx until after update.


18

Uncommitted Dependency Problem

Masalah modifikasi sementara terjadi jika satu transaksi (transaksi pertama) membaca hasil dari transaksi lainnya (transaksi kedua) sebelum transaksi kedua dinyatakan committed.

Biasa dikenal dengan dirty read problem.


19


Contoh transaksi T4 merubah balx menjadi £200 tetapi digagalkan, sehingga balx harus dikembalikan ke nilai awal sebelum transaksi yaitu £100. Sedangkan transaksi T3 membaca nilai hasil modifikasi tadi yaitu, balx (£200) dan menguranginya dengan £10, sehingga memperoleh nilai akhir £190, yang seharusnya £90.

Masalah tersebut dapat dihindari Problem dengan mencegah T3 membaca balx sebelum T4 dinyatakan committed atau abort.

20


Occurs when one transaction can see intermediate results of another transaction before it has committed.

T4 updates balx to £200 but it aborts, so balx should be back at original value of £100.

T3 has read new value of balx (£200) and uses value as basis of £10 reduction, giving a new balance of £190, instead of £90.


21


Problem avoided by preventing T3 from reading balx until after T4 commits or aborts.


22

Inconsistent Analysis Problem

Terjadi ketika transaksi pertama membaca beberapa nilai tetapi transaksi kedua melakukan perubahan terhadap nilai tersebut selama eksekusi transaksi pertama berlangsung. – Contoh transaksi T6 menjumlahkan variable balx (£100),

baly (£50), dan balz (£25). Pada saat yang hampir bersamaan transaksi T5 memindahkan £10 dari balx ke balz, sehingga transaksi T6 mendapatkan hasil akhir yang salah (yaitu kelebihan £10).

Hal ini disebut dengan nonrepeatable ( or fuzzy) read.


23


Masalah tersebut dapat dihindari dengan mencegah transaksi T6 membaca balx dan balz sebelum transaksi T5 lengkap di-update.


24


Occurs when transaction reads several values but second transaction updates some of them during execution of first.

Sometimes referred to as dirty read or unrepeatable read.

T6 is totaling balances of account x (£100), account y (£50), and account z (£25).

Meantime, T5 has transferred £10 from balx to balz, so T6 now has wrong result (£10 too high).


25


Problem avoided by preventing T6 from reading balx and balz until after T5 completed updates.


26

Serializability

Sistem basis data harus dapat mengontrol eksekusi konkurensi dari suatu transaksi untuk memastikan database tetap terjaga konsistensinya.

Asumsi dasar, bahwa setiap transaksi harus tetap menjaga konsistensi database.

Eksekusi secara serial pada suatu transaksi dapat menjaga database tetap konsisten.

Sebuah jadwal (yang mungkin konkuren), serializable jika setara dengan penjadwalan secara serial. Pada bagian ini ada dua bentuk ekivalensi penjadwalan (Schedule Equivalence) : Conflict dan View Serializability.

Pada serializability kita abaikan operasi selain dari instruksi read dan write, serta diasumsikan bahwa transaksi dapat melakukan perhitungan terhadap data di dalam buffer lokal diantara instruksi read dan write.


27

Serializability

Scheduleadalah 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 commit atau abort.

Serial ScheduleSerial Schedule adalah sebuah schedule di mana operasi dari setiap transaksi dijalankan secara berurutan tanpa adanya tarnsaksi yang mengganggu transaksi lainnya (Connolly, 2005, p580).

No guarantee that results of all serial executions of a given set of transactions will be identical.


28

Serializability

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. )


29

Nonserial Schedule

NonSerial Schedule adalah sebuah schedule di mana operasi-operasi dari satu set concurrent transactions mengalami interleaved (Connolly, 2005, p580).

Tujuan serializibility adalah untuk menemukan non serial schedule 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 schedule (nonserial) adalah benar jika memproduksi hasil yang sama seperti beberapa eksekusi serial lainnya. Schedule seperti itu disebut serializable.


30

Serializability

Untuk mencegah inkonsistensi dari transaksi yang mengganggu satu sama lain, penting untuk menjamin serializability dari transaksi yang jalan bersamaan. Pada serializability, urutan operasi baca dan tulis itu penting. Berikut ini hal – hal yang perlu diperhatikan:

Jika dua transaksi hanya membaca satu item data yang sama, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting. Jika dua transaksi melakukan operasi membaca ataupun menulis pada item data yang berbeda, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting. Jika satu transaksi menulis sebuah item data dan transaksi lain baik membaca ataupun menulis pada item data yang sama, maka urutan eksekusi itu menjadi penting.

31

Example of Conflict Serializability


32

Conflict Serializability

Conflict serializable schedule orders any conflicting operations in same way as some serial execution.

Under constrained write rule (transaction updates data item based on its old value, which is first read), use precedence graph to test for serializability.


33

Precedence Graph

Create:– node for each transaction;

– a directed edge Ti Tj, if Tj reads the value of an item written by TI;

– a directed edge Ti Tj, if Tj writes a value into an item after it has been read by Ti.

If precedence graph contains cycle schedule is not conflict serializable.


34


Instruksi Ii dan Ij masing – masing dari transaksi Ti dan Tj , konflik jika dan hanya jika ada beberapa item data yang sama (Q) diakses secara bersama – sama baik oleh Ii dan Ij , serta setidaknya salah satu dari instruksi melakukan operasi write (Q).

1. Jika Ii = read(Q) dan Ij = read(Q), maka Ii dan Ij tidak konflik

2. Jika Ii = read(Q) dan Ij = write(Q), maka Ii dan Ij konflik

3. Jika Ii = write(Q) dan Ij = read(Q), maka Ii dan Ij konflik

4. Jika Ii = write(Q) dan Ij = write(Q), maka Ii dan Ij konflik

Secara intuitif, konflik diantara Ii dan Ij memaksakan perintah logika temporal diantara keduanya.

Jika Ii dan Ij merupakan instruksi dari transaksi berbeda dan tidak konflik, maka urutan instruksi Ii dan Ij dapat ditukar sehingga menghasilkan jadwal baru dengan hasil yang tetap sama.


35


Jika jadwal S dapat ditransformasikan menjadi jadwalan S’oleh serangkaian pertukaran instruksi yang non-konflik, maka bisa dikatakan S dan S’ adalah conflict equivalent.

Bisa dikatakan bahwa jadwal S adalah conflict serializable jika conflict equivalent terhadap penjadwalan serial.

Contoh penjadwalan yang tidak conflict serializable T3 T4

read(Q)write(Q)

write(Q)


36


Penjadwalan 3 di bawah bisa ditransformasikan ke penjadwalan 1, penjadwalan serial dimana T2 diikuti T1 , dengan serangkaian penukaran instruksi yang tidak konflik. Oleh karena itu penjadwalan di bawah ini conflict serializability


37

Example - Non-conflict serializable schedule

T9 is transferring £100 from one account with balance balx to another account with balance baly.

T10 is increasing balance of these two accounts by 10%.

Precedence graph has a cycle and so is not serializable.


38

Example - Non-conflict serializable schedule


39

View Serializability

Offers less stringent definition of schedule equivalence than conflict serializability.

Two schedules S1 and S2 are view equivalent if:– For each data item x, if Ti reads initial value of x in S1, Ti

must also read initial value of x in S2.– For each read on x by Ti in S1, if value read by x is

written by Tj, Ti must also read value of x produced by Tj in S2.

– For each data item x, if last write on x performed by Ti in S1, same transaction must perform final write on x in S2.


40


Schedule is view serializable if it is view equivalent to a serial schedule.

Every conflict serializable schedule is view serializable, although converse is not true.

It can be shown that any view serializable schedule that is not conflict serializable contains one or more blind writes.

In general, testing whether schedule is serializable is NP-complete.


41

Example - View Serializable schedule


42

View Serializability Misalkan S dan S’ adalah dua jadwal dengan serangkaian transaksi yang sama. S dan S’ adalah

view equivalent.

S dan S’ adalah view equivalent jika memenuhi kondisi sebagai berikut :

1. Untuk masing – masing data item Q , jika transaksi Ti membaca inisialisasi nilai pada Q di dalam jadwal S, maka transaksi Ti yang ada di jadwal S’ juga harus membaca inisialisasi nilai pada Q.

2. Untuk masing – masing data item Q, jika transaksi Ti mengeksekusi read(Q) di dalam jadwal S, dan jika nilai yang dihasilkan oleh operasi write(Q) dieksekusi oleh transaksi Tj , maka operasi read(Q) pada transaksi Ti yang harus ada di jadwal S‘ juga membaca nilai Q yang dihasilkan oleh operasi write(Q) yang sama pada transaksi Tj

3. Untuk masing – masing data item Q, transaksi yang sampai ke tahap akhir operasi write(Q) di dalam jadwal S

Seperti yang terlihat, view serializability juga dilihat berdasarkan pada operasi read dan write saja

43

View Serializability Sebuah jadwal S adalah view seralizable , setara dengan penjadwalan serial.

Setiap penjadwalan conflict serializable juga view serializable

Penjadwalan di bawah ini adalah penjadwalan yang view serializable tapi tidak conflict serializable

44


Penjadwalan di bawah menghasilkan outcome yang sama sebagai jadwal serial (T1, T2)

45

Recoverability

Serializability identifies schedules that maintain database consistency, assuming no transaction fails.

Could also examine recoverability of transactions within schedule.

If transaction fails, atomicity requires effects of transaction to be undone.

Durability states that once transaction commits, its changes cannot be undone (without running another, compensating, transaction).


46

Recoverable Schedule

Recoverable Schedule – Jika transaksi Tj membaca sebuah item data yang sebelumnya ditulis oleh transaksi Ti , maka operasi commit Ti muncul sebelum operasi commit Tj .

Jadwal berikut tidak recoverable jika T9 commit segera setelah read

Jika T8 dibatalkan, maka T9 bisa jadi akan membaca state database inkonsisten. Maka dengan demikian database harus memastikan bahwa jadwal dapat dipulihkan jika terjadi sesuatu hal.


47


Cascading Rollback – kesalahan pada satu transaksi yang yang dapat berpengaruh pada serangkaian transaksi lainnya sehingga keseluruhan transaksi akan di-rollback.

Misalkan pada penjadwalan berikut dimana belum ada transaksi yang di-commit, sehingga jika terjadi masalah bisa dipulihkan

Jika T10 transaksinya fail, maka T11 dan T12 juga harus di rollback. Jika tidak demikian, maka akan menyebabkan banyaknya pekerjaan yang tidak akan terselesaikan.

48


Cascadeless Schedule – cascading rollback tidak dapat terjadi, untuk setiap pasang transaksi Ti dan Tj dimana Tj membaca sebuah item data yang sebelumnya ditulis oleh Ti dan operasi commit pada Ti muncul sebelum operasi read pada Tj.

Setiap cascadeless schedule juga dapat dipulihkan (recoverable);

49

Concurrency Control Techniques

Terdapat dua teknik kontrol konkurensi yang memungkinkan transaksi untuk mengeksekusi dengan aman dalam subjek paralel untuk batasan tertentu : – Metode Locking dan– Metode Timestamp

Locking dan timestamping pada dasarnya merupakan pendekatan konservatif (pesimistik) yang dapat menyebabkan penundaan transaksi jika terjadi konflik dengan transaksi lainnya pada waktu yang sama.


50

Locking

Locking adalah sebuah prosedur yang digunakan untuk mengendalikan akses bersamaan ke data. Ketika sebuah transaksi sedang mengakses database, sebuah lock mungkin menolak akses ke transaksi lain untuk mencegah hasil yang salah ( Connolly, 2005, p587 ).

Locking merupakan suatu prosedure untuk mengontrol akses konkuren terhadap data.

Secara umum, transaksi harus menegaskan penguncian (lock) shared (read) atau exclusive (write) terhadap data item sebelum pembacaan (read) atau penulisan (write).


51

Locking - Basic Rules

Shared Lock, jika transaksi memiliki shared lock pada suatu data item, maka transaksi tersebut dapat melakukan pembacaan tetapi tidak melakukan perubahan.

Exclusive Lock, Jika transaksi memiliki exclusive lock pada suatu data item, maka transaksi tersebut dapat melakukan pembacaan dan perubahan terhadap data item tersebut.


52

Penggunaan kunci (lock) :

Setiap transaksi yang membutuhkan akses data item harus terlebih dahulu mengunci item, permintaan shared lock untuk akses pembacaan atau exclusive lock untuk pembacaan dan perubahan.

Jika item belum dikunci oleh transaksi lainnya, maka kunci dapat diberikan.


53

Penggunaan kunci (lock) :

Jika item tersebut telah dikunci, DBMS menentukan apakah permintaan sesuai dengan penguncian yang ada. Jika yang digunakan adalah shared lock maka permintaan akan diberikan, jika bukan (exclusive lock) maka transaksi harus menunggu kunci tersebut dilepaskan.

Transaksi melanjutkan menyimpan kunci sampai secara tegas/eksplisit dilepaskan baik selama eksekusi berlangsung atau ketika selesai (commit atau abort). Ketika exclusive lock dilepaskan maka akibat dari operasi penulisan akan dapat dilihat oleh transaksi yang lain.


54

Example - Incorrect Locking Schedule

S = {write_lock(T9, balx), read(T9, balx), write(T9, balx), unlock(T9, balx), write_lock(T10, balx), read(T10, balx), write(T10, balx), unlock(T10, balx), write_lock(T10, baly), read(T10, baly), write(T10, baly), unlock(T10, baly),commit(T10), write_lock(T9, baly), read(T9, baly), write(T9, baly),unlock(T9, baly), commit(T9) }


55


Jika dimulai dari balx = 100, baly = 400, maka hasilnya harus : balx = 220, baly = 330, jika T9 dieksekusi sebelum T10, atau balx = 210, baly = 340, jika T10 dieksekusi sebelum T9.

Tetapi hasil yang didapat balx = 220 dan baly = 340, maka S bukan serializable schedule. Masalah yang terjadi adalah transaksi melepaskan kunci terlalu cepat, menghasilkan kehilangan isolasi total dan atomicity.

56


Problem is that transactions release locks too soon, resulting in loss of total isolation and atomicity.

To guarantee serializability, need an additional protocol concerning the positioning of lock and unlock operations in every transaction.


57

Two-Phase Locking (2PL)

Suatu transaksi menggunakan protokol 2PL jika seluruh operasi penguncian (locking) mendahului operasi pelepasan kunci (unlock) dalam transaksi. Terdapat dua fase untuk transaksi, yaitu :

– Growing phase – mendapatkan seluruh kunci tetapi tidak dapat melepaskan kunci.

– Shrinking phase – melepaskan kunci tetapi tidak mendapatkan kunci baru.


58

Aturan dasar 2PL Satu transaksi harus meminta sebuah kunci

untuk suatu iter sebelum melaksanakan operasi pada item tersebut. Kunci yang diminta dapat berupa write lock maupun read lock , tergantung kebutuhan

Sekali transaksi melepaskan kunci, maka transaksi tersebut tidak dapat meminta kunci yang baru.


59

Preventing Lost Update Problem using 2PL


60

Preventing Uncommitted Dependency Problem using 2PL


61

Preventing Inconsistent Analysis Problem using 2PL


62

Cascading Rollback

If every transaction in a schedule follows 2PL, schedule is serializable.

However, problems can occur with interpretation of when locks can be released.


63

Cascading Rollback


64

Cascading Rollback

Transactions conform to 2PL. T14 aborts.

Since T15 is dependent on T14, T15 must also be rolled back. Since T16 is dependent on T15, it too must be rolled back.

This is called cascading rollback. To prevent this with 2PL, leave release of all locks

until end of transaction.


65

Concurrency Control with Index Structures

Could treat each page of index as a data item and apply 2PL.

However, as indexes will be frequently accessed, particularly higher levels, this may lead to high lock contention.

Can make two observations about index traversal:– Search path starts from root and moves down to leaf

nodes but search never moves back up tree. Thus, once a lower-level node has been accessed, higher-level nodes in that path will not be used again.


66


– When new index value (key and pointer) is being inserted into a leaf node, then if node is not full, insertion will not cause changes to higher-level nodes.

Suggests only have to exclusively lock leaf node in such a case, and only exclusively lock higher-level nodes if node is full and has to be split.


67


Thus, can derive following locking strategy:– For searches, obtain shared locks on nodes starting at root

and proceeding downwards along required path. Release lock on node once lock has been obtained on the child node.

– For insertions, conservative approach would be to obtain exclusive locks on all nodes as we descend tree to the leaf node to be modified.

– For more optimistic approach, obtain shared locks on all nodes as we descend to leaf node to be modified, where obtain exclusive lock. If leaf node has to split, upgrade shared lock on parent to exclusive lock. If this node also has to split, continue to upgrade locks at next higher level.


68

Deadlock

An impasse that may result when two (or more) transactions are each waiting for locks held by the other to be released.


69

Deadlock

Deadlock merupakan kebuntuan (impasse) yang mungkin dihasilkan ketika dua atau lebih transaksi saling menunggu kunci yang disimpan oleh transaksi lain agar dilepaskan.

Tiga teknik yang umum dilakukan untuk mengatasi deadlock : – Timeout

– Deadlock prevention

– Deadlock detection and recovery


70

Timeouts

Dengan pendekatan timeout, suatu transaksi yang meminta kunci hanya akan menunggu sistem mendefinisikan periode waktu.

Jika kunci belum diberikan dalam periode ini, maka permintaan kunci kehabisan waktu (times out).

Dalam kasus ini, DBMS mengasumsikan transaksi terjadi deadlocked, walaupun mungkin tidak terjadi, dan transaksi tersebut digagalkan dan secara otomatis mengulang dari awal transaksi yang bersangkutan.

71

Deadlock Prevention

Pendekatan lain yang mungkin dilakukan untuk menghindari deadlock adalah memerintahkan transaksi menggunakan transaksi timestamps :

– Wait-Die – memungkinkan hanya transaksi lama menunggu transaksi baru, selain itu transaksi digagalkan (dies) dan diulang dengan timestamps yang sama.


72

Deadlock Prevention

– Wound-Wait – hanya transaksi baru yang menunggu transaksi lama. Jika transaksi lama meminta kunci yang dimiliki oleh transaksi baru, maka transaksi baru akan digagalkan (wounded).


73

Deadlock Detection and Recovery Pendeteksian deadlock biasanya ditangani dengan

membuat konstruksi Wait For Graph (WFG) yang memperlihatkan ketergantungan transaksi, yaitu transaksi Ti bergantung pada Tj jika transaksi Tj memegang kunci untuk data item yang ditunggu olah Ti.

WFG merupakan graf berarah (directed graph) G =(N, E), yang dapat debentuk dengan cara :– Buatlah Node untuk setiap transaksi– Buatlah edge berarah Ti -> Tj, jika Ti menunggu kunci

untuk item yang sedang dikunci oleh Tj. Deadlock terjadi jika dan hanya jika WFG

mengandung siklus.Pearson Education © 2009

74

Example - Wait-For-Graph (WFG)


75

Recovery from Deadlock Detection

Several issues:– choice of deadlock victim;– how far to roll a transaction back;– avoiding starvation.


76

Timestamping

Timestamp adalah identifier unik yang dibuat oleh DBMS untuk mengindikasikan waktu mulai relatif dari suatu transaksi. Dapat dibangun dengan menggunakan waktu sistem pada saat transaksi dimulai, atau dengan penambahan counter logical setiap saat transaksi baru dilaksanakan.

Timestamping adalah protokol kontrol konkuren yang memerintahkan transaksi dalam suatu cara dimana transaksi lama dan transaksi dengan timestamp yang lebih kecil mendapatkan prioritas jika terjadi konflik.


77

Timestamping

Timestamp

A unique identifier created by DBMS that indicates relative starting time of a transaction.

Can be generated by using system clock at time transaction started, or by incrementing a logical counter every time a new transaction starts.


78

Timestamping

Read/write proceeds only if last update on that data item was carried out by an older transaction.

Otherwise, transaction requesting read/write is restarted and given a new timestamp.

Also timestamps for data items:– read-timestamp - timestamp of last transaction

to read item;– write-timestamp - timestamp of last

transaction to write item.


79

Timestamping - Read(x)

Transaksi T membaca item x yang telah diubah oleh transaksi baru (younger), yaitu ts(T) < write_timestamp(x). Berarti transaksi lama mencoba untuk membaca nilai suatu item yang telah diubah oleh transaksi baru. Dalam hal ini transaksi T harus digagalkan dan diulangi dengan timestamp yang baru.

ts(T) >= read_timestamp(x) , dan operasi pembacaan dapat diproses. Ditetapkan read_timestamp(x) = max(ts(T), read_timestamp(x)

80

Timestamping - Read(x)

ts(T) < read_timestamp(x)

– x already read by younger transaction.– Roll back transaction and restart it using a

later timestamp.


81

Timestamping - Write(x)

ts(T) < read_timestamp(x), hal ini terjadi ketika transaksi lama telat melakukan penulisan sehingga transaksi baru membaca nilai yang salah. Dalam hal ini harus dilakukan rolled-back transaksi T dan mengulanginya dengan timestamp berikutnya.

ts(T) < write_timestamp(x), dimana x telah dituliskan oleh transaksi baru. Ini berarti transaksi T berusaha untuk menuliskan nilai obsolete dari data item x. Maka transaksi T harus di-rolled back dan diulangi dengan menggunakan timestamp berikutnya.

Selain itu, dapat ditetap write_stimestamp(x) = ts(T),operasi dapat diterima dan dieksekusi.


82

Example – Basic Timestamp Ordering


83

Comparison of Methods


84

Multiversion Timestamp Ordering

Versioning of data can be used to increase concurrency.

Basic timestamp ordering protocol assumes only one version of data item exists, and so only one transaction can access data item at a time.

Can allow multiple transactions to read and write different versions of same data item, and ensure each transaction sees consistent set of versions for all data items it accesses.


85

Multiversion Timestamp Ordering

In multiversion concurrency control, each write operation creates new version of data item while retaining old version.

When transaction attempts to read data item, system selects one version that ensures serializability.

Versions can be deleted once they are no longer required.


86

Optimistic Techniques

Based on assumption that conflict is rare and more efficient to let transactions proceed without delays to ensure serializability.

At commit, check is made to determine whether conflict has occurred.

If there is a conflict, transaction must be rolled back and restarted. Potentially allows greater concurrency than traditional protocols.

Metode optimistik, didasarkan pada premis bahwa konflik itu jarang ditemui, jadi mereka mengijinkan transaksi untuk lanjut tidak tersinkronisasi dan hanya mengecek konflik di bagian akhir, ketika transaksi melakukan operasi commit.


87

Optimistic Techniques

Three phases:

– Read– Validation– Write


88

Optimistic Techniques - Read Phase

Extends from start until immediately before commit.

Transaction reads values from database and stores them in local variables. Updates are applied to a local copy of the data.


89

Optimistic Techniques - Validation Phase

Follows the read phase. For read-only transaction, checks that data read

are still current values. If no interference, transaction is committed, else aborted and restarted.

For update transaction, checks transaction leaves database in a consistent state, with serializability maintained.


90

Optimistic Techniques - Write Phase

Follows successful validation phase for update transactions.

Updates made to local copy are applied to the database.


91

Granularity of Data Items

Ukuran item data terpilih sebagai unit perlindungan dengan protokol kontrol konkurensi.

Ranging from coarse to fine:– The entire database.– A file.– A page (or area or database spaced).– A record.– A field value of a record.


92

Granularity of Data Items

Tradeoff: – coarser, the lower the degree of concurrency; – finer, more locking information that is needed

to be stored. Best item size depends on the types of

transactions.


93

Hierarchy of Granularity

Could represent granularity of locks in a hierarchical structure.

Root node represents entire database, level 1s represent files, etc.

When node is locked, all its descendants are also locked.

DBMS should check hierarchical path before granting lock.


94

Hierarchy of Granularity

Intention lock could be used to lock all ancestors of a locked node.

Intention locks can be read or write. Applied top-down, released bottom-up.


95

Levels of Locking


96

Database Recovery

Database Recovery merupakan suatu proses penyimpanan/pengembalian database ke state yang benar pada saat terjadi kerusakan. Kebutuhan atas kontrol recovery disebabkan karena penyimpanan data pada umumnya menggunakan empat jenis media penyimpanan berdasarkan tingkat reliabilitas/tahan uji-nya.

Terdapat 2 jenis penyimpanan :Volotile storage, biasanya tidak bertahan jika terjadi kerusakan sistem (system crash). contohnya : main memoryNonvolotile storage, magnetic disk merupakan online nonvolatile storage dan magnetic tape merupakan offline nonvolatile storage. lebih reliable dan lebig murah. Stable storage, merepresentasikan informasi yang telah direplika kedalam beberapa media penyimpanan non-volotile (biasanya disk) dengan jenis kerusakan yang terpisah.


97

Types of Failures

System Crashes, menyebabkan hilangnya data dari main memory. Media Failures, menyebabkan hilangnya sebagian data dari

media penyimpanan secondary. Application Software errors, misalnya logical erroryang terdapat

dalam program yang mengakses database sehingga menyebabkan satu atau lebih transaksi mengalami kegagalan.

Natural physical disaster, bencana alam/musibah seperti :kebakaran, banjir, gempa bumi, kerusakan listrik.

Carelessness, kecerobohan atau tindakan tidak sengaja yang menyebabkan kerusakan data, yang dilakukan oleh operator atau user.

Sabotage, sabotase atau tindakan sengaja merusak atau mencuri data, fasilitas harware maupun software.


98

Transactions and Recovery

Transaksi merepresentasikan unit dasar dari recovery dalam sistem database.

Recovery manager bertanggung jawab atas atomicity dan durability. Jika kesalahan terjadi antara penulisan ke buffer dan mengirimkan buffer database ke penyimpanan sekunder maka recovery manager harus menetapkan status dari transaksi yang melakukan penulisan pada saat terjadi kerusakan.

Jika transaksi dinyatakan commit, maka untuk memastikan durability, recovery manager harus melakukan redo (rollforward) terhadap perubahan transaksi.


99

Transactions and Recovery

Jika transaksi belum committed pada saat terjadi kerusakan, recovery manager harus melakukan undo (rollback) segala akibat dari transaksi tersebut untuk menjamin atomicity transaksi.

Partial undo - Jika hanya terdapat satu transaksi yang tidak diselesaikan.

Global undo - jika seluruh transaksi tidak terselesaikan.


100

Example

DBMS Mulai pada saat t0, tetapi gagal pada saat tf. Diasumsikan data untuk transaksi T2 dan T3 telah dituliskan ke penyimpanan sekunder sebelum terjadi kegagalan. T1 dan T6 dipastikan belum comitted,maka ketika restart recovery manager harus meng-undo T1 dan T6. Untuk transaksi T4 dan T5 disimpan pada media penyimpanan non-volotile, oleh karena itu recovery manager harus melakukan redo transaksi T2, T3, T4, dan T5.


101

Recovery Facilities

DBMS harus menyediakan fasilitas berikut untuk mendukung recovery :Mekanisme Backup, yang akan mebuat salinan dari database secara periodik. Fasilitas Logging (pencatatan), yang menyimpan catatan dari stata transaksi dan perubahan database.Fasilitas Checkpoint, yang memungkinkan merubah database yang sedang dalam pengembangan menjadi permanen.Recovery manager, yang mengizinkan DBMS untuk menyimpan database pada stata konsisten jika terjadi kerusakan/kesalahan.


102

Log File

Contains information about all updates to database:– Transaction records.– Checkpoint records.

Often used for other purposes (for example, auditing).

Untuk menyimpan catatan dari transaksi database, DBMS memiliki file khusus yang disebut log file, yang berisi informasi tentang semua perubahan terhadap database.


103

Log File

Transaction records contain:– Identifier transaksi– Tipe dari record catatan (transaksi start, insert, update, delete, abort,

commit)– Identifier dari data item yang diakibatkan oleh aksi database (operasi

insert, delete dan update)– before-image dari data item, yaitu nilai sebelum dilakukan perubahan

(hanya operasi update dan delete)– after-image dari data item, yaaitu nilai sesudah perubahan (hanya

operasi insert dan update)– Informasi manajemen catatan, seperti pointer ke record catatan sebelum

(previous) dan sesudah (next) untuk transaksi tersebut (seluruh operasi)

104

Sample Log File


105

Log File

Log file dapat dibuat duplexed atau triplexed (yaitu dibuat dua atau tiga salinan terpisah), sehingga bila yang satu rusak masih terdapat yang lain.

Terkadang Log file dipisahkan menjadi dua file random-access yang terpisah.

Potensial terjadi bottleneck, dimana kecepatan penulisan kedalam log file dapat menjadi kritis dalam menentukan keseluruhan performa sistem database.


106

Checkpointing

CheckpointPoint of synchronization between database and log file. All buffers are force-written to secondary storage.

Checkpoint record is created containing identifiers of all active transactions.

When failure occurs, redo all transactions that committed since the checkpoint and undo all transactions active at time of crash.


107

Checkpointing

Checkpoint adalah titik dari penyelarasan (synchronization) antara database dan log file. Checkpoint dijadwalkan saat penetapan sebelum interval dan menyertakan operasi berikut:

Menuliskan seluruh record log dalam main memory kedalam penyimpanan sekunder.

Menuliskan blok perubahan dalam buffer database ke penyimpanan sekunder.

Menuliskan record checkpoint kedalam log file. record ini berisikan identifier dari seluruh transaksi aktif pada saat checkpoint.


108

Checkpointing

Jika kerusakan terjadi, akan melaksanakan redo seluruh transaksi yang committed sejak check point dan melaksanakan undo seluruh transaksi aktif pada saat gagal (crash) . Pada contoh yang lalu dengan checkpoint pada saat tc, perubahan yang dibuat oleh T2 dan T3 telah dituliskan kedalam penyimpanan sekunder, karena itu yang dilakukan :

T4 dan T5

undo transaksi T1 dan T6.


109

Recovery Techniques

Jika database mengalami kerusakan seperti :

Jika database mengalami kerusakan secara luas, misalnya kerusakan disk head dan kerusakan database, maka perlu dikembalikan ke back-up/salinan terakhir dari database dan diaplikasikan ulang operasi update dari transaksi yang committed dengan menggunakan log file.

Jika database hanya mengalami ketidak-konsistenan (inconsistent), maka harus melakukan undo perubahan-perubahan yang menyebabkan tidak konsisten. Juga perlu melakukan redo terhadap beberapa transaksi untuk menjamin perubahan yang dilakukan telah disimpan ke penyimpanan sekunder. Tidak memerlukan back-up salinan dari database tetapi dapat mengembalikan database ke stata konsisten dengan menggunakan before dan after image yang ada dalam log file.

110

Recovery Techniques

If database has been damaged:– Need to restore last backup copy of database and

reapply updates of committed transactions using log file.

If database is only inconsistent:– Need to undo changes that caused inconsistency.

May also need to redo some transactions to ensure updates reach secondary storage.

– Do not need backup, but can restore database using before- and after-images in the log file.


111

Main Recovery Techniques

Three main recovery techniques:

– Deferred Update– Immediate Update– Shadow Paging


112

Deferred Update

Dengan menggunakan protocol recovery deferred update, update tidak dituliskan kedalam database sampai dengan transaksi mencapai titik commit.

Jika transaksi gagal sebelum commit, maka update tersebut tidak akan merubah database dan tidak perlu melakukan undo perubahan.

Tetapi mungkin perlu melakukan redo update dari transaksi yang committed sebagai akibat tidak mencapai database


113

Deferred Update

Dalam hal ini digunakan log file untuk perlindungan dari kesalahan sistem dengan cara :

Ketika mulai transaksi, tuliskan record transaction start pada log fileketika operasi penulisan dilaksanakan , tuliskan record log berisikan seluruh data log yang telah dispesifikasikan sebelumnya. Tidak menuliskan update pada buffer database atau database itu sendiri.Ketika transaksi commit, tuliskan transaction commit pada record log, tulis seluruh record log transaksi ke disk, kemudian selesaikan transaksi. Gunakan record log untuk menjalankan update pada database.Jika transaksi gagal, abaikan record log transaksi dan jangan melakukan penulisan.


114

Immediate Update

Dengan menggunakan protocol recovery immediate update, Update di aplikasikan pada data base ketika dijalankan tanpa harus menunggu titik commit.

Perlu melakukan redo update dari transaksi committed jika terjadi kesalahan, menjadi penting untuk mengulang (undo) akibat dari transaksi yang belum committed pada saat terjadi kesalahan.


115

Immediate Update

Dalam kasus ini digunakan log file untuk perlindungan terhadap kesalahan sistem dengan cara :

Jika transaksi dimulai, tuliskan record transaction start pada log file.Ketika operasi penulisan dilaksanakan, tuliskan record berisikan data-data yang dianggap perlu kedalam log file.Ketika log file sudah ditulis, tuliskan update pada buffer database.Update terhadap database itu sendiri dilakukan ketika buffer dikirimkan kemudian ke penyimpanan sekunder.Ketika transaksi commit, tuliskan record transaction commit di log file.


116

Immediate Update

Pada dasarnya record log dituliskan sebelum penulisan yang sesuai pada database, dikenal dengan Write-ahead log protocol. Jika tidak terdapat record “transaction commit” dalam log, kemudian transaksi tersebut aktif pada saat terjadi kesalahan daka harus digagalkan.

Jika transaksi gagal, log dapat digunakan untuk melakukan undo (melaksanakan in reverse order) dimana telah dituliskan dalam log file.


117

Shadow Paging

Mengatur/memelihara dua table selama transaksi berlangsung yaitu : tabel current page dan shadow page.

Ketika transaksi dimulai, kedua tabel tersebut sama. tabel shadow page tidak akan diubah sesudah itu dan digunakan untuk mengembalikan database pada saat terjadi kesalahan.

Selama transaksi berlangsung tabel current page digunakan untuk mencatat seluruh update terhadap database.

Ketika transakti selesai, tabel current page menjadi tabel shadow page.


118

Advanced Transaction Models

Protocols considered so far are suitable for types of transactions that arise in traditional business applications, characterized by:– Data has many types, each with small number

of instances.– Designs may be very large.– Design is not static but evolves through time. – Updates are far-reaching.– Cooperative engineering.


119


May result in transactions of long duration, giving rise to following problems:– More susceptible to failure - need to minimize

amount of work lost.– May access large number of data items -

concurrency limited if data inaccessible for long periods.

– Deadlock more likely.– Cooperation through use of shared data items

restricted by traditional concurrency protocols.


120


Look at five advanced transaction models:

– Nested Transaction Model– Sagas– Multi-level Transaction Model– Dynamic Restructuring– Workflow Models


121

Nested Transaction Model

Transaction viewed as hierarchy of subtransactions. Top-level transaction can have number of child

transactions. Each child can also have nested transactions. In Moss’s proposal, only leaf-level subtransactions

allowed to perform database operations. Transactions have to commit from bottom upwards. However, transaction abort at one level does not have

to affect transaction in progress at higher level.


122


Parent allowed to perform its own recovery:– Retry subtransaction.– Ignore failure, in which case subtransaction

non-vital.– Run contingency subtransaction.– Abort.

Updates of committed subtransactions at intermediate levels are visible only within scope of their immediate parents.


123


Further, commit of subtransaction is conditionally subject to commit or abort of its superiors.

Using this model, top-level transactions conform to traditional ACID properties of flat transaction.


124

Example of Nested Transactions


125

Nested Transaction Model - Advantages

Modularity - transaction can be decomposed into number of subtransactions for purposes of concurrency and recovery.

Finer level of granularity for concurrency control and recovery.

Intra-transaction parallelism. Intra-transaction recovery control.


126

Emulating Nested Transactions using Savepoints

An identifiable point in flat transaction representing some partially consistent state.

Can be used as restart point for transaction if subsequent problem detected.

During execution of transaction, user can establish savepoint, which user can use to roll transaction back to.

Unlike nested transactions, savepoints do not support any form of intra-transaction parallelism.


127

Sagas

“A sequence of (flat) transactions that can be interleaved with other transactions”.

DBMS guarantees that either all transactions in saga are successfully completed or compensating transactions are run to undo partial execution.

Saga has only one level of nesting. For every subtransaction defined, there is

corresponding compensating transaction that will semantically undo subtransaction’s effect.


128

Sagas

Relax property of isolation by allowing saga to reveal its partial results to other concurrently executing transactions before it completes.

Useful when subtransactions are relatively independent and compensating transactions can be produced.

May be difficult sometimes to define compensating transaction in advance, and DBMS may need to interact with user to determine compensation.


129

Multi-level Transaction Model

Closed nested transaction - atomicity enforced at the top-level.

Open nested transactions - allow partial results of subtransactions to be seen outside transaction.

Saga model is example of open nested transaction. So is multi-level transaction model where tree of

subtransactions is balanced. Nodes at same depth of tree correspond to

operations of same level of abstraction in DBMS.


130

Multi-level Transaction Model

Edges represent implementation of an operation by sequence of operations at next lower level.

Traditional flat transaction ensures no conflicts at lowest level (L0).

In multi-level model two operations at level Li may not conflict even though their implementations at next lower level Li-1 do.


131

Example - Multi-level Transaction Model


132

Example - Multi-level Transaction Model

T7: T71, which increases balx by 5

T72, which subtracts 5 from baly

T8: T81, which increases baly by 10

T82, which subtracts 2 from balx

As addition and subtraction commute, can execute these subtransactions in any order, and correct result will always be generated.


133

Dynamic Restructuring

To address constraints imposed by ACID properties of flat transactions, two new operations proposed: split_transaction and join_transaction.

split-transaction - splits transaction into two serializable transactions and divides its actions and resources (for example, locked data items) between new transactions.

Resulting transactions proceed independently.


134


Allows partial results of transaction to be shared, while still preserving its semantics.

Can be applied only when it is possible to generate two transactions that are serializable with each other and with all other concurrently executing transactions.


135


Conditions that permit transaction to be split into A and B are:– .AWriteSet BWriteSet BWriteLast.

If both A and B write to same object, B’s write operations must follow A’s write operations.

– .AReadSet BWriteSet = . A cannot see any results from B.

– .BReadSet AWriteSet = ShareSet. B may see results of A.


136


These guarantee that A is serialized before B. However, if A aborts, B must also abort. If both BWriteLast and ShareSet are empty, then

A and B can be serialized in any order and both can be committed independently.


137


join-transaction - performs reverse operation, merging ongoing work of two or more independent transactions, as though they had always been single transaction.


138


Main advantages of dynamic restructuring are:

Adaptive recovery. Reducing isolation.


139

Workflow Models

Has been argued that above models are still not powerful to model some business activities.

More complex models have been proposed that are combinations of open and nested transactions.

However, as they hardly conform to any of ACID properties, called workflow model used instead.

Workflow is activity involving coordinated execution of multiple tasks performed by different processing entities (people or software systems).


140

Workflow Models

Two general problems involved in workflow systems: – specification of the workflow, – execution of the workflow.

Both problems complicated by fact that many organizations use multiple, independently managed systems to automate different parts of the process.


t02060030220124090pert15-16 - t0206

Documents

properties of transactions