RE: Big RAC Benchmark Performance Tips?

Not sure about GPFS. If memory serves me correctly - the GPFS is a pseudo clustered file system(proxy i/o by chance?). And seems Oracle would still be using the interconnect for it's instance communication. Seems like the Global Resource Directory would tell an instance if there is an exclusive lock on a block by another instance in the cluster, not the actual GPFS file system.

But the LLT protocol (by veritas) is used instead of the IP stack (say the UDP packets). And, would be used in the communication between instances (aka exclusive locks on blocks,read consistent image,etc).

greg
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mogens Nørrgaard Sent: Tuesday, August 01, 2006 11:59 AM
To: oracle-l_at_freelists.org
Subject: Re: Big RAC Benchmark Performance Tips?

Re 1: No. Cache Fusion is no longer an issue. It's free. Re 1: Yes. Cache Fusion is of course still a cost. It's neccessary, therefor it is, and therfor it has a cost. You can call it anything you like (and people do), but data partitioning still, after all these years, minimize pinging.

Re 2: No idea. I suspect it doesn't matter one iota whatsoever. It's just "I've heard this" vs "I've heard that".

Re 3: Why would you want to disable the excellent index skip scan? Good luck with AUM and ASSM. This test can't fail, as long as you're using anything Oracle recommends.

Re 4: Forget best practices. Forget silver bullets. They work for one site, but never for another. There are only worst practices.

Good luck.

Mogens

VIVEK_SHARMA wrote:

> Folks
>
> A 4-node RAC BIG benchmark with Oracle 10g / AIX 5.3L using a Hybrid
> Banking App. is underway.
>
> *Qs1 Does Cache fusion(Traffic between the nodes thru the
> interconnects) continue to be an expensive operation in Oracle 10g?*
>
> To minimize Cache fusion, Manually Transactions have been grouped such
> that transactions accessing different DB Server Nodes access different
> respective Table partitions (& NOT the same Table partition). Thus
> Different Object BLOCKS are accessed in different DB Server nodes.
>
> NOTE - Partitioning of heavier underlying tables has been done such
> that different partitions lie in DIFFERENT Tablespaces (& hence
> datafiles).
>
> *Qs2 Is Low Latency Protocol - LLT protocol (of Veritas) equivalent or
> something similar available with GPFS?*
>
> Currently default (UDP) is being used.
>
> NOTE - A Past benchmark done by us on SUN using VXFS (Veritas) with
> both Low Latency Protocol (LLT) & User Datagram Protocol (UDP,
> Default) showed LLT had a *98% Lower interconnect utilization* versus UDP.
>
> *Qs3* Any additional init.ora parameters for performance apart from
> the following which have been set?
>
> db_writer_processes=16
>
> db_cache_advice=OFF
>
> event='10196 trace name context forever, level 10' (to disable index
> skip scan)
>
> _library_cache_advice = FALSE
>
> _log_simultaneous_copies 256
>
> _b_tree_bitmap_plans = FALSE (as NO Bitmap indexes exist)
>
> _check_block_after_checksum TRUE
>
> _system_trig_enabled FALSE (Benchmark Has NO need for Triggers)
>
> _wait_for_sync TRUE
>
> NOTE - Standard features i.e. AUM, Tempfiles & ASSM are being used.
>
> *Qs4 Other best practices to deploy?*
>
> Will provide Statspack, Other diagnostics info. as needed.
>
> Thanks indeed
>
> *Configuration*:-
>
> APP & DB machines - *P5* series
>
> Application Hybrid - (OLTP + Batch nature of Trans).
>
> Oracle 10.2
>
> AIX 5.3
>
> Filesystem GPFS
>
> Storage Box DS8300
>
> Hardware RAID 1+0
>
> Underlying Hardware Stripe Unit Size 64 KB
>
> Overlying Logical Volume Manager Stripe Unit Size 32 MB (S.A.M.E.)
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this
> e-mail or its contents to any other person and any such actions are
> unlawful. This e-mail may contain viruses. Infosys has taken every
> reasonable precaution to minimize this risk, but is not liable for any
> damage you may sustain as a result of any virus in this e-mail. You
> should carry out your own virus checks before opening the e-mail or
> attachment. Infosys reserves the right to monitor and review the
> content of all messages sent to or from this e-mail address. Messages
> sent to or from this e-mail address may be stored on the Infosys
> e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l