When a transaction runs slower, it could mean the program runs well. While faster running sometime means error happening.
“sekarang jalannya lambat, berarti sukses” kata temen, aku pun menyetujuinya dg sedikit tersenyum garing. Hal seperti ini sering banget terjadi juga di tempat2 lain yg maek SAP. Sapertos nuju import data export kana database dina instalasi, upami import cepet beres biasana aya masalah, kadang ku lantaran R3trans -x na oge can jalan atanapi koneksi kana database can bener. Sebelum2nya program berjalan cepat selesai tapi ternyata hasilnya bermasalah. Ini terjadi setelah beberapa kali program dibetulkan dan ditransport ke production system yang mengakses beberapa tera byte database dan jutaan baris dokumen bisnis, seringnya dianggap normal saja lambret walau sudah main indexing, archiving, optimasi performansi, reorg, optimasi query dan program, dan segala jurus mempercepat program.
Normal tidaknya kelambatan system bisa dilihat dari transaksi standar SM50, ST03N, ST04, ST06. Bisa juga dari operating system untuk melihat utilisasi proses. Terkadang dari infrastruktur sistem seperti network lambat, direktori archive log penuh. Komponen performansi yg lambat pun harus dianalisa, misalnya database time tidak normal kalau lebih dari 40% dari response time. Ada sekitar 5 komponen response time yg cukup besar dan beberapa lainnya yg berkontribusi kecil.
source code, SAP bahasa ABAP. transaksi SE10 , query , optimasi: indexing , ubah query / baris2 program mendukung indexing. Kesimpulan paling parah : solusi resizing hardware , tambah memory, storage, mesin, lainnya seperti archiving (SARA) beserta storage solutionnya (IXOS, IBM Commonstore)
No comments:
Post a Comment