RE: OCFS2
- From: "Murching, Bob" <bob_murching@xxxxxxxxx>
- To: "'cmarquez@xxxxxxxxxxxxxxxx'" <cmarquez@xxxxxxxxxxxxxxxx>, "'Oracle Discussion List'" <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 8 Aug 2005 11:13:58 -0400
While we're on the subject of OCFS, how many of you logically mirror the
voting disk and OCR if you're fully redundant on the storage side? Same
arguments (pro and con) you'd use for online redo log members, or are there
additional considerations specific to the voting disk and/or OCR?
_____
From: Marquez, Chris [mailto:cmarquez@xxxxxxxxxxxxxxxx]
Sent: Monday, August 08, 2005 11:01 AM
To: Oracle Discussion List
Subject: RE: OCFS2
>>some of you complain about OCFS
>>and make all kinds of dispariging comments
>>please get technical because I fail to find
>>any value in a posting that just bitches
OCFS is slow(er), that is a fact...and slower than RAW when promoted as
begin equal to RAW!?
When going to a new server with more disk (7 spindles vs. 4) and more
powerful CPU, more RAM we find;
- Very, very server waits is for disk IO...even when db activity is
moderate.
- Most of, or often the oracle waits is for disk IO...when activity is
higher.
- RMAN backup is 3 x's longer or more (than a server with only 3 datafile
EXT3 disks).
- RMAN restore is 4 x's longer (than a server with only 3 datafile EXT3
disks).
- Can not (and is not recommended by Oracle) to archive to OCFS...massive
oracle waits when we did.
(This is a real impact because it means that RMAN scripts can *NOT* see all
arch logs as local/shared and *must* get logs from there respective local
arch dest...this is a huge risk on node failure and recovery is needed.)
All of the things I reference above I have not seen once but many, many
times over and over again.
I have personally spent months trying to better or system (disk config) for
OCFS use...and we have made improvements, but reality is that our db ran
much faster "WITH LESS HARDWARE" when we used EXT3.
We had RAID5, then went to RAID1, move arch logs to local EXT fs, re-laid
out every datafile on each disk based on optimal application data access.
The reality is that this db will run immediately faster if we got off OCFS.
Again, I know the reality is "you get what you pay for"...and for OCFS we
have paid nothing in $$$, but plenty in time!
This is not a bash of OCFS, but the reality...my reality...I see it and live
with it every day.
OCFS works and has strong management benefits over RAW, but don't kind
yourself about it equality to other filesystems.
Chris Marquez
Oracle DBA
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Billy Verreynne (JW)
Sent: Mon 8/8/2005 1:44 AM
To: Oracle Discussion List
Subject: RE: OCFS2
I don't get this.. I installed OCFS 1.1 a while back. It simply
worked. And is still working. And is so darn useful I have envious
Unix HP-UX & Solaris sysadmin colleagues desperate for something
similar to use.
I used ASMlib with Powerpath and ran into all kinds of weird
intermittant I/O problems.. which the TAR finally suggesting were
"problems" (I call it plain bugs) in EMC's Powerpath. I lost about 4
weeks of production & development time as a result. Which I could not
afford to loose.
And now some of you complain about OCFS and make all kinds of
dispariging comments on the subject? If you have a gripe, please get
technical because I fail to find any value in a posting that just
bitches about a product.
--
Billy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This e-mail and its contents are subject to the Telkom SA Limited
e-mail legal notice available at
http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
<http://www.telkom.co.za/TelkomEMailLegalNotice.PDF>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
//www.freelists.org/webpage/oracle-l
<//www.freelists.org/webpage/oracle-l>
Other related posts:
