BAB 2 TINJAUAN PUSTAKA 2.1. Data - Replikasi pada Standby Database Menggunakan Metode Incremental Backup
BAB 2 TINJAUAN PUSTAKA
2.1. Data
Data adalah sesuatu yang mewakili objek dan peristiwa yang memiliki arti yang sangat penting bagi user (Hoffer et al, 2005). Dalam pengertian yang lain data adalah fakta yang dapat disimpan dan memiliki arti (Navathe & Elmasri, 2000). Sehingga dapat disimpulkan bahwa data adalah fakta yang telah terjadi, memiliki arti, dan dapat disimpan secara teratur sedemikian rupa sehingga menjadi sebuah form yang dapat digunakan kembali suatu waktu. Data yang saling berhubungan akan dikumpulkan dan disimpan dalam suatu database. Hal ini jelaskan oleh (Connolly, 2002) yang menyatakan bahwa database adalah suatu koleksi data yang saling berhubungan secara logikal, dan sebuah deskripsi data yang dirancang untuk memenuhi kebutuhan informasi suatu organisasi. Database mempunyai sumber data dalam pengumpulan data, bervariasi derajat interaksi kejadian dari dunia nyata, dirancang dan dibangun agar dapat digunakan oleh beberapa user untuk berbagai kepentingan (Waliyanto, 2000). Untuk memasukkan, mengubah, menghapus, memodifikasi dan memperoleh data/informasi dengan praktis dan efisien digunakan sebuah program komputer yang disebut DBMS (Data Base Management System).
2.2. Disaster Recovery
adalah proses, kebijakan dan prosedur yang berkaitan dengan
Disaster recovery
persiapan untuk pemulihan (recovery) atau kelanjutan pada infrastruktur teknologi yang sangat penting (vital) bagi organisasi setelah bencana yang disebabkan oleh alam maupun manusia. Bencana dapat diklasifikasikan ke dalam dua kategori, yaitu:
a. Yang pertama adalah bencana alam seperti banjir, angin topan, tornado atau gempa bumi. Sementara mencegah bencana alam sangat sulit, memastikan langkah-langkah seperti perencanaan yang baik adalah solusi yang lebih tepat.
Langkah-langkah tersebut diharapkan mampu menghindari ataupun mengurangi kerugian akibat bencana (disaster).
b. Bencana buatan manusia. Bencana juga dapat terjadi akibat perbuatan manusia.
Sebagai contoh kegagalan infrastruktur dan terorisme. Dalam hal ini pengawasan dan perencanaan juga diharapkan dapat menghindari kerugian.
Menurut (Gregory, 2009) Disaster Recovery Plan (DRP) adalah bagian dari sebuah proses yang lebih besar sebagai perencanaan kelangsungan bisnis dan termasuk di dalamnya perencanaan untuk memulai kembali aplikasi, data, perangkat keras (hardware), komunikasi elektronik (networking) dan infrastruktur teknologi informasi lainnya. Langkah-langkah kontrol pemulihan (recovery) bencana teknologi informasi dapat diklarifikasikan menjadi tiga jenis, yaitu:
1. Langkah preventive, kontrol yang dilakukan untuk mencegah sebuah bencana yang akan terjadi.
2. Langkah deteksi, kontrol yang bertujuan untuk mendeteksi atau menemukan kejadian yang tidak diinginkan.
3. Langkah korektif, kontrol yang ditujukan untuk memperbaiki atau memulihkan sistem setelah bencana atau peristiwa.
Disaster recovery plan yang baik memastikan bahwa ketiga jenis kontrol
didokumentasikan dan diuji secara teratur.2.3. Konsep Backup
Menurut (Tawar & Wahyuningsih, 2011) Proses backup dalam teknologi informasi mengacu pada pembuatan salinan data, sehingga salinan tambahan tersebut dapat digunakan untuk mengembalikan (restore) semula setelah peristiwa kehilangan data.
Backup data merupakan salah satu pengelolaan data agar data tetap terjaga saat terjadi
perubahan atau kehilangan data. Backup sangat berguna terutama untuk dua tujuan:
a. Untuk memulihkan keadaan setelah bencana (disaster recovery) b. Untuk mengembalikan sejumlah kecil file setelah sengaja dihapus atau rusak. Konsistensi data dalam proses backup harus dijaga, sebelum melakukan backup data. Secara umum tipe backup terbagi menjadi dua, yaitu:
a. Full Backup, yaitu tipe backup yang menyalin file secara keseluruhan dalam satu waktu dengan mengabaikan attribut archive bit file. Setelah file di-backup maka archive bit dari file tersebut akan dihapus sampai file tersebut dimodifikasi. Ketika archive bit diset kembali, ini menandakan bahwa file tersebut telah berubah dan perlu di-backup lagi.
b. Incremental Backup, adalah backup data yang mengalami perubahan sejak backup terakhir dilakukan. Hanya file dengan archive bit yang akan di-backup.
Hal ini akan menghemat penggunaan pita tapi memerlukan waktu yang lama untuk me-restore data karena data tersebar pada pita yang berbeda-beda. Menurut (Elmasri & Rames : 2011) incremental backup sering digunakan karena hanya mengganti perubahan yang terjadi sejak backup terakhir yang telah disimpan.
2.4. Replikasi
Replikasi dicapai dengan memiliki sistem standby, yang merupakan duplikasi dari
database produksi. Replikasi standby diperbaharui setelah database produksi
memanipulasi data, sehingga membuat sistem standby sangat dekat dengan sistem utama (Radulescu, 2002). Replikasi adalah suatu teknik untuk melakukan copy dan pendistribusian data dan objek-objek database dari satu database ke database lain dan melakukan sinkronisasi antara database sehingga konsistensi data dapat terjamin (Tawar & Wahyuningsih, 2011).
Pada dasarnya sistem replikasi membutuhkan minimal dua buah server untuk digunakan sebagai master dan slave. Dengan menggunakan teknik replikasi, data dapat didistribusikan ke lokasi yang berbeda melalui koneksi jaringan lokal maupun internet.
Beberapa keuntungan dari replikasi adalah sebagai berikut:
1. Memungkinkan beberapa lokasi menyimpan data yang sama. Hal ini sangat berguna pada saat lokasi-lokasi tersebut membutuhkan data yang sama atau memerlukan server yang terpisah dalam pembuatan aplikasi laporan.
2. Aplikasi transaksi online terpisah dari aplikasi pembacaan seperti proses analisis database secara online, data smarts atau data warehouse.
3. Memungkin otonomi yang besar. Pengguna dapat bekerja dengan meng-copy data pada saat tidak terkoneksi kemudian melakukan perubahan untuk dibuat
database baru pada saat terkoneksi.
4. Data dapat ditampilkan seperti layaknya melihat data tersebut dengan menggunakan aplikasi berbasis Web.
5. Meningkatkan kinerja pembacaan.
6. Membawa data mendekati lokasi individu atau kelompok pengguna. Hal ini akan membantu mengurangi masalah karena modifikasi data dan pemrosesan query yang dilakukan oleh banyak pengguna karena data dapat didistribusikan melalui jaringan dan data dapat dibagi berdasarkan kebutuhan masing-masing unit atau pengguna.
7. Penggunaan replikasi sebagai bagian dari strategi standby server.
8. Menyembunyikan perbedaan antara layanan replicated dan non-replicated.
Menurut (Wiesman et al, 2000) replikasi database memiliki tiga parameter dalam menentukan karakteristik yang terbaik untuk mereplikasi data, yaitu:
1. Arsitektur Server Parameter kunci pertama untuk dipertimbangkan adalah transaksi yang dieksekusi pada tempat pertama. Ada dua kemungkinan identifikasi, yaitu Replikasi copy primary yang memiliki situs yang spesifik untuk di copy oleh setiap data yang saling terkait. Serta replikasi update everywhere yang memungkinkan update ke item data yang akan dilakukan di mana saja dalam sistem.
2. Interaksi Server Untuk parameter ini terdapat dua hal yang harus dipertimbangkan, yaitu interaksi konstan, protokol dalam kategori ini melakukan pesan tunggal per transaksi dengan mengelompokkan semua operasi dari transaksi dalam satu pesan. Selanjutnya adalah interaksi linear yang biasanya berkaitan dengan teknik yang apabila sebuah server database merambat ke setiap operasi dari sebuah transaksi pada basis per operasi.
3. Terminasi Transaksi Sedangkan pada parameter terakhir juga terdapat dua hal yang harus dipertimbangkan, yaitu terminasi voting yang membutuhkan babak tambahan pesan untuk mengkoordinasi replika yang berbeda. Dan terminasi non-voting yang menyiratkan bahwa situs dapat memutuskan sendiri apakah akan melakukan atau membatalkan transaksi. Dengan membandingkan ketiga karakteristik tersebut Wiesman menyimpulkan bahwa update everywhere memiliki potensi yang baik untuk mereplikasi data.
Teknik replikasi di dalam Data Grid Environments menurut Noraziah (2012) adalah:
1. A Weight-Based Dynamic Replica Replacement. Strategi ini dihitung berdasarkan waktu akses dalam jendela waktu di masa depan, berdasarkan akses pada history terakhir.
2. Distributed Popularity Based Replica Placement Algorithm. Dikembangkan untuk jaringan data hirarkis. Strategi ini memanfaatkan history akses data untuk mengenali file yang sering muncul dan menentukan lokasi replikasi yang optimal untuk meningkatkan kinerja akses data dengan meminimalkan replikasi yang overhead pada pola jalur data yang diberikan.
3. A New Replication Strategy for Dynamic Data Grids diusulkan untuk memperhitungkan situs yang dinamis. Strategi ini dapat meningkatkan ketersediaan berkas, meningkatkan waktu respon dan dapat mengurangi konsumsi bandwidth.
4. Enhance Fast Spread Replication Strategy adalah versi yang disempurnakan pada Fast Spread untuk strategi replikasi data grid. Strategi ini diusulkan untuk meningkatkan total waktu respon dan total konsumsi bandwidth.
5. A Value-Based Replication Strategy untuk mengurangi jaringan latency dan sementara itu untuk meningkatkan kinerja keseluruhan sistem.
6. Agent Based Replica Placement Algorithm diusulkan untuk menentukan calon lokasi untuk penempatan replika yang mengurangi biaya akses, network traffic dan agregat waktu respon untuk aplikasi.
2.5. Primary Database dan Standby Database Primary database adalah database utama yang digunakan untuk menyimpan data.
Database ini diharapkan mampu diakses setiap saat. Maka dari itu jika terjadi transisi
role dan primary database mati, maka secara otomatis pengaksesan terhadap primary
database tersebut juga tidak dapat dilakukan.Standby database merupakan replikasi database yang terdiri dari backup data
dari sebuah primary database. Dengan penerapan redo log archive dari primary
database untuk standby database, sehingga data dapat disimpan di dalam server
database yang tersinkronisasi. Sebuah standby database memiliki tujuan utama
sebagai disaster recovery, backup, analisis, dan reporting (laporan). Jika primary
database hancur atau rusak, admin dapat melakukan failover ke standby database,
dalam kasus ini standby database menjadi primary database yang baru. Admin juga dapat membuka standby database dengan opsi read only, sehingga dapat berfungsi sebagai sebuah database reporting independen.
2.5.1. Failover
Failover yaitu mode backup operational pada saat fungsi komponen sistem (seperti
processor , server, network, atau database) dilakukan oleh secondary system
components ketika komponen utama mengalami kegagalan atau scheduled down time.
Pada konfigurasi standby database semua pengguna aplikasi melakukan transaksi pada primary database. Namun apabila server primary database mengalami kegagalan secara tidak terduga, maka admin harus melakukan failover. Failover adalah operasi yang mengubah standby database menjadi primary database sehingga dapat berjalan secara normal. Operasi ini juga disebut aktivasi standby database. Penting untuk diperhatikan bahwa setelah melakukan failover, admin tidak dapat mengembalikan standby database yang saat ini telah menjadi primary database untuk menjadi standby database kembali.
2.5.2. Redo Log File
Redo log file merupakan bagian terpenting dalam proses database untuk melakukan
proses recovery. Redo log files sebagai tempat catatan setiap transaksi yang terjadi. Berisikan file yang digunakan untuk melakukan instance recovery ketika database mengalami kegagalan.
2.5.3. Archived Log File
Tujuan utama archived log file adalah untuk melindungi database dari kegagalan
instance dan kerusakan media disk melalui pengarsipan secara online dengan
mengaktifkan proses pengarsipan ke dalam redo log file.2.6. Metode Standby Database
terdiri dari tiga metode. Masing-masing metode memiliki kelebihan
Standby database
dan kelemahan. Oleh karena itu seorang admin harus mampu memilih metode
standby database yang sesuai dengan sistem yang ada. Berikut adalah tiga metode
standby database .2.6.1. Metode Standby Database secara Manual
Admin memiliki pilihan untuk menempatkan database dengan menggunakan metode
manual recovery. Untuk melakukan metode ini, admin harus terus menerus dan secara manual mentransfer dan menerapkan archived redo log ke standby database untuk tetap disinkronkan dengan primary database. Berikut adalah proses standby database dengan menggunakan mode recovery manual seperti pada gambar 2.1.
Gambar 2.1. Standby database pada mode recovery manual [Oracle : 1999]Metode recovery manual berguna dalam lingkungan yang mana admin tidak menghubungkan primary database dan standby database. Karena alasan tertentu tidak dapat secara otomatis mentransfer archived redo log ke
primary database
standby database untuk melakukan recovery data. Admin membutuhkan aksi secara
manual dalam hal recovery untuk memperbaharui standby database.
2.6.2. Metode Standby Database secara Managed Recovery
Pada metode ini admin dapat menempatkan standby database dengan cara managed
recovery . Metode ini mengacu kepada standby database yang secara otomatis
menerima archived redo logs dari primary database. Keuntungan utama dari menjalankan metode ini adalah admin tidak harus mentransfer atau menerapkan
archived redo log secara manual. Di bawah ini adalah proses update secara otomatis
pada sebuah standby database pada gambar 2.2.Gambar 2.2. Update secara otomatis pada sebuah standby database [Oracle : 1999]2.6.3. Read-Only Mode untuk Query
Admin juga dapat membuka standby database dalam mode read only setelah manual
terminasi atau managed recovery. Pada saat melakukan mode read only, admin dapat melihat query database bahkan menyimpan data di tablespace sementara selama data sudah di dalam standby database tanpa mempengaruhi file data atau redo log. Kemudian admin dapat mengembalikan standby database untuk mode recovery manual atau managed recovery tanpa harus menutupnya. Berikut adalah proses dalam mode read only yang ada pada gambar 2.3.
standby database
Gambar 2.3. Standby database dalam mode read only [Oracle : 1999] Dalam lingkungan managed standby, standby server terus menerima archived
redo log oleh primary database dan file kontrol trus diperbaharui (update) dengan
record yang ada. Akibatnya, pengarsipan terus berlanjut pada server standby,
meskipun standby database tidak melakukan recovery dalam mode read only.
Standby database yang menggunakan metode read only berguna ketika admin
ingin mengurangi jumlah query yang ada pada primary database. Jika tablespace di dalam sebuah primary database jarang berubah tetapi sering diakses, admin dapat mengarahkan query ke standby database sehingga primary database tidak menjadi overload dengan permintaan akses.