Asm is great when you plan correctly. If you don’t it’s very painful. Eg. If
you have different sized disks asm will be forever rebalancing, and failing as
there is not enough space on the odd disk. So you need to vacate the diskgroup
to rebuild it. (Yes, you know... not my fault, the previous consultant did
it...) If there’s an asm bug you may have to take an outage on the Asm to apply
the patch.
Normal disk operations like dd to asm is almost impossible. Trying to find that
corrupted data block on the asm disk takes great asm expertise from a great
oracle support engineer.
Those were some up of my worst asm nightmares. It was only 2 years ago. I have
since moved on...
Cheers,
Leng
On 31 Oct 2018, at 7:20 am, Stefan Koehler <contact@xxxxxxxx> wrote:--
Hello Dimitre,
what is the problem with direct I/O? You should never run an Oracle database
through page cache anyway :)
I would go with tweaked XFS (e.g. "nobarrier" as this information is usually
not passed through correctly with VMDKs on VMFS, etc.) if it is just one
single instance in this VM.
Best Regards
Stefan Koehler
Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Twitter: @OracleSK
"Radoulov, Dimitre" <cichomitiko@xxxxxxxxx> hat am 30. Oktober 2018 um 19:12--
geschrieben:
Thank you Chris, Matthew and Niall,
so the question is if performancewise ASM is worth it.
With the default Oracle database settings the I/O on XFS would be
synchronous, right?
And if I understand correctly Note 1987437.1, on Linux you cannot enable
async I/O without turning on direct I/O too.
Regards
Dimitre
//www.freelists.org/webpage/oracle-l
