Protocol Transaksi konkruen

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.

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

3 Masalah akibat concurrency

1.       Lost update (modifikasi yg hilang)

Masalah operasi update yg sukses dari seorang pengguna kemudian ditimpali oleh operasi update dari pengguna 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.

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

Masalah terjadi saat suatu transaksi membaca data dari transaksi lain yg belum dicommit. Misalkan 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.

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.

3.       Inconsistent analysis

Masalah terjadi saat satu transaksi membaca beberapa nilai tetapi transaksi kedua pd waktu sama memodifikasi nilai tersebut.

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.

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

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.

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.

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.

Metode untuk menjamin serializability

1. LOCKING

2. TIMESTAMPING

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

Metode Optimistic

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

Metode Locking

Prosedur untuk mengontrol pengaksesan data secara konkuren. Ketika satu transaksi mengakses database, sebuah kunci (lock) dapat mengabaikan akses untuk transaksi lainnya, untuk menghindari hasil yang salah.

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

Aturan dasar penguncian (locking):

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

Penggunaan kunci (lock) :

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.

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 terus menahan suatu kunci sampai dilepaskan secara eksplisit selama eksekusi atau telah selesai.

Matriks LOCKING

Protokol Two-Phase Locking (2PL)

Protokol untuk menjamin serializability. 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.

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.

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

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

·         Deadlock prevention

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

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

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

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

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

Testing for serializability

Serializability : pengontrolan secara konkurensi kepada kebenaran dari kriteria yang membutuhkan eksekusi konkuren dari transaksi harus ekuivalen terhadap efek dari eksekusi serial transaksi tersebut.

Tujuan dari protokol kontrol concurrency adalah menjadwalkan transaksi dengan suatu cara untuk menghindari saling mempengaruhi/mengganggu satu dengan yang lain. Hal yang paling umum dilakukan adalah menjalankan satu transaksi dalam satu waktu, tetapi tujuan dari multi user DBMS adalah memaksimalkan tingkat concurrency atau parallelism dalam sistem, sehingga traksaksi-transaksi dapat dieksekusi secara parallel tanpa mengganggu transaksi lainnya. Serializability mengidentifikasi eksekusieksekusi dari transaksi dijamin untuk kepastian konsistensi.

-          Penjadwalan (Schedule) adalah Serangkaian operasi dari sekumpulan transaksi konkuren yang menjaga perintah dari operasi-operasi dalam setiap transaksi individual.

-          Serial Schedule adalah penjadwalan yang dilakukan dimana operasi-operasi disetiap transaksi dieksekusi secara berurutan tanpa terjadi penyelakan operasi dari transaksi lainnya. Dalam eksekusi serial tidak akan ada interferensi antar transaksi, tetapi tidak menjamin hasil dari keseluruh eksekusi serial dari himpunan transaksi akan sama/identik.

-          Nonserial Schedule adalah penjadwalan yang dilakukan dimana operasi-operasi dari sekumpulan transaksi konkuren saling berselakan (interleaved).

Tujuan dari serializability adalah menemukan nonserial schedule yang memungkinkan transaksi untuk mengeksekusi secara konkuren tanpa mengganggu/interferen yang lainnya dan menghasilkan state database yang dapat dihasilkan oleh eksekusi serial. Dengan kata lain, jika terdapat nonserial schedule yang ekuivalen dengan beberapa serial schedule disebut dengan serializability.

Dalam serializability, perintah operasi pembacaan/penulisan sangat penting:

-          Jika terdapat dua transaksi hanya membaca data item, maka tidak akan terjadi konflik dan perintah tidak diperlukan.

-           Jika terdapat dua transaksi yang membaca atau menulis data item yang terpisah, maka tidak akan terjadi konfilk dan perintah tidak diperlukan.

-           Jika satu transaksi menuliskan data item dan transaksi lainnya membaca atau menulis data item yang sama, maka perintah eksekusi diperlukan.

Contoh konflik dalam Serializability

a.       nonserial schedule S1

b.      nonserial schedule S2, ekuvalen dengan S1

c.       serial schedule S3, ekuivalen dengan S1dan S2

Schedule S3 merupakan serial schedule dan ketika S1 dan S2 ekuivalen dengan S3, maka S1 dan S2 merupakan serializability schedule. Jenis serializability yang seperti ini dikenal sebagai conflict serializability, yaitu memerintahkan operasi yang saling bertentangan dengan suatu cara sama seperti eksekusi serial.

Dengan constrained write rule (transaksi yang mengubah data item berdasarkan padanilai awal, yang pertama kali dibaca), menggunakan precedence (or serializability) graph untuk memeriksa serializability. Precedence Graph merupakan directed graph G = (N,E) yang berisi dari himpunan node N dan edge E, sbb :

Buat node untuk setiap transaksi

-          Buat edge penghubung Ti -> Tj, jika Tj membaca nilai dari item yang ditulis oleh Ti

-          Buat edge penghubung Ti -> Tj, jika Tj menuliskan nilai ke item setelah dibaca oleh Ti

-          Buat edge penghubung Ti -> Tj, jika Tj menuliskan nilai ke item setelah ditulis oleh Ti

Jika edge Ti -> Tj terdapat dalam precedence graph untuk S, kemudian terdapat serial schedule S’ yang ekuivalen dengan S, maka Ti harus ditampilkan sebelum Tj. Jika precedence graph mengandung siklus schedule maka tidak akan terjadi conflict serializability.

Contoh - Non-conflict serializable schedule:

-          T9 memindahkan £100 dari variabel balx ke variabel baly.

-          T10 mengurangi kedua variabel tersebut sebesar 10%.

-          Precedence grah untuk schedule ini memiliki siklus, sehingga bukan merupakan conflict serializability.

View Serializability

Terdapat beberapa jenis serializability yang menawarkan definisi yang tidak terlalu kaku (less stringent definition) dari schedule ekuivalen dari pada conflict serializability. Definisi yang lebih sedikit batasannya disebut dengan view schedule. Dua schedule S1 dan S2 disebut equivalent jika:

-          Untuk setiap data item x, jika Ti membaca nilai awal dari x dalam S1, Ti juga harus membaca nilai awal dari x dalam S2.

-          Untuk setiap pembacaan atas x oleh Ti dalam S1, jika nilai dibaca oleh x dituliskan oleh Tj, Ti juga harus membaca nilai dari x yang dihasilkan oleh Tj dalam S2.

-          Untuk setiap data item x, jika penulisan terskhir dari x ditampilkan oleh Ti dalam S1, beberapa transaksi harus menampilkan penulisan akhir dari x dalam S2.

Schedule dikatakan view serializable jika view tersebut ekuivalen dengan serial schedule. setiap conflict serializable schedule merupakan view serializable, walaupun kebalikannya tidak benar. Dapat menampilkan bahwa view serializable schedule yang tidak conflict serializable terdiri dari satu atau lebih blind writes.

RECOVERABILITY

-          Serializability mengidentifikasikan schedule yang memelihara konsistensi database, diasumsikan tidak ada transaksi yang gagal. Juga memeriksa recoverability dari transaksi dalan schedule. Jika transaksi gagal, atomicity membutuhkan akibat dari transaksi yang harus diselesaikan.

-          Durability state ketika transaksi commit, perubahannya tidak dapat diselesaikan (tanpa menjalankan yang lain, penggantian, transaksi).

-          Recoverable Schedule merupakan schedule yang setiap pasang dari transaksi Ti dan Tj, jika Tj membaca sebuah data item sebelum dituliskan oleh Ti, maka operasi commit dari Ti mendahului operasi commit dari Tj.

Recoverability

Data dan database merupakan komponen terpenting dalam suatu sistem informasi manajemen, disamping tentu saja aplikasi untuk sistem informasi harus tersedia, keduanya saling tergantung. Suatu aplikasi sistem informasi manajemen tidak ada gunanya jika tidak mempunyai data yang lengkap, demikian juga sebaliknya jika punya data tetapi tidak mempunyai aplikasi yang digunakan untuk mengelolanya sehingga tidak dapat dihasilkan suatu laporan, statistik atau pun informasi.

Klasifikasi kerusakan

-          Kerusakan transaksi :

-          Logical errors: transaksi tidak lengkap karena ada kesalahan dalam program

-          System errors: database harus menghentikan sementara transaksi yang aktif karena ada kondisi yang tidak diharpkan (mis., deadlock)

-          System crash: kerusakan listrik atau hardware atau software yang menyebabkan system crash.

-          Penyimpan sementara: I nformasi yang ada di media ini hanya ada selama listrik mengalir

-          Kerusakan disk:  akibat dari head diskdrive yang rusak atau kotor

Algoritma Recovery adalah teknik untuk meyakinkan konsistensi database dan transaksi atomik dan ketahanan terhadap kerusakan memiliki dua bagian :

1.       Aksi yang ditempuh selama transaksi berjalan normal untuk menjamin informasi yang memadai yang kelak dibutuhkan oleh mekanisme recovery

2.       Aksi ditempuh setelah terjadinya kerusakan/kegagalan sistem yang dilakukan untuk memulihkan isi database ke suatu keadaan yang menjamin konsistensi basis data, keatomikan dan ketahanan

Struktur penyimpan

1.       Penyimpan sementara:

1. Tidak mampu mengatasi kerusakan sistem
2. contoh: main memory, cache memory

2.       Penyimpan tetap:

1. Mampu mengatasi kerusakan sistem
2. Cnoth : disk, tape, flash memory,
                     non-volatile (battery backed up) RAM
2. Penyimpan stabil:
1. Bentuk lain dari penyimpanan untuk mengatas kerusakan sistem
2. Pembuatan copy database dan menyimpan di tempat lain untuk menjaga jika ada kerusakan

Akses data

—  Blok menunjukkan satuan pentransferan data dari dan ke disk, dan dapat berisi banyak item / baris data.

—  Buffer block blok yang menyimpan data sementara di main memory.

—  Blok ini bergerak antara disk dan main memory melalui dua operasi:

-          input(B) transfer block B  ke main memory.

-          output(B) transfer buffer blok B ke disk, dan menggantikan blok yang lama.

—  Setiap transaksi T_i mempunyai area kerja private untuk tempat pengelolaan salinan dari semua item data yang diubah oleh transaksi.

-           T_i‘ adalah copy data item X dan disebut x_i.

—  Untuk menyederhanakan, setiap item data disimpan dalam blok tunggal.

—  Transaksi mentransfer data ke dan dari area kerja ke buffer dengan operasi :

-          read(X) memberi harga X dari basis data ke variabel lokal di memori bernama x_i.

-          write(X) memberi harga dari variabel lokal x_i ke item data {X} blok buffer.

-          Jika blok dimana X berada tidak ada di memori utama,maka lakukan perintah input (Bx).

—  Transaksi yang menggunakan kedua operasi tersebut :

                                Ti:           get vTransfer

                                                read (A)

                                                A ß A – vTransfer

            Write (A)

           Read (B)

           B ß B + vTransfer

           Write (B)

           Display A

           Display B

Recovery and Atomicity

Mengubah database tanpa memastikan bahwa transaksi berhasil baik akan membuat database dalam keadaan tidak konsisten. Seperti pada contoh pentransferan uang, transaksi yang mengubah harus berjalan sempurna atau tidak samasekali. Beberapa operasi output membutuhkan Ti  (untuk output A dan B). Kerusakan dapat terjadi bila salah satu perubahan pada item data tidak terjadi.

Dengan asumsi ruang disk yang dialokasikan untuk basis data tidak rusak, maka da 3 pilihan skema untuk menjalankan mekanisme recovery secara otomatis, yaitu :

1.       File log dengan penundaan pengubahan

2.       File log dengan pengubahan langsung

3.       Page bayangan (Shadow paging)

Recovery berbasis log

Sebuah  log adalah pelindung kestabilan penyimpan.

-          File log ini berisi log record, yang berkorelasi dengan semua operasi perubahan pada basis data.

Ketika transaksi T_i mulai, dalam registernya akan tertulis  <T_i  start>log record

Sebelum T_i execute write(X), dalam log record tertulis <T_i, X,  V₁,  V₂>, dimana V₁ adalah nilai X  sebelum ditulis, dan V₂ adalah nilai yang baru dari X.

-          Log record mencatat bahwa T_i telah melakukan penulisan pada X_j   X_j mempunyai nilai V₁ sebelum ditulis, dan akan bernilaiV₂ setelah transaksi write.

Ketika T_i selesai, log record menulis <T_i  commit> .

Log record langsung menulis dalam penyimpan tetap bukan buffer

Duapendekatan penggunaan log

-          Penundaan modifikasi database

-          Pengubahan langsung database

Penundaan pengubahan database

Skema penundaan pengubahan database mencatat semua perubahan ke log, tetapi menunda untuk writes setelah commit.

Anggap transaksi berjalan berurutan

Transaksi mulai dengan menulis record <T_i  start> ke log.

Sebuah operasi  write(X) menyimpulkan bahwa di log record telah tertulis <T_i, X, V>, dimana V adalah nilai baru untuk X

-          Nilai lama tidak diperlukan dalam skema ini

ketika T_i telah commit, maka dalam log tertulis <T_i commit>

Akhirnya, log record dibaca dan digunakan untuk eksekusi penulisan selanjutnya

Selama recovery sesudah rash, sebuah transaksi butuh penyelesaian <T_i  start> dan<T_i commit> dalam log.

Penulisan ulang transaksi T_i ( redoT_i) mengubah nilai data menjadi baru.

Contoh transaksi  T₀ dan T₁ (T₀ dieksekusi sebelum T₁):

                T₀: read (A)                                                         T₁ : read (C)

                                A: - A - 50                                                    C:-   C- 100

                                Write (A)                                                     write (C)

                                read (B)

                                B:-  B + 50

                                write (B)

Berikut ditunjukkan log dari 3 transaksi.

Jika ada kegagalan sistem:

1.       redo(T₀) yang membuat semua nilai item data yang diubah T₀ ke nilai-nilai baru

2.       Untuk me-redo transaksi T₀ hanya membutuhkan file log yang mengandung dua buah record yang memuat  <T₀ start> dan <T₀ commit>

Pengubahan database langsung

Skema immediate database modification adalah mekanisme dengan perubahan secara langsung ke basisdata meskipun transaksi masih berlangsung.

Update log record harus ditulis sebelum item database ditulis

-          Perubahan aktual ke database tidak diperkenankan sebelum record yang bersesuaian dalam file log dituliskan ke media penyimpan stabil

-          Sebelum eksekusi sebuah operasi output(B), record dalam file log yang berhubungan dengan item data B telah ditulis dalam media penyimpan stabil

 Prosedur recovery untuk sistem ini ada dua:

-          undo(T_i) yang merekam kembali nilai semua item data yang diubah oleh transaksi T_i ke nilai awalnya.

-          redo(T_i) yang membuat semua nilai item data yang diubah oleh transaksi T_i ke nilai barunya

Setelah terjadi kerusakan database, skema recovery akan melihat isi file log untuk mengetahui transaksi mana yang akan diulangi, dan transaksi mana yang dibatalkan, dengan aturan:

-          Transaksi T_i harus dikembalikan ke kondisi awal (undo) jika dalam file log ada record <T_i start>, tetapi tidak ada record <T_i commit>.

-          Transaksi T_i harus dituntaskan (redo) jika dalam file log ada record <T_i start> dan <T_i commit>.

Operasi undo dilaksanakan terlebih dahulu dari pada redo.

Contoh:

 Recovery untuk setiap kasus :

a.       undo (T₀): B kembali bernilai 2000 dan B ke 1000.

b.      undo (T₁) dan redo (T₀): C kembali menjadi 700, dan kemudian A dan B are diset ke 950 dan 2050 .

c.       redo (T₀) dan redo (T₁): A dan B di set ke 950 dan 2050 demikian pula  C di set ke 600

Checkpoint

Dalam melakukan redo maupun undo sebuah transaksi ada beberapa kesulitan :

1.       Proses pencarian membutuhkan waktu

2.       Sebagian besar transaksi yang perlu diulangi sudah menuliskan perubahannya ke database sehingga tidak benar-benar perlu diulangi

Untuk mengurangi beban waktu tambahan ini maka digunakan checkpointing

3.       Menulis semua record log yang sedang berada di memori utama ke media penyimpanan stabil.

4.       Menuliskan semua blok buffer yang berubah ke disk.

5.       Menuliskan record < checkpoint> di file log ke media penyimpan stabil.

Selama recovery dibutuhkan kepastian bahwa transaksi T_i mulai sebelum checkpoint :

1.       Keberadaan record <checkpoint> dalam file log memungkinkan sistem menjalankan proses recoverynya dengan lebih efisien

2.       Dari file log dapat diketahui bahwa transaksi T_i yangmemiliki record <T_i commit> yang muncul sebelum checkpoint terakhir .

3.       Kondisi tersebut menandakan bahwa perubahan kedalam database telah dituliskan

Untuk teknik recovery dengan perubahan langsung,maka akan diterapkan ketentuan :

4.       Untuk transaksi Ti dan semua transaksi setelah Ti (dinyatakan sebagai Tk) yang tidak memiliki record <Tk commit>, jalankan operasi undo(Tk)

5.       Untuk transaksi Ti dan semua transaksi setelah Ti (dinyatakan Tk) yang memiliki record <Tk commit>,jalankan operasi redo(Tk)

Untuk teknik recovery dengan penundaan pengubahan, operasi undo tidak dibutuhkan. Karena itu hanya ketentuankedua yangharus dilakukan yaitu menjalankan operasi redo(Tk)

Contoh:

T1 dapat dilanjutkan

T2 dan T3 ulang

T4 batalkan

Shadow Paging

Shadow paging adalah alternatif lain selain file log yang memerlukan akses ke disk yang lebih sedikit.

Dasar pemikiran: merawat dua halaman tabel selama transaksi berlangsung current page table, dan shadow page table

Simpan tabel bayangan dalam penyimpan tetap, dengan demikian jejak transaksi tersimpan.

-          Shadow page table tidak pernah berubah selama eksekusi

Pada waktu mulai maka kedua tabel ditandai. Hanya page asli yang digunakan selama eksekusi transaksi berlangsung.

Kapanpun halaman ditulis untuk pertama kali

-          Copy halaman ini diberikan ke halaman yang tidak dipakai.

-          Halaman sekarang dipakai sebagai sumber untuk di copy

-          Update dilakukan di copyan

Contoh Page Table

Tabel asli dan tabel bayangan terbentuk terbentuk setelah transaksi

Untuk mengcommit transaksi, harus dilakukan :

1.       Menjamin semua page data yang ada dalam memori utama yang telah diubah oleh transaksi, disalin ke dalam disk

2.       Simpan tabel page yang aktif ke disk.

3.       Simpan alamat disk dari tabel page aktif ke lokasi yang tetap dalam media penyimpanan stabil yang telah berisi alamat tabel page bayangan. Aksi ini melakukan penimpaan pada alamat tabel page bayangan yang lama. Tabel page aktif akan menjadi tabel page yang baru dan transaksi commit.

Jika crash terjadi sebelum langkah ke 3 selesai dikerjakan, kita akan kembali ke keadaan sebelum transaksi terjadi. Jika crash terjadi setelah langkah ke 3 maka efek transaksi tersimpan, sehingga redo tidak perlu.

Keunggulan dari shadow-paging

-          Tidak adanya tambahan waktu untuk penulisan record ke dalam file log

-          Proses recovery lebih cepat karena tidak butuh undo atau redo

Kelemahannya :

-          Tambahan waktu untuk proses commit

Proses commit sebuah transaksi membutuhkan sejumlah blok data untuk direkam, seperti blok data aktual, tabel page aktif dan alamat disk dari tabel page aktif

-          Pemisahan data ( fragmentasi )

Skema shadow paging menyebabkan page database mengubah lokasinya saat terjadi perubahan data, sehingga terjadi fragmentasi data yang dapat memperlambat transfer data dari database ke main memory

-          Data sampah (garbage)

Setelah transaksi tercommit, page database yang berisi data versi lama telah diubah menjadi tidak terakses dan page-page inilah yang disebut sampah

-          Lebih sulit dalam mengembangkan algoritma supay transaksi berjalan konkuren

Lebih menggunakan basis log

Recovery untuk transaksi konkuren

Meskipun banyak transaksi yang terlibat, sistemhanya akan menggunakan sebuah buffer disk dan sebuah file log. Blok untuk buffer akan dipakai secara bersama oleh semua transaksi . Jika sebuah transaksi T telah mengubah item data Q, tidak boleh ad atransaksi lain yang boleh mengubah item data yang sama hingga T telah di-commit atau di-roll back.  Dapat memanfaatkan Locking Protocol Dua fase yang ketat, yangmenerapkan penguncian dengan mode exclusive hingga akhir transaksi.

File log dapat digunakan untuk meroll back transaksi yang gagal dengan penelusuran mundur untuk setiap record yang terbentuk.

Dalam sebuah sistem yang konkuren, record checkpoint dalam file log berbentuk < checkpoint L>
diman L merupakan daftar transaksi yang aktif pada saat checkpoint terjadi

Ketika sistem melakukan pemulihan data maka yang dilakukan adalah:

1. cari undo-list dan  redo-list dalam keadaan kosong
2. Lakukan penelusuran mundur terhadap file log sampai ditemukannya  <checkpoint L> . 
   Untuk setiap record yang ditemukan :

-          Jika record adalah <T_i commit>, tambahkan T_i dalam redo-list

-          Ika record adalah <T_i  start>, maka  jika T_i tidak ada dalam redo-list, tambahkan T_i  dalam undo-list

3. Untuk setiap T_i  dalam L, jika T_i itidaka ada dalam redo-list, tambahkan T_i dalam undo-list

Begitu kedua daftar terbentuk, maka proses recpovery akan dilakukan dengan langkah-langkah sbb :

1. Lakukanpenelusuran mundur sampai ditemukan record <T_i start> untuk setiap transaksiT_i dalam undo-list.

-          Selama penelusuran, jalankan operasi undo untuk setiap record dalam file log yangmemiliki transaksi Ti pada undo-list.

2. Cari record <checkpoint L> terakhir dalam filelog.
3. Lakukanpenelusuran maju pada file log mulai dari record <checkpoint L> terakhir dan jalankan operasi .

-          redo untuk setiap record dalam file log yang dimiliki transaksi Ti yang ada dalam redo-list

Contoh Recovery

Langa algorithma recovery dalam file log:

<T₀ start>

<T₀, A, 0, 10>

<T₀ commit>

<T₁ start>

<T₁, B, 0, 10>

<T₂ start>                   /* Scan in Step 4 stops here */

<T₂, C, 0, 10>

<T₂, C, 10, 20>

<checkpoint {T₁, T₂}>

<T₃ start>

<T₃, A, 10, 20>

<T₃, D, 0, 10>

<T₃ commit>

Backup

Berdasarkan waktu pelaksanaan atau strateginya ada 2 jenis operasi backup :

1. Backup statis (Offline backup), dimana backup dilakukan dengan lebih dulu menonaktifkan basis data secara keseluruhan.

-          Backup statis dapat dilakukan oleh sistem operasi atau dengan program khusus yang diadakan DBMS.

-          Backup statis dilakukan dengan penyalinan obyek database secara keseluruhan

2. Backup dinamis (online backup), dimana backup dilakukan tanpa penonaktifan basis data.

-          Backup dinamis dilakukan dengan penyalinan database secara keseluruhan dengan cara selektif, yaitu hanya terhadap tabel-tabel yang mengalami perubahan, misalnya dengan checkpoint

-          Secara periodik, dbms akan melakukan pembentukan file dump di media penyimpanan stabil yang berisi salinan dari semua tabel sebelum terjadinya perubahan

Sistem backup jarak jauh

Remote backup memungkinkan sistem berjalan terus meskipun penyimpan utama mengalami kerusakan.

Pendeteksian kerusakan:

-          Harus menerapkan beberap asaluran komunikasi yang independen diantara situs utama dengan situs backup.

Pemindahan kendali:

-          Ketika situs utama mengalami kerusakan situs backup akanmengambil alih pemrosesan menjadi situs primer baru

Waktu untuk pemulihan

-          Jika isi file log pada situs remotebackup menjadi besar sekali proses recovery akan emmakan waktu, untuk dapat diatas dengan melakukan record redo secara periodik

-          Konfigurasi hot spare dapat membuat proses pengalihan kontrol berlangsung cepat

Waktu untuk commit

-          supaya ada jaminan bahwa perubahan pada transaksi tercommit, sebuah transaksi tidak harus dinyatakan commit sebelum record lognya diterima situs backup.

Derajat durabilitas dapat diklasifikasikan sebagai :

-          One safe. Sebuah transaksi dicommit segera setelah record log tersebut telah ditulis pada situs lokal.

-          Two very safe. Sebuah transaksi di commit segera setelah record log tersbut telah direkam baik pada situs primer maupun backupnya.

Block Storage Operations

Portion of the Database Log Corresponding to T₀ and T₁

 State of the Log and Database Corresponding to T0 and T1

Portion of the System Log Corresponding to T0 and T1

 State of System Log and Database Corresponding to T0 and T1