当HIS系统崩溃时，我用白大佬的BIC-QA 1.1从百万级IO中抢回生命

摘要：一张AWR报告揭露的真相，让我从存储层崩溃的边缘拉回整个医疗系统。这不是SQL调优故事，而是一场与时间的赛跑。

背景

在陪产假休假半个月后，上班第一件事就是先着手数据库第一季度恢复演练。毕竟在评审时看恢复报告是要看每个季度的恢复时间点都要相对一致，不能隔太久的。登录爱数备份 一看，发现了昨晚的备份至今未完成，并且昨天中午的还跑了11个小时。习惯发现问题先群里反馈，然后继续排查。

随后客户大佬就过来了说是业务也反馈慢，于是第一时间先把备份任务停了。

当时忘了停止任务在监控里（也寻思不可能没有），着急排障于是采用的以下之前备份任务卡死kill杀掉备份任务（写这篇文章时发现，当时杀掉后显示异常，现在又是运行中，找到停止给停了）。

当时停了后是有点好转，于是又收集awr

awr看到以下

@?/rdbms/admin/awrrpt

随后跟客户大佬聊，说用工具分析下。我就想到了白大佬的工具，搜索文章后使用。

今年的最后一天：BIC-QA 1.1版本正式上线EDGE插件商城

需要先注册有了API密钥后使用

执行分析后坐等邮件就行

应用再根据这个问题SQL语句清单的SQL_ID去原来的awr查询完整语句，解决问题简述。解决后，IO恢复正常。

最后跟客户大佬聊的是本该所有上线语句上线前就审核后再上线，但由于种种原因吧！基本做不到，并且后续变更也是挺频繁的。于是往后每天收集分析个，如有需要整改的发给应用整改。

以下是我把分析出来的报告扔给kimi和之前的对话，让给出了个总结。

一、深夜告警：HIS系统卡成PPT

"his系统卡死！医生站开医嘱要30秒，检验科报告出不来了！"

登录服务器，第一反应就是跑个vmstat：

vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
13 21 387208 65363648  38976 331988640    0    0   429    31    0    0  2  1 97  0  0
10 33 387208 66400168  38976 331947360    0    0 1203555 11909 90113 97720  7  3 79 11  0
21 30 387208 65917960  38976 331972544    0    0 1413860 10666 95188 120082  8  4 75 13  0

b列=57，wa=21%——这已经不是普通慢了，这是灾难级IO等待。存储层像被堵死的北京二环，CPU空有一身力气却使不出来。

更扎心的是，同样的症状在his1、his2俩台核心服务器上同步上演。这不是单机故障，而是整个存储子系统被压垮了。

二、揪出元凶：一条SQL打爆存储

收集awr看到一条慢查询：

select d.* , r.ITEM_CODE COMITEMCODE , r.TEST_NAME COMITEMNAME , 
       r.REPORT_DOCTOR_NAME APPROVERNAME , r.REPORT_DOCTOR_CODE APPROVERID , 
       r.TREATMENT_CODE TREATMENT_CODE 
from TH_TEST_RECORD_DETAIL d 
leftjoin TH_TEST_RECORD r on d.TEST_CODE = r.TEST_CODE 
AND d.PATIENT_ID = r.PATIENT_ID 
where1=1and d.PATIENT_ID = :1
and d.TEST_DATE >= to_DATE( :2 , 'yyyy/MM/dd HH24:mi:ss' ) 
and d.TEST_DATE <= to_DATE( :3 , 'yyyy/MM/dd HH24:mi:ss' ) 
orderby d.TEST_CODE, d.sort_no

给AI分析发现： TEST_DATE列没索引 。但谁也没想到后果会这么严重。

三、白大佬的BIC-QA 1.1：让真相无处遁形

我把AWR报告塞进白大佬的BIC-QA 1.1（Business Intelligence Center - Quality Analyzer），这个工具像CT扫描仪一样，立刻把病灶照得清清楚楚：

3.1 顶级等待事件雷达图

[图] db file sequential read 43.8% | log file sync 25.2% | DB CPU 15.6%

BIC-QA红色警报：db file sequential read平均等待8ms，远超健康阈值（<5ms）。存储阵列的SAS盘已经跑到极限。

3.2 SQL资源消耗排行榜

BIC-QA智能诊断：这条SQL占用了近一半的DB Time，却一条索引都没用。它像一台没有导航的货车，在亿级数据的TH_TEST_RECORD_DETAIL表上全表扫描了2.3M次。

3.3 I/O热力分布图

[图] /oradata/hisdb/users01.dbf  → 2.1M读/秒
      /oradata/hisdb/users02.dbf  → 1.7M读/秒
      其他表空间                  → 0.1M读/秒

BIC-QA定位：89%的IO压力集中在USERS表空间，这正是HIS核心业务表所在地。存储带宽被这条SQL吃干抹净。

四、止血手术：15分钟创建救命索引

白大佬的工具不仅发现问题，还自动生成修复脚本：

-- BIC-QA推荐索引（在线创建，不影响业务）
CREATEINDEX idx_test_detail_pid_date 
ON TH_TEST_RECORD_DETAIL(PATIENT_ID, TEST_DATE) 
TABLESPACEUSERS
ONLINEPARALLEL8;

-- 收集统计信息
EXEC DBMS_STATS.GATHER_TABLE_STATS('HIS','TH_TEST_RECORD_DETAIL', 
                                   cascade=>TRUE, degree=>8);

执行时间：14分37秒
效果立竿见影：

vmstat的b列从57降到了3，wa从21%降到0.3%。存储阵列的指示灯终于从狂闪的红灯变成了平稳的绿灯。

五、深度反思：为什么一条SQL能拖垮整栋楼？

1. 数据量爆发：TH_TEST_RECORD_DETAIL表已累积8.7亿条记录，但运维监控只关注了表空间使用率，忽略了索引健康度。

2. 执行计划突变：绑定变量窥视（Bind Peeking）导致CBO在特定时间范围内选择了全表扫描，而这条SQL是检验科查询报告的核心语句，每秒被调用200+次。

3. 存储层脆弱：SAS盘的IOPS上限约5000，但这条SQL每秒产生3.8M次物理读，相当于760倍的IO冲击。

六、白大佬的BIC-QA 1.1：DBA的瑞士军刀

这次救火让我彻底成了BIC-QA的脑残粉：

• 一键诊断：自动识别Top SQL、等待事件、I/O热点，生成可视化图表
• 智能建议：不仅告诉你"缺索引"，还给出ONLINE PARALLEL创建脚本，避免业务中断
• 根因溯源：关联OS层vmstat和DB层AWR，定位是SQL问题还是存储问题
• 容量预测：基于当前趋势，预警"再跑3天存储就会彻底卡死"

最关键的是，它把DBA从海量数据中解放出来，15分钟定位问题，15分钟解决问题，剩下的时间可以安心喝茶。

七、终极建议：给HIS系统的保命 checklist

□ 每日巡检：用BIC-QA扫描TOP 10 SQL，关注"逻辑读/物理读>1000"的语句
□ 索引健康：每月检查`DBA_INDEXES`中LAST_ANALYZED是否为NULL
□ 存储隔离：将`USERS`（业务）、`TEMP`（排序）、`REDO`（日志）分置不同存储池
□ 监控升级：不只看CPU和内存，必须监控`iostat -x`的`%util`和`await`
□ 应急预案：预先创建好"KILL SESSION"和"FLASHBACK TABLE"脚本

尾声

当检验科报告打印机的声音重新响起时，天已经亮了。这台HIS系统每天承载着3万+患者的诊疗流程，每一秒的卡顿都可能影响一条生命。

而白大佬的BIC-QA 1.1，就是给DBA配上的听诊器+CT机+手术刀。它不会让问题消失，但能让你在问题杀死系统前，先杀死问题。

工具链：BIC-QA 1.1 + Oracle AWR + vmstat + pidstat
核心命令：create index ... online parallel
最终效果：从"系统崩溃"到"丝般顺滑"，用时29分钟。

工具支持：白大佬BIC-QA 1.1
案例来源：某三甲医院的真实救火现场