enqTM

coding

今天下午,有台服务器出现异常,响应特别慢,io等待奇高,awr top 5事件如下:

经回查ash,找到了造成这些事件的sql语句,如下:

select*from v$active_session_history where event='enq: TM - contention'

select*from v$active_session_history where event='enq: KO - fast object checkpoint'

enq-TM的事件主要由insert /*+ append */语句引起,如下:

enq-TM是一个表级别锁,在本例中主要是由于append引起。

TM 锁在下列场景中被申请:

  1.  在OPS(早期的RAC)中LGWR会以ID1=0 &  ID2=0去申请该队列锁来检查 DML_LOCKS 在所有实例中是全0还是全非0
  2. 当一个单表或分区 需要做不同的表/分区操作时,ORACLE需要协调这些操作,所以需要申请该队列锁。包括:
  3. 启用参考约束 referential constraints
  4. 修改约束从DIASABLE NOVALIDATE 到DISABLE VALIDATE
  5. 重建IOT
  6. 创建视图或者修改ALTER视图时可能需要申请该队列锁
  7. 分析表统计信息或validate structure时
  8. 一些PDML并行DML操作
  9. 所有可能调用kkdllk()函数的操作
  10. 。。。。

enq:KO主要由下列select引起:

enq: KO - fast object checkpoint 发生的原因是:当进行TABLE FULL SCAN (全表扫描) 或并行查询整个segment时, 11g下,因_adaptive_direct_read 默认为true,  达到阀值_small_table_threshold大小的表会被认为是大表,读取数据时不会读入SGA , 而是直接路径读取(direct path read),而direct path read 是需要将数据从磁盘读取到各session 的PGA中,因为不是读入SGA, 所以读取这些表之前需要在所有数据库节点(如果是RAC)触发object level checkpoint,将这些表被修改过的dirty buffer写入磁盘,以保证读取数据的一致性 。

在本服务器中,_small_table_threshold的值如下:

大约为250M。

由于我们的系统是清算系统,故一方面考虑加大_small_table_threshold到1G-2G左右左右,以避免大量的不必要物理读写。如果发生这种等待事件,一个简单的查询可能也会变得非常慢。

至于free buffer waits,不是主因,主要是受前两者牵连所致。造成free buffer waits还有一个原因,就是大DML造成的延迟块清除或者delete造成的undo块写入文件(磁盘子系统慢,io很高,将undo移动到另外一块快的存储之后,性能极大提升):

什么是延迟块清除?

在事务提交前,这个事务修改得block已经被dbwr写到disk中去了。我们知道,块头会记录这个块有活动事务存在,后来这个事务commit时,oracle不可能再把它读回到内存中来修改块头。只能等下回用它时,到undo段里查询事务记录后,再修改块标志为已commit。比如如果对一个大表有delete操作,后续有人对这个表有select操作,因为延迟块清除的特性,就会占用大量buffer。这也是为什么select也会产生redo的原因。(select的时候要修改块头)

delay block cleanout :

主要针对大事务,可能在commit的时候,一些数据脏快已写入数据文件,提交时,无法把这些数据块标记commit,该数据块的下一个读者对其进行delay block cleanout 。数据块的下一个读者首先检查该块的事务状态是否为活动,不活动的话,修改事务的标志(flag)。这样可以避免不必要的事务读。

以上是 enqTM 的全部内容, 来源链接: utcz.com/z/509602.html

回到顶部