distributed transactions
对于distributed transactions，oracle无法区别blocking locks和deadlocks,因为并不是所有的锁信息在本地可见.为了防止
distributed transaction 死锁，oracle会超时分布式事务中的任何调用，如果它没有接受_distributed_lock_timeout 秒之内
任何响应.默认是60秒。如果一个分布事务超时，事务会产生ora-60.强健的应用处理异常的方式和本地入队死锁一样.
同样oracle 8.0，并行事务，包括多个兄弟姐妹同级别的事务分支，死锁和其它单一事务会发现不了（或者隐伏起来）。如果一个事务
受到一个全局事务某个分支的阻塞，也可能阻塞另一个，此时会发现正常的死锁。在oracle8.0中，发现不了这种死锁。为了防止这个，oracle会超时
任何入队锁请求或者锁转变请求（在并行事务的一个分支），如果它是一个分布式事务，ora-99错误会产生.parallel_transaction_resource_timeout默认
为300秒，用它来控制超时。在oracle8.1情况下，采用死锁检测算法来发现这些死锁，因此超时设置没必要了.
optimistic locking
有这样一个情形。两个不同的人可能同时向两个不同的操作员预订一个特定的座位（机票）。那么应用如何处理呢？
应用使用select for update nowait检索这个信息。这样就会保证，如果一个座位可以用，此时它已经被锁定，预订这个座位就会成功实现。这也叫作
早期锁定，或者悲观锁.
另一种方式（或锁）会延迟这个锁的持有，直到客户决定或进行一个预定座位时才会持有这个锁。这叫作乐观锁或晚期锁定.
在业务或应用程序中，到底选择悲观或乐观锁。需要很详细全面的分析。悲观锁应该全力避免，但这样可能加大或增加blocking locks的可能性，虽然很易于得到或实现.
itl entry shortage ---缺乏itl条目
itl是database block中可以变化的头部部分.当一个segment格式化一个新的block,segment会根据initrans配置它的初始itl数量.要是空间足够，itl会根据情况动态增加.直到
database block的大小的最大限制。或者segment的maxtrans,取其最小的一个.
修改一个block的事务必须在itl条目中，记录它的事务标识和对于这个块变更的rollback segment的address.（但是对于离散的事条，为这些变更是没有对应的rollback segment address)。
oracle会查找itl找到重用或空余的条目（指itl entry)。如果 itl所有的entry被一个未提交的事务占用完了，动态会增加一个itl entry，如果有可能.
如果block没有足够的内部空闲空间（24bytes)来创建额外的itl entry,此时事务必须等待（它使用已存在的itl entry提交或rollback)。被阻塞事务会另一个事务，以共享模式（对于tx enqueue)，会随机伪选择。
v$session行等待列会显示对象，文件，目标块的多少个块数量.但是，如果row_wait_row#列显示为unset(没有配置），表明
这个事务没有等待row-level lock,有可能在等待一个空闲的itl entry.
itl entry shortage不足的最大原因是：配置pctree为0.所以配置pctfree为0一定要三思，在多个会话并发访问某个数据块时，使用不必要及过大的inittrans或pctfree，会损及数据密度，降低表扫描的性能.
有一种情况，非默认的initrans配置对于pdml情况下的segments，不能保证它的性能.如果a pdml事务的子事务碰到itl entry不足，它将检查其它itl entry（块中）是否全部被它的兄弟姐妹事务占有，如果是这样的话，
这个事务将rollback，报出ora-12829错误，为了避免自有死锁。处理这种问题就是采用低级或少量的parallelism.或者用
更高的initrans重建这个segment.
row cache enqueues
data dictionary的rows缓存会保存在shared pool中。采用cache不仅会减少对于system tablespace之中data dictionary tables的物理读取次数，而且开启每个对于data dictionary rows的精细粒度的locking.
对于data dictionary rows的锁，叫作row cache enqueue locks.被缓存的data dictionary rows起到resource structure的作用，enqueue lock structure会根据需要动态从共享池中分配。locks可以请求，转化，release.
这种请求可以等待或超时，就像一般的入队锁一样.
但是，在v$lock中是看不到row cache enqueue locks信息。事实上，只能在system 或process的state dumps中可以看到.
根据操作情况，一些row cache enqueue locks通过no-wait mode请求。如果不能马上得到锁，会产生ora-54错误。否则，
如果可能row cache requests会入队，进程等待一个row cache lock wait.
wait parameters(row cache lock waits)
参数 描述
p1 v$rowcache cache#列表示row lock对应的data dictionary table
p2 已经持有锁的模式
p3 必须以何种模式持有锁
以上所指的持有锁模式表示的编号，只是针对于实例锁，而不是本地locks，甚至运行单实例数据库时.但是，这种等待在单实例下很少发生，仅仅只会发生于资源冲突，然而在并行服务中很普遍，因为新的锁请求必须通过分布式锁管理器dlm来socialized.
oracle并不期望row cache enqueue lock的获取和转变，阻塞一些时间.因此，row cache locks等待时间每三秒会超时，假如100次超时（5分钟），会产生一个内部死锁，操作会中断。同时会往alert写入"waited too long for a row cache enqueue lock"信息.另外，一个进程state dump会写入到trace file.
除了对于一个长时间运行，正在发生作用的过程，或包进行ddl时，这个错误被视为bug.
library cache locks and pins
library cache不是一个cache,而是好多少cache.它包含好多的pl/sql程序单元的伪代码。它包含解析树和共享sql语句的执行计划。它也包含sql语句所引用对象的某种抽象的diana形式.这些信息用于pl/sql程序单元编译及sql语句的解析及执行,尽管事实上是，dictionary cache包含不同形式的相同信息.library cache也包含
像同义词转化，依赖跟踪信息，及library cache locks和pins的控制结构.
library cache locks在oracle文档中叫作易碎的解析锁。它们用于sql语句的library cache objects及pl/sql程序单元，以及递归对它们所引用的database object的library cache objects.library cache locks在解析操作被共享模式持有，其后会转化为null mode.如果以后ddl语句修改一个数据对象的定义，这时这个对象的library cache 信息及所有依赖的
library cache object会变成不合理，通过中断这个library cache locks.
但是，当library cache object没有被pinned时，library cache locks被中断。一个pin用于pl/sql程序单元的library cache object或者sql语句，当这些对象正在被编译，解析，或执行时。pins一般情况以共享模式持有，但如果对象的library cache信息被改变，必须以排它模式持有锁.library cache object如：pipes和序列大多发生变化时。当一个library cache
object被pinned时，相反pins用于所有被引用的对象。当一个pin用于数据库对象的library cache object,此时需要一个data dictionary row(基础的）所对应的row cache enqueue lock,因此可以防止产生冲突的ddl.
library cache中每个对象具有一个句柄，它起到library cache locks和pins的资源结构。句柄，锁，pin结构所以从共享池中动态分配。句柄会对持有的锁实行双向链表，等待的锁，持有的pins,等待的pins.
wait parameters(library cache lock and library cache pin waits)
参数 描述
p1 内存中library cache handle的地址
p2 锁的内存地址或pin的结构
p3 锁模式或请求的pin,对象的名字空间namespace,是以10*mode+namespace编号方式来表示。
这种情况下，模式如下：
2 shared
3 exclusive
名字空间有:
0 cursor
1 table,procedure,and others
2,package body
3,trigger
4,index
5,cluster
6,object
7,pipe
对于distributed transactions，oracle无法区别blocking locks和deadlocks,因为并不是所有的锁信息在本地可见.为了防止
distributed transaction 死锁，oracle会超时分布式事务中的任何调用，如果它没有接受_distributed_lock_timeout 秒之内
任何响应.默认是60秒。如果一个分布事务超时，事务会产生ora-60.强健的应用处理异常的方式和本地入队死锁一样.
同样oracle 8.0，并行事务，包括多个兄弟姐妹同级别的事务分支，死锁和其它单一事务会发现不了（或者隐伏起来）。如果一个事务
受到一个全局事务某个分支的阻塞，也可能阻塞另一个，此时会发现正常的死锁。在oracle8.0中，发现不了这种死锁。为了防止这个，oracle会超时
任何入队锁请求或者锁转变请求（在并行事务的一个分支），如果它是一个分布式事务，ora-99错误会产生.parallel_transaction_resource_timeout默认
为300秒，用它来控制超时。在oracle8.1情况下，采用死锁检测算法来发现这些死锁，因此超时设置没必要了.
optimistic locking
有这样一个情形。两个不同的人可能同时向两个不同的操作员预订一个特定的座位（机票）。那么应用如何处理呢？
应用使用select for update nowait检索这个信息。这样就会保证，如果一个座位可以用，此时它已经被锁定，预订这个座位就会成功实现。这也叫作
早期锁定，或者悲观锁.
另一种方式（或锁）会延迟这个锁的持有，直到客户决定或进行一个预定座位时才会持有这个锁。这叫作乐观锁或晚期锁定.
在业务或应用程序中，到底选择悲观或乐观锁。需要很详细全面的分析。悲观锁应该全力避免，但这样可能加大或增加blocking locks的可能性，虽然很易于得到或实现.
itl entry shortage ---缺乏itl条目
itl是database block中可以变化的头部部分.当一个segment格式化一个新的block,segment会根据initrans配置它的初始itl数量.要是空间足够，itl会根据情况动态增加.直到
database block的大小的最大限制。或者segment的maxtrans,取其最小的一个.
修改一个block的事务必须在itl条目中，记录它的事务标识和对于这个块变更的rollback segment的address.（但是对于离散的事条，为这些变更是没有对应的rollback segment address)。
oracle会查找itl找到重用或空余的条目（指itl entry)。如果 itl所有的entry被一个未提交的事务占用完了，动态会增加一个itl entry，如果有可能.
如果block没有足够的内部空闲空间（24bytes)来创建额外的itl entry,此时事务必须等待（它使用已存在的itl entry提交或rollback)。被阻塞事务会另一个事务，以共享模式（对于tx enqueue)，会随机伪选择。
v$session行等待列会显示对象，文件，目标块的多少个块数量.但是，如果row_wait_row#列显示为unset(没有配置），表明
这个事务没有等待row-level lock,有可能在等待一个空闲的itl entry.
itl entry shortage不足的最大原因是：配置pctree为0.所以配置pctfree为0一定要三思，在多个会话并发访问某个数据块时，使用不必要及过大的inittrans或pctfree，会损及数据密度，降低表扫描的性能.
有一种情况，非默认的initrans配置对于pdml情况下的segments，不能保证它的性能.如果a pdml事务的子事务碰到itl entry不足，它将检查其它itl entry（块中）是否全部被它的兄弟姐妹事务占有，如果是这样的话，
这个事务将rollback，报出ora-12829错误，为了避免自有死锁。处理这种问题就是采用低级或少量的parallelism.或者用
更高的initrans重建这个segment.
row cache enqueues
data dictionary的rows缓存会保存在shared pool中。采用cache不仅会减少对于system tablespace之中data dictionary tables的物理读取次数，而且开启每个对于data dictionary rows的精细粒度的locking.
对于data dictionary rows的锁，叫作row cache enqueue locks.被缓存的data dictionary rows起到resource structure的作用，enqueue lock structure会根据需要动态从共享池中分配。locks可以请求，转化，release.
这种请求可以等待或超时，就像一般的入队锁一样.
但是，在v$lock中是看不到row cache enqueue locks信息。事实上，只能在system 或process的state dumps中可以看到.
根据操作情况，一些row cache enqueue locks通过no-wait mode请求。如果不能马上得到锁，会产生ora-54错误。否则，
如果可能row cache requests会入队，进程等待一个row cache lock wait.
wait parameters(row cache lock waits)
参数 描述
p1 v$rowcache cache#列表示row lock对应的data dictionary table
p2 已经持有锁的模式
p3 必须以何种模式持有锁
以上所指的持有锁模式表示的编号，只是针对于实例锁，而不是本地locks，甚至运行单实例数据库时.但是，这种等待在单实例下很少发生，仅仅只会发生于资源冲突，然而在并行服务中很普遍，因为新的锁请求必须通过分布式锁管理器dlm来socialized.
oracle并不期望row cache enqueue lock的获取和转变，阻塞一些时间.因此，row cache locks等待时间每三秒会超时，假如100次超时（5分钟），会产生一个内部死锁，操作会中断。同时会往alert写入"waited too long for a row cache enqueue lock"信息.另外，一个进程state dump会写入到trace file.
除了对于一个长时间运行，正在发生作用的过程，或包进行ddl时，这个错误被视为bug.
library cache locks and pins
library cache不是一个cache,而是好多少cache.它包含好多的pl/sql程序单元的伪代码。它包含解析树和共享sql语句的执行计划。它也包含sql语句所引用对象的某种抽象的diana形式.这些信息用于pl/sql程序单元编译及sql语句的解析及执行,尽管事实上是，dictionary cache包含不同形式的相同信息.library cache也包含
像同义词转化，依赖跟踪信息，及library cache locks和pins的控制结构.
library cache locks在oracle文档中叫作易碎的解析锁。它们用于sql语句的library cache objects及pl/sql程序单元，以及递归对它们所引用的database object的library cache objects.library cache locks在解析操作被共享模式持有，其后会转化为null mode.如果以后ddl语句修改一个数据对象的定义，这时这个对象的library cache 信息及所有依赖的
library cache object会变成不合理，通过中断这个library cache locks.
但是，当library cache object没有被pinned时，library cache locks被中断。一个pin用于pl/sql程序单元的library cache object或者sql语句，当这些对象正在被编译，解析，或执行时。pins一般情况以共享模式持有，但如果对象的library cache信息被改变，必须以排它模式持有锁.library cache object如：pipes和序列大多发生变化时。当一个library cache
object被pinned时，相反pins用于所有被引用的对象。当一个pin用于数据库对象的library cache object,此时需要一个data dictionary row(基础的）所对应的row cache enqueue lock,因此可以防止产生冲突的ddl.
library cache中每个对象具有一个句柄，它起到library cache locks和pins的资源结构。句柄，锁，pin结构所以从共享池中动态分配。句柄会对持有的锁实行双向链表，等待的锁，持有的pins,等待的pins.
wait parameters(library cache lock and library cache pin waits)
参数 描述
p1 内存中library cache handle的地址
p2 锁的内存地址或pin的结构
p3 锁模式或请求的pin,对象的名字空间namespace,是以10*mode+namespace编号方式来表示。
这种情况下，模式如下：
2 shared
3 exclusive
名字空间有:
0 cursor
1 table,procedure,and others
2,package body
3,trigger
4,index
5,cluster
6,object
7,pipe
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9240380/viewspace-660610/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/9240380/viewspace-660610/
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
