oracle-锁概念

http://liwenshui322.iteye.com/blog/1166934

ORACLE DDL锁介绍

在DDL操作中会自动为对象加DDL锁（DDL Lock），从而保护这些对象不会被其他会话所修改。例如，如果我执行一个DDL操作ALTERTABLE T，表T上就会加一个排他DDL锁，以防止其他会话得到这个表的DDL锁和TM锁。在DDL语句执行期间会一直持有DDL锁，一旦操作执行就立即释放 DDL锁。实际上，通常会把DDL语句包装在隐式提交（或提交/回滚对）中来执行这些工作。由于这个原因，在Oracle中DDL一定会提交。

因此，DDL总会提交（即使提交不成功也会如此）。DDL一开始就提交，一定要知道这一点。它首先提交，因此如果必须回滚，它不会回滚你的事务。如果你执 行了DDL，它会使你所执行的所有未执行的工作成为永久性的，即使DDL不成功也会如此。如果你需要执行DDL，但是不想让它提交你现有的事务，就可以使 用一个自治事务（换言之，在执行DDL语句之后，会立即提交事务。这样的话，在执行DDL语句之前，如果执行了DML语句，也会被一并提交，并且不可回滚。）

有3种类型的DDL锁：

1.排他DDL锁（Exclusive DDL lock）：这会防止其他会话得到它们自己的DDL锁或TM（DML）锁。这说明，在DDL操作期间你可以查询一个表，但是无法以任何方式修改这个表。

2.共享DDL锁（Share DDL lock）：这些锁会保护所引用对象的结构，使之不会被其他会话修改，但是允许修改数据。

3.可中断解析锁（Breakable parse locks）：这些锁允许一个对象（如共享池中缓存的一个查询计划）向另外某个对象注册其依赖性。如果在被依赖的对象上执行DDL，Oracle会查看已 经对该对象注册了依赖性的对象列表，并使这些对象无效。因此，这些锁是“可中断的”，它们不能防止DDL出现。

大多数DDL都带有一个排他DDL锁。比如发出如下一条语句：Alter table t add new_column date。

但是，现在有些DDL操作没有DDL锁也可以发生。例如，可以发出以下语句：create index t_idx on t(x) ONLINE;

ONLINE关键字会改变具体建立索引的方法。Oracle并不是加一个排他DDL锁来防止数据修改，而只会试图得到表上的一个低级（mode 2）TM锁。这会有效地防止其他DDL发生，同时还允许DML正常进行。Oracle执行这一“壮举”的做法是，为DDL语句执行期间对表所做的修改维护 一个记录，执行CREATE时再把这些修改应用至新的索引。这样能大大增加数据的可用性。

另外一类DDL会获得共享DDL锁。在创建存储的编译对象（如过程和视图）时，会对依赖的对象加这种共享DDL锁。例如，如果执行以下语句：

Create view MyView
      as
      select *
      from emp, dept
      where emp.deptno = dept.deptno;

表EMP和DEPT上都会加共享DDL锁，而CREATE VIEW命令仍在处理。可以修改这些表的内容，但是不能修改它们的结构。

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

有一个意义非凡的视图可用于查看这个信息，即DBA_DDL_LOCKS视图。对此没有相应的V$视图。DBA_DDL_LOCKS视图建立在更神秘的
X$表基础上，而且默认情况下，你的数据库上不会安装这个视图。可以运行[ORACLE_HOME]/rdbms/admin目录下的
catblock.sql脚本来安装这个视图以及其他锁视图。必须作为用户SYS来执行这个脚本才能成功。一旦执行了这个脚本，可以对视图运行一个查询。
查询语句如下：

select session_id sid, owner, name, type,mode_held held, mode_requested request from dba_ddl_locks

这个视图对开发人员很有用，发现测试或开发系统中某段代码无法编译时，将会挂起并最终超时。这说明，有人正在使用这段代码（实际上在运行这段代码），你可
以使用这个视图来查看这个人是谁。对于GRANTS和对象的其他类型的DDL也是一样。例如，无法对正在运行的过程授予EXECUTE权限。可以使用同样
的方法来发现潜在的阻塞者和等待者。

======================================

http://czmmiao.iteye.com/blog/1473965

深入理解Oracle中的latch(原创)

串行化 概述
串行化 - 数据库系统本身是一个多用户并发处理系统，在同一个时间点上，可能会有多个用户同时操作数据库,
多个用户同时在相同的物理位置上写数据时，不能发生互相覆盖的情况,这叫做串行化，串行化会降低系统的并发性，但这对于保护数据结构不被破坏来说则是必需
的。在Oracle数据库中，通过闩锁（latch）和锁定（lock）来解决这两个问题。
闩锁和锁定既有相同点又有不同点。相同点在于它们都是用于实现串行化的资源。而不同点则在于闩锁（Latch）是一个低级别、轻量级的锁，获得和释放的速
度很快，以类似于信号灯的方式实现。而锁定（Lock）则可能持续的时间很长，通过使用队列，按照先进先出的方式实现。也可以简单地理解为闩锁是微观领域
的，而锁定则是宏观领域的。
注意

：latch是用于保护SGA区中共享数据结构的一种串行化锁定机制。它不仅仅用于buffer cache, 还用于shared pool以及log buffer等。

闩锁（latch）概述


Oracle数据库使用闩锁（latch）来管理SGA内存的分配和释放.Latch是用于保护SGA区中共享数据结构的一种串行化锁定机制。Latch的实现是与操作系统相关的，尤其和一个进程是否需要等待一个latch、需要等待多长时间有关。
Latch是一种能够极快地被获取和释放的锁，它通常用于保护描述buffer
cache中block的数据结构。与每个latch相联系的还有一个清除过程，当持有latch的进程成为死进程时，该清除过程就会被调用。Latch
还具有相关级别，用于防止死锁，一旦一个进程在某个级别上得到一个latch，它就不可能再获得等同或低于该级别的latch。
Latch
不会造成阻塞，只会导致等待。
阻塞是一种系统设计上的问题，等待是一种系统资源争用的问题。

SPIN与休眠

SPIN
在performance tuning的sg上tuning
contention章里看到的，原文是这样的：Latch behavior differs on single and multiple CPU
servers. On a single CPU server, a process requesting an in-use latch
will release the CPU and sleep before trying the latch again. On
multiple CPU servers, a process requesting an in-use latch will “spin”
on the CPU a specific number of times before releasing the CPU and
trying again. The number of spins the process will use is OS specific.
spin 就是一个进程独占cpu time，直到运行的结束。这个期间其他进程不能获得这个cpu的运行时间。对于单CPU来说没有spin概念。
比如数据缓存中的某个块要被读取，我们会获得这个块的
latch，这个过程叫做spin，另外一个进程恰好要修改这个块，他也要spin这个块，此时他必须等待，当前一个进程释放latch后才能spin
住，然后修改，如果多个进程同时请求的话，他们之间将出现竞争，没有一个入队机制，一旦前面进程释放所定，后面的进程就蜂拥而上，没有先来后到的概念，并
且这一切都发生的非常快，因为Latch的特点是快而短暂。
休眠
休眠意味着暂时的放弃CPU，进行上下文切换(context
switch)，这样CPU要保存当前进程运行时的一些状态信息，比如堆栈，信号量等数据结构，然后引入后续进程的状态信息，处理完后再切换回原来的进程
状态，这个过程如果频繁的发生在一个高事务，高并发进程的处理系统里面，将是个很昂贵的资源消耗，所以Oracle选择了spin，让进程继续占有
CPU，运行一些空指令，之后继续请求，继续spin，直到达到_spin_count值，这时会放弃CPU，进行短暂的休眠，再继续刚才的动作。初始状
态下，一个进程会睡眠0.01秒。然后醒过来，并再次尝试获得latch。

进程一旦进入睡眠状态，则会抛出一个对应的等待事件，并记录在视图v$session_wait里，说明当前该进程正在等待的latch的类型等信息。