Beware, following new upgrades to 11gR2, you can find that AMM has
reappeared, even if you think that you have disabled it.
Oracle
Automatic Memory Management (AMM) was introduced in Oracle 10g
for small databases where a one-sized-fits-all approach was used in
small “hands-off” databases that did not have a DBA to intelligently
allocate the SGA pools.
When a small system has a too small RAM region for the SGA,
Oracle AMM will cause a performance problem with RAM thrashing
and it tries to readjust all of the RAM regions.
In all large mission-critical databases, the DBA will disable AMM
because an intelligent human will always do a better job than a
simple software solution, especially when you need to intelligently
reconfigure the SGA in anticipation of a changing workload.
The following references will be helpful in researching the behavior
of AMM:
Disabling AMM in Oracle 11g Release 2
You can enable and disable AMM by changing the value of these
parameters to non-zero settings:
-
sga_target
-
sga_max_size
-
pga_aggregate_target
-
sga_max_size
-
db_cache_size
-
shared_pool_size
-
java_pool_size
Unfortunately a “new feature” in 11gR2
turns AMM on unless a hidden parameter called
_memory_imm_mode_without_autosga is set to FALSE.
Important 11gR2 Note:
Even if AMM has been disabled in Oracle 10g, AMM may reappear in
Oracle 11g unless the following parameter is set:
alter system set
"_memory_imm_mode_without_autosga"=FALSE scope=both;
There is a MOSC note about AMM in 11gR2
that notes that this regression back to AMM is the expected behavior
in 11.2 for immediate memory allocation requests and that Oracle
added this behavior as a 11gR2 new feature when automatic memory
management was disabled.
The 11.2 MOSC note on AMM regression is
note number 1269139.1, titled:
“SGA Re-Sizes Occurring Despite
AMM/ASMM Being Disabled(MEMORY_TARGET/SGA_TARGET=0)”
