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 ?

Gak enaknya jadi admin

Ada kejadian menarik hari ini. Kejadian fatal yang menyebabkan semua orang ngamuk. Gue sebagai admin SAP tentu saja sudah memberikan schedule yang jelas dan memberikan warning ke semua departemen terkait dengan backup offline. Karena proses backup offline gue masih agak bermasalah, jadilah bencana.

Dengan kejadian itu maka orang-orang yang terkait dengan proses job-job background mengalami keterlambatan. Biasalah akhirnya semua cari selamat sendiri dan menimpakan masalah kepada gue dan tim gue.

Pelajaran yang gue petik adalah semua orang cari selamat sendiri-sendiri. Kalau ada masalah semua ditimpakan ke orang lain. Mostly ke tim gue. Yang gue sebel lagi adalah kalau kerjaan dia ok atau berjalan baik, gak pernah ada tuh acknowledge ke tim gue.

Morale Story : Emang semua cari selamat sendiri. Kerjaan admin, salary gak nambah, kalo ada problem, disalahin paling dulu.

Tivoli again !!

Hari ini kantor gue kedatangan lagi. Vendor Tivoli datang lagi karena mereka musti setting ulang script-script backup karena kesalahan pemasangan tape library. Vendor satu lagi harusnya datang juga untuk memindahkan tape backup yang lama ke mesin baru. Tapi gue tunggu-tunggu sampe sekarang blom nongol juga.

Vendor TSM (NPP) lagi setting ulang beberapa script. Selain itu mereka musti ngeberesin aplikasi backup whole FS backup yang memakai DSMJ di beberapa mesin. Kemaren sempet dicoba, DSMJ nya ada yang mau jalan tapi tidak lewat LAN Free (lewat jalur Fiber Channel), ada juga yang tidak mau backup sama sekali.

Well, cukup banyak juga pekerjaan hari ini.

Banyak pekerjaan menumpuk

Pekerjaan di kantor masih menumpuk, tapi kok sempet-sempetnya nge-blog ? he..he..he..

Well, emang kerjaan di kantor masih cukup banyak. Mulai dari reorganization table di SAP, pasang Power Supply di server IBM p520, ngebenerin problem backup SAP untuk server production, problem backup offline DSMJ Tivoli, penukaran tape backup yang salah, menyiapkan server PRD2 untuk trial archiving….

Tuh banyak kan ? he..he..he..

Gue juga lagi nunggu payment dari blogvertise. Harusnya udah dibayar per tanggal 29 Agustus 2009. Sampe sekarang kok belum dibayar yah ?!?! Apa blogvertise lagi bokek ?

Backup Server SAP yang masih bermasalah

Setelah pergantian server SAP, proses backup mengalami masalah. Server yang baru memakai prosesor Power6 dan menggunakan OS IBM AIX 5.3 TL9. Sedangkan software Tivoli yang digunakan adalah versi 5.5. Sampai saat ini proses backup online untuk database SAP masih mengalami masalah. Proses backup bisa berjalan tapi seperti berhenti dan prosesnya menggantung. Proses masih menunggu. Akhirnya terpaksa di-abort agar proses backup yang lain bisa berjalan.

Anehnya sistem lainnya dengan memakai sistem yang hampir sama bisa melakukan proses backup dengan lancar. Memang ada yang beda sih, yaitu SAP ERP 6.0 yang lebih baru dari sistem SAP yang diatas.

Support TSM (Niaga Prima Paramita) pun ikut kebingungan. Sampai sekarang belum ada solusinya.

Lembur lagi…lembur lagi….

Sebenarnya gue udah bosen lembur. Bukan apa-apa, badan gue masih capek gara-gara lembur pergantian server 2 minggu lalu. Lembur lebih dari 24 jam membuat badan terasa sangat capek. Bahkan efeknya masih kerasa sampe sekarang. Gue udah suggest untuk pergantian controller ini dilakukan pada saat nanti libur Lebaran, tapi tetap aja semua maksa untuk dikerjakan besok.

Pekerjaan yang akan dilakukan adalah pemindahan sebagian enclosure storage dari controller lama (DS4500) ke controller baru (DS5100). Selain itu ada beberapa hal yang musti dilakukan termasuk pemindahan server untuk persiapan DR Plan, upgrade firmware untuk enclosure lama agar bisa match dengan controller baru (DS5100), pemasangan SAN switch lama (8 port) sebagai bagian dari persiapan DR Plan, dll.

Sebenarnya permasalahan utama dalam pekerjaan ini adalah constraint waktu. Kita diburu waktu untuk bisa up kembali sedangkan pekerjaan yang musti dilakukan cukup banyak termasuk men-shutdown semua server yang ada di Blade Center. Hal ini karena Blade Center musti diconfigure ulang agar VMWare ESX bisa connect ke storage yang telah dipindahkan controllernya.

MAS SAP ERP 6.0 SR3 Go Live

Sistem SAP ERP 6.0 SR3 di company baru akhirnya Go Live. Minggu ini adalah minggu pertama. Sebenarnya Go Live sudah dimulai sejak minggu lalu, but officially baru minggu ini.

Agak membingungkan juga, Go Live tapi di sisi yang lain-lain seperti Produksi dan pengiriman belum ada. Jadi murni baru modul MM (Pembelian), WM (Penerimaan barang), FI (Master Data, Pembayaran), dll.

Well, role masih agak kacau karena terburu-buru Go Live. Waktu yang disediakan terlalu mepet, cuma 2 bulan kurang. So far masih mbenerin role-role yang kurang.

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

Number of Work Process stopped after started ?!?!

Beberapa hari ini dipusingkan dengan settingan parameter SAP. Kebetulan gue lagi setting server SAP baru yang akan digunakan setelah migrasi pada hari minggu besok. Gejalanya adalah beberapa work process terutama dimana dijalankan terakhir akan langsung berhenti.

Ternyata hal ini disebabkan oleh settingan maximum number of process per user di level OS (AIX) yang belum disetting. Secara default, AIX akan memberikan value 128. Untuk sistem SAP kecil mungkin hal ini tidak mengganggu tetapi karena gue setting untuk sistem yang lumayan besar dengan jumlah work process sekitar 143 maka hal ini memberikan masalah.

Solusinya adalah memberikan value yang cukup untuk parameter maximum number of process per user lewat smitty. Jalankan smitty – System Environments – Change / Show Characteristics of Operating System – Maximum number of process per user. Defaultnya adalah 128. Ubah sesuai kebutuhan.

SAP Note Note 437362 – Composite note ORA-12500

Morale story : “Never give up, never surrender. Keep trying !!!”