公司是做交易支付的，为了交易稳定性，上了各种各样的监控。有连接数告警，有交易失败承兑率的告警等，就昨天的一个告警，我们展开了追踪，我们有自建的awr收集平台，通过半小时打点进行展示；

数据库不忙，当时的系统IDLE,MEM,IO都不忙，尤其是大佬们怀疑的IO。

我们继续去排查存储，看看是否有压力

存储用的Dell Unity 600，有共用存储的情况，顺着思路往下屡，发现有大量写入的是归档盘，而告警的数据库当时才6MB/s，且后面有波峰毛刺，但是监控确未告警，故侧面反映出，不是存储的性能瓶颈。

当前数据库redo log每组2G，我们做了很多参数优化形成了自己公司内部的标准参数实践模板；

至于lgwr的warning，我们也有参数

 ALTER SYSTEM SET "_use_adaptive_log_file_sync"=FALSE scope=both sid='*';

且当时类比了其他数据库系统的平均IO

11.2之前，oracle的lgwr写入模式为post/wait

11.2之后新增了polling模式，可以与post/wait模式自动切换

通过隐藏参数 _use_adaptive_log_file_sync　参数来控制

查看该隐藏参数的方法：

SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ

 FROM SYS.x$ksppi x, SYS.x$ksppcv y

WHERE x.indx = y.indx

 AND x.ksppinm LIKE '%_use_adaptive_log_file_sync%';

当参数设置为false时，lgwr还是采用post/wait方式将日志从buffer写入磁盘

当参数设置为true是，lgwr写入方式会自动在post/wait和polling模式之间进行切换，可能会造成比较严重的log file sync (当使用polling模式时)

建议关闭此参数，且立即生效，无需重启实例。

我现在除了还想动_high_priority_processes别无其他想法，因为我认为数据库就是正常的，但是老大纠结lgwr trc抛出的问题。也许是个讨厌的bug，你们觉得呢？