[转载]---ORA-27123 and Process m001 died故障解决一例
一、本文说明:
首先需要说明一下,我个人比较喜欢看别人发表的一些文章,当我发现作者写的不错的时候我都会转载到这里来,其目的是想增加自己的技术能力,没有盗取作品的意思。L哥写的一些文章都比较不错,赞一个!该原文的作者就是Loucs。
二、转载内容:
今天上午开发的同事问我大概9点左右有没有在开发测试库上操作过什么,说应用连接数据库报错了,但接着说现在又可以连上了,所以问我那时候数据库是不是有异常?我叫他把应用收到的ERROR信息发给我。
错误信息如下:
1 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,当前服务器也很空闲,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的服务器上仅设置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