8 2.1. Prinsip Basis Data Terdistribusi
Pengertian basis data terdistribusi/Distributed Database (DDB) adalah suatu kumpulan berbagai basis data yang secara logika saling berhubungan satu dengan lainnya, yang terdistribusi dalam suatu network komputer. Sedangkan pengertian dari Distributed Database Management System (DDBMS) adalah
software yang mengelola DDB dan menyediakan mekanisme akses yang
membuat proses distribusi transparan bagi user. Dari sini dapat disimpulkan bahwa sistem basis data terdistribusi (DDBS) adalah gabungan dari DDB dan DDBMS.
DDBS berbeda dengan sistem basis data terpusat (centralized database). Pada sistem basis data terpusat, basis data hanya berada pada satu node dalam
network (Gambar 2.1.) dan basis data diatur atau dioperasikan secara terpusat oleh
satu sistem komputer (Site 2 dalam Gambar 2.1).
Gambar 2.1. Sistem Basis Data Terpusat dalam Network
Sumber: Ozsu, M.T., & Valduriez, P. (1999). Principles of Distributed Database Systems. Upper Saddle River, NJ: Prentice Hall.
Sedangkan DDBS adalah suatu sistem dimana basis data terdistribusi diantara sejumlah site yang berbeda (Gambar 2.2). Pada DDBS, data disimpan pada beberapa site. Setiap site secara logika terdiri dari satu processor. Processor
DB DB DB Site 1 Site 2 Site 3 Site 5 Site 4 Communication Network
pada beberapa site tersebut saling terkoneksi satu dengan yang lainnya melalui
network (parallel database systems). DDBS bukanlah “koleksi dari file”
melainkan basis data yang terstruktur dari beberapa file dan saling berelasi antar data (Relational data model). DDBS melakukan distribusi pada processing logic,
functions, data dan kontrol.
Gambar 2.2. Lingkungan DDBS dalam Network
Sumber: Ozsu, M.T., & Valduriez, P. (1999). Principles of Distributed Database Systems. Upper Saddle River, NJ: Prentice Hall.
Ada beberapa keuntungan DDBS dibandingkan dengan sistem basis data terpusat, di antaranya dalam hal:
a. Data sharing, dimana menyediakan otonomi terhadap basis data lokal dan tetap memungkinkan site yang lain untuk melakukan akses pada data.
b. Distributed control, dimana DDBS memberikan kemudahan bagi Database
Administrator (DBA) dalam hal mengatur lokal basis data, daripada sistem
basis data terpusat yang sistem pengaturannya secara terpusat.
c. Distributed processing, dengan DDBS maka banyak proses yang dapat dilakukan secara lokal, tidak perlu mengakses site lain seperti yang dilakukan oleh sistem basis data terpusat. Dengan demikian performance basis data semakin meningkat.
d. Reliability, pada DDBS bila suatu site gagal (down) maka site yang lainnya masih dapat malanjutkan operasinya sebab pada setiap site terdapat basis data. e. Mempercepat proses query. Pada DDBS, query dapat dipecah menjadi
beberapa bagian dan dapat melakukan eksekusi query secara paralel..
DB DB DB DB Site 1 Site 2 Site 3 Site 4 Site 5 Communication Network
f. Scalability, basis data yang sangat besar dapat diimplementasikan apabila didistribusikan pada banyak site.
DDBS dapat diaplikasikan ke dalam berbagai sistem, diantaranya sistem manufaktur, sistem militer, perusahaan MIS, penerbangan, hotel dan organisasi lain yang memiliki struktur organisasi desentralisasi.
2.2. Harapan dari DDBS
Banyak keuntungan yang dapat diambil dari DDBS, mulai dari hal sosiologi untuk desentralisasi sampai dengan hal ekonomi. Semuanya ini dapat dibagi menjadi empat pokok yang dapat dilihat sebagai harapan teknologi DDBS.
2.2.1. Manajemen yang Transparan dari Data yang Terdistribusi dan Tereplikasi Transparansi adalah pemisahan higher–level system dengan user
(lower-level) dalam suatu implementasi. Dengan kata lain, transparansi menyembunyikan
perincian implementasi dari user.
Untuk lebih mengerti dan memahami konsep transparansi ini maka dicontohkan suatu kasus basis data yang terjadi dalam perusahaan. Dimana perusahaan tersebut memiliki kantor di Jakarta, Bandung, Yogyakarta dan Surabaya. Masing-masing kantor ini menjalankan aplikasi penjualan masing-masing dan ingin mengatur basis data sales sendiri. Diasumsikan relational
database terdiri dari EMP(ENO, ENAME, TITLE) dan SLS(SNO, ENO, TGL,
TOTAL). Apabila semua basis data ini tersimpan dalam sistem basis data terpusat, dan ingin diketahui nama pegawai dan sales order yang dibuatnya, maka query yang digunakan adalah:
SELECT ENAME,SNO,TGL FROM EMP,SLS
WHERE EMP.ENO=SLS.ENO
Dengan sistem basis data terdistribusi, tiap data dialokasikan menurut kantor masing-masing sehingga data pegawai kantor Jakarta tersimpan di Jakarta, data pegawai kantor Bandung tersimpan di Bandung dan seterusnya. Begitu pula halnya dengan data sales pada masing-masing kantor. Proses ini adalah proses fragmentasi yang akan dijelaskan lebih lanjut pada sub bab 2.3.1.
Dalam sistem basis data terdistribusi juga dapat dilakukan penduplikasian data dari suatu site ke site yang lainnya karena masalah
performance dan reliability. Hasil dari semuanya ini adalah suatu sistem basis
data terdistribusi dengan fragmentasi dan replikasi (Gambar 2.3.). Transaparan secara penuh (Fully transparent access) berarti setiap user dapat menjalankan
query seperti di atas tanpa memperhatikan atau mempedulikan masalah
fragmentasi, lokasi dan replikasi dari data, dan membiarkan sistem yang menangani semua persoalan tersebut.
Gambar 2.3. Aplikasi yang Terdistribusi
Suatu sistem yang menggunakan query jenis ini dalam suatu basis data terdistribusi, dengan fragmentasi dan replikasi, memiliki beberapa tipe transparansi yang harus diperhatikan, antara lain:
a. Data Independence, yaitu pemisahan atas definisi data dan organisasi dari aplikasi user. Dalam arti, user tidak dapat mengganti definisi data dan organisasi. Ada dua macam data independence yaitu logical data
independence, yang berarti user tidak dapat mengganti struktur logika dari
basis data dan physical data independence, yang berarti menyembunyikan perincian struktur penyimpanan data secara fisik dari aplikasi user.
b. Network Transparancy, dengan ini user tidak perlu mengetahui atau kuatir mengenai perincian operasi dari network (Location Transparancy).
c. Replication Transparancy, masalah replikasi akan dijelaskan lebih lanjut pada sub bab 2.3.2. Pada hal ini, replikasi digunakan untuk meningkatkan
DB
DB DB
DB
Pegawai Surabaya, Pegawai Jakarta,
Sales Order Surabaya
Pegawai Jakarta, Pegawai Surabaya,
Penjualan Jakarta, Penjualan Surabaya
Pegawai Yogyakarta, Pegawai Jakarta,
Penjualan Yogyakarta Pegawai Bandung, Penjualan Bandung Jakarta Communication Network Surabaya Bandung Yogyakarta
reliability, performance dan ketersediaan data (availability). User tidak perlu
mempedulikan keberadaan dari data yang direplikasi, dan membiarkan sistem yang menangani manajemen dari duplikat/replikasi data sehingga user hanya melihat satu data.
d. Fragmentation Transparancy, fragmentasi adalah proses pemecahan basis data menjadi subset yang lebih kecil, dan memperlakukan fragmen tersebut sebagai basis data yang terpisah. Dengan adanya fragmentasi maka diperlukan penanganan khusus pada query yang dijalankan oleh user.
2.2.2. Peningkatan Reliability Melalui Transaksi Yang Terdistribusi
DDBS dapat meningkatakan reliability, sebab terdapat komponen replikasi untuk menghindarkan terjadinya kegagalan pada keseluruhan sistem. Kegagalan dari satu site tertentu atau kegagalan dari link komunikasi yang menyebabkan satu atau beberapa site tidak dapat dijangkau, tidak akan membuat keseluruhan sistem menjadi gagal (down). Dalam basis data terdistribusi, kemungkinan beberapa data tidak dapat dijangkau karena dalam kondisi down dapat diatasi, dengan cara mengijinkan user untuk melakukan akses pada bagian lain dari suatu basis data terdistribusi, yaitu bagian yang merupakan replikasi dari data yang gagal (down). Dengan demikian maka transaksi dapat terus berjalan.
2.2.3. Peningkatan Performance
Masalah peningkatan performance dari suatu sistem basis data terdistribusi dapat dilihat berdasarkan dua hal berikut ini:
a. Basis data terdistribusi yang melakukan fragmen dari basis data, membuat data tersebut disimpan pada jarak yang terdekat dari pemakaiannya (data
localization). Dengan ini maka ada dua keuntungan yang dapat diperoleh,
yaitu sejak setiap site hanya menangani partisi dari basis data, maka penggunaan CPU dan I/O tidak sehebat atau sesering pada basis data terpusat dan sistem lokalisasi ini dapat mengurangi jeda waktu (delay) yang biasanya terjadi dalam suatu wide area nerworks.
b. Dengan adanya parallelism dari sistem yang terdistribusi, maka dapat dihasilkan inter-query dan intra-query parallelism. Inter-query parallelism
adalah kemampuan untuk melakukan eksekusi banyak query pada waktu yang bersamaan. Sedangkan intra-query parallelism adalah kemampuan untuk membagi query menjadi beberapa subquery, dimana masing-masing dieksekusi pada site yang berbeda dari suatu sistem basis data terdistribusi.
2.2.4. Kemudahan dalam Memperluas Sistem
Dalam suatu sistem basis data terdistribusi, terdapat kemudahan dalam hal melakukan akomodasi kenaikan ukuran (size) dari basis data. Aspek yang timbul dari kemudahan memperluas sistem ini adalah dalam hal ekonomi. Lebih murah untuk membuat beberapa sistem dari komputer yang lebih kecil menjadi satu kesatuan dalam suatu sistem komputer yang terdistribusi, daripada satu mesin yang besar (mainframe).
2.3. Mekanisme Distribusi Data
Ada tiga mekanisme yang dapat digunakan dalam mewujudkan suatu sistem basis data terdistribusi, yaitu:
a. Fragmentasi, dimana data dibagi menjadi beberapa partisi atau fragmen. b. Replikasi, dimana terdapat replika atau salinan (copy) dari data pada berbagai
site.
c. Gabungan (mixed) fragmentasi dengan replikasi.
2.3.1. Fragmentasi
Fragmentasi adalah suatu proses membagi atau memecah basis data menjadi subset-subset (fragmen-fragman) yang lebih kecil, dan memperlakukan fragmen tersebut sebagai basis data yang terpisah dan berdiri sendiri. Beberapa alasan pokok digunakannya prinsip fragmentasi ini adalah:
a. Mengurangi network traffic. Dengan dibaginya basis data ke dalam bagian yang lebih kecil dan masing-masing fragmentasi berada pada tempat data digunakan (data localization), maka user dapat mengakses lokal basis data. Hal ini mengurangi network traffic ke remote basis data.
b. Mengamankan data-data tertentu, sebab user hanya dapat melihat data yang telah ditentukan dari proses fragmentasi.
c. Mengurangi kebutuhan sumber (resource). Dengan dilakukannya proses fragmentasi, maka tidak dibutuhkan tempat penyimpanan (storage) yang besar, sebab data yang disimpan akan semakin kecil.
Ada dua macam alternatif untuk membagi tabel menjadi bagian yang lebih kecil. Alternatif tersebut adalah: membagi tabel secara horisontal (horizontal
fragmentation) dan membagi secara vertikal (vertical fragmentation).
Fragmentasi horisontal memungkinkan untuk memasukkan hanya baris-baris yang diperlukan saja dari suatu tabel dengan menggunakan keyword WHERE pada SQL. Pada Gambar 2.4. diilustrasikan fragmentasi horisontal, dimana hanya baris 2,3 dan 6 saja yang dapat diakses oleh site B.
Gambar 2.4. Fragmentasi Horisontal Sumber: SQL Server Books Online
Fragmentasi vertikal memungkinkan untuk memasukkan hanya kolom-kolom yang diperlukan dari suatu tabel dengan mendefinisikan kolom-kolom pada
keyword SELECT di SQL. Pada Gambar 2.5. diilustrasikan fragmentasi vertikal, dimana hanya kolom A,B dan D saja yang dapat diakses oleh site B. Fragmentasi dapat juga dilakukan dengan menggabungkan kedua alternatif di atas, seperti pada Gambar 2.6.
A
Gambar 2.5. Fragmentasi Vertikal Sumber: SQL Server Books Online
Gambar 2.6. Fragmentasi Horisontal dan Vertikal Sumber: SQL Server Books Online
B A
A
2.3.2. Replikasi
Replikasi adalah suatu proses menyalin (copy) dan memelihara (maintain) obyek-obyek basis data, seperti tabel, dari satu basis data ke basis data lain kemudian membuat antar basis data saling bersinkronisasi untuk konsistensi dalam beberapa basis data yang terdistribusi, seperti diilustrasikan Gambar 2.7. Replikasi menggunakan teknologi basis data terdistribusi untuk share data dari berbagai basis data.
Gambar 2.7. Aplikasi Replikasi
Penggunaan replikasi memungkinkan proses distribusi data ke lokasi yang berbeda, yaitu ke remote atau ke mobile user melalui local area network,
dial-up connection, dan melalui internet. Replikasi juga dapat meningkatkan performance dari aplikasi dengan memisahkan data secara fisik berdasarkan
kegunaannya (seperti memisahkan online transaction processing (OLTP) dan
decision support systems), atau mendistribusikan proses basis data melewati
berbagai server.
Beberapa alasan penggunaan replikasi adalah: a. Availability
Replikasi meningkatkan ketersediaan data kapan saja dan dimana saja dari suatu aplikasi, sebab replikasi menyediakan alternatif akses data (Gambar 2.7.). Bila satu site tidak dapat diakses, maka user tetap dapat melakukan
query atau melakukan data manipulasi (insert, update dan delete). Dengan
kata lain, replikasi menyediakan proteksi failover yang sempurna.
DATA Jakarta DATA Bandung DATA Surabaya
b. Performance
Replikasi memberikan kecepatan, dan lokal akses pada shared data, karena replikasi menyeimbangkan aktifitas dari beberapa site. Suatu user dapat mengakses suatu server, sedangkan user yang lainnya mengakses
server-server yang berbeda, dengan demikian replikasi dapat mengurangi load dari
semua server. User dapat juga mengakses data dari site replikasi yang dekat dengannya.
c. Disconnected computing
Teknologi replikasi memungkinkan user untuk mengakses data replikasi selama tidak terkoneksi dari server basis data pusat. Setelah koneksi tercipta dengan pusat, user dapat melakukan sinkronisasi dengan server basis data pusat. Pada saat proses sinkronisasi, user menyebarkan semua perubahan yang dilakukan terhadap data, dan kemudian menerima perubahan yang terjadi selama user tidak terkoneksi dengan pusat.
d. Network load reduction
Replikasi dapat digunakan untuk mendistribusikan data ke beberapa lokasi regional. Sehingga aplikasi-aplikasi dapat mengakses beberapa server regional, daripada mengakses satu server pusat. Konfigurasi ini dapat mengurangi network load secara drastis.
e. Replikasi dapat digunakan untuk memisahkan aplikasi Online Transaction
Processing (OLTP) dengan aplikasi yang selalu membaca data berulang-ulang
(read-intensive) seperti Online Analytical Processing (OLAP), data marts ataupun data warehouse.
Replikasi dapat diimplementasikan pada berbagai jenis aplikasi yang memiliki kebutuhan (requirement) yang berbeda-beda. Beberapa aplikasi membolehkan otonomi terhadap suatu basis data tertentu. Contohnya sales force
automation, perusahaan retail, dan aplikasi lainnya yang jarang terkoneksi dengan server pusat dan melakukan proses sinkronisasi secara periodik ke server pusat.
Anggota dari sales force automation harus menyelesaikan transaksi yang dibuat, tanpa mempedulikan koneksi dengan pusat. Dalam hal ini remote site haruslah memiliki hak otonomi.
Sebaliknya, aplikasi seperti call center dan sistem internet membutuhkan data pada beberapa server untuk disinkronisasi secara terus menerus. Sebagai contoh retail Web site di Internet yang harus menjamin bahwa customer melihat informasi yang sama pada online katalog di berbagai site.
Ada dua parameter dasar untuk memilih desain dari suatu strategi replikasi, yaitu berdasarkan kapan update data disebarkan dan berdasarkan data mana saja yang dapat melakukan operasi update. Masing-masing parameter tersebut dapat dibagi lagi menjadi bagian yang lebih kecil. Berdasarkan kapan
update data disebarkan ke basis data replikasi yang lain, dapat dibagi menjadi:
a. Synchronous Replication (eager)
Pada replikasi ini, setiap ada perubahan yang terjadi pada data langsung di sebarkan ke seluruh replikanya (Gambar 2.8.). Proses penyebaran perubahan ke seluruh replika termasuk dalam transaksi yang melakukan perubahan pada data. Jadi bila satu site gagal, maka seluruh site gagal, karena terletak dalam satu transaksi.
Gambar 2.8. Synchronous Replication (eager) b. Asynchronous Replication (lazy)
Replikasi ini pertama-tama mengeksekusi transaksi update pada lokal replika, kemudian update ini akan disebarkan ke replika yang lainnya (Gambar 2.9.). Selama belum terjadi penyebaran, semua replika tidak lagi konsisten, sebab masing-masing replika memilki nilai data yang berbeda.
Gambar 2.9. Asynchronous Replication
commit
Site 1 Site 2 Site 3 Site 4
Transaction
updates
commit
Site 1 Site 2 Site 3 Site 4
Transaction
Sedangkan parameter yang kedua yaitu berdasarkan data mana saja yang dapat melakukan operasi update, dapat dibagi menjadi:
a. Primary copy (master)
Dengan penggunaan primary copy, maka hanya ada satu replika saja yang diijinkan untuk dilakukan perubahan yaitu pada basis data master. Sedangkan replika-replika yang lainnya berubah sesuai dengan perubahan yang terjadi pada basis data master. Apabila masing-masing site ingin melakukan perubahan, maka site-site tersebut haruslah terkoneksi dengan basis data
master, seperti diperlihatkan Gambar 2.10. dimana site 4 harus terkoneksi
dahulu dengan site 1 bila ingin melakukan perubahan.
Gambar 2.10. Primary Copy Replication b. Update Everywhere (group)
Dengan penggunaan update everywhere, maka tiap replika diijinkan untuk melakukan perubahan data, seperti diperlihatkan Gambar 2.11. Replika-replika yang lainnya berubah sesuai dengan perubahan yang terjadi tiap replika basis data.
Gambar 2.11. Update Everywhere Replication
Site 1 Site 2 Site 3 Site 4
Site 1 Site 2 Site 3 Site 4
Site 1 Site 2 Site 3 Site 4
Update Commit
Site 1 Site 2 Site 3 Site 4
Keempat jenis desain di atas dapat digabungkan menjadi empat macam strategi replikasi, yaitu:
a. Synchronous – primary copy b. Synchronous – update everywhere c. Asynchronous – primary copy d. Asynchronous – update everywhere
Masing-masing strategi tersebut memiliki keuntungan dan kelemahan yang berbeda, sehingga pemilihan dan pertimbangan strategi replikasi harus disesuaikan dengan kebutuhan dan dana.
Strategi Asynchronous dan update everywhere pada replikasi, harus memperhatikan kemungkinan terjadinya konflik pada data. Sebagai contoh, konflik dapat terjadi bila terdapat dua transaksi dari site yang berbeda melakukan perubahan pada data yang sama sebelum proses sinkronisasi. Apabila konflik terjadi, maka diperlukan suatu mekanisme untuk menjamin bahwa konflik tersebut diatasi sesuai dengan kebijakan perusahaan dan menjamin konsistensi dari data pada setiap site.
Ada tiga macam konflik yang mungkin terjadi dalam suatu lingkungan replikasi, yaitu:
a. Konflik update
Konflik pada operasi update dapat terjadi bila dua transaksi dari site yang berbeda melakukan update pada baris data yang sama dan pada waktu yang bersamaan pula.
b. Konflik uniqueness
Konflik uniqueness dapat terjadi pada saat replika baris hendak melanggar integritas dari entity, seperti primary key atau unique constraint. Sebagai contoh, bila dua transaksi dari site yang berbeda melakukan proses insert baris dengan nilai primary key yang sama.
c. Konflik delete
Konflik delete dapat terjadi bila ada dua transaksi dari site yang berbeda, dimana satu transaksi melakukan proses delete pada baris data dan transaksi yang lainnya melakukan proses update atau delete pada baris yang sama dari replika data.
2.4. Basis Data Terdistribusi pada SQL Server 2000
Sistem basis data terdistribusi pada SQL Server 2000 memungkinkan aplikasi untuk mengakses data yang terdistribusi dari lokal dan remote server. Basis data terdistribusi pada SQL Server 2000 menggunakan arsitektur
client/server untuk melakukan proses permintaan informasi. SQL Server 2000
menyediakan fasilitas linked server, agar suatu basis data SQL Server dapat terkoneksi dengan basis data SQL Server yang lain. Linked server adalah link untuk mengakses basis data yang lain, melalui OLE DB Data Source. Setiap
distributed query dapat mereferensi banyak linked server dan melakukan operasi update atau read terhadap masing-masing linked server. Seperti yang
diperlihatkan pada contoh di bawah ini:
select *
from openquery(LINKED_OLAP,
'select [Customer Gender:Gender],sum([measures:unit sales]) from sales
group by [Customer Gender:Gender]')
Untuk mewujudkan prinsip sistem basis data terdistribusi, maka SQL Server 2000 menyediakan teknologi replikasi, yang digunakan untuk proses menyalin (copy) dan memelihara data pada beberapa server.
Replikasi Microsoft SQL Server 2000 menggunakan kiasan
“publish-and-subscribe” untuk menggambarkan komponen dan proses dari topologi suatu
replikasi. Model tersebut dibagi menjadi: publisher, distributor, subscribers,
publications, articles, dan subscriptions. Terdapat juga beberapa proses replikasi
yang bertanggung jawab dalam melakukan proses penyalinan (copy) dan proses pemindahan data antara publisher dan subscriber, yaitu: snapshot agent,
distribution agent, log reader agent, queue reader agent, dan merge agent.
Teknologi replikasi pada SQL Server 2000 dapat diimplementasikan melalui user interface SQL Enterprise Manager, yang digunakan juga untuk melakukan proses administrasi basis data SQL Server 2000.
2.4.1. Model Replikasi pada SQL Server 2000
Model-model replikasi yang digunakan pada SQL Server 2000 dalam implementasinya adalah:
a. Publisher
Publisher adalah server yang membuat dan mengijinkan data tersedia bagi server-server yang lainnya. Publisher dapat memiliki satu atau lebih suatu publication, dimana masing-masing mempresentasikan kumpulan data yang
saling berelasi secara logika. Publisher juga melakukan pengaturan dan penyimpanan semua informasi publication pada site tersebut..
b. Distributor
Distributor adalah server yang melakukan proses distribusi data, dan
menyimpan seluruh sejarah data beserta dengan transaksinya. Tugas dari
Distributor berbeda-beda, tergantung dari tipe replikasi yang diterapkan. Remote distributor adalah server yang terpisah dari publisher dan bertindak
sebagai distributor dari replikasi. Sedangkan local distributor adalah server yang bertindak sebagai publisher dan distributor dari replikasi.
c. Subscriber
Subscriber adalah server yang menerima data replikasi. Subscriber
mendaftarkan diri pada publication, bukan kepada article dalam publication.
Subscriber juga dapat menyebarkan perubahan data yang terjadi ke publisher,
atau pada subscriber yang lainnya. d. Publication
Publication adalah koleksi atau kumpulan dari satu atau lebih article dalam
suatu replikasi basis data. Dengan mengumpulkan beberapa article tersebut akan memudahkan dalam hal mengidentifikasikan data yang saling berhubungan dan mengumpulkan obyek yang akan direplikasikan bersama. e. Article
Article adalah tabel, partisi dari data, atau obyek yang akan direplikasi. Article
dapat berupa keseluruhan tabel atau kolom-kolom tertentu (menggunakan penyaringan secara vertikal), baris-baris tertentu (menggunakan penyaringan secara horisontal), stored procedure, view, atau user-defined function.
f. Subscription
Subscription adalah permintaan replika dari data atau obyek basis data yang direplikasi. Subscriber mendefinisikan publication mana yang akan diterima, dimana dan kapan. Sinkronisasi data dari subscriber dapat dilakukan oleh
publisher (push subscription) atau oleh subscriber (pull subscription). Suatu publication dapat menggunakan gabungan push dan pull subscription.
Gambar 2.12. Model Replikasi pada SQL Server 2000 Sumber: SQL Server Books Online
2.4.2. Tipe Replikasi pada SQL Server 2000
Replikasi yang disediakan oleh Microsoft SQL Server 2000 terdiri dari tiga tipe, yaitu:
a. Replikasi Snapshot b. Replikasi Transactional c. Replikasi Merge
Setiap tipe memiliki kemampuannya sendiri, yang dapat disesuaikan dengan aplikasi yang dibuat. Suatu aplikasi dapat menggunakan beberapa tipe replikasi tersebut sekaligus. Dimana dimungkinkan terdapat beberapa data dari aplikasi tersebut yang tidak melakukan update pada subscriber, tetapi ada juga beberapa bagian data yang sering melakukan proses update. Sehingga tipe replikasi yang dibuat tergantung dengan kebutuhan berdasarkan faktor basis data terdistribusi.
Pelaksanaan setiap tipe dari replikasi tersebut, dimulai dengan pembuatan dan penerapan snapshot pada subscriber. Sehingga apapun jenis replikasi yang dibuat, pasti terdapat proses replikasi snapshot di dalamnya.
2.4.2.1. Replikasi Snapshot
Replikasi snapshot mendistribusikan data sesuai dengan keadaan data pada suatu waktu, dan tidak perlu melakukan proses pengawasan terhadap perubahan data. Tipe replikasi dapat diterapkan pada aplikasi yang jarang melakukan update, atau pada aplikasi dimana nilai data terbaru (up-to-date
values) tidaklah begitu penting. Bila sinkronisasi terjadi maka seluruh snapshot
akan dibuat dan dikirim ke subscriber.
Penggunaan replikasi snapshot ini sangatlah tepat untuk
mendistribusikan suatu replika yang read-only, tetapi juga dimungkinkan terjadi proses update pada subscriber. Bila subscriber hanya melakukan proses pembacaan data, maka konsistensi dari transaksi akan terjamin. Bila subscriber harus melakukan proses update data, konsistensi dari transaksi antara subscriber dan publisher dapat dijaga, sebab data disebarkan menggunakan protokol
two-phase commit (2PC). Replikasi snapshot ini hanya menggunakan sedikit overhead
dari processor, sebab replikasi ini tidak melakukan proses pengawasan terus menerus terhadap perubahan data di server.
Replikasi snapshot diimplementasikan oleh snapshot agent dan
distribution agent. Snapshot agent pertama-tama mempersiapkan file-file dari snapshot yang mengandung skema dan data dari tabel dan obyek basis data yang
telah dipublikasikan, lalu menyimpan file-file tersebut dalam folder snapshot, dan kemudian membuat job sinkronisasi pada basis data distribusi di distributor (seperti yang diilustrasikan pada Gambar 2.13.). Distribution agent kemudian memindahkan informasi snapshot yang terdapat pada basis data distribusinya ke tabel tujuan pada subscriber. Basis data distribusi pada distributor hanya digunakan untuk replikasi, dan tidak mengandung tabel-tabel user.
Gambar 2.13. Replikasi Snapshot
Sumber: SQL Server Books Online
2.4.2.2. Replikasi Transactional
Dengan menggunakan tipe replikasi ini, pertama-tama snapshot hasil inisialisasi dari data akan diterapakan pada subscriber, kemudian bila modifikasi data terjadi pada publisher, maka transaksi tersebut akan disimpan dan disebarkan ke subscriber-subscriber. Replikasi ini berguna bila:
a. Setiap perubahan yang terjadi pada data di publisher akan disebarkan ke
subscriber.
b. Subscriber bersifat reliability dan sering terkoneksi dengan publisher.
Replikasi transactional menggunakan transaction log untuk menyimpan perubahan pada data di tabel yang telah dipublikasikan. Microsoft SQL Server 2000 mengawasi setiap perintah insert, update, dan delete, kemudian menyimpan perubahan tersebut ke dalam basis data distribusi, yang bertindak seperti queue. Kemudian perubahan tersebut disebarkan ke subscriber dan diterapkan sesuai dengan urutannya.
Bila perubahan data hanya dapat terjadi pada publisher, maka kemungkinan terjadinya konflik dapat dihindarkan. Tetapi bila pilihan immediate
updating atau queued updating digunakan dalam tipe replikasi ini, dimana proses
manipulasi data juga diijinkan terjadi pada subscriber, maka kemungkinan terjadinya konflik semakin besar
Replikasi transactional diimplementasikan oleh snapshot agent, log
reader agent, dan distribution agent. snapshot agent pertama-tama
mempersiapkan file-file dari snapshot yang mengandung skema dan data dari tabel dan obyek basis data yang telah dipublikasikan, lalu menyimpan file-file tersebut dalam folder snapshot, dan kemudian membuat job sinkronisasi pada basis data distribusi di distributor. Log reader agent mengawasi transaction log dari setiap basis data yang telah dikonfigurasikan untuk replikasi transactional dan menyalin transaksi yang telah ditandai untuk replikasi dari transaction log menuju basis data distribusi. Sedangkan distribution agent memindahkan
snapshot awal dan transaksi yang berada pada basis data distribusi menuju subscriber (seperti yang diilustrasikan pada Gambar 2.14.)
Gambar 2.14. Replikasi Transactional Sumber: SQL Server Books Online
2.4.2.3. Replikasi Merge
Replikasi merge adalah suatu proses mendistribusikan data dari publisher menuju subscriber, dimana masing-masing publisher dan subscriber diijinkan untuk melakukan perubahan pada saat terkoneksi atau tidak, kemudian menggabungkan perubahan-perubahan antara beberapa site pada saat saling terkoneksi.
Replikasi ini mengijinkan beberapa site untuk berkerja secara otonomi, dan pada suatu waktu menggabungkan perubahan-perubahan menjadi satu kesatuan. Pertama-tama snapshot awal diterapkan pada subscriber, dan kemudian Microsoft SQL Server 2000 menyimpan setiap perubahan pada data yang telah dipublikasikan pada publisher dan pada subscriber. Sinkronisasi data antara berbagai server dapat dilakukan secara terus menerus, atau pada waktu tertentu atau sesuai kebutuhan.
Karena perubahan diijinkan pada beberapa server, maka kemungkinan terjadinya konflik sangatlah besar. Pada replikasi ini terdapat solusi konflik yang dapat ditetapkan pada saat konfigurasi replikasi. Pada saat konflik terjadi, maka pemecah konflik (resolver) akan dijalankan oleh merge agent dan kemudian menentukan data mana yang akan diterima dan didistribusikan ke site-site yang lainnya.
Replikasi ini sangat berguna, bila:
a. Beberapa subscriber perlu melakukan perubahan pada data kapan pun juga dan mendistribusikan perubahan tersebut ke publisher dan subscriber yang lainnya.
b. Subscriber perlu menerima data, membuat perubahan pada saat offline, dan kemudian melakukan sinkronisasi perubahan tersebut dengan publisher dan
subscriber.
c. Konflik tidak diharapkan terjadi ketika data diubah pada beberapa site (sebab data disaring menjadi partisi-partisi dan dipublikasikan ke subscriber yang berbeda).
Replikasi ini diimplementasikan oleh snapshot agent dan merge agent.
Snapshot agent pertama-tama mempersiapkan file-file dari snapshot yang
dipublikasikan, lalu menyimpan file-file tersebut dalam folder snapshot, dan kemudian membuat job sinkronisasi pada basis data publication. Snapshot agent juga membuat stored procedures, triggers, dan system tables tertentu untuk proses replikasi.
Merge agent menerapkan snapshot awal yang berada di basis data publication ke subscriber. Agent tersebut juga menggabungkan setiap perubahan
data yang terjadi di publisher dan subscriber setelah snapshot awal dibuat, dan kemudian mengatasi berbagai konflik sesuai dengan peraturan yang telah dibuat. Peran dari distributor pada replikasi ini sangatlah sedikit, jadi menggabungkan
distributor dengan publisher dalam server yang sama merupakan hal yang umum
di replikasi ini. Distribution agent tidak digunakan sama sekali dalam replikasi
merge, dan basis data distribusi pada distributor hanya menyimpan sejarah data
dan informasi lainnya yang diperlukan oleh replikasi merge.
Gambar 2.15. Replikasi Merge Sumber: SQL Server Books Online
2.4.3. Konflik Replikasi pada SQL Server 2000
Konflik replikasi pada SQL Server 2000 dapat terjadi pada:
a. Tipe replikasi merge, dimana data pada berbagai site diijinkan untuk melakukan manipulasi data pada saat tidak terjadi koneksi dengan publisher. b. Tipe replikasi snapshot dan transactional yang menggunakan pilihan queued
updating, sebab subscriber diijinkan untuk melakukan manipulasi data pada
saat tidak terjadi koneksi dengan publisher.
Meskipun SQL Server 2000 menyediakan berbagai resolusi konflik, tapi yang terbaik adalah meminimalkan atau menghindarkan terjadinya konflik, karena deteksi dan resolusi konflik membutuhkan waktu yang tidak sedikit.
2.4.3.1. Deteksi dan Resolusi Konflik Replikasi pada Replikasi Merge
Ketika terjadi koneksi dan proses sinkronisasi antara publisher dan
subscriber, merge agent akan mendeteksi terjadinya konflik dan menentukan data
mana saja yang diterima dan disebarkan ke site yang lain, berdasarkan cara pemecahan konflik yang telah ditentukan pada saat pembuatan merge publication. Dalam tipe replikasi merge, konflik terjadi bila:
a. Perubahan terjadi pada kolom yang sama dalam baris yang sama (menggunakan perintah insert, update atau delete) pada beberapa replika, dengan menggunakan column-level conflict tracking.
b. Perubahan terjadi pada baris pada beberapa replika, dan menggunakan
row-level tracking.
Merge Agent mendeteksi konflik melalui perbedaan nilai lineage pada
tabel MSmerge_contents untuk suatu article dalam basis data. Setiap masukan pada MSmerge_contents mengandung informasi tentang baris yang telah dirubah. Kolom lineage pada MSmerge_contents memberikan penjelasan tentang sejarah perubahan baris, isinya dirubah secara otomatis oleh merge agent setiap kali terjadi sinkronisasi.
Pada saat merge agent melakukan penggabungan perubahan, maka agent tersebut memeriksa versi nilai lineage pada tiap baris di masing-masing site. Kemudian membandingkan nilai lineage untuk tiap baris yang dirubah antara tabel MSmerge_contents pada publisher dengan tabel MSmerge_contents pada
subscriber, untuk menentukan apakah suatu baris telah dirubah di beberapa site.
Bila baris tersebut tidak dirubah pada beberapa site, maka tidak akan terjadi konflik dan nilai perubahan akan digabungkan. Tetapi bila terjadi perubahan pada baris di beberapa site, maka konflik akan terjadi, dan kemudian resolusi konflik akan dijalankan.
Bila column-level tracking dipilih, maka merge agent akan melakukan perbandingan nilai dari COLV di tabel MSmerge_contents pada baris yang telah diubah.
Setelah konflik terdeteksi, maka merge agent akan menjalankan pemecahan konflik yang telah ditentukan. Apabila pemecahan konflik secara interaktif tidak digunakan, maka konflik akan dipecahkan saat itu juga. Baris yang kalah dalam konflik akan ditulis ke tabel konflik dengan nama
conflict_<PublicationName>_<ArticleName>_usertablename, sedangkan baris
yang menang akan digunakan pada publisher dan subscriber.
Microsoft SQL Server 2000 mengijinkan untuk memilih jenis pemecahan konflik pada replikasi merge ini. Pilihan yang tersedia yaitu:
a. Pemecahan konflik berdasarkan prioritas. Pilihan ini merupakan pilihan yang ditentukan oleh SQL Server 2000. Apabila menggunakan pemecahan ini, maka masing-masing subscriber akan diberi nilai prioritas tertentu (global
subscriptions), atau menggunakan prioritas yang telah ditetapkan (local subscriptions), dimana publisher memegang peranan penuh pada saat proses
sinkronisasi.
b. Pemecahan konflik yang dibuat sendiri sesuai dengan aturan-aturan bisnis pada perusahaan yang bersangkutan. Pemecahan ini dapat diimplementasikan dalam bentuk stored procedure atau obyek COM yang ditulis menggunakan bahasa pemrograman tertentu.
c. Pemecahan konflik lainnya yang disediakan oleh SQL Server 2000, yaitu pemecahan additive, averaging, datetime, maximum, merge text, minimum, dan Subscriber selalu menang.
SQL Server 2000 juga menyediakan pemecahan secara interaktif, yang bisa digabungkan dengan pemecahan yang lainnya seperti pemecahan prioritas. Pada saat menjalankan proses sinkronisasi yang on-demand, pemecahan interaktif
akan memperlihatkan konflik yang terjadi pada saat run-time, dan membiarkan
user untuk memilih data yang akan digunakan untuk memecahkan konflik.
Dengan proses pemecahan ini, maka user haruslah ada untuk merespon pemecahan interaktif pada saat proses merge. Oleh karena itu pemecahan ini tidak sesuai dengan aplikasi yang berdiri sendiri atau terpisah dari interaksi manusia.
Dalam replikasi merge, resolusi konflik terjadi pada level article. Untuk
publication yang mengandung beberapa article, tiap-tiap article dapat memiliki
pemecahan konflik yang sama atau berbeda, sesuai dengan kebutuhan.
2.4.3.2. Deteksi dan Resolusi Konflik Replikasi pada Queued Updating
Proses deteksi dan resolusi konflik pada queued updating berbeda dengan replikasi merge. Pada queued updating, deteksi dan resolusi konflik berdasarkan transaksi. Dengan demikian maka jumlah kebijakan resolusi konflik yang dipilih sangatlah terbatas daripada tipe replikasi merge. Queued updating menangani konflik pada level transaksi, bukan level baris seperti replikasi merge.
Pada saat membuat publication dan memilih queued updating, SQL Server 2000 menambahkan kolom uniqueidentifier dengan default newid. Pada saat data berubah, baik pada publisher atau pada subscriber, baris tersebut mendapat globally unique identifier (GUID) yang baru, untuk mengidentifikasikan bahwa telah terjadi versi baris yang baru. queue reader agent menggunakan kolom ini untuk menentukan terjadinya konflik pada saat sinkronisasi. Tidak seperti replikasi merge, GUID pada queued updating bukan untuk mengidentifikasikan baris, tetapi untuk menandakan bahwa perubahan telah terjadi.
Suatu transaksi pada queue mengandung nilai versi yang lama dan yang baru dari baris. Pada saat transaksi tersebut diterapkan pada publisher, GUID pada transaksi dan GUID pada publication akan dibandingkan. Bila nilai GUID yang lama pada transaksi, sama dengan nilai GUID pada publication, maka publication akan diubah dan baris pada publisher akan diberi guid yang baru sesuai dengan guid yang dibuat pada subscriber. Dengan demikian maka versi baris pada
Bila nilai GUID yang lama pada transaksi, tidak sama dengan nilai GUID pada publication, maka konflik terdeteksi. GUID yang baru pada publication menandakan bahwa ada dua versi baris terjadi, yang satu pada transaksi dari
subscriber dan yang satu lagi dari baris baru pada publisher. Dengan demikian,
sebelum terjadi sinkronisasi, telah terjadi proses perubahan pada baris tersebut di
publisher atau subscriber yang lain.
Pada saat membuat publication dengan queued updating, akan terdapat pilihan bagaimana queue reader agent mengatasi versi baris yang berbeda pada saat sinkronisasi. Pemecahan konflik tersebut adalah:
a. Publisher selalu menang dan subscription dilakukan inisialisasi kembali Dengan melakukan inisialisasi pada subscriber, akan menjamin konsistensi data pada subscriber, tapi memerlukan waktu yang tidak sedikit bila
publication tersebut mengandung data yang sangat besar. Pada saat queue reader agent mendeteksi konflik, maka semua transaksi di queue akan ditolak,
dan subscriber akan diinisialisasi kembali. b. Publisher selalu menang
Dengan resolusi konflik ini, maka konsistensi selalu terjamin, berdasarkan data pada publisher.
c. Subscriber selalu menang
Dengan resolusi konflik ini, maka transaksi subscriber terakhir yang melakukan sinkronisasi pada publisher akan menang. Pada kasus ini, setelah konflik terdeteksi, transaksi tersebut akan merubah data pada publisher.
2.5. Basis Data Terdistribusi pada Oracle 9i
Sama halnya dengan SQL Server 2000, sistem basis data terdistribusi pada Oracle 9i memungkinkan aplikasi untuk mengakses data dari lokal dan
remote server. Sistem basis data terdistribusi pada Oracle 9i juga menggunakan
arsitektur client/server untuk melakukan proses permintaan informasi. Suatu sistem distribusi dimana setiap basis data adalah basis data Oracle disebut juga
homogenous distributed database system, sedangkan heterogeneous distributed database system, sedikitnya satu basis data bukanlah basis data Oracle.
Gambar 2.16. Sistem Basis Data Terdistribusi pada Oracle Sumber: Oracle9i Database Online Documentation
Gambar 2.16. memberikan ilustrasi sistem basis data terdistribusi pada Oracle, dimana terdiri dari tiga basis data yaitu: hq,mfg dan sales. Aplikasi dapat melakukan akses dan memodifikasi data pada beberapa basis data di suatu lingkungan terdistribusi.
Konsep inti dari suatu basis data terdistribusi pada Oracle 9i adalah
database link, yaitu koneksi antara dua server basis data yang mengijinkan client
untuk mengakses server-server tersebut sebagai satu kesatuan basis data secara logika. Sebagai contoh suatu query untuk mengetahui nama karyawan dari basis data sales pada basis data sales.us.americas.acme_auto.com adalah:
SELECT ename
FROM [email protected]_auto.com;
Untuk memaksimalkan prinsip transparansi, Oracle menggunakan
synonym. Synonym mengijinkan user mengakses tabel pada remote server sama
halnya dengan mengakses lokal server. Sebagai contoh, untuk membuat synonym dimasukkan perintah:
CREATE PUBLIC SYNONYM emp
FOR [email protected]_auto.com;
Dengan perintah tersebut, maka daripada mengeksekusi query seperti di bawah ini:
SELECT ename
FROM [email protected]_auto.com;
Suatu aplikasi dapat menjalankan query yang jauh lebih mudah.
SELECT ename FROM emp;
Untuk mewujudkan prinsip sistem basis data terdistribusi, maka Oracle 9i menyediakan teknologi replikasi, yang digunakan untuk proses menyalin (copy) dan memelihara data pada beberapa server.
Replikasi pada Oracle 9i atau disebut juga advanced replication, dapat digunakan untuk berbagai jenis aplikasi seperti yang disebutkan pada sub bab 2.3.2. Advanced replication dapat digunakan pada sistem yang menggunakan versi Oracle berbeda dan pada sistem operasi yang berbeda.
2.5.1. Komponen Dasar Replikasi pada Oracle 9i
Pada sub bab ini akan dijelaskan komponen dasar replikasi pada Oracle 9i yaitu:
a. Obyek Replikasi
Obyek replikasi adalah obyek pada basis data yang berada pada beberapa
server dalam suatu sistem basis data terdistribusi. Dalam lingkungan replikasi,
setiap perubahan yang terjadi pada obyek replikasi akan diterapkan pada replikanya di berbagai site. Obyek replikasi tersebut dapat berupa: table,
index, views, packages, procedure, user-defined type, trigger, synonym, indextype dan user-defined operator.
b. Grup Replikasi
Dalam lingkungan replikasi, Oracle 9i mengatur masing-masing obyek replikasi menggunakan group replikasi. Grup replikasi adalah koleksi atau kumpulan obyek replikasi yang secara logika saling berhubungan. Dengan
demikian maka akan memudahkan dalam hal penanganan beberapa obyek sekaligus. Suatu grup replikasi dapat terdiri dari beberapa obyek pada beberapa skema, dan satu skema dapat mengandung beberapa obyek pada beberapa grup replikasi. Tetapi satu obyek replikasi hanya dapat menjadi anggota dari satu grup replikasi.
c. Site Replikasi
Grup replikasi dapat berada pada beberapa site replikasi. Dalam lingkungan repliksi, Oracle 9i membagi site menjadi dua tipe, yaitu: site master dan site
materialized view. Satu site dapat menjadi site master dan materialized view
untuk grup replikasi yang berbeda. Tetapi, satu site tidak boleh menjadi site
master dan materialized view untuk grup replikasi yang sama.
2.5.2. Tipe Replikasi pada Oracle 9i
Advanced Replication mendukung tipe-tipe replikasi di bawah ini:
a. Replikasi Multimaster b. Replikasi Materialized view
c. Gabungan replikasi Multimaster dan Materialized view
Setiap site master dan materialized view menggunakan schedule link untuk menyebarkan data ke site yang lainnya. Schedule link adalah database link dengan daftar waktu untuk melakukan penyebaran transaksi yang tertunda.
2.5.2.1. Replikasi Multimaster
Replikasi Multimaster (biasa disebut juga dengan replikasi peer-to-peer atau n-way) memungkinkan beberapa site seolah-olah identik (equal peers) dalam mengatur grup-grup dari obyek replikasi dan saling berpartisipasi dalam model
update-everywhere. Semua site dalam replikasi multimaster ini adalah site master,
Gambar 2.17. Replikasi Multimaster
Sumber: Oracle9i Database Online Documentation
Perubahan yang terjadi pada satu site akan dikirim atau disebarkan ke semua site master yang berpartisipasi. Gambar 2.17. memberikan ilustrasi sistem replikasi multimaster. Setiap server basis data Oracle yang bertindak sebagai site
master dalam replikasi multimaster, secara otomatis mengumpulkan data dari
semua replika tabel dan menjamin konsistensi dari transaksi global serta menjamin integritas dari data. Pemecahan dari terjadinya konflik diatasi oleh setiap site master secara independent. Replikasi multimaster menyediakan replika yang lengkap dari setiap tabel yang direplikasi pada setiap site master.
Beberapa keuntungan dari replikasi multimaster ini adalah:
a. Replikasi ini dapat menjaga ketersediaan data dari suatu kegagalan. Sebab setiap site master memiliki replika yang lengkap.
b. Replikasi ini juga berguna untuk load balancing.
Ada dua tipe proses dari replikasi multimaster ini, yaitu: a. Replikasi Asynchronous
Disebut juga dengan replikasi store-and-forward. Dimana proses ini menangkap setiap perubahan lokal yang terjadi, menyimpannya dalam queue dan dalam interval tertentu menyebarkan perubahan tersebut ke site master yang lainnya. Dengan bentuk replikasi ini, maka terdapat waktu dimana setiap
b. Replikasi Synchronous
Pada bentuk replikasi ini, Oracle langsung menerapkan setiap perubahan yang pada suatu site menuju setiap site yang berpartisipasi dalam replikasi. Keseluruhan proses penerapan ini juga termasuk dalam satu transaksi perubahan tersebut. Bila data manipulasi tersebut gagal pada site manapun, maka keseluruhan transaksi akan dikembalikan (roll back). Replikasi
synchronous menjamin konsistensi data pada setiap site kapan pun (real-time). Update pada bentuk ini akan memakan waktu yang lama, sebab menggunakan
protokol two-phase commit (2PC) yang menjamin commit pada remote site.
2.5.2.2. Replikasi Materialized View
Suatu materialized view dapat terdiri dari replika site master tujuan secara lengkap atau hanya sebagian saja. Site master tujuan yang dimaksud di sini bisa berupa tabel master dari site master atau master materialized view dari site
materialized view. Master materialized view adalah materialized view yang
berperan sebagai master bagi materialized view yang lainnya. Multitier
materialized view adalah suatu keadaan dimana suatu materialized view
berdasarkan materialized view yang lainnya.
Di dalam materialized view, data dapat merupakan sebagian data dari site
master. Hal ini termasuk prinsip fragmentasi seperti pada sub bab 2.3.1.
Fragmentasi ini dapat juga berupa baris maupun kolom.
Beberapa keuntungan dari replikasi materialized view ini adalah:
a. Adanya lokal akses pada data, sehingga meningkatkan response time dan
availability.
b. Dapat mengurangi proses query yang berat dari site master atau site master
materialized view, karena user dapat melakukan query pada lokal materialized view.
c. Meningkatkan sekuritas dari data, dengan melakukan replikasi hanya subset dari site master tujuan.
Materialized view dapat dibagi lagi menjadi beberapa tipe untuk
a. Read-Only Materialized view
Suatu aplikasi dapat melakukan query pada read-only materialized view untuk mengurangi akses network menuju ke site master. Bagaimanapun, aplikasi harus melakukan akses kepada site master bila ingin melakukan manipulasi data (DML). Gambar 2.18 memberikan ilustrasi dari suatu replikasi read-only. Tabel pada master atau pada materialized view dari suatu read-only
materialized view tidak perlu memiliki grup replikasi, karena tidak ada data
yang boleh dirubah pada read-only materialized view.
Gambar 2.18. Read-Only Materialized view Sumber: Oracle9i Database Online Documentation
Keuntungan dari read-only materialized view ini adalah menghilangkan kemungkinan terjadinya konflik, sebab data tidak boleh berubah pada
materialized view ini, dan memungkinkan suatu materialized view yang
kompleks.
b. Updatable Materialized view
Dengan membuat suatu updatable materialized view maka user dapat melakukan proses manipulasi data, seperti insert, update dan delete dari site
master atau site master materialized view. Updatable materialized view dapat
memberikan ilustrasi dari suatu replikasi updatable materialized view.
Updatable materialized view harus merupakan bagian dari grup materialized view yang berdasarkan grup replikasi lainnya.
Gambar 2.19. Updatable Materialized view Sumber: Oracle9i Database Online Documentation
Keuntungan yang dapat diperoleh dari updatable materialized view adalah mengijinkan user untuk melakukan query dan update pada lokal replika data, meskipun tidak terkoneksi dengan site master atau site master materialized
view. Keuntungan lainnya yaitu membutuhkan resource yang lebih sedikit
daripada replikasi multimaster, sebab materialized view dapat memiliki data yang sedikit (merupakan subset dari master), sehingga kebutuhan disk space dan memory tidaklah terlalu banyak.
c. Writeable Materialized view
Pada tipe ini, user dapat melakukan data manipulasi (insert, update dan
delete), tetapi semua manipulasi ini tidak akan disebarkan ke site master,
sehingga apabila dilakukan proses refresh maka manipulasi ini akan hilang. Untuk menjamin materialized view konsisten dengan site master atau site
master materialized view, maka perlu dilakukan proses refresh dari materialized view tersebut secara periodik. Materialized view tersebut dapat dikelompokkan ke
a. Fast Refresh
Metode ini menggunakan materialized view log untuk melakukan perubahan hanya pada baris yang berubah sejak dilakukan refresh terakhir kalinya.
b. Complete Refresh
Metode ini melakukan perubahan pada semua materialized view, sesuai dengan data pada site master atau site master materialied view.
c. Force Refresh
Metode ini melakukan fast refresh bila memungkinkan. Bila fast refresh tidak memungkinkan, maka akan dilakukan complete refresh.
2.5.2.3. Gabungan Replikasi Multimaster dan Materialized view
Replikasi multimaster dan replikasi materialized view dapat digabungkan (hybrid) atau dicampurkan (mix) untuk memenuhi suatu kebutuhan aplikasi tertentu. Konfigurasi gabungan ini dapat memiliki banyak site master dan banyak
site materialized view untuk setiap site master. Sebagai contoh, pada Gambar
2.20. terdapat replikasi multimaster antara dua site master, dan materialized view pada site master.
Gambar 2.20. Gabungan Replikasi Multimaster Dan Materialized view Sumber: Oracle9i Database Online Documentation
2.5.3. Konflik Replikasi pada Oracle 9i
Asynchronous multimaster dan updatable materialized view harus
memperhatikan kemungkinan terjadinya konflik pada data. Sebab data pada beberapa site dapat melakukan operasi manipulasi data secara otonomi. Oracle 9i menyediakan berbagai macam metode solusi konflik yang sudah siap untuk diterapkan pada replika basis data sesuai dengan ketentuan (bussiness rule) dari perusahaan. Meskipun Oracle menyediakan fasilitas resolusi konflik, tetapi pilihan yang selalu diutamakan adalah mendesain suatu replikasi dengan menghindarkan kemungkinan terjadinya konflik.
Mekanisme penting yang terlibat dalam pemecahan konflik di Oracle 9i adalah column group, karena ini merupakan dasar dari deteksi dan pemecahan konflik update pada Oracle 9i. Column group adalah grup yang secara logika terdiri dari satu atau beberapa kolom pada tabel yang direplikasi. Setiap kolom pada tabel yang direplikasi adalah bagian dari satu column group. Pada saat melakukan replikasi pada tabel di master definition site, dapat juga dibuat column
group, kemudian memberikan solusi konflik untuk masing-masing column group.
Karakteristik dari suatu column group adalah:
a. Suatu kolom hanya boleh termasuk dalam satu column group. b. Column group dapat terdiri dari satu atau beberapa kolom dari tabel. c. Resolusi konflik dapat dipakai hanya untuk kolom dalam column group.
Untuk mendeteksi dan memecahkan konflik update pada suatu baris, site yang menyebarkan perubahan harus mengirimkan beberapa data tertentu, yang mengandung versi yang lama dan yang baru dari baris tersebut. Jumlah data yang dikirimkan dapat berbeda-beda, tergantung kebutuhan. Apabila semua site yang berpartisipasi dalam sistem replikasi ini menggunakan Oracle versi 8 ke atas, maka dapat digunakan teknologi minimum communication yang disediakan oleh Oracle. Dengan feature ini, maka jumlah data yang dikirim ke site yang lain untuk menentukan konflik pada tiap baris yang berubah dapat diminimalkan, sebab data yang disebarkan adalah:
a. Nilai lama dari primary key dan setiap kolom dalam column group (nilai sebelum modifikasi).
b. Nilai baru dari setiap kolom yang melakukan operasi update dalam column
group.
2.5.3.1. Deteksi Konflik pada Oracle 9i
Setiap site master dalam sistem replikasi, secara otomatis mendeteksi dan memecahkan konflik replikasi. Sebagai contoh, pada saat site master mengirim
deffered transaction queue menuju site master yang lain dalam sistem replikasi, remote procedure yang dipanggil pada site penerima dapat secara otomatis
mendeteksi terjadinya konflik.
Pada saat site materialized view mengirim deffered transaction queue ke
site master atau site master materialized view, maka site penerima akan
menjalankan deteksi dan resolusi konflik. Mekanisme refresh pada materialized
view menjamin, bahwa pada saat refresh telah selesai, maka data pada materialized view akan sama dengan data pada site master, termasuk hasil resolusi
konflik. Dengan demikian maka materialized view tidak perlu melakukan deteksi dan resolusi konflik.
Site penerima (yaitu site master atau site master materialized view)
dalam sistem replikasi, akan mendeteksi terjadinya konflik insert, update dan
delete, sebagai berikut:
a. Site penerima akan mendeteksi konflik update, bila terdapat perbedaan antara nilai lama dari baris yang direplikasi (nilai sebelum modifikasi) dengan nilai sekarang pada baris yang sama di site penerima.
b. Site penerima akan mendeteksi konflik uniqueness bila terjadi pelanggaran terhadap unique constraint, pada saat operasi insert atau update dari baris yang direplikasi.
c. Site penerima akan mendeteksi konflik delete, bila site tersebut tidak dapat menemukan baris yang dilakukan operasi update atau delete, karena primary
key dari baris tersebut tidak ada.
2.5.3.2. Resolusi Konflik pada Oracle 9i
Oracle menyediakan berbagai macam metode solusi konflik untuk memecahkan konflik update dan dapat menjamin kesatuan data pada semua site
pada berbagai sistem replikasi. Resolusi konflik tersebut adalah: minimum,
maximum, latest timestamp, earliest timestamp, additive, average, priority group, site priority, overwrite, dan discard. Oracle juga menyediakan resolusi konflik
untuk konflik uniqueness. Resolusi konflik tersebut adalah: append site name,
append sequence, dan discard. Oracle tidak menyediakan metode solusi konflik
untuk konflik delete. Tetapi Oracle mengijinkan untuk membangun metode solusi konflik sendiri untuk memecahkan masalah konflik sesuai dengan kebutuhan perusahaan.
Untuk menghindarkan terjadinya kesalahan pada resolusi konflik, Oracle menyediakan tambahan metode resolusi konflik sebagai backup bila resolusi konflik yang pertama tidak berhasil. Sebagai contoh, bila resolusi konflik latest
timestamp tidak dapat memecahkan konflik, karena waktu update bersamaan,
maka dapat dijalankan resolusi konflik yang kedua, seperti site priority.
2.6. Remote Access Server
Remote access adalah salah satu feature yang dimiliki oleh Microsoft
Windows 2000 Advanced Server. Feature tersebut memungkinkan remote atau
mobile user yang menggunakan komunikasi dial-up untuk mengakses network
perusahaan, seolah-olah terhubung secara langsung. Remote access juga menyediakan fasilitas virtual private network (VPN), sehingga user dapat mengakses network perusahaan melalui internet.
User dapat menjalankan software remote access dan memulai koneksi ke remote access server. Pada remote access server, yang merupakan Windows 2000 Server, akan mengenali user dan services sessions sampai diakhiri oleh user
sendiri atau network administrator. Remote access client menggunakan tool standar untuk mengakses resources. Sebagai contoh, pada Windows 2000, client dapat menggunakan Windows Explorer untuk membuat koneksi ke drive dan untuk membuat koneksi ke printer.
Salah satu tipe konektivitas remote access server pada Windows 2000 adalah dial-up networking. Dial-up networking digunakan bila remote access
client akan membuat suatu koneksi dial-up yang tidak permanen ke physical port
telecommunications, seperti analog phone, ISDN, atau X.25. Sebagai contoh, mobile user atau home user yang menghubungi nomor telepon port remote access server milik perusahaan. Seperti yang diilustrasikan pada gambar 2.21.
Gambar 2.21. Remote Access Server sebagai Dial-Up Networking Server Sumber: Windows 2000 Books Online
