latch & lock

[@more@]

一、latch

oracle使用latch分配和释放内存

latch分为两种：

1、愿意等待型（waiting-to-wait）

大部分latch属于这种类型，这种类型的锁通过test-and-set的方式获得，当不能获得latch的时候，会绕着CPU旋转，而不放弃CPU，这就是spin

实际上通过执行一段空循环，一直占用CPU，latch以微秒（百万分之一秒）来计算，如果立刻放弃，以引起上下文切换，消耗有可能更大

如果在一定时间内，仍然不能获得，会释放CPU，进入sleep状态，抛出一个等待事件，记录在v$session_wait中

进程会sleep 0.01秒，然后醒来，再次尝试获得latch，如果在达到上限前还不能获得latch,则再次进入sleep,这次会sleep两倍的时间，最高sleep时间为0.2秒

2、不等待类型（no-wait）

类型较少，

以nowait模式开始请求，如果所请求的latch不要用，会立即请求另一个latch，只有当所有的latch都不可用，则会进入等待

3、latch争用

latch争用，通常表现为CPU资源使用过高

检查语句是否使用绑定变量

检查语句执行计划是否合理

二、lock

lock用来控制用户对表里相同数据的并发访问

分为排它锁（X）、共享锁（S）

1、DML锁

DML LOCK 用于确保一次只有一个人能修改某一行，而且你正在处理一个表时别人不能删除这个表。

对数据更新时，不光在数据块头加行级锁，还会在表级别加表级锁

1.1、TX锁（事务锁）

行级排它锁（行级锁只有 X 锁定模式，没有其它锁定模式）

事务发起第一个修改时会得到TX锁，而且会一直持有这个锁直至事务commit或rollback

TX锁是一种排队机制，使得其它会话可以等待这个事务执行

oracle对数据行锁定时，行指向事务ID的一个副本，事务ID存储在包含数据的块中，释放锁时，事务ID却被保留下来，这个事务ID表示了回滚段号、槽和序列号；事务ID留在包含数据行的块内，可以告诉其它会话：你“拥有”这个数据（并非块人所有的数据都是你的，只是你修改的那一行“归你所有”）；另一个会话到来后，它会看到锁ID，由于锁ID表示一个事务，所以可以很快查到持有这个锁的事务是否还活动，如果不活动，则允许会话访问这个数据，如果锁还是活动的，会话就会要求一旦释放锁就得到通知，这就有了一个排队机制：请求锁的会话会排除，等待目前拥有锁的事务执行，然后得到数据

1.2、TM锁（DML Enqueue锁）

表级锁，用于确保在修改表的内容时，表的结构不能改变：drop或alter等DDL操作

如果表有一个TM锁，而另一用户试图执行DDL，则会报：ORA-00054:resource busy and acquire with NOWAIT specified

每个事务只能得到一个TX锁，但是TM锁则不同，修改了多少个对象（表），就能得到多少个TM锁

TM锁的 ID1 列（v$lock)就是 DML 锁定对象的对象 ID ，所以很容易发现哪个对象持有这个锁

系统中统计的TM锁总数通过设置 dml_locks 实现：alter system set dml_locks=xxx scope=spfile;

若 dml_locks 值为 0，则不允许DDL操作，会提示：ORA-00062: DML full-table lock cannot be acquired；DML_LOCKS is 0

表级锁共有5种模式

1.2.1、RX 锁(row exclusive、行级排它锁)

当进行 DML 操作时，会自动在表上添加 RX 锁，

允许其它事务通过 DML 语句修改表内的其它数据行

不允许对锁定的行进行修改

不允许其它事务对表加 X 锁

使用 lock 添加 RX 锁：lock table test in row exclusive mode;

1.2.2、RS 锁（row share、行级共享锁）

允许其它事务通过 DML 语句修改表内的其它数据行

允许添加 RX 锁

不允许对锁定的行进行修改

不允许添加 X 锁

由于 Oracle 在行级只提供X锁，所以 RS 锁（select for update）对应的行级锁也是X锁（但是该行数据实际上还没有被修改）

使用 lock 添加 RS 锁：lock table test in row share mode;

1.2.3、S 锁（share、共享锁）

不允许 DML 操作

允许添加 RS 锁

使用 lock 添加 S 锁：lock table test in share mode;

1.2.4、X 锁（exclusive、排它锁）

其它事务不能进行任何 DML 和 DDL 操作

只能进行 select 操作

使用 lock 添加 X 锁：lock table test in exclusive mode;

1.2.5、SRX 锁（share row exclusive、共享行级排它锁）

不能进行 DML 操作

不能添加 S 锁

使用 lock 添加 SRX 锁：lock table test in share row exclusive mode;

1.2.6、下表为锁的转换关系

1.2.7、锁的编码数值

1.2.8、语句产生表级所有情况

2、DDL锁

DDL操作中会自动添 DDL 锁，从而保护这些对象不会被其它会话修改

有三种类型的DDL锁，

有一个视图 dba_ddl_locks可查看 DDL 锁信息，默认没有安装这个视图；以 sys 运行 $ORACLE_HOME/rdbms/admin/catblock.sql 来安装这个视图及其它锁视图

2.1、排它 DDL 锁（exclusive DDL lock）

防止其它会话得到它们自己的 DDL 锁或 TM（DML）锁

在 DDL 操作期间可以查询一个表，但无法以任何方式修改表

2.2、共享 DDL 锁（Share DDL lock）

会保护所引用对象的结构，使之不会被其它会话修改，但是允许修改数据

在创建存储的编译对象（如过程和视图）时，会对依赖的对象加 共享 DDL 锁，可以修改表的内容，但是不能更改结构

2.3、可中断解析锁（Breakeable parse locks）

你的会话解析一条语句时，对于该语句引用的每一个对象都会加一个解析锁；加这些锁的目的是：如果以某种方式删除或修改了一个被引用的对象，可以将共享池中己解析的缓存语句置为无效（刷新输出）

在shared pool里缓存的SQL游标、PL/SQL代码都会获得引用对象上的解析锁定，如果我们发出DDL命令修改了某个表的结构时，该对象相关的、位于shared pool里的解析锁定就会被打破，从而导致引用了该对象的SQL游标或者PL/SQL程序代码全都失效，下次再执行相同的SQL语句时，需要重新解析，这就是所谓的SQL语句的reload，可打破的解析锁定不会阻止其他的DDL锁定，如果发生与解析锁定相冲突的DDL锁定，则解析锁定也会被打破

2.4、没有DDL锁的DDL操作（create index）

create index会产生2、4级别的TM锁（sys.obj$ 产生一个 RX 锁；在表上产生 S 锁）、一个 TX 锁

如果在create index对表有 DML 操作，会首先在表上添加 RX 锁，与其存在的 S 锁冲突，所以会发生等待

create index online产生2级别的TM锁（在表上产生 RS 锁）、TX锁；同时对 sys.obj$ 的锁消失，会产生一个 sys_journal_xxxx（xxxx为4位数字）的表且这个表上存在 S 锁

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

转载于:http://blog.itpub.net/16835711/viewspace-1056624/