Re: What to keep in ASM?

Right. So if one of your LUNs is slow or overloaded - it's no good. To make it work - all LUNs should be of the same size and performance. In unlikely case of one LUN being swamped with IO requests, it not easy to rebalance diskgroup seamlessly - you can add and/or drop disks and hope for the best or remove datafiles and put them back. No explicit control.

On the other hand, in many cases I won't like the storage box load balance volumes automagically. Though, some control over extent layout would definitely be appreciated but that's another level of manageability already. For standard SAME approach, ASM should work well.

On 2/26/07, Alexander Fatkulin <afatkulin_at_gmail.com> wrote:
> Basically it does a round-robin allocation (+ disk (LUN) size
> acquiring). It tries to avoid the hot spots by striping extents across
> different disks. But it can't say "uh-huh, we got a hot spot here
> let's try to move those things here and there".
>
> On 2/27/07, Don Seiler <don_at_seiler.us> wrote:
> > My understanding is that ASM will also shift data around to avoid the
> > "hot block" scenario, avoiding I/O contention. It wasn't explicitly
> > stated in the passage I pasted, hopefully my understanding is correct.
> >
> > Don.
>
> --
> Alexander Fatkulin,
> Senior Oracle DBA
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Best regards,
Alex Gorbachev

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