01 · Oracle 故障排查方法论与工具箱：拿到告警后的第一小时

系列开篇。大多数新手 DBA 的问题不是不认识工具而是拿到告警后乱抓一气先跑个 AWR再看看进程又去问开发你们改了什么。本篇给出一个可以照着执行的六步框架以及一张什么症状用什么工具的地图。一、为什么需要方法论先看一个真实案例2024-06-17 12:30 左右一套 12cR2 RAC 数据库的节点二主机宕机宕机前观察到内存耗尽需要分析原因。如果毫无章法地排查你会先怀疑数据库参数、再去查存储、再去问网络组——每一步都可能花掉一两个小时。而按方法论排查的实际路径是OSW 日志定位时间窗口12:00 内存还有 52 GB12:16 只剩 1.2 GB——故障酝酿期就在这 16 分钟Alert 日志看错误类型ORA-27301: No buffer space available指向内存/网络ASH 视图按时间窗过滤等待事件cursor: mutex X采样 2434 次一枝独秀顺着等待事件锁定 SQL再查v$sql_shared_cursor发现BIND_EQUIV_FAILURE子游标 2594 个比对 MOS 文档命中已知 BUG 28794230。30 分钟内完成定位。差别不在工具在顺序。二、六步排查框架1. 现象 —— 用户/监控到底报什么慢、报错、卡住、宕机 2. 范围 —— 单个 SQL单实例整个库集群 3. 时间 —— 什么时候开始是否周期性与变更/补丁/数据量增长相关 4. 采集 —— AWR区间聚合/ ASH分钟级/ alert.log / OSW系统层 5. 假设 → 验证 —— 形成假设用数据验证排除或确认 6. 修复 → 监控 —— 修复后必须跟踪指标量化效果每一步的要点步骤关键问题常见错误1 现象复述故障让报告者给出精确报错码把慢当结论不问慢在哪、多慢、谁慢2 范围一条 SQL 慢 ≠ 数据库慢 ≠ 存储慢范围没定就全局扫一遍浪费黄金时间3 时间是否与昨晚发布的版本、今早的批量、上周的数据增长吻合80% 的故障与变更强相关先查变更再查玄学4 采集先采数据再动系统AWR 默认只保留 8 天现场乱敲命令事后无据可查5 假设验证一次只验证一个假设同时改三个参数好了也不知道是哪个起效6 修复监控修复后对比修复前感觉好了就收工第二天复发三、故障分类先定性再动手把故障分成三类每类的工具和节奏完全不同1. 性能类最常见慢 SQL、等待事件、锁争用、CPU/IO 饱和。节奏分钟级响应但分析可以花小时。核心工具是 AWR / ASH / 等待事件。2. 可用性类最紧急数据库起不来、被挂起、节点宕机、连接全断。节奏秒级响应“先恢复再分析”。核心工具是 alert.log、ADRCI、crsctl/srvctlRAC。3. 数据安全类最致命误删数据、坏块、数据不一致。节奏黄金窗口极短UNDO 默认只保 900 秒先冻结现场、保住备份再操作。核心工具是 Flashback、RMAN、LogMiner。踩坑警告数据误删后最容易犯的致命错误是先把表 truncate 了重建——这会同时摧毁回收站和 UNDO 中尚存的历史版本。误删后第一步是停止对该表的一切写入。四、工具箱地图4.1 按故障类型选工具工具看什么粒度适用场景alert.log ADRCIORA- 错误、实例事件、checkpoint事件级一切故障的起点vsession/vsession / vsession/vsession_wait当前谁在等什么实时“现在卡住了”v$active_session_history (ASH)每秒采样的活动会话秒级保留 ~1 小时(内存)几分钟前的瞬时尖刺dba_hist_*AWR 底层表历史性能数据快照级(默认 30 分钟)昨晚/上周的问题回溯AWR 报告区间聚合全景30 分钟~4 小时系统整体变慢ASH 报告具体会话/SQL 细化5–10 分钟AWR 定位后的精确定位ADDM 报告Oracle 自动诊断建议快照区间想要官方答案快速初判SQL Monitor需 Tuning Pack单条 SQL 实时执行详情实时正在跑的慢 SQLOSW / OSWatcherCPU、内存、网络、IO 系统层分钟级判断是不是数据库的锅10046 事件SQL 级等待明细 trace语句级可复现的问题4.2 报告怎么生成速查-- 任意区间 AWRSQL?/rdbms/admin/awrrpt.sql-- 5-10 分钟粒度的 ASHSQL?/rdbms/admin/ashrpt.sql-- ADDM 自动诊断SQL?/rdbms/admin/addmrpt.sql-- AWR 前后对比证明变慢了的神器SQL?/rdbms/admin/awrddrpt.sql4.3 两条必须记住的采集纪律AWR 默认保留 8 天、30 分钟一个快照。想追溯更长周期提前调大-- 保留 30 天、每 30 分钟采一次EXECDBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention43200,interval30);区间选择30 分钟~4 小时。过短5 分钟容易被瞬时尖刺带偏过长24 小时会把高峰平均掉。故障分析首选故障时段 vs 同时长正常时段的 AWR Diff。五、一小时应急流程图告警到达 │ ├─ 库挂了/起不来 ──────→ 02 篇看 alert.log → 03 篇启动排查 → 05 篇文件恢复 ├─ 连不上 ────────────→ 04 篇监听排查先 lsnrctl status再分诊错误码 ├─ 整体变慢 ──────────→ 06 篇生成故障时段 AWR → 看 DB Time Top 5 等待事件 │ ├─ IO 类等待 → 10 篇 存储层 │ ├─ commit 慢 → 08 篇 log file sync │ ├─ 锁等待 ───→ 09 篇阻塞链 │ └─ 个别 SQL → 10 篇慢 SQL 路径 ├─ 报 ORA- 错误 ───────→ 02 篇 alert.log 定位 → 本系列对应专题 └─ 数据误删 ──────────→ 12 篇先停止写入Flashback 黄金窗口六、新手的五个典型误区误区后果正确姿势上来就重启现场证据全毁间歇性故障更难复现先采数据AWR/trace/OSW重启是最后手段直接 KILL 阻塞会话可能产生 in-doubt 分布式事务先查v$session确认无分布式事务再 KILL只看 AWR 不看 alert.logORA-600/7445 类错误在 AWR 里不可见两份都要看alert.log 优先修复后不做对比无法证明有效复发无从对比修复前后各一份 AWR量化 DB Time 变化凭记忆记录故障复盘时细节丢失原始报告存档结论沉淀成文档七、小结六步框架现象 → 范围 → 时间 → 采集 → 假设验证 → 修复监控先定性性能/可用性/数据安全再选工具AWR 管区间趋势ASH 管瞬时尖刺alert.log 管事件真相OSW 管系统层背锅侠鉴定一切修复必须有 Before/After 数据支撑。下一篇02-告警日志与ADRCI-第一现场 —— 告警来了第一分钟打开 alert.log 到底看什么