锁的总结笔记

数据字典锁

数据字典锁是保护的是在数据字典中定义的数据库对象被引用时，保持数据的一致性，主要是保护这些对象在使用的时候，不被删除，改变。为事务提供一致性的对象定义视图。主要有三种类型的数据字典锁：

n 行缓存锁

n 库缓存锁

n 库缓存pins

行缓存锁

1、 存储的是数据字典行

2、 是共享池的一部分

3、 可以减少对SYSSTEM表空间的IO争用

4、 使用行缓存锁来实现数据字典行的find-grain锁

锁的应用：

1、 这些缓存的行为资源结构

2、 锁结构是从共享池中被动态分配；

3、 类型QA。。。QZ

参数_row_cache_instance_locks定义的是行缓存锁的数目。这个锁的请求被放置在队列中，而引起row cache lock的等待事件。

等待事件row cache lock

这个等待事件是由等待row cache锁而引起来的，等待周期是3秒。 当锁在请求的时候得不到响应的时候，这个会话将sleep3秒，然后再重新试，如果经过了1000次的尝试的时候仍然得到布料这个锁的时候，这个锁在等待超时1000次后就被抛弃。并在警告文件中写入“Waited too long for row cache enqueue lock”。

这个等待在RAC环境上是比较常见的，但是在单实例的数据库中相对比较少见，主要是一些资源冲突的结果。

MODE 0 ：NULL lock

MODE 3 ：SHARE

MODE 5 ：exclusive

MODE 10 ：fail to acquire instance lock

参数的含义：

P1 ：cache id (cache# in v$rowcache)

P2 ：mode that is held

P3 ：mode that is requested

库缓存锁

库缓存锁（breakable parse locks）通过请求锁对象的句柄，来控制多客户的库缓存的并发行。主要是当一个客户请求到一个资源的话，其他的客户就禁止连接。

在解析调用的过程中，这些锁被请求时候，

1、 在父和子的句柄为排他模式

2、 所依赖的关系为共享模式

锁被保留为NULL模式的话，

在系统中锁结构映像到实例的锁，可以参考x$kgllk。这个表包含着所有会话的所有的库对象锁（held&requested）。比v$lock视图更详细，

锁的应用

1. 这些资源结构只是一个句柄；

2. 锁结构被动态分配在共享池上；

3. 类型LA...LP

等待事件：library cache lock

这个时间描述的是请求库缓存锁的等待事件。

等待周期为3秒，PMON仅为1秒。

等待事件参数：

P1 ：对象的句柄地址；

P2 ：锁结构地址；

P3 ：100*mode requested + namespace#

Mode 1 ：null mode

Mode 2 ：share mode

Mode 3 ：exclusive mode

这个等待事件应该是比较少。

库缓存pins

库缓存pins是请求到库缓存数据堆，为了管理缓存的一致性。这个句柄上的锁首先被请求。在调用执行的过程中，pin被请求。Pin一个对象将会造成这个对象的数据堆将被载入到内存中，如果客户去修改或者检查这个对象的时候，在请求锁住相关句柄之后，客户必须请求pin在相应的合适对象堆上。这个等待事件的产生的原因就是在客户请求pin一个堆的时候，而这个堆被其他的会话把持，并且请求的pin和当前的pin并不是兼容。

n 在共享模式

读取数据堆

对依赖的对象保护不被修改

n 在排他模式

去修改数据堆

锁的应用

对象的句柄就是一个资源结构

Pin在共享池中被分配

类型NA...NZ

等待事件：library cache pin

等待周期为3秒，PMON仅为1秒。

等待事件参数：

P1 ：对象的句柄地址；

P2 ：pin地址；

P3 ：100*mode requested + namespace#

Mode 2 ：share mode

Mode 3 ：exclusive mode

这个等待事件应该是比较少，除了在pipe和sequence。视图x$kglpn包含的是等待和保持library cache pin的列表。

这里约总结一下 library cache lock和library cache pin的区别和联系；

library cache lock

由上可见这两个锁是一个先后的顺序进行请求的，先锁住所要请求对象的句柄，然后再锁住库缓存对象的数据堆，这个可能就要和上述的enqueue相关的内容相对应了，在哪里介绍了有resource structure，这里的资源句柄应该就是这里的句柄了，library cache lock这个事件在找到这个资源句柄以后将这个锁住，然后找到相应的数据堆的位置，再使用library cache pin将这个数据堆锁住。

对数据堆操作的时候，当只是读取数据堆的数据的时候，就是使用的是共享模式，当需要修改数据堆内容的时候，就需要使用排他模式进行library cache pin锁了。而一般等待得产生主要是在产生排他锁的时候，在访问、执行library cache上的资源时获得的都是共享pin，编译就产生排他锁了。

DML锁

表锁，能够保证在执行整个事务的时候对象定义的一致性；

行锁，能够保证在执行整个事务的时候数据的一致性；

这里所说的事务主要是指在解析和执行SQL阶段的过程。

应用：

表锁是被应用为TM队列；每一个游标都维护着表锁结构的列表，这个列表是解析这个语句时候建立的。在第一次执行这个游标的时候，将会获得所有表的锁，这些锁将在事务的结束或者放弃的时候被释放。

TM队列等的参数：

P1 ：name | mode

P2 ：object ID

P3 ：0

DML表锁失效

可能的性能提高

n 减少锁负担

n 防止阻塞的锁

n 不需要维护外键索引

n 不能使用drop和alter语句

有两种方式实现：

1、 设置dml_locks为0；

2、 使用alter table 命令来使得表锁失效；

DML行锁

锁的应用时在行级锁和事务锁联合一起使用的，行级锁主要是在每一行的头部的锁字节和ITL上应用的。事务锁使用的是TX队列。

事务锁

事务锁是反映一个活动的事务，这些事务锁被列在回滚段头块的事务表中，在ITL中有事务的标识，可以通过这个标识来指向对于地事务表的入口。这些锁被作为TX队列被应用。

TX队列等待得参数：

P1 ：name | mode

P2 ：rbs# |wrap#

P3 ：slot#

事务的标识（XID）

这个事务标识在整个系统中具有唯一性，被用于在数据快或者索引块的ITL中使用。

有三部分组成：

n Rollback/undo segment number

n Transaction table slot number

n Sequence number or wrap#

XID = usn# .slot# .wrap

找到被锁的行

在视图v$session中可以找到我们需要找到的悲锁的行。

ROW_WAIT_OBJ# NUMBER Y

ROW_WAIT_FILE# NUMBER Y

ROW_WAIT_BLOCK# NUMBER Y

ROW_WAIT_ROW# NUMBER Y

BUFFER锁

这个锁的主要目的是为了保护在缓存中的数据快的一致性。主要是用于：

1、 buffer header可以作为一个资源结构；

2、 会话使用buffer handle来联系buffer；

3、 Buffer handle 可以看作一个锁结构；

4、 在共享池中Buffer handle被动态分配；

这里可以看到锁与队列的关系了；

对于每一个数据库缓存中的每一个缓存，都有一个缓存头。这些缓存头是由一个 固定的数组构成，在buffer lock中buffer header扮演着一个resource structue的角色。会话操作缓存头。

Buffer lock正常情况下，是在共享和排他的模式下工作。

等待事件：buffer busy wait

这个事件产生的原因是因为一个会话正在请求一个buffer，而这个buffer正在被读或者被修改。

参数：

P1 : absolute file number

P2 : block number

P3 : ID(reason code)

超时时间正常委1秒，但是如果在前一个等待由于是排他的buffer lock，这时候超时将被增加到3秒。

Buffer lock争用

通过查询视图v$waitstat可以查看到争用确切的位置。这个视图主要存放市的是块争用的统计信息。

X$kcbfwait

数据块的争用

1、 如果等待是因为读产生的，则考虑去除一些没有选择性的索引。（这里是为什么，没有理解）

2、 如果等待是因为修改产生的，则：

减少行密度；

n 改变参数pctfree、pctused；

n 增加initrans;

n 使用MINIMIZE RECORDS_PER_BLOCK减少每个块中的行数；

n 减少db_block_size;

避免right-hand index （这里是什么意思，不太明白）

回滚段争用

Undo header 的等待意义就是需要更多的回滚段；

Undo block 的等待表示回滚段的不合适的缓存；

System undo block和system undo header的等待表示系统RBU出现问题

Save undo block和 save undo header 的等待表示延迟RBU出现问题

为了减少在undo header块上的buffer busy waits的数目：

n 添加更多的回滚段

n 减少transactions_per_roolback_segment，但是这样会造成需要更多的回滚段

减少undo block上的缓存忙等待：

n 使得在单个实例上的回滚段更大；

这个比率应该小于5％，如果大于应该增加回滚段的数量。

索引块的争用

这个和数据块争用相似，但是有两个意外：

n Index block split

n Bitmap index update

Free list争用

主要是发生在多会话试图并行分配或者撤销数据块。出现这个问题时候，在我们查看视图v$waitstat时候是表现为segment header block和free-list block的等待。

解决FREE list 争用

n 查询v$session_wait (get file /block)

n 查询dba_extents(get object name)

n Get free lists for segment

n 重建问题对象或者动态分配更多的free list

n 使用ASSM段

等待事件：write complete waits

这个事件产生的原因是因为等待一个buffer lock，主要是因为这个buffer由于老化被写。超时为1秒。这个事件是一个等待IO完成。在DBWn将老化的buffer写到磁盘的时候，将在这些buffer上标识为“正在被写”。当所有的IO完成以后，这个标识将被清除。这个事件write complete waits就是发生在这个标识被设置的阶段上产生的。

解决的方法：

n 提高DBMn的带宽

1) 增加磁盘的spindles的数量

2) 使用RAID1（条带化），不是使用RAID5

3) 使用异步IO，多个writers

n 减少批量写的大小

1) 写批处理大小是被以下的公式控制：db_files*db_file_simultaneous_writes/2

2) 这个只能用于没有free buffer waits

参数：

P1 ：absolute file number

P2 ：block number

P3 ：ID(reason code)

排序锁

有两种类型

n 永久表空间的临时表锁（TS）；

n 临时表空间的排序段锁；（SS）

保持磁盘排序空间使用的跟踪，是被用于在SGA中的固定数组，是由sessions参数来定义大小，并不是和锁冲突，等待或者死锁相关。

这个排序锁（TS，SS队列）并没有锁的冲突，不能将sort locks和space transaction enqueue(ST)混淆，ST的争用经常是和磁盘排序相关，因为在排序时候，需要增加，扩展和deallocation临时段。

ORA-1575

ORA-1575是空间管理队列（ST）的超时等待引起来的；减少这个错误的方法如下：

1、 使用本地管理表空间；

2、 使用临时表空间存放排序段；

3、 增加sort_area_size，用以减少磁盘排序；

4、 使用合适的extent大小，设置参数pctincrease为0；

SMON功能

1) 合并free extents（5 minutes）

2) 清除临时段(2 hours)

3) 清除在obj$中不存在地对象(12 hours)

4) 如果online builder crashes,清除ind$(1 hours)

5) 缩小回滚段(12 hours)

6) 在启动时候事务恢复

7) 事务回滚（由PMON调用）

合并自由空间

SMON每5分钟合并一次表空间，这个功能实现有一个前提，主要是在系统管理表空间（即字典管理表空间）和pctincrease > 0。在每一次合并得时候ST队列将被把持，如果不需要后台合并的发生，可以通过设置事件10269来禁止后台合并得发生。

临时段的清除

SMON每两个小时执行这个任务，

总结一下：

Data dictionary locks目的主要是保持数据字典的一致性，由以下三种类型组成：

Row cache locks

这个锁主要是针对row cache，将cache row作为资源结构来管理。这个锁等待会引起row cache lock这个等待事件。

Library cache lock

这个锁是请求库缓存对象的句柄。将object handle作为资源结构。这个锁等待会引起library cache lock这个等待事件。

Library cache pin

这个锁是请求库缓存数据堆。将object handle作为资源结构。这个锁等待会引起library cache pin这个等待事件。

DML锁

有两种：

Table lock

Row lock

事务锁

Buffer lock