ITPub博客

首页 > 数据库 > Oracle > 资源供给:并发性控制和锁之五

资源供给:并发性控制和锁之五

原创 Oracle 作者:sunsapollos 时间:2013-12-02 20:52:16 1 删除 编辑
简单案例说明: 某运营商实时计费系统偶尔会出现Session挂起,所有的Session登录几乎完全被挂起,而运行中的Session则可以正常操作。检查 systemdump发现,所有的挂起session都在等待audses$的sequence,只要把占有的SQ lock的Sesssion Kill则所有登录可以继续。检查audses$的cache,为缺省的20,增大audses$的cache为2000,业务系统再也没有出现类似状 况。
    
     对象锁
     Oracle对于任何数据库对象进行操作的时候,都需要施加对象锁,以防止操作的时候被其他进程变更以保持对象的一致性。

     Table & Index: TM  Lock
     Undo Segment:  US  Lock
     Temporary Segment: TS lock,SS Lock
     Sequence:         SQ
    
     通用锁定:          ROW CACHE LOCK
     其他代码类对象: LIBRARY CACHE LOCK

    在本文中我们主要讲述:Sequence的相关锁并发
    在我们的实践中,即使cached sequence的效率也是不够高的,更不要说没有cache的sequence了,相对较慢的sequence获取必然会导致在sequence上存在 比较大的锁冲突。如果大家需要在极高并发性环境下来实现sequence,最好采用sequence自我实现,而不要使用Oracle Sequence,无论是cache还是非cache,其效率都不够高。如果你要求高并发,没有cache的Sequence,其效率太低以至于不可用。
    如果大家仅仅把sequence作为唯一序列号,在高吞吐量环境中建议采用自我实现序号,比如简单++来实现,其效率要比较cached sequence快上很多。

    Sequence,  Cache Sequence
                     nocache Sequence
                     ordered sequence
  
   Sequence对应的字典对象:seq$
   Sequence对象的row cache对象:dc_sequence
  
   Sequence的操作:nextval,curval
  
   Sequence的cache出来的内容在哪里? row cache or other? 也许需要研究一下,我想应该是属于row cache的一部分内容。

   当从sequence cache中获得nextval的时候,Oracle通过row cache object latch的保护来获得nextval。
   当在sequence cache中不存在的时候,需要从seq$中读取cache size的sequence到row cache,这个时候需要获得row cache lock和SQ Lock。
   当sequence不存在cache的时候,在每一次访问的时候都需要更新seq$,除了seq$表格固有的事务锁之外,需要在dc_sequence的对应sequence获得row cache lock以保护row cache的变更。
   当Sequence穿越RAC,无论是row cache lock还是SQ lock都被全局化,将会给sequence的产生性能带来巨大的影响。基于此考虑,在RAC环境中总是要求设置更高的Sequence Cache,比如几万甚至几十万,淡化全局化影响。
   当ordered sequence穿越RAC,问题将无比巨大,Sequence cache将无法发声作用。在任何情况下都不要在RAC环境下使用ordered sequence,如果非要使用,建议采用自我实现。
   通过上面的描述,事实上对于sequence导致的锁定性能问题的处理已经非常简单: 设置足够大的Sequence cache,如果Sequence cache无法满足性能需求,则自我实现它。

  US Lock:
  在undo segment变更的时候(Drop,Offline,online甚至New Block,New extent)都会寻求US lock的保护。
  大家自然可以看到在Undo tablespace空间不足的环境中更加容易看到US lock冲突,特别Oracle 10g开始的自动offline undo Segment在高峰期会带来问题,如果必要可能需要把自动的undo segment offline禁止掉。同样在高并发性环境中,也没有必要把回滚段的autotune打开。
 
  TS lock & SS Lock:
   一般很少会看见TS lock的冲突,但是SS lock大家会发现他,SS lock从本质上是一个空间分配事务,已经在前一节中讲过。当需要获得新的New temporary extent的时候,这个需要获得SS lock。可以发现只要存在空闲的自由空间,几乎不会发生SS lock的冲突问题,即使冲突也是发生ST类的空间分配上。只有当没有自由空间的时候,会话之间会发生SS lock冲突,这个时候会话会重用free extent。特别在RAC环境中,由于无法获知全局的状况,将使SS lock进行全局调配,从而使效率大幅度下降。
   TM lock:
    表格对象锁,任何对于表格的操作都需要施加shared TM lock以避免被ddl变化。大家可能在实践中经常发现一些表格无法做ddl操作,比如drop,alter等等操作会报出ora-00054错误,一般 情况下就是TM lock的问题,由于该对象还被其他会话持有shared TM lock导致无法进行ddl操作。我们也在实践中发现过,对于缺乏串行控制的批处理业务意外的触发了多个进程同时运行,导致运行效率大幅度下跌,其中最主 要的原因也是ddl操作无法完成,总是不断的报告ora-00054错误。
    当然对于任何在表格的DDL操作,Exclusive TM lock将被加载,事实上同时也会要求Exclusive的LIBRARY CAHCE LOCK和ROW CACHE LOCK。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/92650/viewspace-1061903/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
专注于Oracle,BI,Security,DR &^BCP,Performance tuning

注册时间:2013-10-15

  • 博文量
    68
  • 访问量
    725321