[Ocfs2-users] ASM over OCFS2 vs. Standard locally managed tablespaces

Luis Freitas lfreitas34 at yahoo.com
Mon Feb 9 10:30:05 PST 2009


Karim,

    Using ASM over OCFS2 on this scenario would not bring a improvement. You would still have a old version on ASM, and now a complex environment that would be very hard for a support analyst to duplicate internally at Oracle, in case you hit issues.

   If your concern is over your particular version of ASM I would keep it out until you can go to a more stable version of the database. After all ASM on 10g r1 was the first release of this component. I remember seeing some data corruption bugs on 10gR1 related to ASM. (Dont know if they are fixed on your particular version).

   Unfortunatelly this also means that you cannot use the management advantages of ASM.

   I saw the other e-mail sugesting you to install 11g ASM. Perhaps you could go with 10gR2 ASM on your 10gR1 database. This should be supported, but this usually is expected to be used during a upgrade cycle, only to allow the software and the database upgrades to be done in phases. If you hit issues probably support will sugest you to move to 10gR2 database instead of investigating them. Also this brings no guarantee that you wont hit issues, since the problem could be on the database side of the ASM, instead of on the ASM part.

Regards,
Luis

--- On Mon, 2/9/09, Karim Alkhayer <kkhayer at gmail.com> wrote:
From: Karim Alkhayer <kkhayer at gmail.com>
Subject: RE: [Ocfs2-users] ASM over OCFS2 vs. Standard locally managed tablespaces
To: "'Schmitter, Martin'" <Martin.Schmitter at opitz-consulting.de>, lfreitas34 at yahoo.com, ocfs2-users at oss.oracle.com
Date: Monday, February 9, 2009, 12:13 PM




 
 







Thanks Luis/Martin for your thoughts 

   

I’m raising this comparison noting the following givens: 

RAC is operating on Oracle 10.1.0.5; so the ASM is a bit far
beyond hot fixes. 

OCFS2 is also old on SLES9 SP3. That’s why we’re
considering the upgrade to SLES10 SP2. 

Oracle software upgrade is not an option for the moment due to
applications’ certification. 

The RAC + Standby node will be sharing a file system prepared
specifically for recovery  and staging, so that we don’t have to rely on
the network during crisis. 

Since we’re upgrading to SLES10 SP2, it is expected to
have OCFS2 much more stable. However, I still believe that we’ll be stuck
to the existing setup where the databases are not self-managed, and because of
the upgrade is primarily for the sake of OCFS2 . That’s why ASM over
OCFS2, from a concept point of view, could introduce the best of the two worlds. 

   

Best regards, 

Karim 

   

   

   





From: Schmitter, Martin
[mailto:Martin.Schmitter at opitz-consulting.de] 

Sent: Monday, February 09, 2009 3:52 PM

To: Karim Alkhayer; lfreitas34 at yahoo.com; ocfs2-users at oss.oracle.com

Subject: AW: [Ocfs2-users] ASM over OCFS2 vs. Standard locally managed
tablespaces 





   



Hi Karim, 

   

as Luis already stated: 

   

It is not useful to install an ASM “Cluster File
System!” on OCFS2. ASM is a full functional Cluster File System for
Oracle DBs 10g and 11g. There is no need of a second Cluster File System. You
will run in a lot of trouble setting the right timeout’s and preventing
different decisions of the CRS and OCFS2. Please keep in mind, that both (CRS
and OCFS2) are able to reboot your nodes. If you are working with 10g or 11g
make use of ASM! Take care of the ASM Hot Fixes! ASM does all you need. Load
balancing, striping, mirroring, and a lot more… 

   

OCFS2 is a good choice if you are using 3rd party
applications and you need a shared storage. E.g. you are using Oracle 9i with
CRS. Oracle 9i data files won’t work with ASM, so you need another
Cluster File System. If have done a project with 9i and CRS on OCFS2. This was
hard work, but it works fine. 

   

OCFS2 is really great, but if your running a database 10g or 11g,
ASM is and will be the best choice. 

  

BR 

  









Martin
Schmitter 





  





  





--
 





  





  





OPITZ
CONSULTING Gummersbach GmbH 





Martin
Schmitter - Fachinformatiker 





Kirchstr.
6 - 51647 Gummersbach 





http://www.opitz-consulting.de 







Geschäftsführer: Bernhard Opitz, Martin Bertelsmeier  





HRB-Nr. 39163 Amtsgericht Köln 

















Von: ocfs2-users-bounces at oss.oracle.com
[ocfs2-users-bounces at oss.oracle.com] im Auftrag von Karim Alkhayer
[kkhayer at gmail.com]

Gesendet: Montag, 9. Februar 2009 13:47

An: lfreitas34 at yahoo.com; ocfs2-users at oss.oracle.com

Betreff: Re: [Ocfs2-users] ASM over OCFS2 vs. Standard locally managed
tablespaces 







We’re using OCFS2 for RAC on top of  SLES9, which
we’re going to upgrade to SLES10. Around 10 TB RAID6 multi disk arrays, 5
databases on RAC, and 5 single instances standby for the primary site 

  

As there is no AI component in ASM to detect the fast LUNs, and
RAC on SLES requires a shared file system. Therefore, on a set of identical
LUNs, in terms of capacity and speed, ASM should take care of distributing the
balance over LUNs, and OCFS2 is expected to work even better if these LUNs are
placed on several disk groups (arrays) 

  

How would this scenario (ASM over OCFS2) work? What are the cons
and pros? Keep in mind that the goal of such a concept is provide performance
and reliability with  the least possible administration 

  

Appreciate your thoughts 

  

Best regards, 

Karim 

  

  



  









 




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-users/attachments/20090209/90c882bc/attachment.html 


More information about the Ocfs2-users mailing list