RE: 10g RAC without vendor clusterware

From: Pete Sharman <peter.sharman_at_oracle.com>
Date: Sat, 19 Feb 2005 09:27:01 +1100
Message-ID: <20050219092701938.00000002408@psharman-au>

All

I've likewise been too busy to follow this entire thread (as a matter of fa=
ct I've largely been deleting oracle-l messages unread since I don't have t=
he time to look at them), so let me add some comments with my Product Manag=
er hat on (not that I'm a PM but anyway you know what I mean!)  Apologies i=
f some of this has already been covered.  Please, if you have any comments =
on this make sure you send them to me personally as well as the list since =

that way I'm sure to see them and pay more attention. :)

For starters, the adoption rate for ASM is quite high within the 10g custom=
er base.  We are having some challenges with CRS conflicting with some mult=
ipathing drivers due to a miscount conflict and there is some push back (in=
 the form of Fear Uncertainty and Doubt) but those are natural at this stag=
e of the roll out.  To address the specific points made in this email threa=

d, I will provide the following as counter points:

The references on www.oracle.com home page for GRID include video testim= ony, ROI studies and some very compelling quotes in that material. =
The collection of video testimonials is posted on the web site under htt= p://www.oracle.com/broadband and will be updated with one single video whic= h has 6 segments on customer speaking only about ASM.
The ROI studies include a quantification of 20% improvement in storage u= tilization when using ASM. See page 6 of the Aggregate study (dated Dec 20=
which can also be found on the external web site. =
The current version of the Oracle Magazine has a success story about Tal= k America and focuses exclusively on their use of Automatic Storage Managem= ent. See page 23 of the March/April Oracle Magazine (http://www.oracle.com= /oraclemagazine). =
The single point of failure question is addressed by having ASM in a GRI= D environment. ASM can manage a pool of clustered storage and if one node = were to fail, the other nodes continue. ASM is no more of a risk to HA tha= n any other file system or volume manager. It is implemented in a manner t= hat makes the fundamental mechanics of the I/O interaction very robust. It= is holding up very well in customer accounts under the toughest of testing= .=
Using any hardware in an HA environment requires building redundancy acr= oss many layers of the infrastructure. A single NAS head could be the weak= link if all your data depends on that resource being there. The approach = to the best HA in that case would be to mirror across more than one NAS hea= d. ASM can add this capability as an added benefit if one configures ASM r= edundancy with Failure Groups. Adding RAC and ASM gets another layer of pr= otection. Then Data Guard or remote mirroring as yet another. What ASM (a= nd other Oracle 10 features) delivers is a more cost effective way of build= ing an HA configuration.
The issues with ASMLIB need to be addressed separate from Automatic Stor= age Management as it is an extension which is available today on only Linux= . The development and bug fixing is done by a separate team of engineers w= ho are currently struggling with far too many binary incompatible versions = of Linux versions. That said, the bug fixes have been fairly fast on the c= ore Linux platforms and the delay has been mainly seen in porting it to all= the other Linux platforms that exist. (Red Hat vs. SuSE, 32 bit vs. 64 bi= t not to mention all the hardware variations like and z series, AMD or Itan= ium)... Let's not confuse core ASM capabilities with some challenges which = exist for an extension which is enabled for some specific platform that com= es in too many flavours today.

End of PM speak. :)
=

Pete
=

"Controlling developers is like herding cats." Kevin Loney, Oracle DBA Handbook
=

"Oh no, it's not. It's much harder than that!" Bruce Pihlamae, long-term Oracle DBA

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] = On Behalf Of mhthomas
Sent: Friday, 18 February 2005 3:51 AM
To: Koen Van Langenhove
Cc: Alexander Gorbachev; CMarquez_at_aarp.org; oracle-l_at_freelists.org Subject: Re: 10g RAC without vendor clusterware

Hi,

I'm too busy to properly respond but here are a couple answers.

This is a great article, and everyone needs to read it. Jared wrote important stuff about ASM and its helpful. See: http://www.dbazine.com/OLC/still.shtml
In a small shop, e.g. Standard Edition with RAC/ASM, its likely there are recovery, standby, test scenarios that would be non-RAC and also benefit from datafiles on a traditional file system. I think the ASM claim-to-fame is managing a group of disks, e.g. what if you don't have a such a disk group in one of your scenarios?

In our case we have a server configured as emergency recovery and its non-RAC and non-ASM. Its non-trivial to edit init files and requires a complex set of RMAN recovery tasks from our tape libraries.

Other examples include moving files in/out of ASM in various scenarios. One case might be to test the show-stopper ASMLib I/O performance bug (Still not fixed? Anyone working on it at Oracle or is it all acquisitions and outsourcing these days?) you get with ASM and run the same database with/without ASM for testing. I'm still working on other cases to eliminate single point of failure in one of our systems that would cause data loss if Murphy strikes. You can search the web and find quite a few other scenarios of people going ASM to non-ASM and vice versa.

Regards,

Mike Thomas

On Mon, 14 Feb 2005 11:12:06 +0100, Koen Van Langenhove <Koen.Van_Langenhove_at_siemens.com> wrote:
> Hi Mike,
> interesting comments here, thanks.
> - I have virtually no experience using ASM, so can you tell me the
> outlines of such a procedure ? And could you maybe give me a few
> examples of where/why you need to move between ASM and non-ASM ?

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


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

Received on Fri Feb 18 2005 - 17:36:04 CST