From: Michael Austin on
DA Morgan wrote:
> robert wrote:
>> Michael Austin wrote:
>>> How, in your
>>> testing and research, does performance either improve or suffer with
>>> the addition of ASM. The database is scattered across 6 separate
>>> disk groups with logfiles etc in their own disk group.
>>
>> I've no numbers to contribute (though I'm also very interested in the
>> collective experience of this group on this).
>> But I do have a question: how much would we reasonably *expect*
>> performance to be impacted one way or the other by ASM, when we are on
>> a high performance SAN?
>
> On a high end SAN you are reading and writing to a cache not to disk so
> the number of spindles becomes less important. This is part of what
> makes NetApp's RAID4 different from RAID4 from other vendors.

Not sure, but doesn't this statement make my point from earlier RAID5
and SAN discussions :)

>
> ASM seems to prove either a neutral or slightly positive impact (a
> few percent) on performance if compared to raw disk with no LVM. If
> comparing with other LVMs what we see is a substantial drop in CPU
> utilization. Most LVMs are cpu pigs: ASM is not.

ASM also does not do the actual reading/writing - the RDBMS does. In
other words - ASM does not proxy the I/O for the RDBMS - RDBMS writes
directly to the data files. ASM just tells the RDBMS what the extent
map is and only at file open time... which is why you need additional
shared_pool (1MB for every 100GB of file space).

There is a book called Automatic Storage Management - practical
under-the-hood ??? that is very good at the mechanisms within ASM and
RDBMS...
From: robert on
Michael Austin wrote:
> [...] ASM just tells the RDBMS what the extent
> map is and only at file open time... which is why you need additional
> shared_pool (1MB for every 100GB of file space).
>
> There is a book called Automatic Storage Management - practical
> under-the-hood ??? that is very good at the mechanisms within ASM and
> RDBMS...

Thank you for the recommendation. I'll get that one.
Especially if it goes into detail about additional requirements like
shared pool.
From: Robert Klemme on
On 18.12.2008 17:32, Michael Austin wrote:
> ASM also does not do the actual reading/writing - the RDBMS does. In
> other words - ASM does not proxy the I/O for the RDBMS - RDBMS writes
> directly to the data files. ASM just tells the RDBMS what the extent
> map is and only at file open time... which is why you need additional
> shared_pool (1MB for every 100GB of file space).

That's an interesting bit of information. How is the ASM able to
replace a clustered file system? Does it provide only the meta data
layer which controls concurrent access to files?

> There is a book called Automatic Storage Management - practical
> under-the-hood ??? that is very good at the mechanisms within ASM and
> RDBMS...

I am assuming you mean this one: http://www.amazon.com/dp/0071496076

Kind regards

robert