Re: asm on san

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.

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.



.

Relevant Pages

  • Re: asm on san
    ... 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. ... I was recently involved in the implementation and support of moving a huge multiTB database from one storage vendor to another. ... The fact that it was in a RAC cluster also helped. ...
    (comp.databases.oracle.server)
  • Re: The 9997th file specific DOSFS problem
    ... The average performance of accessing the raid, single file I/O, is ... The 512 bytes "tiny cache" for the FAT is very intersting. ...  The larger the cluster size, ...
    (comp.os.vxworks)
  • Re: ASM for single-instance 11g db server?
    ... Cluster-consistent file system ... The problem with ASM is that it cannot be accessed by the general purpose ... that not only works on a single node, but across an entire cluster. ... That includes tiny databases as well as ELDB's ...
    (comp.databases.oracle.server)
  • Re: ASM for single-instance 11g db server?
    ... I have no more thant 5 years of ASM experience ... not only works on a single node, but across an entire cluster. ... ASM is good for RAC. ... Usually, disks are the bottleneck. ...
    (comp.databases.oracle.server)
  • Re: RAC/how should i store oracle files on a SAN
    ... >>>The thing is that my SAN already have RAID and RAID 10, ... >>>think it's ok if i have ASM on top of the RAID?. ... > adding disk from one and subtracting from the other. ... If you are presenting the SAN volume to the server as 1 LUN, ...
    (comp.databases.oracle.server)