Home » Posts tagged 'Oracle Data Guard'

Tag Archives: Oracle Data Guard

SAP jadi lambat ?!?!


Hari selasa lalu seperti yang gue udah posting sebelumnya, company gue sedang melakukan POC Riverbed, sebuah appliance bandwidth optimizer. Riverbed sendiri berfungsi dengan sangat baik. Bahkan dengan diaktifkannya fitur optimized dan SDR, data reduction untuk archived log yang dikirim dalam konfigurasi Oracle Data Guard bahkan bisa mencapai 80%.

Fantatis sekali !!

Namun ternyata ada problem yang terjadi di server SAP Production yang berfungsi sebagai Primary Database (dalam konfigurasi ODG gue). Kadang SAP menjadi sangat lambat, kemudian balik ke kecepatan normal lagi, kemudian kembali lagi.

Sampe hari kemaren masih kejadian seperti itu. Dari diagnosa gue dan team, ada 3 hal yang terjadi dan dicurigai sebagai symptoms nya, yaitu :

  1. Pemasangan Riverbed, as you know gue lagi PoC Riverbed
  2. Adanya rebuild index table LTAP. Yang aneh rebuild index ini dianggap harmful index oleh database check SAP
  3. Adanya job report untuk menghitung report aset yang memakan waktu lama dan masih berjalan

Tindakan yang gue ambil pertama adalah menghapus index yang harmful. Namun ternyata hal ini tidak membantu. Langkah kedua adalah mencopot lagi konfigurasi PoC Riverbed. Setelah dicopot, ternyata performa server gue kembali normal. Hal ini memang aneh karena secara konfigurasi seharusnya tidak ada pengaruh nya. Karena Riverbed menerima data yang ditulis oleh proses ARC0 dan ARC1.

Baru sore kemaren mendapatkan pencerahan. Gue baru inget bahwa ada Redo Log group (SAP secara standar dan default menggunakan 4 set group Redo Log yang bisa ditulisi oleh proses LGWR). Gue curiga pada saat yang bersamaan 4 group file ini aktif semua karena masih nulis ke sisi standby database sehingga proses di SAP menjadi terhambat. Cuma gue belum bisa membuktikan hipotesa gue. Saat ini alat Riverbed nya masih ditarik oleh vendor nya.

Minggu depan gue bakal bisa mencoba lagi dan membuktikan hipotesa gue.

Morale Story : Pencerahan pasti akan datang, cuma seringnya waktunya kok ya pas injury time ?!?! Ah, yang penting sih ada pencerahan. Betul, gak ?

PoC Riverbed Steelhead gatot !!


Company tempat gue bekerja sudah implement Oracle Data Guard sebagai mekanisme untuk Disaster Recovery Plan. Kelemahan ODG adalah file-file archived log yang dikirim dari Primary DB ke Standby DB dalam kondisi plain atau tidak terkompresi. Gue udah nanya ke konsultannya, memang ODG tidak menyarankan adanya mekanisme kompresi disaat creation archived log. Akibatnya ukuran/size file archive log yang ter-create cukup besar.

Hal ini akan mengganggu apabila file-file tersebut dikirim ke Standby DB melewati WAN yang memiliki keterbatasan bandwidth. Apalagi harga sewa bandwidth di Indo masih sangat mahal. Vendor menawarkan mekanisme kompresi lewat appliance bernama Riverbed.

Hari Kamis lalu alat itu dan 1 konsultan datang untuk melakukan PoC di tempat kami. Settingan network dijalankan lewat WAN simulator. Namun anehnya, Riverbed tidak menangkap satupun traffic archived log yang lewat. Padahal jelas-jelas file tersebut terkirim lewat network.

Hari ini sementara dianggap PoC Riverbed gatot alias gagal total.

Migrasi Server SAP WS


Hari Sabtu pukul 24:00 atau hari minggu jam 00:00, migrasi server Wings dimulai. Tahapan pertama adalah shutdown aplikasi SAP dan database di server lama. Setelah itu dilakukan backup Whole File System. Proses backup memakan waktu cukup lama karena besarnya data yang dibackup. Data SAP sendiri mencapai 2,6 TB ditambah data-data file system. Proses backup dijalankan lalu ditinggal pulang.

Minggu pagi sekitar jam 07:00 kami datang lagi dan proses backup sudah selesai. Langkah selanjutnya adalah melakukan copy datafile Oracle, control file, file-file offline redolog dari server lama ke server baru. Proses ini memakan waktu sekitar 7 jam dan baru selesai sekitar pukul 14:00.

Seharusnya langkah selanjutnya adalah setting Oracle Data Guard dahulu karena database di server lama (yang akan difungsikan sebagai database standby) tidak boleh dalam posisi OPEN. Kesalahan terjadi saat vendor melakukan setting HACMP ulang di server lama  yang menyebabkan script HACMP berjalan dan menaikkan database dalam posisi OPEN. Aplikasi SAP juga ikut naik.

Karena terjadi kesalahan di step sebelumnya terpaksa dilakukan proses copy ulang. Kali ini dari server lama ke server baru. Sebelumnya dilakukan setting dahulu untuk Oracle Data Guard karena setting ODG tidak melihat IP Address server. Proses copy ulang dilakukan dan memakan waktu cukup lama dan baru selesai pukul 02:00 Senin dini hari. Kami terpaksa melanggar kesepakatan dengan departemen lain yang mana kami akan menaikkan SAP pukul 01:00 dinihari.

Dengan banyak effort dan masalah di RFC connection ke server SAP R/3 sister company lain sehingga SAP baru bisa up pukul 06:30 Senin pagi. Gue baru bisa pulang pukul  07:00.

Sesampainya di rumah gw masih ditelepon lagi karena ternyata background job banyak yang tidak berjalan. Setelah diselidiki hal ini terjadi karena job dibuat dan dijalankan pada spesifik server tertentu sehingga pada saat server name diubah job tidak ikut berubah. Terpaksa melakukan create ulang background job. Demikian juga proses backup.

Well, sampai detik ini masih lancar. I hope…

Ganti server SAP


Hari minggu ini seharusnya jadwal di rumah. Well, apa daya ? ada pekerjaan yang musti dikerjakan segera, yaitu mengganti server SAP yang lama ke server yang baru. Server lama akan dipindahkan ke DR site.

Pergantian server ini meliputi ganti server, setting dan konfigurasi HACMP, setting dan konfigurasi Oracle Data Guard sebagai DR Plan, setting backup TSM ke server baru, dll.

Rencana ini dilaksanakan sejak tadi malam dengan melakukan backup server lama terlebih dahulu. Backup sudah selesai. Saat ini server lama sedang meng-copy datafile-datafile server lama ke server baru.

Waiting Mode : ON

Fokus pekerjaan minggu ini


Minggu ini cukup banyak pekerjaan yang musti dikerjakan. Ada 2 hal besar yang akan dikerjakan, yaitu persiapan user dan role SAP untuk company baru yang akan go live tanggal 17 Agustus 2009 nanti dan persiapan pergantian server untuk company holding pada tanggal 9 Agustus 2009 ini.

Pekerjaan pertama yaitu design dan create role untuk user-user company baru ini cukup detail. Musti banyak dilakukan testing dan penyesuaian. Karena itu diharapkan team functional sudah menyiapkan tim testing dan memberikan masukan yang relevan.

Pekerjaan kedua adalah migrasi dari server lama ke server baru. Persiapan HACMP sudah disiapkan minggu lalu. Minggu ini sebelum dilakukan migrasi akan disiapkan pula untuk prosedur backup dan tape management-nya. Baru nanti pada hari minggu dilakukan migrasi serta setting Oracle Data Guard-nya.

Semoga pekerjaan-pekerjaan minggu ini dapat berjalan lancar. Amin..

Persiapan HACMP dan skenario migrasi Server SAP


Jadwal minggu ini adalah persiapan untuk HACMP di mesin baru. Mesin baru sudah disiapkan, termasuk restore database dan aplikasi SAP. Gue juga udah kontak ke konsultan SAP Basis yang akan di-hire untuk konfigurasi script HACMP buat server baru. Hal ini karena konfigurasi HACMP akan gue ubah menjadi lebih simple.

Skenario migrasi adalah HACMP masuk, baru kemudian restore datafile dari server lama ke server baru. Hal ini dibutuhkan untuk menyamakan status terakhir dari database SAP. Sekaligus akan dilakukan setting Oracle Data Guard dan TSM.

Renovasi rumah gue juga memasuki hari kedua. Sepertinya akan cukup cepat karena kemaren udah menaikkan tembok belakang.

POC Oracle Data Guard : Day 4 a.k.a Last Day


Hari ini adalah hari terakhir engineer CTI yang melakukan config POC Oracle Data Guard. Hari ini konfigurasi ODG yang kemaren dibuat dihancurkan lagi karena akan disetting untuk persiapan instalasi HACMP dulu. HACMP akan dimulai minggu depan. Jadi perlu disiapkan environment nya.

So stay tuned

POC Oracle Data Guard : Day 3


Setelah kemaren menyelesaikan sejumlah testing transaksi level database dan level SAP, serta melakukan testing switchover maupun failover, akhirnya bisa dianggap bahwa ODG cukup oke. Konfigurasi Oracle Data Guard yang kemaren dibikin hancur karena data sudah tidak konsisten dan tidak sinkron antara 2 database, primary dan standby. Pada saat sebelum pulang kemaren, sudah sempet dilakukan restore lagi (dengan cara meng-copy datafile  agar sinkron).

Hari ini akan dilakukan setting lagi untuk Oracle Data Guard. Posisi akan dikembalikan sebagai Primary dan Standby database.

Can’t wait to check ODG configuration again.

Perubahan konfigurasi untuk ODG


Agar bisa dijalankan Oracle Data Guard ada beberapa perubahan yang mesti dilakukan baik di Primary Database maupun Standby Database. Perubahan terutama dilakukan pada beberapa file berikut :

  • listener.ora
  • tnsnames.ora
  • sqlnet.ora
  • init.ora atau pfile atau spfile (tergantung database pake apa)

Setelah perubahan dilakukan, dilakukan transfer datafile dari primary ke standby agar posisi datafile konsisten. Apabila database standby pernah di-open maka ini menjadi wajib dilakukan. Karena kalau tidak dilakukan maka standby database akan dianggap tidak konsisten. Control file di standby database juga perlu di-create dengan posisi standby dari control file milik primary database.

Untuk sisi SAP di primary database tidak ada perubahan. Perubahan dilakukan di environment SAP di sisi standby database. Perubahan yang perlu adalah mengubah dbs_ora_tnsname menjadi service name standby (lihat di tnsnames.ora dan atau listener.ora yang baru). Baru SAP instance di standby server bisa dijalankan. Jangan lupa soal saplicense yah…

POC Oracle Data Guard : Day 2


Projek POC Oracle Data Guard di kantor memasuki hari kedua. Kemaren tim CTI sudah melakukan konfigurasi untuk settingan Primary dan Standby Database. Namun, karena sebelumnya database yang di-config sebagai standby DB pernah di-open, data didalamnya menjadi tidak konsisten. Akhirnya untuk menyamakan posisi konsisten dengan database primary, tim melakukan restore database untuk level datafile. Datafile yang ada di primary dikirim lewat SCP (Secure Copy). Mekanisme SCP memerlukan package openssl dan openssh.

Pada saat kami tinggal kemaren, posisi masih melakukan copy. Gue belum sempet mengecek apakah proses copy sudah selesai.

Well, jadwal hari ini adalah melakukan testing ODG. Checklist testing sudah disiapkan dan siap dijalankan.