BAB II LANDASAN TEORI
2.1
Data Menurut berbagai kamus bahasa Inggris-Indonesia, data diterjemahkan
sebagai istilah yang berasal dari kata “datum” yang berarti fakta atau bahanbahan keterangan. Dari sudut pandang bisnis, data bisnis (business data) adalah deskripsi organisasi tentang sesuatu (resources) dan kejadian (transactions) yang terjadi (business data is an organization’s description of things (resources) and events (transactions) that it faces). Sedangkan menurut Menurut Kadir (8) Data adalah Deskripsi tentang benda, kejadian, aktifitas dan transaksi yang tidak mempunyai makna atau tidak berpengaruh secara langsung kepada pemakai.
2.2
Basis Data Definisi paling sederhana dari basis data adalah koleksi dari sekumpulan data
yang disimpan untuk kemudian di temu kembali (Garmany et all 1). Sedangkan menurut Guy Kawasaki (3) basis data adalah versi digital dalam bentuk file yang berisi informasi tentang objek (information sheets) dan keterkaitannya (binder) yang memberikan efisiensi untuk menggunakan informasi tersebut. Dalam komputerisasi detail dari informasi disebut record. Setiap record berisi informasi suatu objek, record selanjutnya membentuk sebuah bidang (field). Field adalah area yang digunakan untuk menyimpan bagian dari record seperti nip, nama alamat, dan lain lain. Pada tabel 2.1 dianalogikan keterhubungan antara dunia nyata dan basis data. Tabel 2.1 Analogi dunia nyata dan dunia basis data Dunia Nyata
Dunia Basis data
Binder
Berkas basis data
Berkas informasi tentang objek
Records
Bagian dari objek
Field
7
8
2.3
Database Management System (DMBS) DBMS adalah produk-produk perangkat lunak yang dapat mengelola data
sebagai sumber untuk digunakan bersama-sama, yang memungkinkan pengguna dalam suatu kelompok atau organisasi dapat menggunakan basis data yang sama (Bontempo and Saracco 2). Agar para pengguna basis data dapat melakukannya secara efisien, produk DBMS harus menghasilkan mekanisme untuk menyimpan data, akses terhadap data, menjaga keamanan data, serta menjamin kualitas dan integritas data dalam hal pemeliharaan dan perbaikan jika terjadi kesalahan. Saat ini perangkat lunak DBMS menawarkan banyak hal untuk mendukung berbagai variasi platform komputerisasi, mulai dari personal hingga sistem komputerisasi pararel. Produk-produk DBMS tersedia untuk berbagai lingkungan sistem operasi seperti DOS, Windows, Netware, OS/2, Macintosh, Unix, Linux dan lain-lain. Teknologi DBMS juga sangat berpengaruh luas terhadap industri perangkat lunak, semenjak konsep DBMS dibuat sejak saat itu pula berbagai kakas dikembangkan untuk mempermudah mengakses basis data. Teknologi kakas yang paling populer saat ini adalah query, pelaporan, dan paket-paket grafis untuk membuat laporan dengan grafik. Gambar 2.1 menggambarkan contoh penerapan DBMS.
Gambar 2.1 Contoh penerapan DBMS [Referensi: Database Management Principles and Product,1995]
2.4
Structure Query Language (SQL) SQL merupakan salah satu contoh bahasa perubahan bentuk, atau bahasa yang
digunakan pada relasi data untuk mengubah masukan data menjadi keluaran yang diharapkan (Connoly and Begg 385). Sebagai
suatu
bahasa,
SQL
memiliki
standar
ISO
standarization organization) yang terdiri dari dua komponen utama:
(international
9
-
Data Definitition language (DDL) untuk menentukan struktur basis data dan melakukan akses terkontrol terhadap data.
-
Data Manipulation Language (DML) untuk menemukan kembali dan melakukan pembaharuan terhadap data.
2.5
Heterogen Menurut Kamus Besar Bahasa Indonesia (KBBI), heterogen merupakan
berbagai unsur yang berbeda sifat atau berlainan jenis; beraneka ragam. Sedangkan menurut keilmuan lain misalnya dalam kata “campuran heterogen” adalah campuran yang tidak serba sama membentuk dua fasa atau lebih, dan terdapat fasa-fasa yang jelas diantara fasa-fasa terebut.
2.6
Replikasi Basis Data Menurut Jhon Garmany et all (121) replikasi basis data adalah proses
penggandaan sebahagian atau keseluruhan objek basis data ke suatu atau beberapa basis data lainnya. Basis data tersebut dapat terletak di suatu tempat lain atau kedepan akan dijadikan server basis data utama. Karena kecepatan dan keandalan internet, banyak pengguna merasa replikasi kedepan tidak dibutuhkan, jika hal tersebut benar kegiatan transaksi data akan terjadi dari mana saja dan kapan saja ke satu penyedia data. Ketika basis data tersebut tidak dapat diakses karena kerusakan, maka semua kegiatan transaksi data tidak akan dapat dilakukan. Replikasi merupakan tawaran solusi untuk masalah tersebut karena setiap basis data memiliki salinan dari data yang direplikasi. Kebutuhan akan replikasi terhadap seluruh atau sebahagian dari basis data menjadi meningkat dan umumnya dibutuhkan oleh perusahaan untuk dapat melakukan konsolidasi terhadap informasi yang mereka miliki. Beberapa perusahaan menggunakan beberapa metode replikasi untuk mengirimkan data ke data warehouse perusahaan. Replikasi juga dapat digunakan untuk menghasilkan bagian tertentu dari basis data yang dapat digunakan untuk pelaporan, sehingga dapat menghapus dampak dari agregasi data pada basis data utama. Replikasi juga diharapkan mampu untuk memenuhi basis data yang high availability (HA) yang membutuhkan zero-failover times dimana aplikasi dapat
10
melakukan query ulang ke basis data yang telah direplikasi jika terdapat kesalahan fatal dari basis data utama maupun dari isu bencana (disaster recovery). Replikasi basis data juga memliki keterbatasan, memahami keterbatasan yang ada tentunya dapat membuat proyek replikasi menjadi lebih berhasil.
2.5.1 Metode-metode Replikasi Replikasi basis data pada setiap DMBS tidaklah sama, setiap DBMS memiliki metode replikasi yang berbeda, beberapa metode replikasi menurut Garmany et all (122): 1. Replikasi manual, yaitu replikasi yang dilakukan secara manual dengan memanfaatkan fasilitas ekspor dan impor pada DBMS, atau menggunakan distributed query pada basis target. Contoh distributed query yang dibuat pada basis data target: CREATE TABLE pegawai AS SELECT nip, nama, alamat FROM pegawai@Server 1_Database WHERE kodefakultas = ‘FASILKOM’; 2. Basis data Siaga (Standby Database), yaitu replikasi dengan cara membuat membuat sebuah proses yang akan mengirimkan semua perubahan pada basis data utama dan mengirimkan ke sebuah basis data siaga. 3. Replikasi menggunakan trigger, yaitu replikasi yang dilakukan dengan cara membuat trigger pada tiap tabel yang ada. Trigger merupakan sebuah kejadian yang dapat digunakakan untuk menangkap perubahan-perubahan pada objek-objek basis data dan segara mengirimkan perubahan pada baris data tersebut ke basis data target. 4. Replikasi menggunakan Views, secara umum Views digunakan pada tabeltabel untuk mempermudah perintah-perintah dalam melakukan kueri data, Views layaknya seperti tabel virtual. Pada DBMS Oracle disebut juga materialized
views. Setiap perubahan yang terjadi terhadap tabel-tabel
dijadikan view, secara otomatis views akan mengikuti semua perubahan data.
11
Hasil dari views dapat digunakan untuk melakukan replikasi jika dibuat pada basis data target dan dibuat menjadi sebuah material data. 5. One-Way Replication, replikasi yang dilakukan dengan cara menggunakan pemicu atau kemampuan replikasi built-in pada DBMS yang mengirimkan semua atau sebahagian perubahan objek-objek pada basis data sumber ke basis data target. Pada metode ini basis data target bersifat read only
. Gambar 2.2 Replikasi One Way [Referensi: Logical Database Design Principles, 2005] 6. Writeable Replication, yaitu metode replikasi seperti One-Way Replication, bedanya, perubahan pada objek-objek basis data pada lokal target tetap dapat dilakukan. Perubahan yang terjadi pada basis data target tidak direplikasi ke basis data sumber. 7. Updateable replication, yaitu metode replikasi dimana basis data sumber dan basis data target dapat diperbaharui secara bersamaan, pada metode ini merancang,
membuat,
dan
memelihara
jauh
lebih
sulit
karena
mempertimbangkan collusions dan konflik. Metode Updateable replication dapat di implementasikan dengan tiga cara yaitu: a. Push-Pull merupakan teknik replikasi dimana basis data target menarik (pull) perubahan-perubahan dari basis data sumber. Ketika update terjadi pada basis data target, maka perubahan yang terjadi akan di push terlebih dahulu ke basis data sumber, kemudian di pull balik ke basis data target.
12
Gambar 2.3 Replikasi Push-Pull [Referensi: Logical Database Design Principles, 2005] b. Multi-Master merupakan teknik replikasi dengan kondisi semua basis data berperan sebagai basis data master dan saling menyebarkan setiap terjadi perubahan objek-objek basis data ke basis data lain sesuai topologi replikasi yang diterapkan.
Gambar 2.4 Replikasi Multi-Master [Referensi: Logical Database Design Principles, 2005] c. Streams merupakan teknik terakhir yang merupakan cara baru replikasi berbasis log pada basis data. Disebut Streams karena teknik ini akan membaca perubahan log dan melakukan pull terhadap perubahan data yang sudah di-commit kemudian dikirimkan berbentuk stream ke basis data target. d. Dari metode metode yang sudah dijabarkan tentunya setiap metode
memiliki kelebihan dan kekurangan. Kelebihan dan kekurangan dari setiap
13
metode dapat dilihat pada Lampiran 1 Kelebihan dan kekurangan metodemetode replikasi.
2.5.2
Konflik pada Replikasi
Pada basis data terdapat primary key yang berfungsi sebagai identitas unik untuk setiap baris data. Menambahkan baris data baru ke sebuah tabel yang memiliki primary key yang sudah ada akan menyebabkan kegagalan. Sementara pada lingkungan replikasi, semua tabel harus memiliki kunci unik untuk dapat melakukan identifikasi perubahan tiap baris data sehingga dapat di replikasi ke basis data lainnya. Jika tabel-tabel pada basis data tidak memiliki kunci yang unik minimal harus memiliki kombinasi kolom sebagai indentifikasi unik baris data. Akibat dari kunci ini akan menimbulkan konflik jika kunci unik yang di replikasi sudah ada pada basis data lainnya.
2.5.3
Penghindaran Konflik
Seperti yang telah dibahas sebelumnya konflik terjadi akibat dari referential integrity constraints yaitu kunci unik pada baris data. Mekanisme replikasi terdahulu menambahkan kolom ID, tetapi hal ini tidak dianjurkan karena tidak ada hubungan antara baris data dengan kolom ID. Secara umum setiap tabel harus memiliki kunci utama. Ketika tabel mengijinkan redundansi baris data tetap membutuhkan kunci unik untuk setiap baris data. Dibawah ini terdapat tiga cara yang dapat digunakan untuk membuat kunci unik agar dapat menghindari konflik pada replikasi menurut Garmany et all (131): 1. Central Repository yaitu hanya mengijinkan satu basis data untuk menciptakan primary key untuk semua basis data pada topologi replikasi yang akan diterapkan. Masalah dari cara ini adalah ketergantungan terhadap basis data yang berfungsi sebagai generator primary key, jika terjadi kegagalan network, transaksi lokal tidak dapat dijalankan karena gagal mendapatkan nilai kunci yang baru. 2. Assigning blocks of numbers, yaitu membuat sendiri primary key dari sebuah sekuen yang diatur dengan menambahkan blok nilai pada kunci utama. Hal ini dilakukan dengan cara membagi sekuen pada setiap kunci data yang dimulai
14
dari angka yang berbeda. Misalnya Server basis data A dimulai dari angka 1 dan terakhir pada angka 99999999, Server basis data B dimulai dari angka 100000000 sampai 199999999 dan seterusnya dengan batasan maksimum sekuen sesuai tipe data yang diterapkan pada kunci utama. Kelemahan dari cara ini adalah tidak berfungsi baik jika menambah server basis data yang baru karena harus memotong atau membatasi ruang untuk ketersediaan kunci yang sudah diterapkan. 3. Assign a site prefix, yaitu salah satu cara yang fleksibel dengan skalabilitasnya membuat semua sekuen diawali dari kunci utama 1 pada tiap kunci data dan menambahkan sebuah prefix untuk setiap urutan kunci sesuai nama basis data. Jika semua penamaan basis data unik maka nilai dari kunci tidak akan berbenturan. Menghindari konflik menjadi bagian dari perencanaan replikasi oleh sebab itu perancangan untuk melakukan replikasi memerlukan tahapan analisis terhadap topologi replikasi yang akan diimplementasikan.
2.5.4 Resolusi Konflik pada Replikasi Resolusi konflik adalah proses mendefinisikan aturan-aturan pada basis data ketika konflik terdeteksi. Jika penyelesaian terhadap konflik dapat dilakukan, antrian transaksi tidak terhenti dan dapat terus dilanjutkan. Dibawah ini didefenisikan metode resolusi konflik menurut Garmany et all (132) yang diterapkan oleh DBMS Oracle yang juga dapat dilakukan pada DBMS lainnya: 1. Latest TimeStamp, ketika sebuah transaksi replikasi gagal sebelum dilakukan perubahan, timestamp dari baris data akan dibandingkan, jika timestamp data kedua lebih terbaru dari data yang sudah ada, maka data yang kedua dapat diproses. Implementasi ini dapat dilakukan dengan menambah kolom dengan tipe data datetime dan menggunakan trigger untuk mengisi kolom tersebut ketika insert terjadi. 2. Minimimum/maximum value, ketika terjadi konflik terhadap kolom antara dua transaksi, metode minimum/maximum akan dipicu, dan melakukan evaluasi terhadap nilai-nilai yang terkini dari kolom yang didefinisikan kemudian
15
memilih nilai yang lebih rendah atau lebih tinggi untuk menentukan apakah kolom yang baru akan diterapkan. 3. Group priority value. pada kasus ini kolom-kolom dikelompokan dengan menambahkan nilai prioritas terhadap kolom-kolom pada tabel. Resolusi konflik ditentukan oleh prioritas tertinggi dari kolom-kolom tersebut. 4. Site Priority Value, pada cara ini basis data pada tiap mesin diberikan nilai prioritas. Ketika konflik terjadi antara dua baris data, baris data yang berasal dari basis data lainnya dengan prioritas tertinggi yang akan diproses. Satu atau lebih dari metode resolusi konflik yang telah dijabarkan dapat diterapkan pada tabel, dan basis data akan melakukan ekseskusi terhadapnya untuk mengatasi konflik yang terjadi pada saat replikasi
2.5.5
Replikasi Pada SQL Server
SQL Server adalah produk relational database server yang dikembangkan oleh Microsoft. Fungsi utama dari produk ini adalah untuk menyimpan dan temu kembali data. Versi terakhir saat ini adalah SQL Server 2008 R2 dengan penambahan fitur baru seperti PowerPivot, Share Point, Master Data Service, dan service lainnya termasuk Replication Service. Replication Service adalah suatu mekanisme yang tersedia pada SQL Server untuk dapat melakukan replikasi terhadap perubahan yang terjadi pada basis data penyedia (publisher) ke basis data penerima (subscribers). Perubahan di-publish (menggunakan replikasi streams) dengan urutan posisi kejadian, dan biasanya ada latensi terhadap perubahan yang terjadi pada publisher untuk dapat diproses ke subscribers. Gambar 2.5 mengilustrasikan proses replikasi pada SQL Server 2008, dimana harus ada minimal tiga Server roles yang dibutuhkan untuk mendukung replikasi yaitu: -
Publisher, server roles yang melakukan publikasi
-
Distributor, server roles yang melakukan distribusi
-
Subscriber, server roles yang berfungsi sebagai menerima data
16
Gambar 2.5 Proses replikasi pada SQL Server [Referensi: SQL Server Replication: Providing High Availability using Database Mirroring, 2008] Replikasi pada SQL Server 2008 bergantung pada agen-agen yang berfungsi melakukan tugas-tugas terkait dengan pelacakan perubahan dan proses pendistribusian, agen-agen yang berperan pada SQL Server 2008 untuk mendukung replikasi adalah sebagai berikut: -
Snapshot Agent, agen yang berjalan pada distributor, agen ini bertugas untuk mempersiapkan skema dan inisialisasi dalam bentuk file dari perubahan tabeltabel dan objek-objek lain yang akan di-publish, kemudian menyimpan sebagai snapshot file yang isinya merupakan rekaman semua informasi tentang sinkronisasi pada basis data yang akan didistribusikan.
-
Log Reader Agent, agen yang berjalan pada distributor. Agen ini bertugas untuk menghubungkan ke publisher dan memindahkan transaksi-transaksi yang sudah diberi tanda untuk proses replikasi dari log transaksi publikasi ke distribusi.
17
-
Distribution Agent, agen yang berjalan pada distributor untuk melakukan push
subcriptions,
dan
berjalan
pada
subscriber
melakukan
pull
subscriptions. Agen ini juga menerima initial snapshot (opsional) ke subscriber dan memindahkan transaksi-transaksi yang sudah siap di proses dari distribution ke subscribers -
Queue Reader Agent, agen yang berjalan pada distributor. Agen ini hanya digunakan untuk replikasi transaksional dengan subscriptions ter-update, dan memindahkan perubahan-perubahan yang terjadi pada subscribers kembali ke Publisher.
2.5.6
Replikasi Pada MySQL
MySQL adalah produk relational database management system (RDBMS) yang berjalan sebagai sebuah server yang menyediakan multi-user access ke beberapa basis data yang ada. Pada proyek pengembangan MySQL, sumber kode program tersedia dibawah lisensi GNU General Public dibawah berbagai pernjanjian eksklusif. MySQL dimiliki dan disponsori oleh sebuah perusahaan nirlaba
yang berlokasi di Swedia bernama MySQL AB yang saat ini telah
diakuisisi oleh perusahaan Oracle. Pada April 2009 versi MySQL ditawarkan dalam dua varian yang berbeda yaitu open source MySQL Community Server dan Commercial Enterprise Server. MySQL menawarkan banyak fitur termasuk fitur replikasi. Replikasi pada MySQL memungkinkan replikasi dari satu basis data mysql (Master) ke satu atau lebih basis data MySQL lainnya (Slave). Karena replikasi bersifat asyncrhonous, basis data yang dijadikan slave tidak harus terhubung secara permanen untuk menerima update dari master. Hal ini mengartikan bahwa jarak dan komunikasi data tidak menjadi hal yang utama. Objek yang dapat direplikasi pada MySQL bergantung pada konfigurasi yang diterapkan, bisa seluruhnya, basis data tertentu atau bahkan tabel-tabel tertentu. Replikasi MySQL berdasarkan pada mekanisme binary logging. Instance MySQL yang bertindak sebagai Master (sumber basis data) menangkap aktivitas terhadap transaksi data sebagai sebuah events ke binary log. Informasi dari binary log disimpan dalam bentuk logging yang berbeda berdasarkan perubahan pada
18
basis data yang berhasil di rekam. Slave dikonfigurasikan untuk membaca binary log dari Master dan melakukan eksekusi events terhadap binary log Master ke basis data Slave MySQL pada lokal target.
2.6
Arsitektur Oracle Goldengate Oracle GoldenGate merupakan perangkat lunak untuk melakukan replikasi
data. Arsitektur proses Oracle GoldenGate bersifat modular terdiri dari tiga proses yaitu Capture, Trail Files, dan Delivery diilustrasikan seperti gambar 2.6
Gambar 2.6 Arsitektur proses Oracle GoldenGade [Referensi: Oracle GoldenGate 11g: Realtime Access to Realtime Information, 2010] Oracle GoldenGate sangat ideal pada lingkungan yang heterogen dalam melakukan proses replikasi karena bersifat Log-Based Change Data Capture yang saat ini hampir didukung oleh semua vendor-vendor basis data. Pada lampiran 2 Platform sistem operasi dan basis data yang didukung Oracle GoldenGate merupakan lingkungan heterogen yang didukung oleh versi Oracle GoldenGate yang digunakan pada penelitian ini. Oracle GoldenGate dapat memberikan fleksibilitas untuk menangkap dan menggandakan objek-objek tertentu pada basis data seperti perubahan-perubahan data yang terjadi pada saat transaksi, dan perubahaan pada data definition language (DDL) pada setiap topologi replikasi yang diterapkan seperti pada gambar 2.7.
19
Gambar 2.7 Topologi yang didukung oleh Oracle GoldenGate [Referensi: Oracle® GoldenGate Windows and UNIX Administrator’s Guide, 2011] Dengan fleksibilitas, seleksi, dan transformasi yang dimiliki Oracle GoldenGate, serta fitur-fitur proses yang dapat dikostumisasi, Oracle GoldenGate dapat diterapkan untuk mendukung beberapa kebutuhan koorporasi dalam bisnis antara lain: -
Bisnis yang berkelanjutan yang memiliki kemampuan ketersedian data yang baik.
-
Migrasi basis data
-
Integrasi data
-
Pendukung Keputusan (Decision Support) dan data warehouse Dari ketiga proses tersebut seperti yang telah dijabarkan sebelumnya, Oracle
GoldenGate memiliki komponen-komponen yang melakukan tugas tertentu dalam melakukan proses replikasi yaitu: Extract, Data pump, Replicat, Trails, Checkpoints, Manager dan Collector. Pada gambar 2.8 arsitektur logik Oracle GoldenGate
diterapkan
pada
proses
initial
data
loads
dan
Change
Synchronization. Ini merupakan konfigurasi dasar, variasi dari model tergantung dari kebutuhan bisnis itu sendiri.
20
Gambar 2.8 Arsitektur logik Oracle GoldenGate. [Referensi: Oracle® GoldenGate Windows and UNIX Administrator’s Guide, 2011] 2.6.1 Komponen-komponen Logik Oracle GoldenGate 1. Extract Proses Extract berjalan pada mesin sumber dan merupakan suatu mekanisme untuk menangkap transaksi data (Change Data Capture) yang terjadi pada basis data. Extract dapat dilakukan dengan 2 cara, yaitu : 1. Initial load : digunakan untuk melakukan replikasi secara langsung dari sumber ke target untuk satu kali proses. 2. Change synchronization : digunakan untuk menjaga agar data sumber selalu sama dengan data pada target, extract menangkap semua transaksi yang terjadi (tambah, ubah, hapus) dan langsung melakukan sinkronisasi ke mesin target. Jika mendukung juga dapat menangkap perubahan pada DDL. Ketika perubahan data terjadi, extract memperoleh data dari dua cara yaitu Database recovery log atau transcation log dari aplikasi lain. Extract menangkap semua perubahan yang terjadi terhadap objek yang sudah dikonfigurasikan sejak awal, namun hanya akan mengirimkan informasi perubahan dari transaksi yang telah di-commit. Setelah Extract menangkap semua transaksi yang telah dicommit, semua log record terhadap transaksi tersebut ditulis ke dalam trail. 2. Data Pumps Data pumps adalah komponen extract tambahan bersifat opsional yang dibuat pada mesin sumber. Ketika data pump tidak digunakan, extract akan melakukan
21
pencatatan ke trail yang berada di mesin target melalui TCP/IP. Jika data pump dikonfigurasikan, extract akan melakukan pencatatan ke dalam trail pada lokal sistem dan dari sini data pumps akan membaca trail dan menyalinnya ke trail yang berada pada mesin target. Kegunaan data pumps antara lain: -
Perlindungan jika terjadi kegagalan network
-
Di implementasikan pada beberapa fase dari seleksi data dan perubahan data
-
Konsolidasi data dari beberapa sumber ke target, agar dapat membagi sumber daya terhadap target dari sumber-sumber replikasi
-
Sinkronisasi satu sumber untuk beberapa target, dapat membuat beberapa data pumps yang berbeda pada satu mesin sumber untuk beberapa mesin target
3. Replicat Replicat berjalan pada mesin target dan berfungsi membaca perubahan data dari proses extract (Change Data Delivery) dan kemudian dilakukan replikasi ke basis data pada mesin target. Dapat menggunakan banyak replicat dengan banyak extract secara paralel untuk meningkatkan kinerja dalam melakukan replikasi. 4. Trails Untuk mendukung ekstraksi yang terus-menerus dalam replikasi terhadap transaksi data yang terjadi pada basis data di mesin sumber, Oracle GoldenGate menyimpan sementara perubahan dalam bentuk file yang dinamakan trail. Trail dapat berada di mesin sumber dan mesin target atau diantara keduanya, tergantung konfigurasi dari Oracle GoldenGate itu sendiri. Jika disimpan pada sistem lokal, trail dinamakan extract trail (atau local trail). Jika disimpan pada mesin target dinamakan remote trail. Proses baca tulis trail akan terjadi jika proses extract menemukan adanya transaksi terhadap data dan menuliskannya ke local trail jika menggunakan data pumps, ataupun remote trail jika tidak menggunakan data pumps. Kemudian mengirimkannya ke remote trail pada mesin target. Replicat akan membaca trail dan melakukan perubahan ke basis data pada mesin target. Berikut adalah hal
22
yang dapat dilakukan Oracle GoldenGate terhadap trail dan bagaimana melakukan manajemen terhadap trail tersebut: -
Trail akan diciptakan selama proses terjadi
-
Pembuatan file trail akan menyesuaikan secara otomatis untuk mengijinkan proses tanpa interupsi terhadap pembuatan file, trail akan disimpan pada folder dirdat pada root Oracle GoldenGate diletakkan
-
Ukuran trail secara umum adalah 10MB, penamaan trail adalah <prefix><seq number>, prefix didefinsikan dua karakter alpha numerik yang ditentukan pada parameter file extract, setiap nama akan ditambahkan secara otomatis 6 karakter numerik mulai dari 000000 – 999999
-
Dapat membuat lebih dari satu trail untuk memisahkan data dari objek yang berbeda.
-
Banyaknya trail dapat dibersihkan dengan menambahkan parameter PURGEOLDEXTRACT pada parameter MANAGER
-
Versi Oracle GoldenGate yang berbeda akan menyebabkan header file trail berbeda. Untuk men-set versi dari trail digunakan opsi parameter FORMAT pada EXTTRAIL, EXTFILE, RMTTRAIL, RMTFILE
5. Checkpoint Checkpoint digunakan menyimpan posisi read dan write yang terakhir pada setiap proses yang terjadi pada basis data untuk tujuan recovery. Checkpoint memastikan perubahan basis data telah disinkronisasikan saat ekstraksi dan replikasi agar dapat menghindari proses yang berulang-ulang. 6. Manager Manager adalah kontrol proses dari GoldenGate. Manager harus dijalankan pada tiap mesin dimana Oracle GoldenGate di-instalkan sebelum memulai proses extract dan replicat. Manager memiliki beberapa fungsi, yaitu : -
Memonitor dan me-restart proses GoldenGate.
-
Memelihara trail dan log
-
Mengalokasikan ruang data penyimpanan trail
-
Pemberitahuan error dan peringatan
-
Menerima dan meneruskan request dari user interface.
23
2.6.2
Program dan utilitas Oracle GoldenGate
Selain arsitektur logik, pada direktori root Oracle GoldenGate terdapat program dan utilitas yang dapat digunakan untuk mendukung proses replikasi seperti pada tabel 2.2. Beberapa program belum tentu terdapat pada folder instalasi tergantung file sumber Oracle GoldenGate yang telah diunduh. Tabel 2.2 Program dan utilitas yang terdapat pada Oracle GoldenGate. Program Cobgen Convchk Ddlcob
Defgen
Emsclnt
Ggmxinstall 2.6.3
Deskripsi Berfungsi menciptakan definisi berdasarkan bentuk dasar COBOL, digunakan Oracle GoldenGate untuk Datawise pada Stratus Berfungsi melakukan konversi file-file checkpoint ke versi yang terbaru Berfungsi menciptakan DDL untuk membuat tabel pada target, berdasarkan bentuk dasar COBOL, digunakan Oracle GoldenGate untuk Datawise pada Stratus Berfungsi menciptakan definisi dari tipe data sesuai referensi yang digunakan oleh Oracle GoldenGate, ketika mesin sumber dan mesin target memiliki definisi data yang berbeda Berfungsi mengirimkan pesan kejadian yang diciptakan oleh Collector dan Replicat pada sistem Windows dan Unix ke EMS pada sistem NonStop Kode-kode instalasi Oracle GoldenGate untuk basidata SQL/MX
Sub Direktori Oracle GoldenGate
Di dalam root direktori Oracle GoldenGate memiliki sub direktori yang digunakan untuk meletakan file yang digunakan selama proses replikasi yaitu: 1. dirchk Direktori yang di gunakan untuk meletakkan checkpoint yang
diciptakan
oleh proses extract dan replicat yang menghasilkan data
berurutan dari
operasi
file
baca
dan
tulis.
Format
penamaan
adalah
<nomorurutan>.ekstensifile 2. dirdat Direktori yang di gunakan untuk meletakkan trail diciptakan dari proses extract. File ini kemudian diproses oleh proses Replicat. 3. dirdef Direktori yang di gunakan untuk meletakkan file definisi data yang dibuat oleh utilitas DEFGEN. Format nama file didefinisikan oleh pengguna dan ditentukan secara eksplisit dalam parameter defgen.
24
4. dirpcs Direktori yang di gunakan untuk meletakkan status proses. File ini hanya dibuat saat proses sedang berjalan. Nama file menunjukkan program, nama proses
port,
dan
ID
proses.
Bentuk
penamaan
file
adalah
.<Extension file>. Ekstensi file adalah PCE untuk Extract, PCR untuk Replicat, atau PCM untuk proses Manager. 5. Dirprm Direktori yang di gunakan untuk meletakkan parameter yang dibuat oleh administrator untuk setiap konfigurasi parameter proses dan paramater yang digunakan oleh utilitas. Dibuat dan diubah melalui perintah EDIT PARAMS pada GGSCI, tetapi dapat juga dibuat dan diubah secara langsung. Bentuk penamaan file adalah . PRM. Misalnya mgr.prm adalah paramater untuk Manager. 6. Dirrpt Direktori yang di gunakan untuk meletakkan report yang diciptakan oleh proses extract, replicat dan manager. ketika sebuah proses pada status abend, file .rpt akan diubah secara otomatis, walau bagaimanapun untuk menghasilkan statistik dari setiap proses, perintah PRINT REPORT pada GGSCI
harus
dipanggil.
Bentuk
penamaan
file
berupa
grup>.rpt 7. dirsql Direktori yang di gunakan untuk meletakkan kode-kode SQL.
2.7
Replikasi Active-active BI-Directional Active-active BI-Directional adalah topologi replikasi dimana ada dua mesin
sistem yang memiliki struktur yang sama, dapat saling merubah ketika proses transaksi terjadi oleh aplikasi pada tiap sistem seperti pada gambar 2.9.
25
Gambar 2.9 Topologi bi-directional [Referensi: Oracle® GoldenGate Windows and UNIX Administrator’s Guide, 2011] Pada konfigurasi BI-Directional terdapat sekolompok proses yang aktif pada tiap sistem. Data di-extract pada satu sistem dan di kirimkan ke sistem lainnya kemudian diterima oleh replicat pada lokal sistem target. Detil komponen Arsitektur logik dari topologi ini dapat dilihat pada gambar dibawah ini.
Gambar 2.10 Komponen arsitektur logik topologi bi-directional [Referensi: Oracle® GoldenGate Windows and UNIX Administrator’s Guide, 2011] Bi-directional ini juga mendukung load sharing yaitu kemampuan untuk mendistribusikan lalu lintas keluar dan masuk melalui beberapa jalur. Dapat juga digunakan untuk toleransi bencana jika aplikasi bisnis yang berjalan memiliki struktur yang sama pada tiap mesin. Menurut Oracle® GoldenGate Windows and UNIX Administrator’s Guide DBMS yang didukung oleh Oracle GoldenGate pada topologi active-active BI-Directional adalah: -
c-tree
-
DB2 on z/OS and LUW
-
MySQL
-
Oracle
-
SQL/MX
-
SQL Server
26
-
Sybase
-
Teradata Untuk dapat menerapkan Oracle dengan topologi BI-Directional, terdapat
beberapa kondisi basis data yang harus diperhatikan diantaranya: 1. TRUNCATES TRUNCATES adalah perintah DDL yang berfungsi untuk mengosongkan basis data, perintah ini tidak akan mencatat transaksi tersebut ke log basis data. Oracle GoldenGate hanya mendukung beberapa DBMS yang dapat mendukung perintah ini dan tidak dapat dikonfigurasi pada kedua basis data yang akan direplikasi, melainkan harus dari satu sumber basis data. 2. Data Definition Language (DDL) Untuk dapat melakukan replikasi DDL antara dua basis data, dapat dilakukan jika metadata kedua basis data tersebut identik dengan ukuran maksimum operasi DDL 2MB untuk seluruh objek basis data seperti: clusters, function, indexes, packages, procedure, tabel-tabel, roles, views, dan objek lainnya. 3. Jumlah Basis data Semakin banyak basis data yang akan direplikasi, maka proses re-sinkronisasi tanpa downtime semakin komplek, dan membuat semakin sulit dalam merancang dan memanajemen rutin-rutin resolusi konflik. 4. Konfigurasi Basis data Salah satu basis data harus di desain sebagai sumber data yang dipercaya (trusted source), merupakan basis data utama (primary database) dan merupakan pusat sistem dari basis data yang lain sehingga menjaga frekuensi backup pada trusted source perlu juga dilakukan. 5. Perancangan Aplikasi Replikasi Active-active tidak direkomendasikan untuk digunakan untuk perangkat lunak berbayar, kecuali perangkat lunak tersebut di rancang untuk mendukung replikasi, beberapa kendala mengapa active-acitve BI-Directional tidak direkomendasikan untuk hal tersebut: a. Paket perangkat lunak tersebut mungkin saja memiliki objek dan tipe data yang tidak didukung oleh Oracle GoldenGate
27
b. Terdapat operasi DML yang tidak bisa dikontrol, yang mungkin dapat menyebabkan konflik pada saat diterima oleh replicat c. Tidak dapat merubah struktur data agar dapat didukung oleh active-active BI-Directional 6. Keys Untuk keakuratan deteksi terhadap konflik, semua records harus memiliki identitas unik, dan bukan identitas null. Jika memang memungkinkan selalu membuat primary key pada tiap tabel, jika tidak memungkinkan, gunakan kunci unik lain dengan menggabungkan beberapa kolom dengan opsi parameter KEYCOLS pada paramater MAP dan TABLES, jika tidak menggunakan kedua-duanya Oracle GoldenGate akan menggunakan semua kolom pada tabel yang dianggap valid. 7. Triggers dan Cascaded Deletes Triggers dan Cascade Deletes
menyebabkan operasi DML tidak dapat
direplikasi oleh Oracle GoldenGate. Untuk mencegah hal tersebut, langkahlangkah dibawah ini harus dilakukan. a. Melakukan modifikasi untuk mengabaikan operasi DML yang dilakukan oleh Replicat, dapat menggunakan parameter DBOPTIONS dengan opsi SUPRESSTRIGGERS untuk menon-aktifkan triggers pada Replicat b. Menon-aktifkan ON DELETE CASCADE dan menggunakan trigger pada tabel induk untuk melakukan fungsi penghapusan pada tabel turunan. 8. Database-generated values Pada basis data yang men-generasi nilai kunci pada tabel, jarak antar nilai harus berbeda pada tiap sistem, dengan catatan tidak tumpang tindih, sebagai contoh pada dua basis data, satu basis data men-generasi nilai ganjil, dan yang lain bernilai genap. Untuk lingkungan n-server setiap nilai kunci dibuat dengan kenaikan nilai kunci yang berbeda. 9. Volume data Pada konfigurasi standar sudah memungkinkan menjalankan Oracle GoldenGate Jika: a. Beban transaksi konsisten dan jumlah volume kurang lebih tersebar merata di antara setiap objek yang akan direplikasi
28
b. Tidak ada proses yang terjadi diantara berikut ini: -
Dimana tidak menjalankan transaksi data yang berkepanjangan pada tabel
-
Tabel-tabel yang memiliki jumlah kolom yang banyak dan selalu berubah, atau tabel yang memiliki kolom-kolom dimana Oracle GoldenGate harus mengambil kolom dengan tipe data LOBs, atau kolom yang dipengaruhi oleh prosedur SQL, dan kolom yang tidak tercatat pada log transaksi.
10. Resolusi konflik Prosedur resolusi konflik harus diletakkan pada setiap sistem untuk mencegah collusion yang mungkin terjadi ketika perubahan dilakukan terhadap sekumpulan data identik pada sistem yang terpisah pada waktu yang sama. Pada lingkungan active-active, pencegahan konflik harus dapat diidentifikasi dengan segera dan dapat dicegah secara otomatis jika memungkinkan, namun aplikasi bisnis yang berbeda akan membuat area kebutuhan juga menjadi berbeda. Selain itu pada active-active BI-Directional, replikasi yang terjadi dari satu sistem ke sistem lain harus dicegah agar tidak melakukan replikasi kembali ke sistem semula, jika tidak dilakukan pencegahan, maka proses akan terjadi terus tanpa batas sebagai contoh: - Update baris data terhada pada server 1 - Proses extract akan menangkap perubahan tersebut dan mengirimkan ke server 2 - Proses replicat akan meng-update baris pada server 2 - Proses extract pada server 2 akan menganggap terjadi perubahan dan mengirimkan ke server 1 - Proses replicat pada server 1 akan menerima kembali data tersebut untuk ke dua kalinya - Perulangan ini akan terjadi secara terus menerus Untuk mencegah loopback, beberapa hal dibawah ini perlu dilakukan: -
Mencegah proses capture dari operasi-operasi SQL yang dibuat oleh replicat, tetapi mengaktifkan proses capture terhadap operasi-operasi SQL yang dibuat oleh aplikasi, di definisikan pada parameter extract.
29
-
Identifikasi transaksi lokal yang dibuat oleh replicat agar proses extract mengabaikan transaksi-transaksi tersebut.
-
Pencegahan terhadap proses ini tergantung pada basis data yang digunakan, secara umum proses extract akan mengabaikan operasi SQL yang diciptakan oleh proses replicat kecuali basis data Teradata. Parameter yang melakukan kontrol terhadap hal ini adalah: 1. GETAPPLOPS, INGNOREAPPLOPS, akan melakukan kontrol terhadap operasi DML yang dihasilkan oleh aplikasi atau akan diabaikan. 2. GETREPLICATES, IGNOREREPLICATES akan melakukan kontrol terhadap operasi DML yang dihasilkan replicat atau akan diabaikan oleh proses extract.
11. Identifikasi transaksi yang terjadi pada proses replicat Untuk menjaga proses replicat tidak terjadi berulang, maka setiap proses akan menyimpan semua transaksi replicat sebagai checkpoint pada sebuah table, pada
paramater
EXCLUDETRANS
extract
harus
ditambahkan
pada
TRANLOGOPTION SQL
Server,
dan
TRANLOGOPTION FILTERTABLE pada MySQL, sehingga proses extract akan mengabaikan tabel tersebut.
