db time爆表但top events平静，大概率是os层问题，需立即检查osw：vmstat看swap、netstat查丢包、iostat盯io延迟；ora-27300报错时osw的memavailable比awr更早暴露内存耗尽；rac节点aas差异大时osw能定位私网丢包；无osw则用/proc/meminfo等实时命令补缺。
AWR里DB Time爆表但Top Events平静，先查OSW有没有丢包或Swap飙升
DB Time远超Elapsed × NUM_CPUS（比如60分钟快照、112核，理论上限6720分钟，实际DB Time达18000分钟），但Top 5 Timed Foreground Events里全是低占比等待（如SQL*Net message from client占8%、db file sequential read平均才0.8ms），这种“高负载+低信号”组合，大概率是OS层出了问题，不是数据库本身卡。这时AWR给不出答案，必须立刻翻OSW归档。
重点盯OSW的三个输出文件：vmstat里si/so列是否持续非零（表示Swap in/out）；netstat里retransmit或packet drop是否突增；iostat中%util接近100且await > 30ms。这些在AWR的Operating System Statistics里要么不体现（如丢包）、要么延迟严重（如SWAP_FREE_BYTES剩得多，但SWAP_USED_BYTES已在爬升）。
ORA-27300 fork failed with status:12报错时，OSW比AWR更早暴露内存耗尽
当alert.log出现ORA-27300: OS system dependent operation: fork failed with status:12，说明Linux已无法为新进程分配内存——这不是Oracle SGA/PGA配多了，而是整个系统/proc/meminfo里的MemAvailable跌破临界值。AWR的FREE_MEMORY_BYTES可能还显示有20G，但它只采样MemFree，而MemFree在内核回收缓存前会虚高。OSW的meminfo输出则包含MemAvailable，且每5秒一次，能精确看到它从3G掉到128MB的过程。
此时要同步检查OSW的ps快照：是否有非Oracle进程（如rsync备份、logrotate）在故障窗口内突然吃掉数GB RSS；top输出里%MEM列是否多个进程集体冲高。AWR里INACTIVE_MEMORY_BYTES没涨，恰恰说明内核连“可回收内存”都快没了，根本来不及标记为inactive。
RAC节点AAS差异大但AWR汇总报告掩盖热点，OSW能定位私网延迟
单实例AWR里enq: TX - row lock contention占比仅2%，但RAC环境下节点A的Avg Active Sessions是6.2、节点B只有0.3，这种撕裂必须分实例查。即使用了@?/rdbms/admin/awrrpti.sql，AWR仍无法告诉你为什么块请求卡在节点间——gc cr block lost平均等待1.2秒，到底是磁盘慢、LGWR堵，还是私网丢包？
OSW的netstat -s归档会直接暴露：TCP retransmits在故障时段从日均17次跳到每分钟200+；ip -s link显示tx_dropped激增。再结合ping -c 100 -s 8192私网IP的丢包率（OSW不自动做，但数据在ping子目录里），就能确认是MTU不匹配或交换机buffer溢出。AWR里的TCP_RECEIVE_SIZE_MAX（4MB）和GLOBAL_RECEIVE_SIZE_MAX不一致，只是间接线索，OSW才是实锤。
OSW数据缺失时，用V$OSSTAT和/proc/meminfo补关键缺口
客户没部署OSW？别硬等。立刻登录数据库服务器跑三行命令：cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree"看真实可用内存；grep -i "retrans" /proc/net/snmp查TCP重传；awk '{print $1,$10}' /proc/net/dev算网卡收发错误率。这些比AWR的V$OSSTAT更及时——V$OSSTAT里SWAP_USED_BYTES需手动查，且采样间隔受_os_statistics_frequency控制（默认30分钟），而/proc是实时的。
注意两个坑：V$OSSTAT的NUM_CPUS_ONLINE可能小于NUM_CPUS（比如超线程被禁用），导致你误判CPU调度能力；/proc/meminfo的Active(anon)和Inactive(anon)比AWR的INACTIVE_MEMORY_BYTES多一层匿名页分类，排查Java进程泄漏时更准。
OS层问题不会在AWR里留完整证据链，它只记录“结果”。真正卡死前的5分钟，OSW的vmstat里cs（context switch）可能已从2000飙到15000，而AWR的DB CPU还没明显变化——因为上下文切换本身不计入DB CPU，但会让所有会话排队等调度。这点最容易被忽略。
