RE: 64 node Oracle RAC Cluster (The reality of...)

Are you specifically talking about OCFS or the CFS that is provided by the OS? You know a lot more about the OS level stuff than I do (not that it would be hard to do that!) I'm not sure if these are generic OS concerns you have or ones specifically aimed at OCFS (which is another thing I don't know much about!)  

Pete  

"Controlling developers is like herding cats." Kevin Loney, Oracle DBA Handbook  

"Oh no, it's not. It's much harder than that!" Bruce Pihlamae, long-term Oracle DBA

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala Sent: Wednesday, 22 June 2005 11:05 AM
To: peter.sharman_at_oracle.com
Cc: kevinc_at_polyserve.com; mwf_at_rsiz.com; Rich.Jesse_at_quadtechworld.com; oracle-l_at_freelists.org; Peter Ross Sharman Subject: Re: 64 node Oracle RAC Cluster (The reality of...)

On 06/21/2005 08:42:50 PM, Pete Sharman wrote:
>
> Seriously, where a CFS is supported by the OS, why would you do anything else for the ORACLE_HOME?
>
>
> Pete

Because CFS might not be the best fit for a myriad of small files that need to be paged into the memory quickly. CFS may not support anything but direct I/O, therefore not caching $ORACLE_HOME/bin/oracle and shared libraries on $ORACLE_HOME/lib, which means that almost all page faults will be hard faults. On the other hand, if CFS does cache files as is the case with UFS by SUN Microsystems, it needs the same type of mechanism to synchronize the caches across the nodes as are the ones used by oracle. That might perform well only if background_dump_dest, user_dump_dest and core_dump_dest are not on the same global file system. Also, resist temptation to put archive destinations on CFS. Putting it on normal FS and then sharing it over public connection by NFS is much faster then by putting it on CFS.

--
Mladen Gogala
Oracle DBA


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


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