awr中physical writes是统计周期内平均值，非瞬时吞吐量，受redo瓶颈、检查点频率、dbwr延迟写等非硬件因素压制，数值偏低反而是健康信号；需结合log file sync等待、checkpoint触发频次及redo writes对比综合判断。
awr报告里的物理写速度（physical writes）不是瞬时吞吐量，而是统计周期内的平均值，且受多种非硬件因素压制——它慢于磁盘理论带宽，完全正常，甚至往往是健康信号。
Physical Writes数值本身不反映IO能力上限
AWR中Physical Writes来自DBA_HIST_SYSSTAT或报告中的“Instance Activity Stats”，单位是“块数/秒”（默认8KB），再换算成MB/s。这个值是整个快照周期（比如60分钟）内所有写操作的总和除以时间，天然抹平了峰值。而SSD标称的2GB/s是连续顺序写的理论极限，Oracle写入却是随机小块、带日志同步、受检查点控制的混合负载。
- 写操作被分散在多个环节：log buffer → redo log file → db buffer → datafile，中间穿插latch、checkpoint queue、write list争用
- 大量
Physical Writes实际是dbwr进程执行的延迟写（delayed write），并非用户事务直接触发 - 如果数据库启用了
DB_WRITER_PROCESSES多进程，AWR不会告诉你哪个进程卡在I/O调度队列里
log file sync等待高时，Physical Writes反而可能偏低
当log file sync在Top 5事件里占比超15%，说明事务提交被日志写入拖住。此时前台进程在等LGWR刷redo，DBWR还没轮到写datafile，Physical Writes数值就会被“憋住”——不是磁盘慢，是redo路径先堵死了。
- 查
v$sysstat确认：select name, value from v$sysstat where name = 'physical writes'，对比redo writes增长速率，若后者远高于前者，就是redo瓶颈压制了datafile写入 - 检查
log_buffer大小是否过小（常见于OLTP系统），导致频繁force write；或日志文件是否放在慢盘上（如NAS、单块SATA） - 别只看
Physical Writes绝对值，重点看log file sync平均等待时间（单位ms）：>5ms需干预，>20ms已严重
检查点触发频率直接影响Physical Writes分布
AWR报告里Physical Writes低，但DB Time高、db file sequential read高，大概率是检查点太激进——DBWR被频繁唤醒做增量写，每次写量小、次数多，平均速率拉低，同时引发大量buffer busy waits。
- 看报告中“Background Wait Events”部分，
control file sequential read或checkpoint completed出现频次是否异常 - 查参数：
fast_start_mttr_target设得太小（如 - 对比两个时段报告：
Physical writes+Physical writes from cache之和是否稳定？若波动剧烈，说明检查点策略失衡
真正要盯的不是Physical Writes比磁盘标称值低多少，而是它和log file sync、db file scattered read、free buffer waits之间的比例关系——单独一个数字没意义，脱离等待事件和SQL行为谈IO性能，等于在真空中测风速。
