Re: ASM and VMWARE

Hello Ed,
one large LUN maybe enough if your databases are some playground database with almost no I/O but as soon as you put a little bit of I/O pressure on the database(s) you have to have more LUNs due to full disk queue issues on the OS layer (inside the VM).

If your disk queue becomes full (let's say your disk queue is 256 and you only have one LUN) and the DBWR tries to write some dirty blocks it will wait on "db file async I/O submit" which is usually a non-blocking system call io_submit().

Finally, you can get nasty wait chains like these if your I/O load reaches a certain level and you have a busy app :

• enq: TX - index contention → free buffer waits →> db file async I/0 submit
• enq: TX - index contention -> buffer busy waits [data block] -> buffer busy waits [data block] - free buffer waits →> db file async I/0 submit

> Ed Lewis <eglewis71_at_gmail.com> hat am 14.06.2024 20:56 CEST geschrieben:
>
> Hi,
>
> I recently took on a project with a new client.
>
> I’m tasked with building several databases in a RAC environment (19.23)
>
> ASM is being used with VMWARE on a EMC Unity Array. I recommended
>
> creating a few disk groups with a minimum of 4 LUNS (same size) for each group.
>
> The unix admin is against doing that saying that just use 1 large
> disk for each group.
>
> He says it’s a disadvantage when using a virtual disk infrastructure
> like we have with our EMC Unity disk farm.
>
> He states it is actually a disadvantage to carve up such small
> physical disks at the SAN Storage Array processor
>
> level and is not actually even possible as only whole disks can be
> assigned to a particular use at that level.
>
>
>
> Although, I have not worked much with VMWARE, I’ve never heard of
> these restrictions
>
> when using ASM, so I have my doubts.
>
> Any thoughts or experiences on this would be greatly appreciatedl

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