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

  • From: "Zhu,Chao" <zhuchao@xxxxxxxxx>
  • To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 27 Oct 2010 09:52:29 +0800

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
SAN
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;


-- 
Regards
Zhu Chao

Other related posts: