RE: RAC 10.2 + Sun Cluster 3.1 + QFS

>>>>Am I correct? Could I use QFS for Oracle datafiles as well
as flash recovery area? If yes, is there a perticular reason to choose QFS over ASM beside eaiser file management?

...Sun should be answering this, or you can see it in Oracle's words here:
https://metalink.oracle.com/metalink/plsql/f?p=140:1:156324369626265908 but read on...

Since you are going with Sun Cluster, at least you wont get Oracle's CRS ATONTRI
(http://www.freelists.org/archives/oracle-l/05-2006/msg00834.html), but you still have to live with braindead SCSI-III Persistent Res for "fencing" (which isn't fencing at all really). Better than systems getting
rebooted for lack of anything better to do I guess. Still not very robust.

As for a CFS, over ASM, well, it depends on how much risk and change you want to pile into one basket. To a lot of "real datacenters" with organizational structure, ASM presents concerns.

To system and storage administrators, ASM is a "black box". Unless the sole usage for
storage in the datacenter is Oracle, and therefore the storage administrators rely
entirely on Oracle space utilization tools such as Enterprise Manager , they
cannot even detect when ASM space is approaching full capacity. A simple

glance at df(1) or third party systems management tools are no longer sufficient.
So, if there is an unplanned space requirement, the DBA has to ask the storage administrator for another "chunk of raw disk" to add to ASM. This
in turn makes the storage administrator take action in a sort of emergency
reactive mode. The system administrator in turn has to perform the OS level
configuration and discovery naturally involved with making a raw chunk of
disk available to an application.

If database administrators are not perfect in their ability to project future
space requirements, they will make routine, troublesome, last-minute requests
for storage-not the most harmonious operating conditions by any means. Contrast
this to the storage model of a cluster filesystem. The storage and system
administrators have RAC storage utilization levels within plain view using
the same monitoring tools and methods they use for all the other applications
they support. Oracle is a very important application, but storage and system
administrators have a great deal more to think about. Provided the CFS you
choose is online resizable, storage and system administrators can add space to
CFS without the database administration staff ever picking up the telephone.
Action always yields better results than reaction.

There are also a lot of files that must go in shared disk that cannot be

placed into ASM. Some datacenters strive for standardization. Clustered environments can be confusing enough as it is so changing both the fundamental
way databases are stored and limiting the effectiveness of the storage group
in one fell swoop can lead to disaster.

Oracle databases have consisted of filesystem files for nearly 30 years and storage administrators need to have control. It is for this reason that datacenters are increasingly choosing to deploy RAC onto CFS solutions such as PolyServe on Linux/Windows or in your case QFS.

A real CFS (Like QFS or PolyServe and must unlike OCFS1 and Sun GFS) support
locating ***all*** Oracle files into the cluster filesystem. Without a general purpose cluster filesystem, applications that use such

features as External Tables, BFILE, and UTIL_FILE will not function the same, or not at all, with RAC. Administration is simplified as well since
there is no need to navigate between servers to access ORACLE_BASE directories
for logging, trace, scripts and so forth. The idea behind a RAC deployment
on a general purpose cluster filesystem is to get more of a "single system
feel", which is an important characteristic to a lot of datacenters.

The problem I have, and I still hold a grudge, is that all those "misfire" CFSs like Sun GFS (proxy) and OCFS1 (not really a filesystem at all, just a datafile container), Sistina, Lustre, etc is that they create confusion in the marketplace. Look, people that are serious about cluster filesystems don't like it when providers say they have a cluster filesystem then footnote the thousands of things their CFS diesn't support because it is not POSIX complain and/or it is architected with a braindead first-to-market approach like master/slave metadata and lock managers. So when a company ( like PolyServe) that builds a CFS from the ground up to be a real CFS, battles must be fought against misperceptions. I hate battling misconceptions and predispositions. That is me, now you know why I'm crabby sometimes :-)

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