Re: asm on san

From: Robert Klemme <>
Date: Sun, 14 Dec 2008 11:13:00 +0100
Message-ID: <>

On 14.12.2008 03:19, Michael Austin wrote:
> Robert Klemme wrote:

>> On 13.12.2008 23:28, hpuxrac wrote:
>>> In this business you have got to be prepared for the fact that
>>> warm-and-fuzzy only lasts 3-5 years. And if someone doesn't keep up
>>> they fall by the wayside.
>> Switching to the latest and greatest all the time is not an option for 
>> everyone.  Especially in the area of storage that back 24x7 systems 
>> large volume data migration can be difficult to impossible.  IMHO 
>> understanding of the underlying technologies and how they will scale 
>> in a few years from now is important.  There are some fundamental 
>> issues with RAID 5 that a large cache can only mask.  

> Yes, that is true, however, with todays technology, they mask it very
> well. And as I stated, the virtualization and obfuscation at the array
> level, including the RAID settings within the array as well as stripping
> within ASM and potentially IBM's SVC front-end, the RAID level is
> *almost* a moot point.

Yes, I agree. Unfortunately this is not too good news, because as the importance of RAID level decreases, new challenges and potential sources for issues arise: network topology, bandwidth, software issues in SAN etc. - the whole thing has become significantly more complex than in the old days(TM). :-)

>> It may well be that you hit the IO bandwidth limit no sooner than two 
>> years from now by which time you face a necessary hardware upgrade and 
>> migration of a few TB which can be painful - and costly.

> I would like to take this opportunity to share one of the biggest
> benefits I have ever seen in a piece of technology from Oracle. I was
> recently involved in the implementation and support of moving a huge
> multiTB database from one storage vendor to another. Using ASM, we were
> able to move the data ONLINE and without interruption to normal
> day-to-day operations. It took a few :) days, but was seamless in its
> implementation and extremely painless given the magnitude of the move.
> The fact that it was in a RAC cluster also helped.
> I would provide more details but then I would have to .... [you know the
> rest :) ], I will say that our 3 smallest DISKGROUPS were just shy of
> 1TB and in parallel (used each ASM instance in the cluster), moved all 3
> in < 2.5hrs.
> Once the move was complete, the old vendors LUNS were removed from the
> system, the cluster rebooted and performance is well within SLA.
> Suffice it to say, that just a few short years ago, this would have been
> a near impossibility... leaving most customer "stuck" with their
> previous choice of storage vendor.

Thanks for sharing! I haven't been exposed to ASM too much so far and will definitively keep this in the back of my head.

Kind regards

        robert Received on Sun Dec 14 2008 - 04:13:00 CST

Original text of this message