此异常查到网上有一篇不错的文章例如以下：
08:56:03,273 INFO – 运行Do func=[GetSeqNo] keyNam=[keynam];KeyVal=[PRYPAYBILSYSTRACKNO20130125];SeqNam=[keyval];tblName=[pryseqrec];len=[6];circleString=[1];colName=[null] 2 08:56:03,296 ERROR – 获取数据库连接失败！ : Cannot create PoolableConnectionFactory (ORA-01034: ORACLE not available 3 ORA-27123: unable to attach to shared memory segment 4 Linux Error: 22: Invalid argument 5 Additional information: 7 6 Additional information: 2162692 7 )
OK，我看到了ORA-27123：unable to attach to shared memory segment错误，我猜想多数和内存有关。
这是一台CentOS 5.5上跑着Oracle 11.2.0.1的PC SERVER。
首先我查了下告警日志，发现近期有不少进程死掉现象，例如以下：
1 ... 2 Fri Jan 25 00:00:46 2013 3 Process m001 died, see its trace file 4 Fri Jan 25 00:07:36 2013 5 Process W000 died, see its trace file 6 Fri Jan 25 01:00:48 2013 7 Process m000 died, see its trace file 8 Fri Jan 25 01:07:45 2013 9 Process W000 died, see its trace file 10 Fri Jan 25 01:55:40 2013 11 Process m000 died, see its trace file 12 Fri Jan 25 02:07:50 2013 13 Process W000 died, see its trace file 14 Fri Jan 25 02:35:28 2013 15 Process m000 died, see its trace file 16 Fri Jan 25 03:05:45 2013 17 Process m000 died, see its trace file 18 Fri Jan 25 03:37:56 2013 19 Process W000 died, see its trace file 20 Fri Jan 25 03:58:01 2013 21 Process W000 died, see its trace file 22 Fri Jan 25 04:05:34 2013 23 Process m000 died, see its trace file 24 Fri Jan 25 04:25:51 2013 25 Process m000 died, see its trace file 26 Fri Jan 25 05:00:07 2013 27 Process m001 died, see its trace file 28 Fri Jan 25 05:09:22 2013 29 Process m000 died, see its trace file 30 Fri Jan 25 05:45:57 2013 31 Process m000 died, see its trace file 32 Fri Jan 25 06:01:04 2013 33 Thread 1 cannot allocate new log, sequence 1781 34 Private strand flush not complete 35 Current log# 1 seq# 1780 mem# 0: /opt/11g/oracle/oradata/orcl/redo01.log 36 Thread 1 advanced to log sequence 1781 (LGWR switch) 37 Current log# 2 seq# 1781 mem# 0: /opt/11g/oracle/oradata/orcl/redo02.log 38 Fri Jan 25 06:20:45 2013 39 Process m000 died, see its trace file 40 Fri Jan 25 07:00:15 2013 41 Process m001 died, see its trace file 42 …...
网上对Process m001 died,see its trace file和Process W0000 died,see its trace file类似的问题有非常多讨论，基本都是由于进程数达到上限了。
我也查了下数据库參数设置和当前情况：
1 SQL> col RESOURCE_NAME for a20 2 SQL> col LIMIT_VALUE for a20 3 SQL> select resource_name,MAX_UTILIZATION,LIMIT_VALUE from v$resource_limit where resource_name in ('processes','sessions'); 4 5 RESOURCE_NAME MAX_UTILIZATION LIMIT_VALUE 6 -------------------- --------------- -------------------- 7 processes 281 500 8 sessions 282 792
--可见离上限还有非常大距离。问题不是它导致的。
--查看了下top，当前server也非常空暇，free查看内存使用情况，也没有问题。
1 [root@orcl ~]# free -m 2 total used free shared buffers cached 3 Mem: 12172 10245 1926 0 363 8288 4 -/+ buffers/cache: 1593 10579 5 Swap: 5535 68 5467
--我手动切换日志而且checkpoint了下，发现告警日志里又出现了Process died。
1 SQL> alter system switch logfile; 2 3 System altered. 4 5 SQL> alter system checkpoint; 6 7 System altered. 8 9 Process m001 died, see its trace file 10 Fri Jan 25 10:09:34 2013 11 Process m000 died, see its trace file 12 Fri Jan 25 10:17:39 2013
--我查了下/dev/shm的情况，尽管在物理内存12G的server上仅设置6G认为有点小。但眼下情况看来并不会导致太大问题。
1 [root@orcl ~]# df -Th /dev/shm 2 文件系统 类型 容量 已用 可用 已用% 挂载点 3 tmpfs tmpfs 6.0G 8.1M 6.0G 1% /dev/shm
--接着我查了下shmmax值设置。这个參数定义了共享内存段的最大尺寸(以字节为单位)。假设设置不当，我们就会遇到ORA-27123。
1 [root@orcl ~]# more /etc/sysctl.conf | grep shmmax 2 kernel.shmmax = 1073741824 3 4 [root@orcl ~]# more /proc/sys/kernel/shmmax 5 1073741824
--我发现此參数设置了1G，我认为在一个使用AMM的系统(这是我没全然检查之后的想法)上这个值应该须要上调的。
我没立即更改，继续查问题。
--OS上找了以上内容之后我又回到数据库。看了下内存相关设置，这一查吓一跳。本以为使用AMM的系统竟然颠覆了我得想法：
1 SQL> show parameter memory 2 3 NAME TYPE VALUE 4 ------------------------------------ ---------------------- ------------------------------ 5 hi_shared_memory_address integer 0 6 memory_max_target big integer 0 7 memory_target big integer 0 8 shared_memory_address integer 0
--OK。Oracle 11g引入了AMM特性之后。Oracle也推荐使用它，当然，这不表示10g的ASSM不可用，依据特殊情况也有系统这样使用。 但我手头里的11g版本号数据库基本都在使用AMM特性。并且用得也非常好。
--查看sga和pga。例如以下：
1 SQL> show parameter sga 2 3 NAME TYPE VALUE 4 ------------------------------------ ---------------------- ------------------------------ 5 lock_sga boolean FALSE 6 pre_page_sga boolean FALSE 7 sga_max_size big integer 1G 8 sga_target big integer 1G 9 10 SQL> show parameter pga 11 12 NAME TYPE VALUE 13 ------------------------------------ ---------------------- ------------------------------ 14 pga_aggregate_target big integer 3844M
--到这里问题发生原因基本浮出水面了，SGA大小不足以满足需求而导致的。
--问题发生阶段的AWR报告中也能看到library hit命中率非常低。硬解析比較严重。另外软解析的比重也非常低。
原因找到了，解决这个问题就简单了。
首先跟开发的同事大概说明了一下原因。然后也跟开发的领导申请了停机时间，通知了其它开发者之后改动參数并重新启动数据库攻克了问题。
--操作例如以下：
1、改动shmmax參数值，提升到2G：
1 [root@orcl ~]# vi /etc/sysctl.conf 2 kernel.shmmax = 2147483648 3 4 [root@orcl ~]# sysctl -p 5 6 [root@orcl ~]# more /etc/sysctl.conf | grep shmmax 7 kernel.shmmax = 2147483648
2、启动AMM特性，设置memory_target为6G：
1 SQL> create pfile='/home/oracle/pfile_20130125.bk' from spfile; 2 3 File created. 4 5 SQL> alter system set memory_target=6G scope=spfile; 6 7 System altered. 8 9 SQL> shutdown immediate 10 Database closed. 11 Database dismounted. 12 ORACLE instance shut down. 13 14 SQL> startup 15 ORACLE instance started. 16 17 Total System Global Area 2042241024 bytes 18 Fixed Size 1337548 bytes 19 Variable Size 1392510772 bytes 20 Database Buffers 637534208 bytes 21 Redo Buffers 10858496 bytes 22 Database mounted. 23 Database opened. 24 25 -- 查看 26 SQL> show parameter memory 27 28 NAME_COL_PLUS_SHOW_PARAM TYPE VALUE_COL_PLUS_SHOW_PARAM 29 ------------------------------ ---------------------- ------------------------------ 30 hi_shared_memory_address integer 0 31 memory_max_target big integer 6G 32 memory_target big integer 6G 33 shared_memory_address integer 0 34 35 SQL> select * from v$sgainfo; 36 37 NAME BYTES RESIZE 38 ---------------------------------------------------------------- ---------- ------ 39 Fixed SGA Size 1337548 No 40 Redo Buffers 10858496 No 41 Buffer Cache Size 520093696 Yes 42 Shared Pool Size 486539264 Yes 43 Large Pool Size 16777216 Yes 44 Java Pool Size 16777216 Yes 45 Streams Pool Size 16777216 Yes 46 Shared IO Pool Size 0 Yes 47 Granule Size 16777216 No 48 Maximum SGA Size 2042241024 No 49 Startup overhead in Shared Pool 167772160 No 50 Free SGA Memory Available 973078528 51 52 12 rows selected. 53 54 SQL> show parameter sga 55 56 NAME_COL_PLUS_SHOW_PARAM TYPE VALUE_COL_PLUS_SHOW_PARAM 57 ------------------------------ ---------------------- ------------------------------ 58 lock_sga boolean FALSE 59 pre_page_sga boolean FALSE 60 sga_max_size big integer 1952M 61 sga_target big integer 1G
