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性能应该是满足需求的。

没有使用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了

你把awr和ash发上来，看下

看下AWR报告里面的top sql