Implementasi Distributed Database Heterogeneus (Oracle and Micc Access)

Distributed database (basis data terdistribusi) adalah sebuah lingkungan dimana data dalam dua atau lebih instance di akses oleh user seakan – akan sebagai sebuah single database. Pengakasesannya mungkin saja hanya terbatas pada read only atau mengijinkan updates pada satu atau lebih instances.

Ada 2 tipe lingkungan basis data, yaitu lingkungan heterogeneous dan lingkungan yang homogeneous.
 Homogeneous
 Seluruh site / server basis data yang terdistribusi mempunyai software RDBMS yang sama.
 Seluruh site yang berpartisipasi sadar terhadap adanya site yang lain dan seluruh site telah terkonfigurasi untuk saling bekerjasama antar satu site dengan site yang lainnya.
 Nampak oleh user sebagai sebuah aplikasi tunggal.
 Hetergeneous
 Beberapa site mungkin menggunakan skema dan software yang berbeda.
 Antara satu site dengan site yang lain mungkin tidak sadar satu dengan yang lainnya.

Penyimpanan Data
Ada beberapa tipe dari penyimpanan data relational di Oracle terkait dengan lingkungannya yang terdistribusi :
 Replikasi
Sistem merawat multiple copy dari data dan di simpan pada site yang berbeda untuk pengaksesan yang cepat dan toleransi terhadap kesalahan.
 Fragmentasi
Relasi di pecah menjadi beberapa bagian dan di simpan di beberapa tempat / site yang berbeda.
 Kombinasi Replikasi dan Fragmentasi
Relasi dipecah menjadi beberapa partisi dan di copy ke beberapa site yang berbeda.

Dengan adanya replikasi ini, maka akan ada beberapa keuntungan yang bisa di peroleh, yaitu :
 Availability
Kegagalan akses terhadap sebuah relasi pada sebuah site tidak mempengaruhi terhadap ketersediaan data relasi yang diakses karena masih bisa mengakses relasi tersebut di site yang berbeda.
 Paralellisme
Query pada sebuah relasi r mungkin di proses pada beberapa node secara parallel.
 Reduced Data Transfer
Pengaksesan pada data mungkin lebih murah karena dapat diakses pada local site saja.

Walaupun dengan adanya distributed database mempunyai keuntungan, tetapi tetap ada beberapa kelemahan, yaitu :
 Cost update tinggi
Biaya untuk mengupdate setiap replica akan tinggi, karena setiap replica harus di update.
 Concurrency control bisa jadi sangat tinggi
Jika setiap replica dapat di update oleh transaksi-transaksi secara local, maka kompleksitas dari concurrcency controlnya juga akan meningkat.
(Satu satunya solusi adalah menganggap salah satunya sebagai primary copy dan apply concurrency control hanya pada primary control saja)

Fragmentasi
Fragmentasi merupakan sebuah konsep yang membagi data ke dalam bentuk vertical atau horizontal. Perhatikan contoh berikut :

tabel_mhs_yang_difragmen_secara_horisontal

Cara Mengatasi status “suspect” pada database di SQL Server 2000

Failure pada database bisa terjadi lewat berbagai sebab, salah satunya adalah power outage / mati lampu. Kondisi ini menyebabkan database tidak sempurna dalam melakukan rutin rutin proses penulisan dari memory ke database. Hal buruk yang bisa terjadi adalah ‘corrupt’ pada data file atau log file. Sehingga ketika di hidupkan lagi database tidak bisa langsung up karena filenya ada yang korup.

Berikut salah satu solusi mengatasi kondisi “suspect” database pada SQL Server 2000.

1. Asumsi nama database kita yang “suspect” adalah basdat

2. Backup basdat_Data.MDF dan basdat_Log.LDF ke direktori lain. (* utk jaga jaga saja)

3. Jalankan Query berikut dari query analyzer

use master

go

sp_configure ‘allow updates’, 1

RECONFIGURE WITH OVERRIDE

go

select status from sysdatabases where name = ‘basdat’

update sysdatabases set status= 32768 where name = ‘basdat’

go

*kalo tidak bisa ganti 32768 dengan -32678

4. Eksekusi perintah diatas menjadikan status database di rubah dari ‘suspect’ ke emergency/offline/read only.

5. Dalam status emergency/offline/read only tersebut kita bisa melakukan ekspor data dari database basdat. Buat 1 database baru dengan nama ‘sementara’.

6. Lakukan eksport data dari Enterprise Manager lalu kilk pada Database basdat, masuk ke tabelnya lalu klik kanan All Task -> Export. Ekspor semua table yang di inginkan (* kondisi ini tidak menjamin semua data bisa selamat, jika ada yang korup nanti ada verifikasi error pada saat export, tapi setidaknya data yang tidak korup masih bisa di selamatkan di database basdat tersebut)

7. Setelah selesai mengeksport semua table yang di inginkan ke database ‘sementara’ (* utk menampung sementara sebelum kita kembalikan ke database ‘basdat)’. Maka langkah selanjutnya adalah menghapus database ‘basdat’ yg bersifat read only/emergency/offline. (* database ‘basdat’ tidak bisa di rubah statusnya menjadi online, jadi mau gak mau kita harus menghapusnya dan membuatnya lagi -> tp pastikan semua data yg di inginkan sudah masuk ke database ‘sementara’)

8. Setelah di hapus buat lagi database dengan nama ‘basdat’ lagi, lalu lakukan eksport lagi dari database ‘sementara’ ke database ‘basdat’.

9. Cek kembali dengan query ke database ‘basdat’. Semoga berhasil dan tidak ada masalah

10. Kembalikan status database dengan perintah

use master

go

sp_configure ‘allow updates’, 0

RECONFIGURE WITH OVERRIDE

go

NB : Penulis tidak menanggung efek samping dari prosedur di atas. Selama penulis mencobanya tidak ada masalah. Jadi untuk keamanan tolong backup database anda dahulu sebelum melakukan trik di atas. Semoga bermanfaat dan tidak terjadi apa apa J