Re: Storage choice for Oracle database on VMware

Hi Radoulov

Just wondering in youtr tests did you set FILESYSTEMIO_OPTIONS to SETALL in xfs?

Thanks

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-8563382580318212349_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Nov 9, 2018 at 3:46 PM Radoulov, Dimitre <cichomitiko_at_gmail.com> wrote:

> Hello all,
>
>
> after a few quick tests on XFS and ASM (calibrate_io and swingbench) I see
> that direct and asynchronous I/O definitely make a difference.
>
> Stefan and Neil, thank you for your suggestions!
>
>
>
> Regards
>
> Dimitre
>
>
>
> On 31/10/2018 12:29, Neil Chandler wrote:
>
> Radoulov,
>
> The caching in the SGA understands your data usage patterns through the
> LRU algorithms and will have cached all of the best data. The FS cache, if
> you dump it out, will look a lot more like white noise with few discernable
> patterns. The SAN cache even more so. The more single block reads you have,
> the more like white noise it all looks. The liklihood of there being a
> cache hit in the FS or SAN cache is relatively low. The advantage of direct
> path reads significantly outweights the advantage of both of those caches.
> It is worth noting in that on most SAN caches, if you specify that the LUN
> is for a database it will disable read-ahead to pre-populate the cache as
> it understands that it is not the best use of the cache (the general rule
> is that SAN cache should be reserved exclusively for writes when the SAN is
> used for the database.)
>
> Note that these statements are generalisation, and that there may be
> cases where your assertion is true but they will be an edge case and I
> would recommend that you have a provable scenario to justify running in
> that configuration.
>
> Neil Chandler
> Database Guy.
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>
> <oracle-l-bounce_at_freelists.org> on behalf of Radoulov, Dimitre
> <cichomitiko_at_gmail.com> <cichomitiko_at_gmail.com>
> *Sent:* 31 October 2018 07:20
> *To:* Andrew Kerber
> *Cc:* lkaing_at_gmail.com; contact_at_soocs.de; Oracle-L Group
> *Subject:* Re: Storage choice for Oracle database on VMware
>
> Thank you all for the valuable input!
>
> > what is the problem with direct I/O? You should never run an Oracle
> database through page cache anyway :)
>
> I'm not sure if direct I/O is always the best choice. I think that certain
> workloads may benefit from the FS cache.
>
> Anyway, I'm wondering why setall is still not the default value for
> filesystemio_options on Linux (most probably because of the bugs with
> certain filesystems and kernel versions).
>
>
>
> Regards
> Dimitre
>
>
> Il giorno mar 30 ott 2018, 22:38 Andrew Kerber <andrew.kerber_at_gmail.com>
> ha scritto:
>
> Most places with growing databases and heavy duty environments on vmware
> use ASM. Some use XFS or similar and LVM, though I am not fond of those.
>
> On Tue, Oct 30, 2018 at 4:34 PM Leng <lkaing_at_gmail.com> wrote:
>
> 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_at_soocs.de> 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: _at_OracleSK
> >
> >> "Radoulov, Dimitre" <cichomitiko_at_gmail.com> 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
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>
> --
> Andrew W. Kerber
>
> 'If at first you dont succeed, dont take up skydiving.'
>
>
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-8563382580318212349_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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