匿名用户
AWR如下：
我看平均等待事件enq: TM - contention的高，
log file parallel write 和log file sync 都再10以内ms应该是不算高的吧
在数据库上面我通过ash定位阻塞会话，持有enq: TM - contention等待事件的会话最终阻塞都定位到lgwr进程持有log file parallel write。
我疑惑的：
1、是不是log file parallel write导致的enq: TM - contention，是不是把redo日志换到高性能的磁盘后enq: TM - contention也就被解决的？
2、还是log file parallel write和enq: TM - contention两者并没有关系，我应该最重排查enq: TM - contention？
但是根据awr信息log file parallel write 和log file sync 都在10以内ms是不是说明io是满足需求，又跟上面换磁盘的方法又产生了冲突。。。
请各位大佬指教一下，不胜感激，生产环境cpu:16c,内存32g,数据库版本11g
toevent
enq: TM - contention通常是由于事务处理过程中的并发问题引起的，而不是由于I/O性能问题。这种等待事件通常发生在一个会话试图锁定一个表，而另一个会话已经在使用这个表。这可能是由于并发的DML操作（如INSERT，UPDATE，DELETE）或并发的DDL操作（如ALTER TABLE，DROP TABLE等）引起的。
log file parallel write和log file sync是与redo日志写入相关的等待事件。log file parallel write是将redo日志缓冲区的内容写入到磁盘的redo日志文件中，而log file sync是等待redo日志写入到磁盘的操作完成。这两个等待事件的性能主要取决于磁盘的I/O性能。
所以，你的问题1，log file parallel write不太可能导致enq: TM - contention。把redo日志换到高性能的磁盘可能会改善log file parallel write和log file sync的性能，但不太可能解决enq: TM - contention的问题。
你的问题2，log file parallel write和enq: TM - contention两者并没有直接的关系。你应该主要排查enq: TM - contention的问题。
你的AWR报告显示log file parallel write 和log file sync 的等待时间都在10以内ms，这通常被认为是正常的，说明你的I/O性能应该是满足需求的。
评论
有用 3没有使用ssd盘, log file sync 这个速度也是正常;
log file sync 会影响enq: TM - contention, 但是平均等待10毫秒, 不会导致enq: TM - contention 平均等待185毫秒;
主要矛盾应该还是行锁相关语句: 有些update 语句从发起到commit的这个过程比较长, 其他session的update 在等行锁(enq: Tx - row lock contention) , 还有session的insert /*+ append */ 在等表锁(enq: TM - contention).
还有可能是并发的insert /*+ append */导致了enq: TM - contention
上面两种是大概率情况, 可能还有其他情况, 那就需要分析ash了
评论 有用 1