enqTM

  • Z时代
  • 2024-01-10
  • 分类：综合

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

回到顶部