看看io等待高不高，对比一下redo量，看看有没有突增。

如果io等待高，则io处理不过来

日志切换不频繁，一共切换了4个，日志组300m一个。有个dg。

有类似的信息。

Thu Sep  5 18:46:45 2019

ARC1: Evaluating archive   log 2 thread 1 sequence 290339

ARC1: Unable to archive log 2 thread 1 sequence 290339

当时特地ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH;

除此，看不出什么问题

看上去是io的问题，可以生成下正常时间的sp报告，对比看下。

应该是有特定的业务模块在那个时间运行，特别是1455248145这条SQL占到了40%，建议排查应用或者优化相关SQL。

          -------------------------------------------------------------
SQL ordered by Gets for DB: MESASSY  Instance: mesassy  Snaps: 2025 -2027
-> End Buffer Gets Threshold:     10000
-> Note that resources reported for PL/SQL includes the resources used by
   all SQL statements called within the PL/SQL code.  As individual SQL
   statements are also reported, it is possible and valid for the summed
   total % to exceed 100

                                                     CPU      Elapsd
  Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
     56,432,290          390      144,698.2   40.3   894.11    876.92 1455248145
Module: oracle@lixora01 (TNS V1-V3)
SELECT "A2"."NODENAME" FROM "FWFLATPLAN" "A4","FWFLATPLAN_N2M" "
A3","FWFLATNODE" "A2","FWPROCESSPLAN" "A1" WHERE "A4"."PLANNAME"
=:B1 AND "A4"."SYSID"="A3"."FROMID" AND "A3"."TOID"="A2"."SYSID"
 AND "A1"."NAME"="A4"."PLANNAME" AND "A1"."ACTIVEVERSION"="A4"."
PLANVERSION" AND "A2"."NODENAME" NOT LIKE '%DieBond%' AND INSTR(
UPPER("A2"."NODENAME"),'MOLD_')<=0 AND INSTR(UPPER("A2"."NODENAM
E"),'UV')<=0 AND INSTR(UPPER("A2"."NODENAME"),'SAW')<=0 AND INST
R(UPPER("A2"."NODENAME"),'WIREBOND')<=0 AND INSTR(UPPER("A2"."NO
DENAME"),'LASERMARK')<=0 AND "A2"."NODENAME" NOT LIKE '%TopLaser
Mark%' ORDER BY "A2"."STEPSEQ"

SQL ordered by Reads for DB: MESASSY  Instance: mesassy  Snaps: 2025 -2027
-> End Disk Reads Threshold:      1000

                                                     CPU      Elapsd
 Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
        525,772            5      105,154.4   14.9    23.88     45.51 1132812986
Module: oracle@ship02 (TNS V1-V3)
SELECT "AOLOT","PLANQTY" FROM "FWCATNS_AOLOT" "E"

这个情况难搞之处就是没有频繁commit，正常时候比异常时刻还要高，avg.redo write，正常时刻比异常还要低。不论正常与否，cpu没有什么波动。

@章芋文这个语句执行次数多，平摊后也不算高，而且cpu没有什么波动。而且其他6.20-6.50之间出现主要logfile sync时也不一定有这个语句，比如上一个附件

经过对比，发现出现log file sync时，数据文件的读写延迟就比较高，正常时刻，数据文件读写延迟低。用的是3par7200+3par8200，存储。

感觉是存储问题，查查硬盘、cache电池等有没有报错

目前问题已经排查出来，是同在一个存储上的另一套rac做增量备份。