Apakah metode terbaik untuk mengimplemetasikan DRP (Disasters Recovery Plan) pada Microsoft SQL Server?

Artikel itu saya buat dikhususkan untuk pada Database Administrator SQL Server yang mempunyai database SQL Server dengan tingkat availability yang sangat tinggi.

Apa yang dimaksud dengan DRP (Disasters Recovery Plan)?
Disasters Recovery Plan, atau saya singkat DRP, adalah metode/rencana yang diterapkan/disusun oleh kita apabila terjadi hal-hal yang tidak diinginkan terjadi pada database atau mesin tempat menyimpan database yang kita punyai, sehingga menimbulkan rusak atau bahkan hilangnya data pada database kita. Hal-hal yang tidak diinginkan tersebut bisa bermacam-macam, misalnya data terhapus, mesin tempat menyimpan database kita rusak, kebakaran pada ruang tempat menyimpan mesin database kita, bencana alam dan lain sebagainya.

Beberapa hal yang harus diperhatikan dalam mengimplementasikan DRP
Sebelum kita membuat metode/rencana/langkah-langkah yang akan kita pakai dalam mengimplementasikan DRP ini, ada beberapa hal yang harus kita perhatikan berkaitan dengan implemetasi DRP ini. Hal-hal yang harus diperhatikan tersebut antara lain adalah :
Buat suatu list yang yang diurutkan berdasarkan tingkat availability dari semua database yang ada dalam mesin/server kita
Bedakan lokasi tempat menyimpan mesin/database/backup kita dengan lokasi tempat menyimpan mesin/database yang sedang running
Pilih metode yang terbaik untuk metode DRP ini, disesuaikan dengan semua resources yang ada pada kita, kalau memang kita tidak bisa mengeluarkan anggaran tambahan untuk implemetasi DRP ini.
Lakukan simulasi metode DRP yang telah kita tetapkan
Lakukan pengecekkan metode DRP secara berkala
Lakukan review terhadap metode DRP yang telah kita terapkan

Metode manakah yang terbaik?
Microsoft SQL Server menyediakan beberapa metode untuk mengimplementasikan DRP ini.
Data Transformation Services (DTS)
DTS bisa digunakan untuk meng-copy objek-objek database dan data antara database yang berbeda dalam server yang sama atau dengan server yang berbeda.
Keuntungan :
- Menyediakan wizard yang user friendly
- Menyediakan fasilitas untuk bisa membuat functionality secara programmatic
- Data bisa di transfer ke dalam berbagai macam format
Kerugian :
- Tidak bisa dijadikan warm-standby server
- Memakai resources server dan bandwidth yang besar, sehingga apabila database kita sudah berukuran besar, kemungkinan data tidak sinkron akan besar
Kesimpulan :
Sangat sulit untuk maintain warm-standby server dengan menggunakan DTS ini, karena kerugian-kerugian tersebut diatas. Untuk itu, gunakan DTS untuk men-transfer data daripada menjadikannya sebagai metode untuk DRP.

Bulk Copy (BCP)
BCP bisa dikatakan sebagai versi primitif dari DTS, karena bisa dijalankan dengan menggunakan command line.
Keuntungan :
- Efisien dan cepat dalam men-transfer data dengan ukuran yang besar
Kerugian :
- Sama kerugiannya DTS
- Tidak bisa digunakan untuk men-transfer objek database selain tables dan views
- User interface yang tidak bagus
- Tidak ada fungsi untuk scheduling
Kesimpulan :
Sangat sulit untuk maintain warm-standby server dengan menggunakan BCP ini, karena kerugian-kerugian tersebut diatas. Untuk itu, gunakan BCP untuk men-transfer data dengan cepat daripada menjadikannya sebagai metode untuk DRP.

Replication
Replication atau replikasi men-transfer data dari satu database ke database lain, dan bisa juga men-transfer dari SQL Server ke semua jenis ODBC data sources.
Replikasi ada 3 jenis :
- Snapshot Replication : Transfer tables secara komplit dari satu database ke database lain (tidak ideal untuk table yang besar)
- Transactional Replication : hanya men-transfer perubahan yang terjadi dalam database sumber
- Merge Replication : merupakan replikasi 2 arah, baik digunakan untuk data yang terdistribusi.
Keuntungan Transactional Replication :
- Hanya men-transfer perubahan yang terjadi dalam database sumber
- Dengan rencana yang baik, perbedaan antara database sumber dan database tujuan bisa diatur waktunya
- Enterprise Manager menyediakan user interface yang bagus
Kerugian :
- Banyak hal yang bisa menyebabkab proses replikasi ini terjadi error, diantaranya dalah :
o Tingkat availability dari server-server yang lain (publisher, distributor, subscriber)
o Availability SQL Server Agent
o Security permission dalam folder Snapshot
o Bandwidth network
o Hubungan antara publisher, subscriber and distributor
o Tempat ruang kosong dalam harddisk distribution database
- Semua table harus mempunya primary key
- Memerlukan perhatian besar dari database administrator dan harus dimonitor secara kontinyu
- Tidak bisa men-transfer objek database, seperti UDF (User Define Function)
Kesimpulan :
Selama transactional replication bisa digunakan untuk men-transfer data antara server yang satu dengan yang lainnya, tetap memerlukan setup dan monitoring yang agak sedikit sulit. Sebagai pertimbangan gunakan transactional database ini untuk maintain database reporting dengan men-transfer dari OLTP database.

Clustering
Clustering merupakan metode terbaik untuk High Availability karena bisa otomatis memindahkan koneksi ke server lain bila server primer mengalami masalah. Dalam cluster aktif/pasif, server sekunder secara terus menerus momonitor server primer, dan akan segera mengambil alih apabila server primer mengalami masalah.
Keuntungan :
- High Availability
- Tidak ada campur tangan user, ketika melakukam recovery server.
Kerugian :
- Memerlukan SQL Server Enterprise Edition dalam tiap-tiap server, sehingga memerlukan cost untuk licensing yang lebih mahal.
- Memerlukan spesifikasi hardware yang compatible untuk proses clustering.
- Sulit dalam mebuat konfiguransinya
- Memerlukan un-clustering dan re-clustering ketika akan mengimplementasikan SQL Server Service Pack.
- Memerlukan 2 koneksi yang dihubungkan decara fisik.
Kesimpulan :
Clustering adalah merupakan salah satu cara yang terbaik untuk solusi High Availability pada Microsoft SQL Server, tetapi bukan merupakan metode pendekatan terbaik untuk DRP, kecuali kalau digabung dengan metode-metode yang lain, seperti backup/restore, disk mirroring, dan sebagainya.

Backup/Restore
Backup database menyediakan duplikat dari database yang sedang running, dan proses backup juga tidak hanya membuat duplikat dari suatu database tetapi termasuk dengan objek-objek yang ada dalam database tersebut.
Keuntungan :
- Membuat duplikat data dan objek dalam database dengan sama persis.
- Bisa mudah diimplementasukan dengan menggunakan wizard Database Maintenance Plan
- Hanya memerlukan sedikit resources untuk monitoring, karena hanya sekali di configure
Kerugian :
- Ketika melakukan proses restore, database harus dalam keadaan single user mode
Kesimpulan :
Dengan mengkombinasikan full database backup dan transaction log backup bisa dijadikan salah satu alternatif sebagai metode untuk proses DRP.

Log Shipping
Log shipping ada proses pemindahan/peng-copy-an transaction log files secara otomatis. Log Shipping memerlukan server primer dan server sekunder yang harus kita tetapkan.
Keuntungan :
- Log Shipping menyediakan kapabilitas untuk proses copy dan restore log files secara otomatis berdasarkan durasi tertentu dan secara terus menerus.
- Dengan Log Shiping ini perbedaan data diantara server primer dan sekunder bisa dikurangi.
Kerugian :
- Tidak tersedia pada Microsoft SQL Server 7.0
Kesimpulan :
Log Shipping boleh dikatakan sebagai metode DRP yang terbaik, karena resiko kehilangan data sangat sedikit dan sedikti pula waktu untuk downtime.


Dari semua uraian diatas kita bisa mengambil salah satu metode yang paling baik manakah yang bisa diimplemetasi sebagai metode untuk DRP.


Deni Kusdeni
Database Specialist, INTIMEDIA
Email : deni@intimedia.com
dkusdeni@gmail.com

Me and my best Friend

Friends always come and go, but friendship is never end
Saya (bertopi), bersama teman terbaik dalam sebuah acara kantor....

SAP/R3 Single Sign On and ITS

Sudah 3 minggu ini saya mencoba melakukan installasi dan setting SAP agar bisa melakukan metode Single Sign On (SSO). Pada akhirnya semua bisa dilakukan dengan baik, meskipun harus "tabrakan" sana-sini.

SAP bisa jalan dengan menggunakan SSO setelah saya set Secure Communication Network (SNC) pada sisi SAP R3 Application server-nya.

Sekarang yang belum adalah konfigurasi SAP SSO yang jalan di atas platform ITS (Internet Transaction Server), sedangkan SAP/R3-nya sendiri sudah mulus jalan diatas ITS, sehingga user bisa mengakses-nya dengan menggunakan browser.

Mudah-mudahan SSO dengan ITS bisa juga di setting dengan baik......