并发性控制和锁之五
资源供给：并发性控制和锁之五
原创 Oracle 作者：sunsapollos 时间：2013-12-02 20:52:16 7163 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。
对象锁
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/，如需转载，请注明出处，否则将追究法律责任。
