Re: Anonymous huge pages for Linux

The vendor is already working on an enhancement to support pluggable db. There is some logic in the application to detect changes and errors in the schemas, tablespaces, permissions etc. that throw false errors when run against a PDB, and no way to easily suppress the errors. For the current / supported versions we need to stick with non-pluggable db. Later versions of the app should resolve this issue.

On Tue, Jan 10, 2023 at 11:08 AM Mark W. Farnham <mwf_at_rsiz.com> wrote:

> No value add here, but I am curious what might make a pluggable db not
> supported by an application.
>
>
>
> The primary reason for my curiosity is that a valid reason that an
> application might not be supported on a pdb might be a valid enhancement
> request regarding pdb.
>
>
>
> Of course it might just be a statement from a vendor that only exists as
> self-defense because the vendor has not tested on pdb.
>
>
>
> Good luck!
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Jon Crisler
> *Sent:* Monday, January 09, 2023 9:49 PM
> *To:* Todd Bellaver
> *Cc:* mark_at_bobak.net; oracle-l
> *Subject:* Re: Anonymous huge pages for Linux
>
>
>
> LOL, no worries, I got a laugh. The problem is that we might have 10 to
> even 50 db on the same server. Although each db will be small, they do
> require their own instance, and pluggable db are not supported in the
> application.
>
> This might be a situation where I do not use huge pages at all, and take
> the performance hit in favor of reliability.
>
>
>
> On Mon, Jan 9, 2023 at 6:25 PM Todd Bellaver <todd.bellaver_at_gmail.com>
> wrote:
>
> Jon,
>
>
>
> My apologies for the sharp NO. It was an echo from when a bunch of us
> talked about this over a night of DBA debauchery. Mark, thanks for the
> better answer.
>
>
>
> My 2-cents. Consider configuring your Oracle DB server build policy to
> set huge pages to 40% of physical memory. This 40% is for the *combined*
> SGAs of all the databases on the database server. The other 60% is for the *combined
> *PGA Aggregate Limits (*not targets*) of all the databases on that server
> and OS. 40% is just a suggestion, 35% may be better. Do the math for what
> works best for your environment.
>
>
>
> I hope this is also a better answer.
>
>
>
> Best of luck on your Oracle adventures.
>
>
>
> Todd
>
>
>
>
>
>
>
>
>
> On Mon, Jan 9, 2023 at 5:26 PM Mark J. Bobak <mark_at_bobak.net> wrote:
>
> To the best of my knowledge, anonymous husepages are still a non-starter
> when it comes to Oracle.
>
>
>
> On Mon, Jan 9, 2023 at 3:44 PM Jon Crisler <joncrisler_at_gmail.com> wrote:
>
> Has anybody had success using anonymous huge pages in later versions of
> Red Hat or OEL ? The accepted practice has been to disable anonymous huge
> pages and use fixed huge pages, due to performance issues and bugs.
> However we are working on a project that may require the rapid provision
> of small test databases, which will make maintaining manual huge pages a
> headache. If anonymous huge pages work well now, that would be my
> preferred configuration.
>
>

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