IMPLEMENTASI CONCURRENCY CONTROL DALAM DATABASE ORACLE 10G UNTUK MULTIUSER MENGGUNAKAN ORACLE PLSQL (Contoh Kasus : Aplikasi Berupa Simulasi Untuk Teller Bank dalam Mengakses Rekening Nasabah Bank)

  

IMPLEMENTASI CONCURRENCY CONTROL DALAM

DATABASE ORACLE 10G

UNTUK MULTIUSER MENGGUNAKAN ORACLE PL/SQL

(Contoh Kasus : Aplikasi Berupa Simulasi Untuk Teller Bank

dalam Mengakses Rekening Nasabah Bank)

  

SKRIPSI

Ditujukan Untuk Memenuhi Salah Satu Syarat

Memperoleh Gelar Sarjana Teknik Jurusan Teknik Informatika

  

Disusun Oleh :

Shinta Grace Octovia

015314090

  

JURUSAN TEKNIK INFORMATIKA

FAKULTAS SAINS & TEKNOLOGI

UNIVERSITAS SANATA DHARMA

YOGYAKARTA

  

2007

  

IMPLEMENTATION OF CONCURRENCY CONTROL IN

DATABASE ORACLE 10G

FOR MULTIUSER USING ORACLE PL/SQL

(Case Study : Aplication in Simulation Form Used By Bank Teller

  

In Order To Access The Customer Bank Account)

SKRIPSI

Proposed To Fulfil One Of The Requirements

  

To Obtain Bachelor Degree In Information Technology

By :

Shinta Grace Octovia

  

015314090

  

INFORMATION TECHNOLOGY

FACULTY OF SCIENCE & TECHNOLOGY

SANATA DHARMA UNIVERSITY

YOGYAKARTA

  

2007

  

PERNYATAAN

  Dengan ini saya sebagai penulis tugas akhir menyatakan dengan sesungguhnya bahwa skripsi yang saya tulis ini tidak memuat karya atau bagian karya orang lain, kecuali pemikiran, metode atau hasil penelitian orang lain yang diambil disebutkan dengan jelas sebagai acuan.

  Yogyakarta, September 2007 Penulis Shinta Grace Octovia

HALAMAN PERSEMBAHAN

  Karya ini kupersembahkan untuk : “The King Of Majesty”, Tuhanku Yesus Kristus, karena atas anugerahNyalah karya ini dapat dimulai serta diakhiri dengan indah. Segala hal yang terbaik hanya pantas diberikan untukNya… ,

  Bapak dan Mama, atas kuatnya dukungan cinta lewat doa, semangat dan harapan yang tidak pernah pudar, untukku...

  , Babang, Tinus, Uda, InangUda, Bou, Amangboru, serta semua sepupu & seluruh keluarga besar, yang senantiasa memberikan dorongan semangat serta dukungan doa, untukku…

  , “My BIG family in Christ”, yang telah mendukungku dalam meraih segala hal yang terbaik yang telah DIA tentukan sejak semula… ,

  Seluruh sahabat & teman, yang telah menemaniku dan turut memberikan kehangatan pada hari-hari yang telah kujalani…

HALAMAN MOTTO

  “ Trust in the LORD with all your heart and lean not on your own understanding; in all your ways acknowledge Him, and He will make your paths straight” Proverbs 3 : 5-6 Ia membuat segala sesuatu indah pada waktunya..

   ( Pengkhotbah 3 :11a)

“Aku melayangkan mataku ke gunung-gunung;

dari manakah akan datang pertolonganku?

  

Pertolonganku ialah dari TUHAN,

yang menjadikan langit dan bumi ”

• Mazmur 121 : 1-2 –

  ABSTRAKSI

  Transaksi dalam sebuah aplikasi yang digunakan oleh single user menjamin keakuratan data dalam database yang diupdate pada suatu waktu.

  Namun lain halnya pada transaksi yang terjadi pada aplikasi yang digunakan oleh beberapa user/multiuser. Harus ada managemen transaksi berupa concurrency

  control

  untuk mengelola transaksi-transaksi yang terjadi. Hal ini menjadi penting mengingat transaksi yang terjadi pada aplikasi yang digunakan oleh multiuser tersebut dapat saja terjadi secara bersama-sama dalam suatu waktu dan dapat melakukan intervensi secara simultan pada suatu item data. Jika transaksi- transaksi tersebut tidak dikelola dengan baik oleh database, maka akan dapat mengakibatkan data yang tidak valid serta tidak konsisten.

  Concurrency control dalam managemen transaksi ini akan

  diimplementasikan dalam contoh kasus berupa aplikasi simulasi untuk teller Bank dalam mengakses rekening nasabah Bank. Setiap teller akan diberi hak untuk mengakses database rekening nasabah. Namun pada suatu waktu ada kemungkinan rekening seorang nasabah di-update secara bersama-sama oleh lebih dari satu teller. Implementasi concurrency control yang baik untuk multiuser pada setiap transaksi dalam database dapat menjamin data dalam keadaan yang valid dan konsisten.

  ABSTRACT The transaction of an application using for single user guarantee the

accuracy data on database when updated on a same periodic time. However, in

the same case, it could be different with the transaction which used by multiusers.

Management transaction such as concurrency control is needed to manage the

transactions occured. Concurrency control is an important matter because the

transactions occured on the application which used by the multiusers could be

happen concurrently at the same time and could be execute as simultant

intervension on a data item. When the transactions are not manage in a good

management transaction such as concurrency control on the database, it caused

the data result not valid and not consistent.

  Concurrency control on this transaction management case will be

implemeted on the case study of application in simulation form used by bank

teller in order to access the customer bank account. Every teller has rightful

authority to access the database account of the costumer. However, at the same

periodic time there probably updating occured to the account simultantly by more

than one teller. A good implementation of concurrency control for multiuser at the

transaction when accessing item data on the database could guarrantee the data

in a valid and consistent condition.

KATA PENGANTAR

  Puji dan syukur penulis panjatkan kepada Tuhan Yang Maha Kuasa yang telah melimpahkan berkat-Nya sehingga penulis dapat menyelesaikan Laporan Tugas Akhir ini. Penulisan tugas akhir ini ditujukan untuk memenuhi salah satu syarat memperoleh gelar Sarjana Teknik Jurusan Teknik Informatika.

  Terselesaikannya penulisan tugas akhir ini tidak lepas dari peran serta beberapa pihak, baik secara langsung maupun secara tidak langsung. Oleh karena itu, penulis ingin menyampaikan terima kasih kepada pihak-pihak yang telah ikut membantu dalam penulisan tugas akhir ini, baik dalam memberikan bimbingan, petunjuk, kerjasama, kritikan, maupun saran antara lain kepada:

  1. Bapak JB. Budi Darmawan, S.T., M.Sc., selaku Dosen Pembimbing, yang telah banyak membantu terutama dalam memberikan bimbingan, dukungan, dan perhatian, sehingga penulis dapat menyelesaikan laporan tugas akhir ini. Terima kasih banyak atas semuanya, Pak.

  2. Ibu Agnes Maria Polina, S.Kom., M.Sc., selaku Ketua Jurusan Teknik Informatika Universitas Sanata Dharma.

  3. Bapak Alb. Agung Hadhiatma, S.T., M.T dan Bapak H. Agung Hernawan, S.T, selaku Dosen Penguji TA.

  4. Seluruh Dosen Universitas Sanata Dharma, khususnya Dosen yang mengajar di Teknik Informatika, yang telah memberikan dan mengajarkan banyak ilmu

  5. Bapak dan Mama yang telah mendukungku sepenuhnya. Trimakasih untuk segenap keberadaan diri kalian untukku... I’m so blessed to have you as my parents.

  6. My lovely Bro’: Babang & Tinus. Trimakasih untuk dorongan semangat terus menerus lewat sms, hehe! ☺ Always prays, that God give you all the best in your life...

  7. Uda&Inanguda, Bou&Amangboru, Ica dan segenap keluarga besar Hutasoit.

  Mauliate...

  8. My BIG.. BIG.. family in Christ : TQ for all the joy & happiness!! Buat AKTBku : Herma, Yuli, Geo, Fani. TQ tuk dukungan dalam bentuk - sms, doa, dll... I praise God to have u all as my lovely sista...

• Kak Fona & Bang Be, TQ a lot 4 da everything..

  Fanya, Ardi, Pras, Reni, Fani Hohoho!! Always “FACING OUR - GIANT!!!” ☺ SEMANGAT!!! Adik-adik TPSY semuanya! TQ dah jadi “pasukan doa”ku ☺ - Rekan-rekan P’tas, semuanya!! TQ!! -

  9. Vrysca & Lia, TQ untuk segenap bentuk pertolongan yang tepat pada waktunya... Hehe ☺

  10. Teman-teman kost 99999 : Diana, Maria, July, Welly, Jean, Vivi, Olive.

  Makasih banget dah nemenin hari-hariku dengan banyak tawa.

  11. Teman-teman TI’01 : Nia (TQ for our sharing ‘bout anything), Nita, Vivi, Christin, Desni, Andri, Tio, Andi, Sigit, Anand, Dami, Wahyu (& Anton),

  Narko & Teman-teman kelompok proyek RPL : Yoseph, Manu, Vini (yang dah jauh dimato).

  12. Untuk Rina, Gini, Lia, Mahendra, Ani, Fani, Mindy, yang terus menerus memberikan semangat kepada penulis untuk menyelesaikan TA ini.

  13. Matakuliah : KALKULUS... TQ dah ngajarin arti “Perjuangan tak henti” menghadapi setiap keterbatasan diri di “sekolah kehidupan” ini.

  14. Dan seluruh pihak yang telah ikut ambil bagian dalam penyelesaian laporan tugas akhir ini yang tidak dapat penulis sebutkan satu-persatu.

  Seperti kata pepatah, “Tak ada gading yang tak retak”, maka penulis menyadari segala keterbatasan dalam menyelesaikan laporan tugas akhir ini. Oleh karena itu, penulis ingin menyampaikan mohon maaf apabila terdapat kesalahan dan kekurangan. Untuk itu, penulis mengharapkan kritik dan saran yang membangun dari seluruh pihak yang membutuhkan laporan tugas akhir ini.

  Semoga laporan tugas akhir ini dapat memberikan manfaat bagi siapa saja yang membutuhkannya. Atas segala perhatiannya dan kerjasamanya, penulis ucapkan terima kasih.

  Yogyakarta, September 2007 Penulis, Shinta Grace Octovia

  

DAFTAR ISI

Halaman Judul........................................................................................................

  i Halaman Persetujuan.................................................................................................. ii Halaman Pengesahan........................................................................................ iii Halaman Pernyataan......................................................................................... iv Halaman Persembahan.............................................................................................. v Halaman Motto................................................................................................. vi Abstraksi........................................................................................................... vii Abstract................................................................................................................ viii Kata Pengantar.................................................................................................... ix Daftar Isi........................................................................................................... xii Daftar Gambar................................................................................................... xvi Daftar Tabel....................................................................................................... xviii BAB I Pendahuluan ……………………………………………………………..

  1 1.1 Latar Belakang Masalah………………………………….....................

  1 1.2 Rumusan Masalah..…………………………………………………….

  2 1.3 Batasan Masalah.……………………………….……………………….

  2 1.4 Tujuan Penelitian..…………………………………………..................

  3 1.5 Metodologi Penelitian .………………………………………................

  3 1.6 Sistematika Penelitian…………………………………….....................

  4 BAB II Landasan Teori………………………………………………………….

  5

  2.2 Pembahasan tentang Concurrency Control…………………………….

  7

  2.2.1 Kebutuhan Concurrency Control…………………………………

  7

  2.2.2 Masalah yang Muncul dalam Akses Bersama dan Hasil yang Diharapkan……………………………………………………….

  8 2.3 Concurrency Control dalam Oracle........................................................

  11 2.3.1 Multiversion Read Consistency………………………………..

  12 2.3.2 Macam-macam Level Isolasi Oracle..........................................

  15 2.3.3 Deteksi Deadlock……………...................................................

  17 2.4 Database Oracle 10g..............................................................................

  17 2.5 Pemrograman Database dengan Oracle PL/SQL................................

  19 2.5.1 Mengambil Data di PL/SQL........................................................

  21 2.5.2 Memasukkan Data Menggunakan PL/SQL.................................

  21 2.5.3 Meng-update dan Menghapus Data..............................................

  22 2.5.4 Konvensi Nama……....................................................................

  22 2.5.5 Mengontrol Transaksi……........................................................

  23 2.6 Aplikasi Database C#.NET...................................................................

  24 2.6.1 Mengenal C#.NET......................................................................

  24 2.6.2 Teknologi ADO.NET.................................................................

  24 2.6.2.1 Oracle Connection……………………………………..

  26 2.6.2.2 Oracle Data Adapter dan Data Set………......................

  26 2.6.2.3 Oracle Command…........................................................

  27

  2.6.3 Membuat Koneksi Database……………………………………

  27

  3.1 Analisa Permasalahan…………………………………………………

  47

  39

  40

  40

  43

  43

  44

  52

  37

  58

  64

  71

  74

  76 4.4.6 User Interface Form Transaksi Transfer Saldo..........................

  4.4.7 User Interface Form Transaksi Total Saldo................................

  4.4.8 User Interface Form Hasil Transaksi Penarikan Tunai..............

  39

  37

  3.1.1 Permasalahan-permasalahan yang Timbul jika Tidak Terdapat Penanganan Concurrency Control……………………………..

  4.4.1 User Interface Form Utama.............................................................

  3.1.2 Sistem yang Dikembangkan…………………………………… 3.1.3 Requirement Analysis..................................................................

  3.1.4 Data Modelling………………………………………………… 3.2 Perancangan Sistem ………………………………………………….

  3.2.1 Perancangan Database………………………………………… BAB IV Implementasi Sistem……….………………………………………….

  4.1 Karakteristik Sistem………………………………………………….

  4.2 Kebutuhan Sistem…………………………………………………… 4.3 Setting Koneksi Oracle 10g XE ke C#.Net………………………….

  4.4 Pembuatan Antar Muka Pemakai (User Interface)..............................

  4.4.2 User Interface Form Login Teller Bank.....................................

  34

  4.4.3 User Interface Menu Utama.......................................................

  4.4.4 User Interface Form Transaksi Penarikan Tunai........................

  4.4.5 User Interface Form Transaksi Penyetoran Tunai.......................

  28

  29

  31

  33

  4.4.9 User Interface Form Hasil Transaksi Penyetoran Tunai............

  4.4.11 User Interface Form Hasil Transaksi Total Saldo Nasabah......

  81

  83 BAB V Analisa Hasil.........................................................................................

  83 5.1 Pengujian Aplikasi ...............................................................................

  5.1.1 Pengujian Aplikasi Tanpa Menggunakan Concrrency

  83 Control.........................................................................................

  5.1.1.1 Pengujian Terhadap Masalah Hilangnya Data yang

  84 Diubah ( Lost of Update)....................................................

  5.1.1.2 Pengujian Terhadap Masalah Analisa yang Tidak Konsisten ( The Inconsistent Analysis Problem)..............

  89

  5.1.2 Pengujian Aplikasi Dengan Menggunakan Concurrency Control....................................................................

  94

  5.1.2.1 Pengujian Terhadap Masalah Hilangnya Data yang

  96 Diubah ( Lost of Update)..................................................

  5.1.2.2 Pengujian Terhadap Masalah Analisa yang Tidak 101 Konsisten ( The Inconsistent Analysis Problem)...............

  5.2 Kelebihan dan Kekurangan Sistem.......................................................... 108 108 5.3.1 Kelebihan Sistem .......................................................................... 109 5.3.2 Kekurangan Sistem......................................................................

  BAB VI Penutup .................................................................................................. 110 110 6.1 Kesimpulan ............................................................................................

  6.2 Saran ...................................................................................................... 110 111 DAFTAR PUSTAKA............................................................................................

  

DAFTAR GAMBAR

Tabel Keterangan Halaman

  52 Gambar 4.7 Form Transaksi Penarikan Tunai Untuk Aplikasi Dengan Concurrency Control

  76 Gambar 4.17 Form Hasil Transaksi Penyetoran Tunai Untuk

  75 Gambar 4.16 Form Hasil Transaksi Penyetoran Tunai Untuk Aplikasi Tanpa Concurrency Control

  74 Gambar 4.15 Form Hasil Transaksi Penarikan Tunai Untuk Aplikasi Dengan Concurrency Control

  71 Gambar 4.14 Form Hasil Transaksi Penarikan Tunai Untuk Aplikasi Tanpa Concurrency Control

  71 Gambar 4.13 Form Transaksi Total Saldo Untuk Aplikasi Dengan Concurrency Control

  65 Gambar 4.12 Form Transaksi Total Saldo Untuk Aplikasi Tanpa Concurrency Control

  64 Gambar 4.11 Form Transaksi Transfer Saldo Untuk Aplikasi Dengan Concurrency Control

  59 Gambar 4.10 Form Transaksi Transfer Saldo Untuk Aplikasi Tanpa Concurrency Control

  58 Gambar 4.9 Form Transaksi Penyetoran Tunai Untuk Aplikasi Dengan Concurrency Control

  53 Gambar 4.8 Form Transaksi Penyetoran Tunai Untuk Aplikasi Tanpa Concurrency Control

  48 Gambar 4.6 Form Transaksi Penarikan Tunai Untuk Aplikasi Tanpa Concurrency Control

Gambar 2.1 Diagram Transsisi Transaksi

  47 Gambar 4.5 Form Menu Utama Untuk Aplikasi Dengan Concurrency Control

  45 Gambar 4.4 Form Menu Utama Untuk Aplikasi Tanpa Concurrency Control

  44 Gambar 4.3 Form Login Teller Bank Untuk Aplikasi Dengan Concurrency Control

  43 Gambar 4.2 Form Login Teller Bank Untuk Aplikasi Tanpa Concurrency Control

  37 Gambar 4.1 User Interface Form Utama

  36 Gambar 3.6 Tabel Relasi Transaksi Pada Teller Bank

  35 Gambar 3.5 Data Flow Diagram

  35 Gambar 3.4 Diagram Berjenjang

  34 Gambar 3.3 Context Diagram

  33 Gambar 3.2 ER-Diagram

  6 Gambar 3.1 Use Case Diagaram

  77

Gambar 4.18 Form Hasil Transaksi Transfer Saldo Tanpa

  78 Concurrency Control

Gambar 4.19 Form Hasil Transaksi Transfer Saldo Dengan

  79 Concurrency Control

Gambar 4.20 Form Hasil Transaksi Total Saldo Tanpa

  81 Concurrency Control

Gambar 4.21 Form Hasil Transaksi Total Saldo Dengan

  81 Concurrency Control

Gambar 5.1 Simulasi 2 Transaksi Berjalan Bersamaan untuk

  85 Aplikasi Tanpa Concurrency Control – Hilangnya Data Yang Diubah

Gambar 5.2 Simulasi Hasil Transaksi 2 Transaksi Berjalan

  85 Bersamaan untuk Aplikasi Tanpa Concurrency Control – Hilangnya Data yang Diubah

Gambar 5.3 Simulasi 2 Transaksi Berjalan Bersamaan untuk

  90 Aplikasi Tanpa Concurrency Control – Masalah Analisa yang Tidak Konsistent

Gambar 5.4 Simulasi Hasil Transaksi 2 Transaksi Berjalan

  91 Bersamaan untuk Aplikasi Tanpa Concurrency Control – Masalah Analisa yang Tidak Konsisten

Gambar 5.5 Simulasi 2 Transaksi Berjalan Bersamaan untuk

  96 Aplikasi Dengan Concurrency Control – Terhadap Masalah Hilangnya Data Yang Diubah

Gambar 5.6 Simulasi Hasil Transaksi 2 Transaksi Berjalan

  97 Bersamaan untuk Aplikasi Dengan Concurrency Control – Terhadap Masalah Hilangnya Data yang Diubah

Gambar 5.7 Simulasi 2 Transaksi Berjalan Bersamaan untuk 102

  Aplikasi Dengan Concurrency Control – Masalah Analisa yang Tidak Konsistent

Gambar 5.8 Simulasi Hasil Transaksi 2 Transaksi Berjalan 103

  Bersamaan untuk Aplikasi Dengan Concurrency Control – Masalah Analisa yang Tidak Konsisten

  DAFTAR TABEL Tabel Keterangan Halaman

Tabel 2.1 Level Isolasi Transaksi Menurut SQL92

  10 Tabel 2.2 Berbagai Tipe Data PL/SQL

  19 Tabel 2.3 Berbagai Operator PL/SQL

  20 Tabel 2.4 Namespace Pada ADO.NET

  25 Tabel 3.1 Ilustrasi Masalah Hilangnya Data Yang Diubah

  29 Tabel 3.2 Ilustrasi Masalah Analisa Yang Tidak Konsisten

  30 Tabel 3.3 Struktur Tabel Nasabah

  38 Tabel 3.4 Struktur Tabel Jenis Transaksi

  38 Tabel 3.5 Struktur Tabel Transaksi

  38 Tabel 3.6 Struktur Tabel Teller Bank

  38 Tabel 5.1 Proses Yang Terjadi Pada Pengujian Aplikasi

  88 Tanpa Menggunakan Concurrency Control – Terhadap Masalah Hilangnya Data Yang Diubah

Tabel 5.2 Proses Yang Terjadi Pada Pengujian Aplikasi

  94 Tanpa Menggunakan Concurrency Control – Terhadap Masalah Analisa Yang Tidak Konsisten

Tabel 5.3 Proses Yang Terjadi Pada Pengujian Aplikasi 100

  Dengan Menggunakan Concurrency Control – Terhadap Hilangnya Data Yang Diubah

Tabel 5.4 Proses Yang Terjadi Pada Pengujian Aplikasi 107

  Dengan Menggunakan Concurrency Control – Terhadap Masalah Analisa Yang Tidak Konsisten

BAB I PENDAHULUAN

1.1 Latar Belakang Masalah

  Masalah yang timbul dalam sebuah aplikasi database untuk multiuser yaitu bagaimana database tersebut dapat menjamin data yang dipresentasikan kepada user merupakan data yang konsisten, walaupun terdapat beberapa transaksi yang mengeksekusi data tersebut dalam waktu yang hampir bersamaan. Akses bersama pada suatu aplikasi database untuk multiuser relatif lebih mudah jika semua user hanya membaca data, sehingga tidak ada yang saling melakukan interfensi satu dengan yang lainnya terhadap suatu data. Namun lain halnya jika pada suatu saat yang hampir bersamaan terdapat dua atau lebih user yang mengeksekusi suatu data dalam database secara simultan atau paling sedikit terdapat satu user yang melakukan update, padahal user lain yang mengeksekusi data tersebut belum selesai dengan eksekusinya, hal ini mengakibatkan data yang diberikan kepada user dalam keadaan tidak konsisten dan tidak valid. Diperlukan sebuah penanganan berupa concurrency control untuk melindungi data dari akses secara simultan oleh multiuser.

  Salah satu contoh implementasi penanganan concurrency control yang baik dalam dunia nyata adalah aplikasi yang digunakan oleh Teller Bank dalam mengakses rekening Nasabah Bank. Pada saat yang hampir bersamaan mungkin suatu data dari database rekening nasabah milik seorang Nasabah Bank. Permasalahan yang timbul yaitu bagaimana data dalam database yang diberikan kepada user tetap konsisten dan merupakan hasil yang sebenarnya, walaupun terdapat beberapa interfensi/perubahan yang dilakukan oleh beberapa Teller Bank terhadap suatu data rekening milik seorang Nasabah dalam waktu yang hampir bersamaan dan secara simultan.

1.2 Rumusan Masalah

  Dari latar belakang masalah diatas terdapat beberapa rumusan masalah yaitu:

1. Bagaimana mengimplementasikan concurrency control dalam database

  Oracle 10g untuk multiuser dengan menggunakan Oracle PL/SQL?

  2. Bagaimana mengintegrasikan implementasi concurrency control dalam database Oracle 10g tersebut dalam sebuah aplikasi untuk Teller Bank dalam mengakses rekening Nasabah Bank?

1.3 Batasan Masalah

  concurrency control

  Dalam mengimplementasikan dalam database Oracle 10g untuk multiuser dengan menggunakan Oracle PL/SQL, contoh kasus aplikasi berupa simulasi untuk Teller Bank dalam mengakses rekening Nasabah Bank, dilakukan batasan sebagai berikut:

1. Database yang digunakan diasumsikan database terpusat (centralized

  database

  2. Aplikasi hanya berupa simulasi, bukan program utuh yang dapat dipakai oleh Teller Bank.

  3. Tidak membahas jaringan komputer dan keamanannya.

  1.4 Tujuan Penelitian

  Mengimplementasikan concurrency control dalam database Oracle 10g untuk multiuser dalam suatu aplikasi untuk end user berupa aplikasi simulasi untuk Teller Bank dalam mengakses rekening Nasabah Bank.

  1.5 Metodologi Penelitian

  1. Studi pustaka tentang concurrency control dalam Oracle

  2. Menganalisa permasalahan-permasalahan yang dapat terjadi dalam aplikasi untuk multiuser dan merumuskan sistem yang akan dibangun untuk dapat mengatasi permasalahan-permasalahan yang ada.

  3. Merancang sistem yang akan dibangun meliputi perancangan database, perancangan user interface secara terinci guna memberikan gambaran umum mengenai sistem yang akan dibangun.

  4. Mengimplementasikan rancangan aplikasi untuk Teller Bank dengan implementasi concurrency control didalamnya..

1.6 Sistematika Penelitian

  Sistematika penelitian skripsi secara garis besar meliputi:

  BAB I. PENDAHULUAN Bab ini berisi tentang Latar Belakang Masalah, Rumusan Masalah, Batasan Masalah, Tujuan Penelitian, Metodologi Penelitian, Sistematika Penulisan. BAB II. LANDASAN TEORI Bab ini membahas landasan teori yang menjelaskan tentang Transaction Management, Concurrency control, Concurrency control dalam Oracle, Database Oracle 10g, Pemrograman Database dengan Oracle PL/SQL, dan Aplikasi untuk User menggunakan C#.NET.

BAB III. ANALISA PERMASALAHAN DAN PERANCANGAN SISTEM Bab ini membahas tentang analisa permasalahan, system yang dikembangkan, perancangan database, dan perancangan user interface. BAB IV. IMPLEMENTASI SISTEM Bab ini membahas mengenai cara mengimplementasikan sistem yang dibuat kedalam suatu program. BAB V. ANALISA HASIL Bab ini berisi analisa hasil dari imlementasi yang telah dibuat pada bab sebelumnya. BAB VI. KESIMPULAN DAN SARAN Bab ini berisi kesimpulan dan saran.

BAB II LANDASAN TEORI

2.1 Pembahasan tentang Management Transaksi

  Transaksi adalah sebuah tindakan atau serangkaian tindakan, dilakukan oleh single user atau program aplikasi, yang membaca atau mengubah isi dari database. Terdapat 4 hal dasar yang harus dimiliki semua transaksi, yaitu:

1. Atomicity. Sebuah transaksi adalah sebuah unit yang tidak dapat dibagi lagi sehingga dapat melakukan seluruhnya atau tidak melakukan apapun.

  Ini merupakan tanggung jawab dari subsystem recovery dari DBMS untuk memastikan ke’atom’annya.

  2. Consistency. Sebuah transaksi harus mentransformasikan satu keadaan konsisten ke keadaan konsisten lainnya. Ini merupakan tanggung jawab dari DBMS dan pengembang aplikasi untuk memastikan kekonsistenannya.

  3. Isolation. Transaksi secara bebas mengeksekusi yang lainnya. Dengan kata lain, sebagian transaksi yang tidak lengkap akan mengakibatkan transaksi yang lain menjadi tidak visible.Ini merupakan tanggung jawab dari subsistem concurrency control untuk memastikan isolasi.

  4. Durability. Setelah DBMS memberitahu pengguna bahwa transaksi telah selesai dengan sukses, maka efeknya tetap bertahan bahkan jika system

  Ini merupakan tanggung jawab dari recovery subsystem untuk memastikan durability .

  Berikut Gambar2.1 merupakan digram transisi sebuah transaksi:

  commit

PARTIALLY

  End

  COMMIT TED

COMMIT ED

  transaction Begin transaction abort

  ACTIVE

  abort

FAILED ABORTED

Gambar 2.1 Diagram Transisi Transaksi

  Dalam diagram transisi terdapat 5 keadaan yaitu:

  1. ACTIVE (aktif)

  2. PARTIALLY COMMITTED (sebagian dilaksanakan)

• terjadi setelah perintah terakhir dieksekusi
• pada saat ini, mungkin ditemukan transaksi melanggar serializability atau melanggar integrity constraint, maka transaksi harus dibatalkan. Transaksi demikian akan menuju FAILED (keadaan gagal) dan harus dibatalkan
• jika transaksi sukses, beberapa update dapat disimpan secara aman

  3. COMMITTED (dilaksanakan)

  4. FAILED (gagal)

• Terjadi jika transakasi tidak dapat dilaksanakan atau transaksi dibatalkan pada saat ACTIVE (keadan aktif).
• Kondisi ini terjadi jika user membatalkan transaksi atau protocol

  concurrency control membatalkan transaksi untuk memastikan serialibility.

  5. ABORTED (dibatalkan)

2.2 Pembahasan tentang Concurrency control

  Concurrency control adalah proses pengelolaan operasi-operasi yang

  berjalan bersamaan dalam database dengan tidak saling mengganggu satu sama lain.

2.2.1. Kebutuhan Concurrency control

  Kebutuhan concurrency control dalam managemen transaksi untuk multiuser menjadi penting, mengingat sistem untuk multiuser memungkinkan terjadinya akses bersama terhadap sebuah database. Akses bersama relatif mudah jika seluruh user hanya membaca data, sehingga tidak ada yang melakukan interfensi satu dengan lainnya. Akan tetapi, pada saat dua atau lebih user mengakses database secara simultan dan paling sedikit satu user melakukan update, maka akan terjadi interfensi yang dapat mengakibatkan

  

2.2.2. Masalah yang Muncul dalam Akses Bersama dan Hasil yang

Diharapkan

  Terdapat beberapa masalah yang dapat terjadi yang disebabkan oleh akses bersama oleh multiuser, yaitu:

  1. Lost update problem (Masalah hilangnya data yang diupdate) : Sebuah transakasi yang melakukan update, namun pada waktu interfal yang bersamaan proses update tersebut ditimpa oleh transaksi lain.

  2. Uncommitted dependency problem / dirty read (masalah kebergantungan terhadap transaksi yang belum commit) : Sebuah transaksi dibiarkan untuk melihat hasil transaksi intermediate (menengah) dari transaksi lain sebelum dilakukan commit.

3. Inconsistent analysis problem (masalah analisa yang tidak konsisten) :

  Sebuah transaksi membaca beberapa nilai dari database tetapi transaksi kedua melakukan update terhadap sebagian dari beberapa nilai tersebut selama proses eksekusi yang pertama.

  4. Nonrepeatabel (atau fuzzy) read : Sebuah transaksi T membaca ulang data item yang sebelumnya telah dibaca, sementara itu transaksi lain melakukan modifikasi. Sehingga T akan menerima 2 buah nilai yang berbeda untuk data item yang sama.

  5. Phantom read : Transaksi T mengeksekusi sebuah query yang menerima sekumpulan tuple dari sebuah relasi dengan predikat tertentu, melakukan eksekusi ulang query pada waktu berikutnya tetapi menemukan kembali pada waktu tertentu. Untuk menangani masalah-masalah tersebut di atas, diperlukan kontrol yang baik untuk menjamin konkurensi data dan konsistensi data.

• Konkurensi data berarti bahwa banyak user yang dapat mengakses data pada waktu yang bersamaan
• Konsistensi data berarti bahwa masing-masing user dapat melihat tampilan data yang konsisten, termasuk jika terdapat perubahan yang dilakukan oleh transaksi oleh user lain. Kontrol yang baik dalam database terhadap eksekusi dari transaksi yang dijalankan bersamaan yaitu jika transaksi yang dieksekusi bersama tersebut menghasilkan hasil yang sama seperti jika transakasi-transaksi yang ada dieksekusi secara serial (transaksi dijalankan sendiri-sendiri, tanpa ada sela, menjamin konsistensi data). Hal ini dinamakan serializability.

  Serializability , yang merupakan parameter keberhasilan dalam concurrency control

  ini dapat dicapai dengan menggunakan macam-macam level isolasi pada transaksi (transaction isolation levels), mekanisme locking pada data, dan timestamp.

• Level Isolasi. Level isolasi mengontrol tingkat dimana transaksi tertentu terbuka terhadap tindakan transaksi lain yang melakukan eksekusi secara bersama. Dengan memilih satu dari empat kemungkinan pengaturan level isolasi, user dapat memperoleh penanganan konkurensi yang peka terhadap perubahan uncommitted oleh transaksi lain.

READ UNCOMITTED, READ COMMITTED,

  Plilihan level isolasi adalah

  REPEATABEL READ SERIALIZABLE

  dan . Berikut merupakan tabel level isolasi transaksi menurut ANSI/ISO SQL standard (SQL92) terhadap penanganan 3 masalah yang ditemukan dalam akses bersama.

  

Isolation Dirty Read Nonrepea tabel Phantom

level Read Read

Read Mungkin Mungkin Mungkin uncommitted Read

  Tidak Mungkin Mungkin

  committed Repea

  tabel Tidak Tidak Mungkin

  read Serializable Tidak Tidak Tidak

Tabel 2.1 Level Isolasi Transaksi menurut SQL92

  SERIALIZABLE

  Level isolasi secara umum merupakan yang paling aman dan direkomendasikan untuk kebanyakan transaksi. Akan tetapi, beberapa transaksi dapat bekerja dengan level isolasi lebih rendah, dan sejumlah kecil lock yang diminta dapat memberikan konstribusi untuk meningkatkan performa sistem.

• Metode Locking. Locking adalah sebuah prosedur yang digunakan untuk melakukan kontrol pada akses bersama pada data. Pada saat satu transaksi melakukan akses ke dalam database, sebuah lock akan menyebabkan pelarangan akses ke dalam transaksi untuk mencegah hasil yang tidak konsisten. Terdapat 2 jenis lock, yaitu Shared Lock, dan Executive Lock. Jika sebuah transaksi memiliki shared lock pada sebuah data item, maka

tidak dapat melakukan update. Sedangkan jika sebuah transaksi yang memiliki executive lock pada sebuah data item dapat melakukan pembacaan maupun update item tersebut. Namun dalam mekanisme locking, deadlock bisa terjadi. Deadlock adalah sebuah jalan buntu yang merupakan hasil dari dua atau lebih transaksi yang saling menuggu lock yang akan dilepaskan yang dipegang oleh transaksi yang lainnya.

• Metode Timestamp. Timestamp adalah sebuah identitas yang unik yang dibuat oleh DBMS yang menunjukkan adanya waktu starting yang relativ dari sebuah transaksi. Metode ini agak berbeda dengan metode locking. Tidak ada locking, dan tidak ada deadlock. Metode locking pada umunya mencegah konflik dengan cara membuat transaksi yang lain menunggu. Dalam metode timestamp, tidak ada menunggu, transaksi yang mengalami konflik secara sederhana dirollback dan re-start.

2.3 Concurrency control dalam Oracle

  Dalam menangani akses bersama, Oracle menggunakan protokol

  

Multiversion-Read Consistency yang menjamin user melihat data yang konsisten

  yang diminta. Jika user lain mengubah data utama selama proses eksekusi query, Oracle menjaga sebuah versi dari data sebagaimana adanya data tersebut pada waktu query dimulai. Jika terdapat transaksi uncommitted dalam progress ketika query dimulai, Oracle meyakinkan bahwa query ini tidak melihat perubahan yang dibuat oleh transaksi ini. Oracle juga tidak menempatkan beberapa lock pada data untuk operasi baca, yang artinya bahwa sebuah operasi baca tidak pernah memblok sebuah operasi tulis.

2.3.1. Multiversion Read Consistency

  Implementasi dari protocol Multiversion Read Consistency yang akan dibahas meliputi Rollback segment, Serial Change Number (SCN) dan Lock.

• Rollback Segment, merupakan struktur dalam dalam database Oracle digunakan untuk menyimpan informasi undo, ketika transaksi sedang mengubah data dalam blok, Oracle pertama-tama menulis tampilan data sebelumnya ke Rollback segment. Sebagai tambahan untuk mendukung

  Multiversion Read Consistency , Rollback segment juga digunakan untuk

  meng-undo sebuah transaksi. Oracle juga memelihara satu atau lebih

  Redo-Logs , yang merekam semua transaksi yang terjadi dan digunakan untuk me-recover database pada saat terjadi kesalahan dalam system.

• System Change Number (SCN), digunakan untuk memelihara order kronologis yang tepat dalam operasi. Oracle menjaga SCN. SCN adalah sebuah pemikiran tentang timestamp yang merekam order yang didalamnya operasi terjadi. Oracle menyimpan SCN dalam Redo-Log untuk me-redo transaksi dalam urutan yang tepat. Oracle menggunakan SCN untuk menentukan versi sebuah item data yang mana harus digunakan dalam sebuah transaksi. Oracle juga menggunakan SCN untuk menentukan kapan untuk memberikan informasi dari Rollback Segment.
• Lock. Locking terjadi untuk semua statement SQL jadi seorang user tidak pernah membutuhkan untuk me-lock resource-resource yang ada secara tegas, meskipun Oracle menyediakan sebuah mekanisme untuk memperbolehkan seorang user untuk mendapat lock secara manual atau untuk mengubah default locking. Default mekanisme locking, men-lock data pada level terendah dari yang dibatasi untuk menjamin integritas ketika memperbolehkan tingkat tertinggi dari concurrency. Oracle menyimpan informasi row-locking selama blok data actual dimana baris tersebut disimpan. Sebagimana Oracle menyimpan lock pada baris selama blok data, Oracle tidak pernah meningkatkan lock.

  Oracle support tipe-tipe dari lock, meliputi:

• DDL locks- digunakan untuk memproteksi objek skema, seperti definisi dari tabel dan view.
• DML locks – digunakan untuk memproteksi pokok data, sebagai contoh lock pada tabel memprotek seluruh tabel dan baris lock pada baris.
• Internal locks- digunakan untuk memproteksi struktur data yang dishare.
• Internal latches- digunakan untuk memproteksi kamus data entri, file- file data, tabelspace dan rollback segment.
• Distributed lock- digunakan untuk memprotek data dalam sebuah lingkungan distribusi dan atau parallel server
• PCM locks- Parallel cache management (PCM) lock digunakan untuk memproteksi buffer cache dalam sebuah lingkungan parallel server.

Oracle mengenal 2 level konsistensi baca, yaitu statement-level read

  

consistency (konsistensi baca level statement) dan transaction-level read

consistency

  (konsistensi baca level transaksi).

1. Konsistensi Baca Level-Statement (Statement-Level Read Consistency)

  Oracle secara otomatis senantiasa menyelanggarakan konsistensi baca pada level statemen. Hal ini menjamin setiap data yang dikembalikan oleh sebuah query berasal dari sebuah titik tunggal (single point) dalam waktu dimana query tersebut dimulai. Oleh karena itu, sebuah query tidak pernah melihat data kotor/dirty read maupun setiap perubahan yang dilakukan oleh transaksi lain yang

  

commit selama query tersebut dieksekusi. Hasilnya yaitu hanya data yang commit

  sebelum query mulai yang dapat dilihat oleh query. Query tersebut tidak melihat perubahan commit setelah eksekusi statement mulai. Sebuah hasil yang konsisten dibangun untuk setiap query, menjamin kekonsistenan data, dan dalam hal ini tidak memerlukan aksi apapun dari user. Statement-statement SQL seperti SELECT, INSERT, UPDATE, dan DELETE menggunakan sebuah query untuk menetapkan data mana yang akan dipengaruhi. SELECT statement merupakan sebuah query explicit dan dapat mempunyai query bersarang atau operasi join. Sebuah statement INSERT dapat menggunakan beberapa query bersarang. UPDATE dan DELETE statement dapat mengggunakan klausa WHERE atau subquery-subquery untuk menghasilkan hanya beberapa baris dalam sebuah tabel lebih daripada semua baris.

  Beberapa query yang digunakan oleh INSERT, UPDATE dan DELETE operasi hanya melihat data yang telah ada sebelum operasi mulai untuk membuat perubahan.

2. Konsistensi Baca Level-Transaksi (Transaction-Level Read Consistency)

  Konsistensi baca Level-Transaksi ini berjalan di sebuah transaksi yang berjalan menggunakan jenis isolation level serializable. Semua data mengakses gambaran suatu keadaan dari database seperti pada saat sebuah transaksi mulai. Hal ini berarti data yang dilihat oleh semua query pada transaksi yang sama merupakan konsisten dengan pasti pada sebuah titik tunggal (single point) dalam waktu, kecuali jika beberapa query dibuat oleh sebuah transaksi serializable melihat perubahan yang dibuat transaksi tersebut. Konsistensi baca level-transaksi menghasilkan pembacaan yang repeatabel dan tidak membuka sebuah query untuk masalah phantom.

2.3.2. Macam-macam Level Isolasi Oracle READ COMMITTED