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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> wrote:
Don writes:
I'm probably a dinosaur and way behind in feature adoption, but I'vebeen
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
--
//www.freelists.org/webpage/oracle-l
