top - 13:05:54 up 15 days， 13:10， 12 users，  load average: 45.59， 48.43， 49.50
Tasks: 5451 total，   5 running， 5436 sleeping，   0 stopped，  10 zombie
Cpu(s):  7.8%us，  2.7%sy，  0.0%ni， 88.3%id，  0.1%wa，  0.1%hi，  0.9%si，  0.0%st
Mem:  363033360k total， 256454800k used， 106578560k free，  1368868k buffers
Swap: 377487328k total，        0k used， 377487328k free， 167948244k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16422 oraaems2  15   0 6399m 5.3g 5.3g S  0.0  1.5   4:16.15 ora_dbw1_AEM02
16426 oraaems2  15   0 6399m 5.3g 5.2g S  0.0  1.5   4:08.93 ora_dbw3_AEM02
16424 oraaems2  15   0 6399m 5.2g 5.2g S  0.0  1.5   4:09.52 ora_dbw2_AEM02
16419 oraaems2  15   0 6399m 5.2g 5.2g S  0.0  1.5   4:06.01 ora_dbw0_AEM02
26885 oraaems2  15   0 6394m 3.9g 3.9g S  0.0  1.1   7:01.84 oracleAEM02 (LOCAL=NO)
9779 oraaems2  16   0 6392m 3.8g 3.8g S  0.0  1.1   3:36.58 oracleAEM02 (LOCAL=NO)
26535 oraaems2  15   0 6394m 3.5g 3.5g S  0.0  1.0   7:26.10 oracleAEM02 (LOCAL=NO)
5825 oraaems2  15   0 6394m 3.5g 3.5g S  0.0  1.0   4:29.41 oracleAEM02 (LOCAL=NO)
26932 oraaems2  15   0 6394m 3.4g 3.4g S  0.0  1.0   5:46.79 oracleAEM02 (LOCAL=NO)
5882 oraaems2  15   0 6394m 3.4g 3.4g S  0.0  1.0   3:55.93 oracleAEM02 (LOCAL=NO)
26479 oraaems2  15   0 6394m 3.4g 3.4g S  0.0  1.0   6:43.21 oracleAEM02 (LOCAL=NO)
25670 oraaems2  15   0 6394m 3.3g 3.3g S  0.0  1.0   6:00.96 oracleAEM02 (LOCAL=NO)
28928 oraaems2  15   0 6394m 3.3g 3.3g S  0.0  0.9   3:05.69 oracleAEM02 (LOCAL=NO)
5792 oraaems2  15   0 6394m 3.1g 3.1g S  0.0  0.9   4:42.41 oracleAEM02 (LOCAL=NO)
29874 oraaems2  15   0 6394m 2.9g 2.9g S  0.0  0.8   2:20.13 oracleAEM02 (LOCAL=NO)
1964 oraaems2  15   0 6398m 2.8g 2.8g S  0.0  0.8   1:16.83 oracleAEM02 (LOCAL=NO)
1954 oraaems2  15   0 6394m 2.7g 2.7g S  0.0  0.8   0:54.40 oracleAEM02 (LOCAL=NO)
5788 oraaems2  15   0 6394m 2.6g 2.6g S  0.0  0.8   3:26.67 oracleAEM02 (LOCAL=NO)
1970 oraaems2  15   0 6394m 2.5g 2.5g S  0.0  0.7   0:37.69 oracleAEM02 (LOCAL=NO)
16435 oraaems2  15   0 6393m 1.9g 1.9g S  0.0  0.6   1:29.38 ora_smon_AEM02
5816 oraaems2  15   0 6394m 1.9g 1.8g S  0.0  0.5   2:35.20 oracleAEM02 (LOCAL=NO)
24344 oraaems2  15   0 6389m 1.6g 1.6g S  0.0  0.5   0:03.12 oracleAEM02 (LOCAL=NO)
5790 oraaems2  16   0 6394m 1.3g 1.3g S  0.0  0.4   0:47.47 oracleAEM02 (LOCAL=NO)
16417 oraaems2  15   0 6386m 1.2g 1.2g S  0.0  0.4   0:21.68 ora_mman_AEM02
24323 oraaems2  15   0 6389m 1.2g 1.2g S  0.0  0.3   2:02.72 oracleAEM02 (LOCAL=NO)
1962 oraaems2  15   0 6394m 1.2g 1.2g S  0.0  0.3   0:41.28 oracleAEM02 (LOCAL=NO)
1958 oraaems2  15   0 6394m 1.1g 1.1g S  0.0  0.3   0:39.05 oracleAEM02 (LOCAL=NO)
22982 oraaems2  15   0 6393m 814m 807m S  0.0  0.2   2:24.63 ora_cjq0_AEM02
18024 oraaems2  15   0 6393m 599m 592m S  0.9  0.2  74:31.45 oracleAEM02 (LOCAL=NO)
　　能够看到进程的内存消耗都集中在AEM02这个库上，这个库其实是一个很小的库，SGA的设置只有6G，怎么内存消耗这么大呢。
　　首先查看数据库日志，没有相关的警告和错误。从启动开始，负载都很小。发现了一句比较奇怪的日志，但是hugapage的部分没有报错。
　　Starting ORACLE instance (normal)
　　****************** Huge Pages Information *****************
　　Huge Pages memory pool detected (total: 30000 free: 16509)
　　DFLT Huge Pages allocation successful (allocated: 0)
　　***********************************************************
　　然后查看了下sga的设置。发现sga_target设置为了0，同时shared_pool_size，db_cache_size也都是0，这个从配置来说也确实是个问题。
　　因为负载很小，在线做了修改，观察了一下数据库的内存使用情况，还是没有任何的改变。
　　排除了shared_pool_size和db_cache_size的影响，注意力都集中在了启动日志的那句话上"DFLT Huge Pages allocation successful (allocated: 0)"
　　为什么hugepage可用，但是没有分配呢。查看其它的实例启动情况都使用到了hugepage。
　　后能够想到的只能是11g中的新参数memory_target了。
　　一查看发现还真是，memory自动管理启动之后，hugep page不会启用了，这也是为什么日志中huge page allocation 为0的原因了。
SQL> show parameter memory
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address             integer     0
memory_max_target                    big integer 16016M
memory_target                        big integer 16016M
shared_memory_address                integer     0
　　但是这个和那100G的内存关系大吗，我使用top 把AEM02内存使用第一页的进程情况作了统计，发现已经占用了85G的内存资源，基本能够说明问题了。
　　明白了这一点再来看ipcs的结果能够理解一些数据的意义了。
> ipcs -a
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 500105218  root      644        80         2
0x00000000 500137988  root      644        16384      2
0x00000000 500170757  root      644        280        2
0x550002fb 500203526  root      644        256064     1                 locked
0xba17ff18 500760585  xxxxx    660        35704012800 3963
0xd9152b54 500695050  xxxxx   660        3542089728 37
0x91442618 500826123     aems2  660        4096       0
0xdb22d1bc 500957196  xxxxxx  660        3340763136 32
　　但是memory_target的修改和参数memory_max_target是关联的，无法在线修改，而且在生产中也不适宜做这样大胆的尝试，所以以上的分析只能说是一个猜想，只能静静等待下一次实例重启的机会来验证这个判断了。