Diskusi tentang Load balance di RAC

Ada diskusi saya dengan teman-teman di milis indo-oracle tentang RAC. Tampaknya menarik untuk saya taruh di blog ini. Ini tentang load balance.

Sharing teman I

I have rac environment: hp-ux itanium, 2 node rac, db 10.2.0.2, hp-serviceguard

Now we got problem may be bug… From the OS side it seem balance, that the currently processes running is same (throughtop/glance). The memory utilization is almost balance as well as cpu

But from inside oracle node2 has 70% from total sessions. I have configured server-side and client side load balancing altogether. clb_goal set to short, throughput in the service

From SR support told me that querying V$osstat on this platform return no rows, that may be the root cause.

Tanggapan saya

Memory dan CPU sudah balance, itu berarti “load balance” sudah tercapai. CMIIW, term “load balance” itu menitik beratkan pada load system secara keseluruhan, bukan semata-mata jumlah session di masing-masing instance.

Kadang (bahkan sering) jumlah session tidak berbanding lurus dengan load (pemakaian resource). Load untuk 1 session transaksi insert 1 row BERBEDA dengan load untuk 1 session yang melakukan deleting 1m rows.

Tanggapan teman I

Anehnya kalau dilihat dari dalam oracle gv$servicemetric, jelas2 gak balance. Kalau dari sisi OS balance hanya terlihat “process running saja” masing2 node kelahatan process running (dgn top) memang balance, tapi dari sisi utilisasi cpu, memory, disk beda banget..

so ada yg pernah mengalami? and how to solve?

Kemarin sempat balance karena saya coba re-register PMON terhadap service yg sedang running dgn merubah parameter local_listener, cuman ya itu dia kadang2 rada angot, load balance nya jadi dodol
lagi….tapi besoknya jadi balance lagi….. he…he…. seperti teka-teki silang 🙂

Tanggapan saya

He… he… kayak teka-teki silang ya. Makanya Pak, Oracle dibilang “Ora kelar-kelar” 🙂

Dulu saya pernah ngalamin yang seperti itu di versi 9i. Analisa dari Oracle Support (TAR) terlalu lama, biasanya paling-paling apply patch atau apply latest patch set. Akhirnya kita putusin gak pake RAC lagi.

Dulu juga pernah ngalamin banyak problem di RAC 10.2.0.2, terutama dengan tingginya wait-wait yang berkaitan dengan cluster. Akhirnya kita putusin pake single node saja. Viola… response time jadi cepet banget.

High availability yang ditawarkan Oracle harus kita bayar dengan turunnya response time.

Tentu saja, tidak semua solusi dari Oracle cocok dengan environment kita. Dan tentu saja juga, banyak yang terbantu dengan solusinya Oracle.

Ada situasi, kondisi, dan NASIB yang menentukan. Yang terutama, NASIB 🙂

Tanggapan teman II

Dear Pak Rohmad. Saya sangat tidak sependapat dengan statement anda dan menurut saya itu adalah pendapat dari sebuah kegagalan anda. Apa pendapat anda dari Capture database RAC saya di attament email ini…? Dan Saya sangat merasakan sekali benefit dari Oracle RAC ini, benar-benar ZERO Downtime. Sehingga Aplikasi ERP kita tidak pernah terganggu ( bisnis proses tidak terganggu ), sekalipun kita melakukan Restart salah satu Database Server kita maupun kita sedang melakukan maintenance server kita. Btw, saya juga tidak pernah mengalami problem seperti keluhan anda di Oracle RAC saya.

Tanggapan saya

Iya, dari sisi Oracle Corp saya mungkin orang yang gagal mengemban misi Oracle untuk menjadikan Oracle sebagai main solution. Namun dari sisi company saya, paling tidak saya bisa membantu menunjukkan product-product Oracle yang mana yang cocok dengan environment yang ada.

Saat ini saya memantain 4 RAC, masing-masing dua node. Dulunya lebih banyak lagi. Kita pernah menambah salah satu RAC menjadi 3 node; namun ya itu, keinginan tidak sesuai dengan kenyataan, akhirnya kita kembalikan lagi ke 2 node. Teori tidak selamanya memberi kenyataan yang perfect. Bug-bug sering muncul ketika resource utilization meningkat drastis. Bug, adalah bukti nyata tidak mungkin sempurnanya suatu teori (konsep).

RAC, untuk tujuan high availability, menambah layer baru di bawah database, yaitu cluster. Cluster inipun punya layer lagi, yaitu software clusternya Oracle (CRS di 10g) dan cluster di level machine.

Penambahan layer adalah penambahan possibility untuk mendapat masalah tambahan.

Ketika ada masalah, atau bug muncul, Oracle belum tentu mendapat solusi dengan cepat. Seperti yang pernah saya alami. Karena masalahnya unik, belum pernah ada, maka team Oracle support melempar masalah saya ke team development Oracle. Lhah… berapa lama saya mesti menunggu, sementara aplikasi tidak boleh lama-lama dalam keadaan bad-performance? Bad performance berarti REVENUE LOSS. Yah… tampaknya keputusan yang terbaik adalah melepaskan RAC. Setelah performance bagus; kita tetep mesti mencari solusi high availability, menunggu Oracle mendapat solusi atau memakai solusi lain selain Oracle.

Btw, syukur, RAC anda tidak mendapat masalah. Sayapun bersyukur, 4 RAC saya yang saat ini running tidak bermasalah.

This entry was posted in Administration, Concept and tagged , , , , . Bookmark the permalink.

One Response to Diskusi tentang Load balance di RAC

  1. harry says:

    Pak Rohmad, saya ingin melakukan instalasi RAC pada 2 mesin server yg identik dan mempunyai internal storage di masing2 server. Bisakah saya dapatkan dokumen instalasi RAC database 10g for Linux X86 64 bit untuk internal Hardisk. Saya sudah mencoba mencari di website oracle dll yg saya temukan harus menggunakan Shared Storage.
    Demikian terima aksih atas bantuannya.

Leave a Reply

Your email address will not be published. Required fields are marked *