Dengan perasaan nggak berdosa, gw nyalain aja tuh instance DB, abis ngasih perintah startup, si DB mulai bangkit dari tidurnya… but, wait…

ada keluar error di konsol putty gw, ORA-01092 : ORACLE instance terminated. Disconnection forced, trus instancenya mati lagi ??? gw ngacir ngeliat alert_log nya :

ORA-30012: undo tablespace 'UNDOTBS1' does not exist or of wrong type
Mon Apr  7 10:37:38 2008
Error 30012 happened during db open, shutting down database
USER: terminating instance due to error 30012
Instance terminated by USER, pid = 1286356
ORA-1092 signalled during: alter database open
...

Whahahaha… ternyata nemu juga masalahnya.. gw jadi inget kemaren gw baru aja rebuild undo tablespace nya jadi nama tablespace undonya gw rubah, dari UNDOTBS1 ke UNDOTBS, naaahh.. ironisnya nih, setelah gw rubah, gw nggak rubah juga parameter di SPFILE nya….

Sambil garuk-garuk kepala, gw ganti isi parameter undo tablespace di init.ora dengan nama yang sesuai, pas gw bikin kapan hari.. trus jalanin lagi proses startup databasenya pake pfilenya…

SQL > startup pfile='/appora/oracle/admin/sidgue/pfile/init.ora';

setelah instancenya bisa nyala, trus gw musti bikin spfile yang baru, biar nti pas gw startup lagi, nggak usah pake parameter pfile segala… huh.. ngrepotin ajah… hehehhee

SQL > create spfile from pfile;

Untungnya masalahnya ada di DEVELOPMENT, jadin nggak pake acara deg-deg an.. whehehehe. Ok, sekarang database nya bisa up dengan lancar.. aseek..! ngacir deh gw kw pantry, ambil gorengan bu APRI… nyam-nyam…!

Oh ya.. klo mo liat-liat punya expert.. hehehe.. ada di sini linknya  http://www.dba-oracle.com/t_ora_01092_oracle_instance_terminated.htm

Lha.. ditanya begituan gw juga bingung juga.. wong biasanya juga nggak pa2 kok.., kok baru sekarang ada yang busy terus, nah curiga nih gw, akhirnya dengan senang hati (baca : berat hati) gw cabut dari kost-an and ngacir ke kantor dengan cuma pake celana pendek n kaos oblong plus lucky strike gw nggak kelupaan.

Di kantor, lewat topas gw emang liat ada hardisk yang busy mulu.. gw bilang ajah ke bos klo ada yang busy mulu pak hardisknya.. eh si bosnya malah nanya balik ke gw, itu hardisk apaan ya mas ? isinya apa ajah ya mas, ada proses apaan aja di situ ya mas, kok bisa seratus persen mulu ? GRUBYAk… iya ya.. kenapa nggak gw cari ada apaan disitu yah?

Walhasil gw coba liat-liat lari ke mount point mana itu hardisk ? sambil tanya-tanya commandnya ke teman-teman gw.. ketemu juga…

1. Lihat hardisk yang busy itu ada di mount point yang mana ?

lspv -l {nama hardisk} <enter>

Disitu keluar nama nama volume group yang udah dibikin dan di assign dengan nama mount point yang bersangkutan, contoh keluaran :

2. Lihat hardisk mana saja yang juga masuk ke mount point yang dimaksud itu ?

lslv -l {nama LV_NAME} <enter>

Disitu keluar nama-nama hardisk yang dialokasikan ke mount point yang kalian maksud, contoh keluaran :

Muter-muter…. hehehe nggak puas sama command-command yang di maksud, coba-coba juga command-command yang lain… tanya-tanya juga ke sysadmin gw.. hoho untukngnya doi baik, bisa kooperatif and nggak pelit2 amat, ngasih tau klo gw belum tahu and sama-sama nyari tahu klo doi belum tahu.. Jadi deh muncul pertanyaan yang macem-macem, trus gw catet disini, ya lumayan bisa di liat lagi klo ntar lupa.

1. Lihat volume group yang dibuat pada server

lsvg <enter>

Disitu keluar nama nama volume group yang udah dibikin, contoh keluaran :

271 $ lsvg

rootvg

ora_vg

soft_vg

ora2_vg

backup_vg

2. Lihat detail dari sebuah volume group

lsvg -l {nama volume group yang mau dilihat detailnya} <enter>

Keluar nama logical volume yang ada di volome group tersebut, contoh keluaran :

 270 $ lsvg -l backup_vg

 backup_vg:

 LV NAME  TYPE LPs PPs PVs LV STATE MOUNT POINT

 ofa_backup_lv jfs2 4800 4800 7 open/syncd /ofa_backup

 backup_rtk_lv jfs2 7520 7520 10 open/syncd /rtk_backup

 loglv03  jfs2log  1 1  1 open/syncd N/A

3. Lihat detail logical volume berisi hardisk apa saja ?

lslv -l {LV Name dari keluaran diatas} <enter>

Keluar nama logical volume yang ada di volome group tersebut, contoh keluaran :

273 $ lslv -l backup_rtk_lv

backup_rtk_lv:/rtk_backup

PV COPIES IN BAND DISTRIBUTION

hdisk30 799:000:000 20% 160:160:159:160:160

hdisk34 799:000:000 20% 160:160:159:160:160

hdisk35 799:000:000 20%  160:160:159:160:160

hdisk36 799:000:000 20% 160:160:159:160:160

hdisk37 799:000:000 20% 160:160:159:160:160

hdisk38 799:000:000 20% 160:160:159:160:160

hdisk25 798:000:000 19% 160:159:159:160:160

hdisk32 793:000:000 19% 160:154:159:160:160

hdisk33 400:000:000 20% 080:080:080:080:080

hdisk39 735:000:000 21% 160:160:159:160:096

4. Lihat statistik hardisk menurut logical volume

iostat hdisk36 hdisk37 hdisk38 hdisk25 hdisk32 hdisk33 hdisk39 3

Keluar altifitas dari setiap detail hardisk yang ada disebuah logical volume, contoh keluaran :

tty: tin tout avg-cpu: % user % sys % idle % iowait

 0.0 913.0 0.4 7.3 92.3 0.0

Disks:      %   tm_act Kbps tps  Kb_read   Kb_wrtn

hdisk36   0.0      0.0      0.0        0         0

hdisk37   0.0      0.0      0.0        0         0

hdisk38  75.0   6485.3     51.0        0     19456

hdisk39   0.0      0.0      0.0        0         0

Jadi gitu deh, oh ya.. btw klo misal ada cara yang mungkin lebih efektif dan lebih cepat, misal pake command yang lain, tolong dibenarkan yah, ato kasih masukan gitu.. biar bisa lebih mudah. Ada cara lain sih biasanya gw pake topas buat ngeliatin perfomance secara keseluruhan, cuma biasanya juga nggak jelas mana saja hardisk yang emang bener2 sibuk dan isinya adalah sesuatu yang patut dicurigai. Klo pake topas kan emang sih udah urut mana hardisk yang paling sibuk sampe yang paling nggak sibuk, cuma karena layar monitor gw yang kecil, jadi nggak keliatan semua statistik hardisknya.. ok kawan, sekian dulu !

Awal ceritanya sih, sebenarnya gw pengen buat partisi di salah satu tabel yang nyimpen data transaksi sales, yang musti di simpen setahun.. eee ndak tau nya tabel yang dikatakan histori transaksi itu ternyata masih ke-update dan ke-insert sama data-data baru dengan tanggal transaksi yang udah lama.. Nah Loh…

Walhasil gw disuruh bikin trigger buat log sapa aja session yang masukin data-data aneh itu.. wah jangan-jangan… jangan jangan .. haha… Ya udah deh, mulai aja bikin trigger sederhana.. buat nangkep pelakunya. Sebelumnya gw dah buat tabel audit di schema gw sendiri yang udah punya role DBA. Biar mudah struktur tabelnya emang gw ambil dari view v$session, nggak ditambahain apa apa.. trus baru bikin trigger di tabel yang datanya ngaco tadi…

Klutak-klutik .. kayaknya triggernya dah jadi deh… tinggal dicompile.. No Errors.. WHoopss kok muncul itu ? statusnya masih invalid boss.., penasaran juga.. perasaan nggak ada yang salah ma codenya. Isi codenya cuma ambil value userenv dari tiap session trus cocokin ke v$session, trus gw masukin lagi ke tabel yang gw buat.. Wheng..wheng .. kenapa yah..

Terpaksa deh mohon pencerahan ke mbah gugel, hoho… ngga nemu nemu.. eh kebeneran ada sebiji manusia nongol dibelakang gw.. “Mas… user sampeyan mesti di grant select ke v_$session dulu.. baru bisa select…”. Lho kan user gw dan punya role DBA, kenapa masih nggak bisa select ke ke v$session pas bikin trigger ? dalam hati gw nggak setuju ama sohib gw yang masih gw bilang manusia (abis uda kayak kesetanan aja klo lagi pas bikin script / koding sesuatu… jam tiga Men..!! masih sempet juga nyari-nyari exception… dasar si Oling &^*&)).

Singkat cerita.. gw turutin dah kasih grant select ke view itu.. trus compile lagi… jalan bosss.. no error found.. mantab benar tuh anak, hehe.. nah biar gw ndiri nggak lupa, gw tulis aja di blog nih, sapa tau juga ada yang lagi lupa hehe..

Btw mohon pencerahan klo ada yang tau alasannya kenapa yah gw musti grant user DBA gw.. ?

Regards, mashimi.

Perfoma sistem yang baik diperoleh dari desain sistem dan maintenance yang baik yang diterapkan dalam sebuah sistem aplikasi. untuk membangun sebuah sistem dibutuhkan ketelitian extra pada saat membuat desain awal sistem, sehingga akan lebih mempermudah usaha tuning sistem pada saat sistem sudah berjalan menjadi production sistem.

Permasalahan perfoma menjadi semakin penting pada lingkungan production system, seiring dengan perkembangan sistem yang semakin besar dan rumit. Untuk mengakomodasi kebutuhan ini, maka diperlukan metode peningkatan perfoma yang baru, yang diharapkan akan dapat membuat sebuah sistem dapat lebih menampilkan perfoma terbaiknya.

Stategi tuning perfoma sangat bervariasi tergantung dari kebutuhan dan tujuan sistem yang berbeda, satu contoh mudah adalah kebutuhan perfoma untuk sistem online akan jauh berbeda penerapannya dengan metode perfoma yang dilakukan pada data warehouse. Metode perfoma sistem dibangun dan diterapkan dalam sebuah sistem, dan tidak terjadi begitu saja secara otomatis. Permasalahan perfoma seringkali dimunculkan oleh serialisasi / antrian dan kelebihan beban pada resource. Pada saat terjadi kelebihan resource, maka sistem tidak dapat menampilkan perfoma yang lebih baik dari perfoma aktualnya.

Metode tuning yang dimunculkan saat ini adalah perencanaan yang lebih baik dalam melakukan desain aplikasi database untuk mencegah kelebihan beban pada resource yang dapat mengakibatkan downtime, dengan cara mengurangi konflik resource / penggunaan resource secara bersamaan, sehingga aplikasi dapat berjalan dengan perfoma terbaik dan dapat mendukung kebutuhan bisnis.

A. MEMAHAMI OPSI INVESTASI

Dengan melihat kenyataan yang ada bahwa kebutuhan investasi yang tidak murah seperti prosesor dengan kemampuan tinggi, memori dan storage, bisnis unit akan berpikir dua kali untuk melakukan investasi lebih dengan membeli lebih banyak resource untuk menaikkan perfoma sistem.

Pada banyak kasus, Penyediaan budget untuk melakukan pengadaan CPU baru, memori atau lebih banyak storage / media penyimpanan dapat mendongkrak perfomance dan atau melakukan troubleshouting sistem secara cepat, dengan meminimalkan resiko kegagalan sistem. Namun yang perlu disadari oleh semua divisi baik itu divisi infrastruktur, development dan application support adalah, penambahan resource tersebut merupakan solusi jangka pendek yang dengan cepat pula akan menjadi usang seiring dengan peningkatan beban kerja dari aplikasi yang tidak mungkin berkurang lebih rendah dari kebutuhan awal dalam mendukung proses bisnis.

Fakta berikutnya adalah, muncul dari pertanyaan klasik, bagaimana kita bisa melakukan usaha tuning sebuah sistem, jika tidak mengenal dengan baik seluk beluk aplikasinya ? apa kegunaan, bagaimana karakteristiknya, apa yang akan dihasilkan oleh aplikasi itu ? Keadaan seperti ini acapkali menjadi sebuah masalah yang selalu dihadapi oleh perusahaan-perusahaan dengan tingkat ‘lalu lintas’ personel / karyawan yang tinggi. Bagaimana bisa sebuah bisnis bisa dengan cepat memperoleh kestabilan dan perfoma optimal sebuah sistem jika, pilot-pilot pengendara sistem sering kali harus berpindah kursi..? karena bagaimanapun seorang pilot, juga harus memiliki intuisi dan kemampuan analisa yang tajam atas karakteristik dan peta kekuatan pesawatnya. Oleh karena itu, perekrutan sumber daya juga bisa dikelompokkan ke dalam investasi perusahaan atas pencapaian perfoma sistem yang diharapkan.

B. MEMAHAMI SKALABILITAS SISTEM

Apa yang dimaksud dengan skalabilitas sistem adalah kemampuan sistem yang ada dalam mengakomodasi lebih banyak proses dari apa yang mampu dilakukan sistem pada posisi aktual. Dengan kata lain jika bisnis beranjak berkembang dua kali lipat dari kebutuhan awal, maka tentu saja kebutuhan sistem juga akan berkembang menjadi dua kali lipat kebutuhan awal. Efek negatif dari skalabilitas sistem yang buruk dapat diketahui dari beberapa hal sebagai berikut :

• Kebutuhan akan reporting data yang sulit dipenuhi.
• Mengurangi availability sistem, karena object-object database akan memakan waktu lebih lama untuk dilakukan maintenance.
• Peningkatan dalam skala waktu dan anggaran dalam rangka troubleshouting berkaitan dengan permasalahan yang muncul.

Sebuah aplikasi dikatakan overload dan tidak lagi memenuhi syarat skalabilitas sebuah aplikasi, jika tidak ada lagi kemungkinan sebuah sistem yang mendukungnya mampu untuk bekerja diluar batas rata-rata transaksi aktual. Contoh nyata yang diberikan bahwa sebuah sistem telah keluar dari batas skalabilitas adalah :

• Terjadinya aktifitas locking yang semakin meningkat.
• Peningkatan jumlah user akan turut meningkatkan kebutuhan resource, baik itu dari segi hardware dan atau software (lisence).
• Penggunaan processor yang melebihi beban kemampuan.
• Desain sintax query yang buruk dan struktur tabel (penerapan partisi) dan index yang salah akan memperlambat kinerja aplikasi karena terjadinya tingkat pembacaan tabel dengan I/O tinggi.
• Pencapaian maximum throughput I/O pada monitoring storage, dikarenakan pembacaan tabel pada peak session, sehingga storage tidak mampu lagi mengeluarkan data yang diminta.
• Alokasi penggunaan memori pada server database yang turut juga menggunakan paging space secara berlebihan.
• Penggunaan thread berlebihan pada aplikasi yang mengakibatkan bottleneck, baik dari segi I/O ataupun ketersediaan CPU.

Jika sebuah sistem telah berada pada posisi tersebut diatas, maka tugas dari seorang application architecture untuk melakukan koordinasi dengan team terkait (manajemen, development, infrastruktur), dan segera melakukan review desain sistem dan melakukan perbaikan-perbaikan yang dianggap perlu agar mencapai solusi terbaik.

Berfokus pada skalabilitas sistem, perbedaan jenis aplikasi dan bisnis mempunyai pendekatan skalabilitas yang berbeda, disesuikan dengan karakteristik bisnis dan aplikasi yang menggawanginya, walaupun dalam pengertian dan tingkat penanganan sama. Satu contoh mudah untuk menggambarkan skalabilitas sistem adalah, skalabilitas pada internet based sistem.

Karakter aplikasi yang berbasis internet dapat digambarkan sebagai berikut :

• Ketersediaan sistem 24x7x365
• Jumlah user yang tidak dapat diprediksi.
• Kesulitan untuk melakukan perencanaan kebutuhan sistem.
• Kemampuan sistem untuk menangani berbagai macam jenis query dalam waktu yang bersamaan.
• Penerapan arsitektur applikasi multi tier.
• Perkembangan sistem yang sangat cepat.
• Minimal waktu untuk melakukan testing.

Karakteristik internet based application tersebut diatas menjadikan tantangan tersendiri diantaranya dan yang paling utama adalah timeframe waktu yang sangat singkat dalam proses development dan testing. Secara umum, bahwa kurang tercapainya desain awal yang baik akan pasti mengakibatkan satu hal yaitu desain dan implementasi ulang pada saat sistem berada pada garis batas skalabilitasnya.

Dari kacamata bisnis, proses tersebut harus ditebus dengan harga yang sangat mahal akibat kehilangan jumlah pengguna aplikasi diakumulasikan dengan biaya desain dan implementasi ulang yang seringkali lebih besar dari pada biaya pembuatan desain dan implementasi sistem yang baru.

Ada kalanya sebuah desain atas skalabilitas sebuah sistem yang baik, tidak berjalan dengan mulus pada saat implementasi yang sesungguhnya. Hal ini bisa disebabkan atas :

• Munculnya permasalahan yang tidak terduga pada saat implementasi sistem, sehingga memaksa proses implementasi keluar dari rel desain, misalkan dibutuhkannya server baru sebagai pengganti server lama yang terbakar karena bencana alam / kecelakaan, hingga akhirnya dilakukan pemangkasan budget pada bagian lain demi tercapainya target implementasi sesuai dengan timeline yang telah ditentukan.
• Perubahan kebijakan bisnis dan penyesuaian politik kantor yang muncul pada saat proses implementasi sistem tanpa diimbangi dengan usaha nyata dalam rangka penyesuaian atas desain sistem yang sudah dibuat. Misalnya, penyimpanan data pada storage yang pada saat desain hanya dibatasi untuk aktif selama 3 bulan transaksi dan selebihnya dihapus, ternyata berubah untuk disimpan selama 1 hingga 2 tahun masa transaksi, sehingga membuat skalabilitas sistem tidak lagi mempunyai nilai yang sama pada saat desain awal aplikasi.

Kesimpulan yang didapat adalah poin skalabilitas dalam desain dan implementasi sistem harus ditetapkan dengan tepat dan bijaksana, serta disajikan lengkap dengan rule / aturan main yang jelas dan disepakati oleh semua divisi terkait agar dicapai sistem yang tangguh dan sanggup menampilkan perfoma terbaik dalam mendukung proses bisnis.