11.2.0.3 created 3 shard memory segment irrespective of the size of the shmmax (even if whole of sga could fit within it). Now on 12c it seems there are some more changes and deviation from the behavior seen on 11.2.0.3. Instead of 3 segment it only creates 2 segments. This behavior is seen for both CDB and non-CDB and nattach on the smaller segment is twice the size of the large segment.
Current memory parameters in the database using ASMM (not AMM)
show parameter sga sga_max_size big integer 1360M sga_target big integer 1360M show parameter memory memory_max_target big integer 0 memory_target big integer 0Limits for the share memory segments in the kerenl
ipcs -lm ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 67108864 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1Shmmax is 64GB. So creating an shared memory segment of 1360MB is not an issue and no need to break it up to multiple segments.
Created segments for the datbase
ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x7b917ec8 12189696 grid 640 4096 0 0x00000000 12222465 grid 640 4096 0 0x11380e5c 23756802 oracle 640 18874368 146 0x00000000 23789571 oracle 640 1409286144 73Only two segments (owned by Oracle) and nattch on the smaller segment is twice that of the larger segment. Nattach value on the larger segments represents the total number of sessions in the database. If a new session is created then nattach value for both segments reflect the change in the session count. On 11.2.0.3 all segments had the same value for nattch.
To link the shared memory seen to the database use sysresv
$ORACLE_HOME/bin/sysresv IPC Resources for ORACLE_SID "cdb12c1" : Shared Memory: ID KEY 23756802 0x11380e5c 23789571 0x00000000 Semaphores: ID KEY 294915 0xc6ed03c4 Oracle Instance alive for sid "cdb12c1"Looking at the size of the shared memory segments created shmid 23789571 is the largest segment which is 1409286144 bytes (1344 MB) is not same size as the SGA. The small segment with shmid 23756802 is 18874368 bytes (18MB) and together both segments are 1362 MB (which is > 1360MB SGA size).
If it's assumed that both segments together make up the SGA then it opens up the question why the smaller segment shows twice the number of process attached to it than the larger segment. So far nothing on metalink about this. Awaiting for answers from Oracle...