tugas_10111497_if11

4
AbstraksiPermasalahan 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 KunciConcurrency 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

Upload: teguh-subekti

Post on 12-Feb-2016

3 views

Category:

Documents


0 download

DESCRIPTION

tugas besar teori SBD

TRANSCRIPT

Page 1: TUGAS_10111497_IF11

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

Page 2: TUGAS_10111497_IF11

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.

Page 3: TUGAS_10111497_IF11

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

Page 4: TUGAS_10111497_IF11

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.