事情已经过去一年,发生在15年1月份,某全国业务系统,实时的号码办理系统,收到短信告警,该系统断开连接。数据库出现大量enq: SQ – contention、cursor: pin S wait on X等事件,alert日志中出现大量的ORA-04031报错。进行flush share pool后进行了相关查询操作。
9点前后,活动会话数突然攀升,与alert日志在1月31号首次出现ORA-04031错误时间吻合
TO_CHAR(TRUNC(SA COUNT(*)
---------------- ----------
2015-01-31 08:44 23
2015-01-31 08:45 28
2015-01-31 08:46 25
2015-01-31 08:47 27
2015-01-31 08:48 33
2015-01-31 08:49 37
2015-01-31 08:50 27
2015-01-31 08:51 23
2015-01-31 08:52 38
2015-01-31 08:53 30
2015-01-31 08:54 32
2015-01-31 08:55 35
2015-01-31 08:56 28
2015-01-31 08:57 27
2015-01-31 08:58 27
2015-01-31 08:59 41
2015-01-31 09:00 556
2015-01-31 09:01 754
2015-01-31 09:02 673
2015-01-31 09:03 45
2015-01-31 09:04 111
2015-01-31 09:05 36
Alert日志内容:
Sat Jan 31 08:47:36 2015
Thread 1 advanced to log sequence 36910 (LGWR switch)
Current log# 2 seq# 36910 mem# 0: /dev/essdb3vg2/rdb3vg2_1_redo21
Current log# 2 seq# 36910 mem# 1: /dev/essdb3vg3/rdb3vg3_1_redo22
Sat Jan 31 09:00:50 2015
Errors in file /oraclelog/admin/essdb3/bdump/essdb31_j008_15925.trc:
ORA-12012: error on auto execute of job 1
ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","select sysdate + 1 / (24 * 6...","sql area","tmp")
Sat Jan 31 09:00:51 2015
Errors in file /oraclelog/admin/essdb3/bdump/essdb31_j003_24229.trc:
ORA-12012: 自动执行作业 1644 出错
ORA-04031: 无法分配 32 字节的共享内存 ("shared pool","update seq$ set increment$=:...","sql area","tmp")
Sat Jan 31 09:01:31 2015
Errors in file /oraclelog/admin/essdb3/bdump/essdb31_j005_24233.trc:
ORA-12012: 自动执行作业 1624 出错
ORA-04031: 无法分配 32 字节的共享内存 ("shared pool","update seq$ set increment$=:...","sql area","tmp")
Sat Jan 31 09:01:31 2015
Errors in file /oraclelog/admin/essdb3/bdump/essdb31_j008_15925.trc:
ORA-12012: 自动执行作业 927 出错
ORA-04031: 无法分配 32 字节的共享内存 ("shared pool","update seq$ set increment$=:...","sql area","tmp")
Sat Jan 31 09:01:43 2015
Errors in file /oraclelog/admin/essdb3/bdump/essdb31_smon_6599.trc:
ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","insert into sys.col_usage$ (...","sql area","tmp")
分析:
1,由于share pool无法更新字典表SEQ$,因此出现大量的sequence类等待事件是必然的,这也解释了为什么在top5里为什么enq: SQ – contention等待时间较长。
2,通过查询V$DBA_HIST_SQLTEXT可以发现以”SELECT ROW_.*”开头的sql文本共592个,且每个SQL_ID对应sql文本的行数较多,所有的SQL文本分别对应不同的SQL_ID,说明sql的绑定变量存在问题,每次执行SELECT ROW_.*都需要硬解析,会占用大量的share pool。
3,在后台的alert日志中,可以发现大量的ora-4031告警,而且大部分都为同一条语句,这种日志情况的输出都是发生在申请free chunk的过程中,同一条语句在遍历free list的时候,每扫描一个子池,申请不到空间,都会报一个错。
4,Cursor:pin S wait on x该等待事件主要是由较高的硬解析和高version count造成的,高硬解析和高version count都会大量的消耗shared_pool空间,直接结果就是shared_pool空间不足。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。