Re: Pga is growing on 11.2.2.0
Date: Tue, 14 Apr 2015 18:30:11 -0400
Message-ID: <CAAaXtLBcYJ+Yj5RnVdVDBrJusUba1SzV+X+wZ3s2eHbtB1rc+Q_at_mail.gmail.com>
That sort of thing is hardly shocking, if you set AMM loose and let it do its own thing completely without constraints. Sadly, though, that seems to be more-or-less the way Oracle had envisioned its use.
You'll generally be much happier with AMM if you set lower-bounds for all of your major memory pools, and leave AMM less room to play around. In my mind, leaving (only) about 20% of the database memory to AMMs discretion seems about right. I have no rigorous math or case-studies to support that -- just instinct.
Perhaps others have studied this more thoroughly?
On Tue, Apr 14, 2015 at 5:59 PM, Ls Cheng <exriscer_at_gmail.com> wrote:
> +1
>
> AMM is a piece of junk, last customer had 8GB memory_target and after a
> week AMM set db_cache_size to 64M.. uh oh
>
> On Tue, Apr 14, 2015 at 6:25 PM, Rich Jesse <
> rjoralist3_at_society.servebeer.com> wrote:
>
>> Don writes:
>>
>> > I'm probably a dinosaur and way behind in feature adoption, but I've
>> been
>> > burned by AMM thrashing the hell out of memory in the past as well.
>>
>> Dinosaurs rock, AMM resizing does not. I had fun when a 3rd party app not
>> using binds caused the library cache to grow to more than 11GB. The
>> instance would effectively hang for 10 minutes when tables had stats
>> collected and then attempted to invalidate all affected 250K+ cursors.
>> Good
>> times...
>>
>> Rich
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 15 2015 - 00:30:11 CEST