关于RDBMS共享内存分配问题的疑问？

枕霜卧雪

从11g之后在ASMM下，sga创建Shared Memory Segments时从10g时的一个变为现在的3个了，详细信息见下面信息
但是经过计算，在os中分配的共享内存段的大小是826M，而db层我划分的sga大小是824M。
PS. 我只有linux环境，在别的操作系统，更大的内存分配情况时，os层和db层的差异更大。

疑问：
1.11g中为什么要将共享内存段划分为三段？（两端小点儿的，一段大的）
2.为什么实际os中划分的大小，与db中设置的参数大小有2M的差异？

能否请刘大解释一下？

[oracle@tbdb ~]$ uname -a
Linux tbdb.com 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux

主机内存大小如下：
[oracle@tbdb ~]$ cat /proc/meminfo
MemTotal:      2058780 kB
MemFree:        752444 kB
Buffers:         77376 kB
Cached:         875284 kB
SwapCached:          0 kB
Active:         547548 kB
Inactive:       645312 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      2058780 kB
LowFree:        752444 kB
SwapTotal:     1052248 kB
SwapFree:      1052248 kB
Dirty:             184 kB
Writeback:           0 kB
AnonPages:      240212 kB
Mapped:         223336 kB
Slab:            55736 kB
PageTables:      35856 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   2081636 kB
Committed_AS:  1509472 kB
VmallocTotal: 34359738367 kB
VmallocUsed:       840 kB
VmallocChunk: 34359737459 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

cpu信息如下:
[oracle@tbdb ~]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      :        Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping        : 7
cpu MHz         : 2201.125
cache size      : 6144 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up pni monitor ssse3 lahf_lm
bogomips        : 4402.25
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

共享内存分配如下：
[root@tbdb ~]# ipcs -asmq

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x7401009f 2228224    root      600        4          0                       
0x74010075 2949121    root      600        4          0                       
0x00000000 3309570    root      644        80         2                       
0x74010074 2916355    root      600        4          0                       
0x00000000 3342340    root      644        16384      2                       
0x00000000 3375109    root      644        280        2                       
0x00000000 3440646    oracle    600        393216     2          dest         
0x00000000 3473415    oracle    600        393216     2          dest         
0x00000000 3506184    oracle    600        393216     2          dest         
0x00000000 3538953    oracle    600        393216     2          dest         
0x00000000 3571722    oracle    600        393216     2          dest         
0x00000000 3604491    oracle    600        393216     2          dest         
0x00000000 3637260    oracle    600        393216     2          dest         
0x00000000 3670029    oracle    600        393216     2          dest         
0x00000000 3702798    oracle    600        393216     2          dest         
0x00000000 3735567    oracle    600        393216     2          dest         
0x00000000 3768336    oracle    600        393216     2          dest         
0x00000000 3833873    oracle    640        8388608    25                     ---这是sga共享内存
0x00000000 3866642    oracle    640        855638016  25                    ---这是sga共享内存
0xa4a98124 3899411    oracle    640        2097152    25                      ---这是sga共享内存
0x00000000 3932180    oracle    600        393216     2          dest         
0x00000000 3964949    oracle    600        393216     2          dest         

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x000000a7 0          root      600        1         
0x99a59e9c 131073     oracle    640        154

从输出结果中计算共享内存大小是：
(8388608+855638016+2097152)/1024/1024 =826 M

数据库信息如下：
13:37:39 sys@TSDB> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

补丁信息如下（截取部分）：
Patch  16902043     : applied on Thu Feb 05 12:57:08 CST 2015
Unique Patch ID:  16676143
Patch description:  "Database Patch Set Update : 11.2.0.3.8 (16902043)"
   Created on 24 Sep 2013, 23:20:58 hrs PST8PDT
Sub-patch  16619892; "Database Patch Set Update : 11.2.0.3.7 (16619892)"
Sub-patch  16056266; "Database Patch Set Update : 11.2.0.3.6 (16056266)"
Sub-patch  14727310; "Database Patch Set Update : 11.2.0.3.5 (14727310)"
Sub-patch  14275605; "Database Patch Set Update : 11.2.0.3.4 (14275605)"
Sub-patch  13923374; "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch  13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch  13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"

数据库共享内存分配如下：
13:41:40 sys@TSDB> show sga

Total System Global Area  860160000 bytes
Fixed Size                  2233200 bytes
Variable Size             322964624 bytes
Database Buffers          532676608 bytes
Redo Buffers                2285568 bytes
13:41:45 sys@TSDB> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 824M
sga_target                           big integer 824M

枕霜卧雪

我观察了HP-UX和rhel 5.5环境下的11.2.0.3版本的db，包括ASM磁盘的SGA在内。
内存均会被分为三段，如果按照顺序来：
key                     bytes
0x00000000    内存大小<=10% SGA  ===> 当sga内存越大时占比就会越高。
0x00000000    内存大小>= 90% SGA ===> 该段内存占比最高，是主要的共享内存
0x?????????    内存大小<= 5% SGA   ===> 同样sga越大，占比越高，但是该段是唯一一段有key的
                                                                 地址，也是三个共享内存段中最小的一段。

但是，更深层次的原因和划分方法，就只有从源码和bug中推断了。
资源有限，只能点到为止。

后续：
1.再看到sga分成三段，就不要惊讶了！
2.如果实例shutdown imm后，startup报错，就要看一下三段sh和sm是否都释放了。
   有一个存在的话，就无法完成startup。
3.实际分配的sh是按照OS中内存页大小配置的，sga如果设置不"整齐"的话，分配sh的时候，三段共享内存会自动进行对其，对其后的结果就是，sh总内存大小要稍稍大于sga大小（此段为根据现象推测，无实际文章和理论依据）。
   但这并不会造成过多的内存消耗，所以无需太过在意！
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
至此，暂时结贴吧！
再次感谢各位大师的关注和回复！

枕霜卧雪

tjsxxl 发表于 2015-3-6 14:55
Applies to:
Oracle Database - Enterprise Edition - Version 11.2.0.3 to 11.2.0.3 [Release 11.2]
Infor ...

感谢您的回复。
至于到底为什么会将sga的sh内存分成三段，MOS的1399908.1并没有太明确的说明。
文章中说，sga的共享内存段，在某种情况下允许分裂，并没有明确指出：when and how。
而且，也没有解释为什么会和db中sga的设置大小有差异，差异在什么地方。
是os中sh页大小设置的原因？还是其他原因？
后续引出，在sga设置大小时，是否要考虑设置为XX的整数倍，才能保证共享内存空间不浪费？

枕霜卧雪

anbob 发表于 2015-3-6 14:00
0xa4a98124 3899411    oracle    640        2097152    25     
这2M 不是吧？

非常感谢您的回复。
但是我说的不是单个sh段和db中设置大小差异，而是合计。


[oracle@tbdb ~]$ sysresv

IPC Resources for ORACLE_SID "tsdb" :
Shared Memory:
ID              KEY
3473415         0x00000000
3506184         0x00000000
3538953         0xa4a98124
Semaphores:
ID              KEY
131073          0x99a59e9c
Oracle Instance alive for sid "tsdb"

tjsxxl

Applies to:
Oracle Database - Enterprise Edition - Version 11.2.0.3 to 11.2.0.3 [Release 11.2]
Information in this document applies to any platform.
Goal

This document explains why databases have multiple shared segments after upgrading to 11.2.0.3, without making any change in the settings and parameters.

Solution

From 11.2.0.3, all databases are expected to have multiple shared memory segments.

The additional shared memory segments are an expected side effect of the fix for unpublished Bug 12654172 included 11.2.0.3. Part of that fix is to ensure that each shared memory segment making up the SGA only contains sub-areas with an identical alignment requirement - hence we end up spreading the SGA over more separate SHM segments..

In cases of very large numbers of databases this change may require the customer to review of the OS parameter SHMMNI (or equivalent), but otherwise this change should not be a problem - we have always allowed the SGA to split over multiple SHM segments - this change just adds an additional reason that can cause the split.

tjsxxl

Why Multiple Shared Memory Segments are Created From 11.2.0.3 (文档 ID 1399908.1)

anbob

0xa4a98124 3899411    oracle    640        2097152    25     
这2M 不是吧？

oradebug ipc
-OR
$ORACLE_HOME/bin/sysresv

确认下

枕霜卧雪

补充一下：
[root@tbdb ~]# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586