• If SGA_TARGET is set and PGA_AGGREGATE_TARGET is not set, we will still auto-tune both parameters. PGA_AGGREGATE_TARGET will be initialized to a value of (MEMORY_TARGET-SGA_TARGET). 

• If PGA_AGGREGATE_TARGET is set and SGA_TARGET is not set, we will still auto-tune both parameters. SGA_TARGET will be initialized to a value of min(MEMORY_TARGET-PGA_AGGREGATE_TARGET, SGA_MAX_SIZE (if set by the user)) and will auto-tune subcomps. 
• If neither is set, they will be auto-tuned without any minimum or default values. We will have a policy of distributing the total memory set by memory_target parameter in a fixed ratio to the the SGA and PGA during initialization. The policy is to give 60% for sga and 40% for PGA at startup. 

If MEMORY_TARGET is not set or set to set to 0 explicitly (default value is 0 for 11g): 

• If SGA_TARGET is set we will only auto-tune the sizes of the sub-components of the SGA. PGA will be autotuned independent of whether it is explicitly set or not. Though the whole SGA(SGA_TARGET) and the PGA(PGA_AGGREGATE_TARGET) will not be auto-tuned, i.e., will not grow or shrink automatically. 
• If neither SGA_TARGET nor PGA_AGGREGATE_TARGET is set, we will follow the same policy as we have today; PGA will be auto-tuned and the SGA will not be auto-tuned and parameters for some of the sub-components will have to be set explicitly (for SGA_TARGET).
• If only MEMORY_MAX_TARGET is set, MEMORY_TARGET will default to 0 and we will not auto tune sga and pga. It will default to 10gR2 behavior within sga and pga. 
• If sga_max_size is not user set, we will internally set it to MEMORY_MAX_TARGET. 

In a text initialization parameter file, if you omit the line for MEMORY_MAX_TARGET and include a value for MEMORY_TARGET, the database automatically sets MEMORY_MAX_TARGET to the value of MEMORY_TARGET. If you omit the line for MEMORY_TARGET and include a value for MEMORY_MAX_TARGET, the MEMORY_TARGET parameter defaults to zero. After startup, you can then dynamically change MEMORY_TARGET to a non-zero value, provided that it does not exceed the value of MEMORY_MAX_TARGET.

 

How Oracle Database Decides Between ISM and DISM

Oracle Database 9i introduced a new init.ora parameter, SGA_MAX_SIZE, to activate DISM. This variable establishes the maximum size to which the SGA can grow; it can only be modified statically (in other words an Oracle Database reboot is required before any change to SGA_MAX_SIZE takes effect). Oracle Database will use DISM instead of ISM if SGA_MAX_SIZE is set larger than the total of the database buffers (in particular, DB_CACHE_SIZE dynamic SGA resizing is not supported with the older db_block_buffers parameter), the shared pool, the redo buffers, the large pool, the Java pool, and the SGA fixed size (representing Oracle's internal requirements). Once DISM has been invoked, Oracle Database automatically locks an amount of memory determined by the total of the elements described above (database cache, shared pool, etc). Subsequently, the DBA can alter the size of the database buffers (DB_CACHE_SIZE) and the shared pool (SHARED_POOL_SIZE) with Oracle Database's alter system command.

From Oracle Database 10g, the size of the SGA can also be controlled by the SGA_TARGET parameter rather tuning the buffer cache and shared pool individually.
Depending on the command, Oracle Database then locks additional memory, subject to the upper limit imposed by SGA_MAX_SIZE, or releases memory for use elsewhere by the operating system.

From Oracle Database 11g, the choice between ISM and DISM is based on the following criteria:
• From the 11.2.0.1 release Oracle Database uses DISM if it is available on the system and MEMORY_TARGET or MEMORY_MAX_TARGET is set by the user. Note that, by default,
from Oracle Database 11.2.0.1 the installer sets MEMORY_TARGET, thereby invoking DISM. When MEMORY_TARGET is in use, the default is to allocate 60% of the available memory to the
SGA, which also means that 60% of memory used by Oracle Database will be locked.
• For earlier releases, from Oracle Database 9i, DISM will be used if it is available on the system, and if the value of the SGA_MAX_SIZE initialization parameter is larger than the size required for all SGA components combined. This enables Oracle Database to lock only the amount of physical memory that is used.
• Oracle Database uses ISM if the entire shared memory segment is in use at startup or if the value of
the SGA_MAX_SIZE parameter is equal to or smaller than the size required for all SGA components combined. Regardless of whether Oracle Database uses ISM or DISM, it can always exchange the memory between dynamically sizable components such as the buffer cache, the shared pool, and the large pool after it starts an instance. Oracle Database can relinquish memory from one dynamic SGA component and allocate it to another component.

 How to check if ISM or DISM are in use:

>  ps -ef | grep smon

oracle  4692     1   0   Feb 05 ?        1507:23 ora_smon_rdb

> pmap -xs 4692 | grep ism

0000000C74000000     151552     151552          -          -   4M rwxs-    [ dism shmid=0x4 ]
0000000C7D400000      45056      45056          -          -    - rwxs-    [ dism shmid=0x4 ]
0000000C80000000       4096       4096          -          -   4M rwxs-    [ dism shmid=0x4 ]
 

-----------------------------------------------------------------

 

How much memory is locked now:

SQL> select (select count(*)  from sys.x$ksmge) * (select bytes from v$sgainfo where name = 'Granule Size')/1024/1024 from dual;