tugas_10111497_if11
DESCRIPTION
tugas besar teori SBDTRANSCRIPT
Abstraksi— Permasalahan yang terjadi pada aplikasi untuk
multiuser yaitu akses bersama yang dilakukan oleh beberapa user
dengan melakukan berbagai transaksi pada waktu yang bersamaan
pada database dapat menyebabkan data yang tidak
konsisten.Diperlukan sebuah penanganan berupa Concurrency
Control dan Recovery System untuk melindungi data dari akses
secara simultan oleh multiuser untuk menghindari inkonsistensi data
sehingga data tidak terjadi keasalahan.Implementasi
Transaction,Concurrency Control,Recovery System dan akan
dilakukan dalam database SQL untuk multiuser dalam suatu aplikasi
untuk end user berupa aplikasi simulasi untuk Teller Bank dalam
mengakses rekening Nasabah Bank.
Kata Kunci— Concurrency Control, Transaction,Recovery
System,Multiuser,konsisten
I. PENDAHULUAN
Permasalahan yang terjadi pada aplikasi untuk multiuser yaitu
akses bersama berupa transaction dengan intensitas tinggi
yang dilakukan oleh beberapa user pada waktu yang
bersamaan terhadap server pada database dapat menyebabkan
data yang tidak konsisten sehingga data yang didapat menjadi
tidak akurat dan terjadi kesalahan .Diperlukan sebuah
penanganan berupa Concurrency Control untuk melindungi
data dari akses secara simultan oleh Mutliuser dan Recovery
System untuk pemulihan data tersebut. Implementasi
Concurrency Control akan dilakukan dalam database SQL
Server untuk multiuser dalam suatu aplikasi untuk end
user berupa aplikasi untuk Teller Bank dalam mengakses
rekening Nasabah Bank. Aplikasi yang dipakai hanya berupa
simulasi bukanmerupakan program utuh dengan
analisis.Dalam hal ini pembahasan akan difokuskan kepada
pembahasan Concurensy Control mengingat perannya yang
sangat signifikan dalam proses pencarian solusi masalah ini.
II. TRANSACTION,CONCURENSY CONTROL,RECOVERY SYSTEM
Transaksi adalah serangkaian aksi yang di lakukan user oleh
aplikasi untuk mengubah isi data base , atau lebih tepatnya
serangkaian aksi yang di lakukan pengguna terehadap suatu
aplikasi. Transaksi selalu merubah dari satu stata konsisten ke stata
lainya,walaupun konsisten data dapat terganggu selama
transaksi berjalan .
Output dari terbagi menjadi 3 hal :
1. Suskses adalah transaksi dikatakan commited dan database
mencapai stata baru atau stata berikutnya
2. Gagal adalah transaksi di katakan aborted, dan
database harus dikembalikan ke stata yang lama
sebelum traksaksi.transaksi ini di sebut roll back atau
undo
3. Transaksi yang comited tidak dappat di gagalkan
transasksi yang di gagalkan akan roolback yang dapat
di proses ulang di waktu mendatangan
Sifat-sifat Transaksi :
Atomiticity(Keutuhan) Transaksi merpakan unit yang
tidak terlihat yang harus dilakukan secara
keseluruhan atau tidak sama sekali
Consistensy(Ketepatan) Transaksi harus mengubah
database dari satu stata konsisten ke stata lainnya/
berikutnya
Isolation(Pemisahan) Transaksi di eksekusi secara
terpisah dari yang satu dengan yang lainya
Durablity(Daya Tahan) Secara permanen direkan ke
dalam database dan tidak akan hilang dikarenakan
kegagalan berikutnya.
Subsitem Transaksi DBMS :
Transaction Manager mengkoordinasikan transaksi
untuk kepentingan program aplikasi, yang saling
berkomunikasi dengan scheduler
scheduler yaitu modul yang bertanggung jawab
menangani implementasi strategi khusus untuk
kontrol concurrency
Kontrol konkurensi adalah masalah yang timbul ketika
beberapa proses terjadi pada berbagai tempat di sistem.
Solusi awal untuk hal ini adalah dengan memastikan
kelas-kelas serializability, two-phase locking, dan
formalisasi pendekatan optimistic. Mekanisme populer
untuk kontrol konkurensi adalah two-phase locking.
Kontrol konkurensi yang dapat disesuaikan
diimplementasikan pada sistem RAID. Penelitian
diharapkan berlanjut, pada bidang semantik dari transaksi
dan terutama pada sistem yang berorientasi objek. Pada
sistem berskala besar, sangat sulit untuk mem-blok akses
ke objek basis data untuk melakukan transaksi. Locking
pada masa yang akan datang tidak akan relevan lagi pada
kasus seperti ini.
Ketika multiple user mengakses multiple objek basis data
yang berada pada multiple site di sistem basis data
terdistribusi, maka permasalahan kontrol konkurensi akan
terjadi.Konflik terjadi apabila sekumpulan read dari satu
IMPLEMENTASI TRANSACTION,CONCURENCY
CONTROL,RECOVERY SYSTEM UNTUK APLIKASI
MULTIUSER MENGGUNAKAN DATABASE SQL
transaksi berpotongan dengan sekumpulan read dari transaksi
lainnya, dan/atau sekumpulan write dari satu transaksi
berpotongan dengan sekumpulan write dari transaksi lainnya.
Transaksi T1 dan T2 dikatakan konflik jika kedua-duanya
dieksekusi pada waktu yang bersamaan. Bila T1 telah selesai
sebelum T2 dikirim ke sistem, dalam kasus ini sekumpulan
read dan write saling memotong, tidak dianggap konflik.
Konflik diperhatikan pada sekumpulan write yang saling
memotong di antara dua transaksi. Ada tiga pendekatan secara
umum untuk mendesain algoritma kontrol konkurensi:
1. Wait. Jika dua transaksi konflik, transaksi yang konflik
harus menunggu sampai transaksi lainnya selesai.
2. Timestamp. Urutan eksekusi transaksi berdasarkan
timestamp. Setiap transaksi memiliki timestamp yang unik dan
dua transaksi yang konflik diselesaikan berdasarkan urutan
timestamp. Timestamp dapat diletakkan di awal, tengah, atau
akhir eksekusi. Pendekatan berdasarkan version digunakan
untuk menentukan timestamp objek basis data.
3. Rollback. Dua transaksi yang konflik, salah satu
transaksinya diulang kembali pengerjaannya. Disebut juga
optimistic, karena bila terjadi konflik maka beberapa transaksi
akan di-rollback. Algoritma berdasarkan Mekanisme Wait
Sistem akan melakukan lock pada entitas basis data. Ada dua
tipe lock:
1. Readlock. Transaksi akan mengunci entitas pada mode
shared. Sehingga transaksi lain yang menunggu untuk
membaca beberapa entitas juga bisa mendapatkan readlock.
2. Writelock. Transaksi akan mengunci entitas pada mode
eksklusif. Jika ada satu transaksi akan melakukan
penulisan pada entitas yang telah di-writelock, maka
transaksi lainnya tidak boleh mendapatkan readlock
maupun writelock pada entitas ini.
Lock akan menimbulkan masalah baru. Livelock dan
deadlock. Livelock terjadi ketika suatu transaksi berkali-
kali gagal dalam mendapatkan lock. Deadlock terjadi
ketika beberapa transaksi melakukan lock pada beberapa
entitas pada saat yang bersamaan; setiap transaksi
mendapatkan lock dari entitas yang berbeda dan saling
menunggu transaksi lainnya untuk melepaskan lock.
Deadlock dapat diatasi dengan:
1. Setiap transaksi melakukan lock pada semua entitas sekali.
Jika ada beberapa lock yang digunakan oleh beberapa
transaksi lainnya, maka transaksi akan melepaskan semua
lock yang ada. 2. Membuat order linier secara acak pada
item-item, dan semua transaksi melakukan urutan request
berdasarkan order ini.
Deadlock ini sangat jarang terjadi, sehingga akan lebih efektif
ditanggulangi ketika telah terjadi daripadamelakukantindakan
preventif dari awal yang memakan biaya lebih besar.Protokol
sederhana yang diperlukan, sehingga setiap transaksi dapat
memenuhi aturan keberlanjutan adalah two-phase locking
(2PL).
1. Fase locking. Transaksi mengambil lock tanpa melepasnya.
2. Fase unlocking. Dalam fase ini, transaksi melepaskan lock
yang ada dan tidak boleh mengambil lock.
lockpoint merupakan keadaan sesaat sebelum pelepasan
lock yang pertama kali dilakukan. Algoritma berdasarkan
Mekanisme Timestamp .Untuk mendapatkan timestamp
unik untuk transaksi pada node berbeda di sistem
terdistribusi, clock setiap node harus disamakan. Untuk
menyelaraskan clock dapat digunakan message passing.
Algoritma berdasarkan Mekanisme Rollback/Optimistic.
Terdapat 4 fase eksekusi transaksi pada pendekatan
kontrol konkurensi optimistic:
1. Read. Proses membaca tidak terlalu dibatasi. Hasilnya
diletakkan pada variabel lokal. Sekumpulan read tergantung
juga pada proses validasi.
2. Compute. Transaksi menghitung sekumpulan nilai dari data
entitas yang disebut sekumpulan write. Hasilnya diletakkan
pada variabel lokal.
3. Validate. Sekumpulan write dan read transaksi lokal
divalidasi oleh sekumpulan transaksi yang sedang berjalan.
4. Commit and Write. Setelah berhasil divalidasi, akan
dijalankan di sistem dan diberikan timestamp. Sekumpulan
write akan diubah menjadi variabel global dan nilainya
dikirim ke setiap node. Jika tidak berhasil divalidasi, transaksi
diulangi lagi dari fase compute atau read.
Evaluasi Performansi dari Algoritma Kontrol Konkurensi
Derajat Konkurensi Serial history memiliki derajat konkurensi yang rendah,
sedangkan pendekatan 2PL dan optimistic memberikan derajat
konkurensi yang lebih tinggi. Tingkat Lanjut untuk
Peningkatan Konkurensi Timestamp yang Multidimensional
Protokol ini memungkinkan transaksi untuk memiliki vektor
timestamp sampai k elemen. Maksimum k diperoleh dari dua
kali jumlah maksimum operasi pada satu kali transaksi.
Relaksasi dari Two-Phase Locking
Suatu transaksi dapat melepaskan suatu lock, sebelum
transaksi ini me-request beberapa lock lagi. Pada transaksi
berikutnya yang mengambil lock ini, lock tidak dapat
dilepaskan sampai transaksi sebelumnya tidak lagi me-request
lock.
System Defined Prewrites
Prewrite menunjukkan bahwa value dari transaksi akan di-
write disaat yang akan datang. Prewrite tidak akan mengubah
status objek data. Ketika prewrite dari suatu transaksi
dilakukan, transaksi akan melakukan operasi precommit.
Setelah tahapan ini, transaksi lain dapat membaca prewrite,
walaupun transaksi ini belum di-update dan di-commit.
Dengan prewrite, sistem yang terdiri dari transaksi berdurasi
panjang maupun pendek dapat diseimbangkan, sehingga tidak
ada delay untuk transaksi berdurasi pendek.
Transaksi yang Fleksibel
Memungkinkan spesifikasi dari beberapa alternatif subset dari
subtransaksi untuk dieksekusi dan menghasilkan eksekusi
yang berhasil dalam satu dari beberapa alternatif subset
tersebut. Eksekusi dari transaksi yang fleksibel dapat diproses
dalam beberapa cara.
Kontrol Konkurensi yang dapat Disesuaikan
Sistem basis data yang ada, saling terhubung dengan sistem
basis data terdistribusi yang heterogen. Penggunaan konsep
sistem basis data Reliable, Adaptable, Interoperable,
Distributed (RAID), menjadi fasilitas dalam metode kontrol
konkurensi. Model umum untuk pendekatan terhadap sistem
dan transaksi yang berbeda adalah dengan generic state,
converting state, dan suffix sufficient state.
KONSEP RECOVERY
Recovery dari suatu kegagalan transaksi biasanya berarti
database direstore ke status yang konsisten ke waktu sebelum
terjadi kegagalan.Untuk mengcover kesalahan atau kegagalan
dari transaksi, sistem memaintain sebuah log untuk menjaga
jalannya semua operasi yang mempengaruhi nilai dari item
database. Informasi ini mungkin akan dibutuhkan untuk
mengcover adanya kegagalan. LOG disimpan di storage, dan
secara berkala diback-up ke storage lainnya untuk menjaga
dari kerusakan yang fatal.
Beberapa strategi recovery :
1. Jika terjadi kerusakan ke sebagian besar database,
misalnya disk crash, metode recovery merestore kopi
sebelumnya dari database yang sudah diback-up ke
storage khusus (biasanya tape) dan membangun
kembali status dengan mengaplikasikan kembali atau
redo operasi dari transaksi yang commit dari log
backed-up sampai waktu dimana terjadi kegagalan
2. Ketika database tidak secara fisik rusak tetapi hanya
menjadi tidak konsisten karena adanya kesalahan
(system crash, system error, local error, concurrency
control), strategi adalah membalik semua perubahan
yang menyebabkan ketidak konsistenan yaitu dengan
meng-undo beberapa operasi. Kemungkinan juga
dengan melakukan redo beberapa operasi supaya dapat
merestore status database yang konsisten.
III.PEMBAHASAN
Pengujian direncanakan dilakukan menggunakan 2 aplikasi
tanpa concurrency control yaitu penarikan tunai dan
penyetoran tunai yang dijalankan bersama-sama dan 2 aplikasi
dengan concurrency yaitu penarikan tunai dan penyetoran
tunai yang dijalankan bersama-sama , masing masing
memiliki delay waktu selama 10 detik. Dengan adanya delay
maka aplikasi yang berjalan dapat dibuat bertabrakan. Delay
ditentukan dalam setiap procedure yang dipakai. Pengujian
terhadap 2 aplikasi yang dijalankan bersamaan (bertubrukkan)
akan merepresentasikan 2 masalah utama yaitu :
Masalah hilangnya data yang diubah (Lost of
Update). Sebagai contoh digunakan, transaksi
penarikan tunai dan penyetoran tunai.
Masalah analisa yang tidak konsisten (Inconsistent
analiysis problem)
Masalah hilangnya data yang diubah (Lost of Update)
Diilustrasikan transaksi Penarikan Tunai dilakukan terhadap
nasabah dengan no rekening 00011 sebesar Rp.200000.
Transaksi Penyetoran tunai juga dilakukan terhadap nasabah
dengan no rekening 00011 sebesar Rp.100000. Jumlah saldo
nasabah dengan no rekening 00011 adalah Rp.1500000.
Transaksi sama-sama dieksekusi, transaksi penyetoran
dieksekusi terlebih dahulu, kemudian transaksi penarikan tunai
berikutnya.
Tanpa Concurrency Control
Transaksi penyetoran tunai lebih dulu selesai dengan keluaran
saldo Rp.1700000 untuk no rekening 00011 dari saldo awal
Rp.1500000 + penyetoran Rp.200000, kemudian transaksi
penarikan tunai selesai dengan keluaran saldo terakhir
Rp.1400000 untuk rekening 001 dari saldo awal Rp 1500000-
penarikan Rp.100000.Dengan demikian, tampak hilangnya
data yang diubah oleh transaksi penyetoran tunai sebesar
Rp.200000. Karena seharusnya data Saldo nasabah terakhir
adalah Rp.1500000 + Rp.200000 –Rp.100000 = Rp. 1600000
Dengan Concurrency Control
Transaksi penyetoran tunai lebih dulu selesai dengan keluaran
saldo Rp.1700000 untuk no rekening 00011 dari saldo awal
Rp.1500000 + Rp.200000, kemudian transaksi penarikan tunai
selesai dengan keluaran saldo terakhir Rp.1600000 untuk
rekening 00011 dari Saldo Rp.1700000 – Rp.100000.
Dengan demikian,tampak bahwa transaksi tidak mengalami
masalah hilangnya data yang diubah.
Masalah analisa yang tidak konsisten (Inconsistent analiysis
problem)
Penghitungan jumlah total saldo seluruh nasabah memiliki
keluaran berupa parameter OUT yaitu nilai_sum yang memuat
jumlah total_saldo seluruh nasabah dengan cara
menjumlahkannya satu persatu. No rekening 00011 memiliki
saldo sebesar Rp.1000000 akan mentransfer saldonya sebesar
Rp.200000 ke nasabah dengan no rekening 00012 yang
memiliki saldo Rp.1000000, Kemudian transaksi sama-sama
dieksekusi.
IV.KESIMPULAN
Aplikasi dapat mencegah masalah hilangnya data yang
diubah (Lost of Update) dan juga masalah analisa yang
tidak konsisten (the inconsistent analysis problem)
Concurrency control dalam SQL Server dapat dicapai
dengan beberapa cara, seperti menggunakan :
Statement SELECT .. FOR UPDATE
Isolation level SERIALIZABLE
Statement UPDATE pada diri sendiri sebelum
melakukan proses baca dengan maksud mengubah data
yang dibaca.
V.DAFTAR PUSTAKA
1. Connolly,T.,Begg, C.,DATABASE SYSTEM A
Practical Approach To Design, Implementation And
Management, Addison Wesley,2002.
2. Ir.Inge Martina, 36 Jam Belajar Komputer Microsoft
SQL Server 2000, Elexmedia Komputindo,2003.
3. Dusan Petkovic, SQL SERVER 7 A BEGINNER’S
GUIDE, Osborne/Mcgraw-Hill,1999.
4. Coulouris George, Dollimore Jean, and Kindberg
Tim, ―Distributed Systems Concepts and Design,‖
Pearson Education Ltd, 2001.