注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

常在心

淡泊明志,人生自在

 
 
 

日志

 
 

异常终止会话导致系统被Hung(分析思路)  

2011-06-08 14:13:38|  分类: oracle优化 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
异常终止会话导致系统被Hung
责任编辑:晓熊作者:fuyuncat   2009-09-23   


文本Tag: Oracle Oracle数据库管理 Oracle选件

  【IT168 技术文档】问题和现象

  接到生产支持的同事报告:数据库反应非常慢,很多数据库操作无法完成,DB出在被hung住的状态。同时,他们通过OEM发现其中一个节点(我们的数据库是10G RAC环境,3个节点)上发现存在很高的“Active Sessions Waiting: Other”的waits,见下图:



  分析

  "Active Sessions Waiting: Other"这一类的Waits是统计了RAC数据库中除IO和Idle waits之外的所有waits事件,要分析造成这些waits的原因,我们需要知道具体是那些event导致的waits。由上图中问题出现的时间段,我取了9月1号13:00到9月2号12:00之间awr report进行进一步分析。从awr report的top events中,得到了有价值的东西:



  我们可以看到,Top 5 events中,有2个events是属于Other的,也就是说,这2个event是导致系统"Active Sessions Waiting: Other"异常的根本原因。我们再具体分析这2个events。

  "DFS lock handle"这一event是在RAC环境中,会话等待获取一个全局锁的句柄时产生的。在RAC中,全局锁的句柄是由DLM(Distributed Lock Manager 分布式锁管理器)所管理和分配的。大量发生这一event说明全局锁句柄资源不够分配了。决定DLM锁数量的参数是_lm_locks,9i以后,它是一个隐含参数,默认值是12000。没有特殊情况,这一值对于一个OLTP系统来说是足够的。我们不能盲目地直接增加资源,而是需要找到导致资源紧张的根本原因。锁资源紧张,说明存在大量事务获取了锁,但是事务没有提交、回滚。那么,又是什么导致了这些事务不结束呢?应用程序代码不完善,没有提交事务?或者那些事务还在等待别的资源?分析到此,我们暂时先放下这一event,看下top event中的另外一个异常event。

  "enq: US - contention",这个event说明事务在队列中等待UNDO Segment,通常是由于UNDO空间不足导致的。结合对前一event的分析,初步判断正是因为大量事务在等待队列中等待UNDO资源,导致全局锁没有释放。为了验证这一判断,我分别查询发生这2个events的对象是那些。先看"DFS lock handle"的wait对象:

  SQL代码


 select o.object_id, o.owner, o.object_name, o.subobject_name, o.object_type, s.cnt
  from dba_objects o,
  (select current_obj#, count(*) cnt from dba_hist_active_sess_history
  where snap_id between 14315 and 14338
  and event='DFS lock handle'
  group by current_obj#) s
  where object_id = s.current_obj#
  order by cnt desc;
  OBJECT_ID OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_TYPE CNT
  ---------- ------------------ ------------------------ ----------------- -------------- ----------
  121517 CS2_PARTY_OWNER PARKING_LOT_TXN_PK INDEX 1524
  121525 CS2_PARTY_OWNER PARKING_LOT_SHMT_IDX2 INDEX 1074
  121518 CS2_PARTY_OWNER PARKING_LOT_TXN_IDX1 INDEX 984
  121430 CS2_PARTY_OWNER PARKING_LOT_TXN TABLE 664
  121524 CS2_PARTY_OWNER PARKING_LOT_SHMT_IDX1 INDEX 606
  121516 CS2_PARTY_OWNER PARKING_LOT_IDX3 INDEX 594
  121523 CS2_PARTY_OWNER PARKING_LOT_SHMT_PK INDEX 524
  ... ...

  看到发生这一event的对象都是PARKING_LOT模块中的几个相关对象。再看"enq: US - contention"的对象:

  SQL代码


select o.object_id, o.owner, o.object_name, o.subobject_name, o.object_type, s.cnt
  from dba_objects o,
  (select current_obj#, count(*) cnt from dba_hist_active_sess_history
  where snap_id between 14315 and 14338
  and event='enq: US - contention'
  group by current_obj#) s
  where object_id = s.current_obj#
  order by cnt desc;
  OBJECT_ID OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_TYPE CNT
  ---------- ----------------- ----------------------- ----------------- ------------ ----------
  121517 CS2_PARTY_OWNER PARKING_LOT_TXN_PK INDEX 1447
  121525 CS2_PARTY_OWNER PARKING_LOT_SHMT_IDX2 INDEX 1095
  121518 CS2_PARTY_OWNER PARKING_LOT_TXN_IDX1 INDEX 946
  121430 CS2_PARTY_OWNER PARKING_LOT_TXN TABLE 586
  121433 CS2_PARTY_OWNER PARKING_LOT_PK INDEX 482
  121523 CS2_PARTY_OWNER PARKING_LOT_SHMT_PK INDEX 474
  121516 CS2_PARTY_OWNER PARKING_LOT_IDX3 INDEX 461
  ... ...

  可以看到,发生这2个event的对象基本都是相同的对象。这一结果对之前的判断是一个很大的支持:"enq: US - contention"是导致"DFS lock handle"的原因,我们需要重点着手解决"enq: US - contention"问题。还是那句话:不要盲目增加资源,找到导致资源紧张的原因先。在我们的环境中,创建了3个UNDO Tablespace分别指定给了3个节点,管理方式是Auto的。每个UNDO表空间的大小是20G。在这之前,从来没有出现过UNDO资源不足的问题。

  首先,我想到一个可能是UNDO_RETENTION时间太长、且UNDO表空间被设置为GUARANTEE了。这样的话,会导致许多已经结束的事务的UNDO数据被保护起来不被使用,UNDO_RETENTION的时间越长,这些数据占用的UNDO空间就越多,这样就很容易导致"enq: US - contention"问题。从awr report中看到,UNDO_RETENTION的时间设置得确实比较长:7200秒。再看一下表空间是否被GUARANTEE了:

  SQL代码


select tablespace_name, retention from dba_tablespaces where tablespace_name like 'UNDO%';
  TABLESPACE_NAME RETENTION
  ------------------------------ -----------
  UNDOTBS1 NOGUARANTEE
  UNDOTBS2 NOGUARANTEE
  UNDOTBS3 NOGUARANTEE

  结果发现表空间并没有做retension guarantee,这一可能性被排除。

  那我们再看一下到底是那些事务占用了UNDO空间,结果出乎意料:

  SQL代码


SELECT a.sid, a.username, b.xidusn, b.used_urec, b.used_ublk, sq.sql_text
  FROM v$session a, v$transaction b, v$sqlarea sq
  WHERE a.saddr = b.ses_addr
  a.sql_address = sq.address(+);
  SID USERNAME XIDUSN USED_UREC USED_UBLK SQL_TEXT
  ---------- ----------- ---------- ---------- ---------- -----------
  1511 CS2_PARTY 1 9 1

  我们在该节点上并没有找到大量占用UNDO空间的事务的。那UNDO空间的实际使用情况到底是怎样的呢?

  SQL代码


 SELECT SEGMENT_NAME, TABLESPACE_NAME, BYTES, BLOCKS, EXTENTS, SEGMENT_TYPE
  FROM DBA_SEGMENTS
  WHERE SEGMENT_TYPE LIKE chr(37)||'UNDO'||chr(37)
  order by TABLESPACE_NAME, bytes desc;
  SEGMENT_NAME TABLESPACE_NAME BYTES BLOCKS EXTENTS SEGMENT_TYPE
  -------------- --------------- ---------- -------- ---------- ------------------
  _SYSSMU69$ UNDOTBS1 2.0709E+10 2528008 4615 TYPE2 UNDO
  _SYSSMU123$ UNDOTBS1 11141120 1360 170 TYPE2 UNDO
  _SYSSMU34$ UNDOTBS1 11010048 1344 168 TYPE2 UNDO
  ... ...

  找到症结了。_SYSSMU69$这个回滚段占据了19.3G的空间!再看看这个回滚段中的扩展段(extent)的状态:

  SQL代码


select status, sum(blocks)
  from dba_undo_extents
  where segment_name='_SYSSMU69$'
  group by status;
  STATUS SUM(BLOCKS)
  --------- -----------
  ACTIVE 2528008

  全部扩展段都是active的,正常的话,说明有事务正在使用该回滚段的所有扩展段。但实际上却找不到这样的事务:

  SQL代码


select
  r.name "RBS name",
  t.start_time,
  t.used_ublk "Undo blocks",
  t.used_urec "Undo recs"
  from
  gv$transaction t,
  v$rollname r
  where r.usn = t.xidusn
  and r.name = '_SYSSMU69$';
  no rows selected

  这一点不正常。最大的可能性就是当初使用该回滚段的事务被异常终止了,导致资源没释放。这一点,通过与生产支持的同事确认,得到一个这样的事实:

  1号上午,他们发现报表系统的一个housekeeping在删除一个日志表的数据消耗大量资源,影响到其它模块的运行,于是先用Kill Session的方式杀掉会话,但是会话仍在运行(对于大事务来说,这很正常,kill session会回滚还未提交的事务,事务越大,回滚时间越久),于是就在操作系统上将该进程杀掉了。这个作业是凌晨1:00开始运行的,在删除这张表之前,会先删除其它几张表,这大概需要2、3个小时的时间,也就是说大概在4:00左右开始删除该表。那我们再查一下该回滚段是在什么时间开始激增的:

  SQL代码


 select begin_time,end_time,undotsn,undoblks,txncount,activeblks,unexpiredblks,expiredblks from v$undostat;
  2009-09-01 05:19:01 2009-09-01 05:29:01 1 1268 7993 2529896 30048 48
  2009-09-01 05:09:01 2009-09-01 05:19:01 1 1779 8916 2529896 30024 72
  2009-09-01 04:59:01 2009-09-01 05:09:01 1 5745 14819 2529896 30024 72
  2009-09-01 04:49:01 2009-09-01 04:59:01 1 78200 5120 2451832 104448 3712
  2009-09-01 04:39:01 2009-09-01 04:49:01 1 114524 5213 2339672 115840 99360
  2009-09-01 04:29:01 2009-09-01 04:39:01 1 102563 6448 2236904 123264 193680
  2009-09-01 04:19:01 2009-09-01 04:29:01 1 144123 7370 2095304 189056 275632
  2009-09-01 04:09:01 2009-09-01 04:19:01 1 110936 20206 1989672 308864 261456
  2009-09-01 03:59:01 2009-09-01 04:09:01 1 80127 13635 1911464 367360 273744
  2009-09-01 03:49:01 2009-09-01 03:59:01 1 107125 11822 1807576 499840 252576

  可以看到,正是在4:00左右开始急剧增长的。基本上我们可以确认正是这一异常操作导致大量的回滚段被占用也没被释放!

  由于该回滚段的状态处于ONLINE状态,且其所有扩展段都是ACTIVE的,所以我们不能DROP或SHRINK它。现在,我们有两个方案来解决该问题:

  由于对于的事务已经不存在了,我们无法通过提交或回滚事务来是否回滚段资源。那么,最直接的方法就是重启实例,重置回滚段;

  临时解决方案就是增加或者新建一个UNDO表空间,使其它事务能正常运行。

  第一个方案会影响到其它模块,只能到周末downtime的时候实施。于是采用第二个方案:临时增加了为UNDOTBS1增加了10g空间。在杀掉一些由于这些等待被彻底hung住的会话后,整个数据库恢复了正常。

  评论这张
 
阅读(154)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017