It appears that with 12c there's a change in the way shared memory segments are allocated when using automatic shared memory management (ASMM not AMM). Metalink note 15566.1 describe when shmmax parameter is large enough to contain the whole of SGA then a single shared memory segment will be allocated. However this behavior was changed on 11.2.0.3 and when a SR was raised and it was confirmed this was the intended behavior going forward from 11.2.0.3 with an explanation on 1399908.1.
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)
Created segments for the datbase
To link the shared memory seen to the database use sysresv
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...
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 sgaLimits for the share memory segments in the kerenl
sga_max_size big integer 1360M
sga_target big integer 1360M
show parameter memory
memory_max_target big integer 0
memory_target big integer 0
ipcs -lmShmmax is 64GB. So creating an shared memory segment of 1360MB is not an issue and no need to break it up to multiple segments.
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 67108864
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1
Created segments for the datbase
ipcs -mOnly 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.
------ 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 73
To link the shared memory seen to the database use sysresv
$ORACLE_HOME/bin/sysresvLooking 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).
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"
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...