seeking for opinions on migrate from Sun to X86: ASM vs filesystem, HA options;

From: Zhu,Chao <>
Date: Wed, 27 Oct 2010 09:52:29 +0800
Message-ID: <>

Hi, All

    We are in the progress of POC migrate from Sun Niagara platform to X86 platform for some of our database; Previously our database platform purely run on top of :
Sun HW+Solaris
Veritas as volume manager/HA
and oracle on top of it;

   With desireto X86(some due to dual vendor strategy, some due to cost reason, and some due to performance reason, you know Niagara performance for heavy transaction), everythign has to be re-evaluated; Currently we have a few open discussions: 1. Shall we still use veritas as volume manager/ext3,ext4 of vxfs as filesystem?

   Our architecture is saying that and i totally disagree;    my point is definitely we should go with ASM, no matter on SAN or local disk(we plan to run some database on local disk);   a few reason:

  1. From design, ASM is designed for oracle database server usage; much simpler than veritas, and go through 4 major release (10.1/10.2/11.1/11.2) and integrated with its product better;
  2. On ASM, we never need t*o worry about IO balance across volume*s, it always balances IO; on current volume manager, we have to carefully balance the IO; we have cases some volume(280gb/4lun from san) got 2000iops during busy hours, and some got very few ;
  3. On ASM, we never need to *worry about crash recovery (FSCK);* -- correct me I am wrong;
  4. On ASM, we never* need to worry about AIO; *AIO is critical for database IO performance (especially write heavy); On ext3, there is no real KAIO available(my knowledge is a bit old though); only threaded AIO;
  5. On Ext3, we have to carefully watch/manage the filesystem buffer cache(just like the AIX platform, sun do not have this problem); By default linux like to cache into buffer_cache; for oracle database we do not want this;
  6. Last but not least, ASM is a total solution oracle recommends for database now; We get more vendor bless than other solution; And more important, if we indeed run into problem, there is no finger point between redhat/oracle; (maybe we want to re-evaluate redhat linux vs oracle enterprise linux? There is part of the poc we want to do for oracle enterprise kernel though);

and architecture team member raised some concern:

  1. ASM is still fairly immature from a volume manager and file system standpoint. It is not posix compliant, and the only tools to access it are from Oracle. You can’t get to the data easily without running Oracle.
  2. You have to run another Multipathing product if you are not using the Veritas stack. Sometimes the MP product, is more than the entire Veritas stack, especially on Linux
  3. There is no way to easily do delta mirrors and other functions, that we might and might not use in our environment.
  4. It locks us into Oracle
  5. Our current standby’s give us the ability to copy over a file from a standby.. It is going to be difficult to do this with ASM.
  6. It changes the support structure, currently the unix team is responsible for the storage, file systems, volumes etc. This would become the DBA’s responsibility, or at least could.
  7. Clustering becomes an issue. My gut feel is that we don’t want to go with RAC as a general product in the environment, because of the cost, complexity, and the vendor lockin. And it is difficult to use Linux HA, VCS etc, if we are using ASM ok, next topic is about whether we should do VCS HA or CRS HA; but i guess this topic is busy enough, i will open a seperate thread for the discussion;


Zhu Chao

-- Received on Tue Oct 26 2010 - 20:52:29 CDT

Original text of this message