Part1Log file sync的判断步骤
1、提交过于频繁 2、存储IO资源紧张 3、Rac之间的SCN同步 4、Rac之间的CR块同步 5、控制文件争用 6、提交方式异常 7、磁盘或者网络异常
Part2log file sync的引起原因和解决步骤
1提交过于频繁
怎么判断是事务提交频繁的具体判断 wait Classes by Total Wait Time里的commit是否出现？是否排前几？Avg Wait（ms）是否超够了五毫秒？
Key Instance Activity status里的user commits的per Second数值是多少算是过于频繁？ user calls的per Second是否大于60？
user calls÷(user commits+user rollbacks) < 30 如果这个计算小于30，就认为每次提交包含的SQL条数过于紧凑，需要调整应用的提交次数。
###########################################
解决方式 让开发修改提交频率，把小事务改成大事务 或者 修改提交方式，但是如果数据库异常宕机，会有数据丢失的风险
alter system set commit_logging='batch' scope=both sid='*';
alter system set commit_wait='nowait' scope=both sid='*';
2存储IO资源紧张
如果 log file parallel write和log file sync两个等待事件出现频率、占比、平均等待时间类似，说明是存储IO资源紧张导致的 log file sync 发生。
判断是写的慢还是写达到了极限 这个是通过dd来验证磁盘的性能
mkdir -p /soft/testdisk/
dd if=/dev/zero of=/soft/testdisk/io_test.bin bs=4096 count=1000 oflag=direct
加上strace看是否有卡断
strace -T -e trace=write dd if=/dev/zero of=/soft/testdisk/io_test.bin bs=4096 count=1 oflag=direct
我在测试虚拟机上的机械盘是2.8M/s，固态是35.8M/s，仅作参考。如果查看awr报告发现了峰值到达了2.8左右，说明是到达了极限。
也可以通过这个语句来判断redo切换频率具体到分的频次，来判断的更加精确。
SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24:MI') AS minute_time,
COUNT(*) AS log_switches
FROM v$loghist
WHERE first_time >=
TO_DATE('2025-06-20 15:00:00', 'YYYY-MM-DD HH24:MI:SS')
AND first_time < TO_DATE('2025-06-20 16:00:00', 'YYYY-MM-DD HH24:MI:SS')
GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24:MI')
ORDER BY minute_time;
也可以看ASH报告最后的等待事件触发频率
解决措施 日志、Undo表空间与数据盘分开存放，避免 IO 竞争
日志盘的 raid 一般推荐 1+0 或者 RAID 0
磁盘的 IO 调度为 deadline： cat /sys/block/sdb/queue/scheduler
3Rac之间的SCN同步
待定，还没搞明白
4Rac之间的CR块同步
Avg global cache cr block flush time (us): 60秒以上
Avg global enqueue get time (us): 60秒以上
gcs log flush sync 需要注意平均等待时间和总等待时间的时间段，等待事件的时间段越长越说明问题。 解决措施
alter system set "_cr_server_log_flush"=False scope=both sid='*';
5控制文件争用
当enq:CF-contention和 log file sync同时出现的时候，就代表着控制文件争用出现了问题。
控制文件太大
SQL> SELECT
name AS controlfile_path,
block_size,
file_size_blks,
(block_size * file_size_blks) / 1024 / 1024 AS size_mb
FROM v$controlfile;
CONTROLFILE_PATH BLOCK_SIZE FILE_SIZE_BLKS SIZE_MB
----------------- ---------- -------------- ----------
+DATA/OJNDEV8/CONTROLFILE/current.261.1204131481 16384 1202 18.78125
############################################
其中18.78125是控制的大小，du -sh 算出来的差不多
[root@ojndev81:/tmp]# du -sh Current.261.1204131481
19M Current.261.1204131481
缩减控制文件，可以删除归档、可以重建控制文件 还有就是控制文件超过2G，算是严重事故，需要及时定位观察。
另一个引起的原因，Rman操作比较频繁 尽量少在业务高峰期进行RMAN操作（比如说RMAN删除归档）
6提交方式异常
判断方式 LGWR的trace文件，关键字是 “Log file sync switching to ” 提交方式的切换
select name,value from v$sysstat where name in ('redo synch poll writes','redo synch polls');
NAME VALUE
----------------------------- ----------
redo synch poll writes 0
redo synch polls 0
解决方式
alter system set "_use_adaptive_log_file_sync"=False scope=both sid='*';
7磁盘或者网络异常
ping、traceroute判断网络卡断
判断磁盘卡断 strace -T -e trace=write dd if=/dev/zero of=/soft/testdisk/io_test.bin bs=4096 count=1 oflag=direct
