摘要：一家三甲医院HIS系统频繁卡顿，信息科和厂商都认为是服务器老化，50万采购单已走到审批流程。作者介入后，没有看设备清单、没有看方案报价，而是用一套自创的DG Framework决策治理框架，从DG4需求决策四问到DG-5五层定位法逐级排查，最终在Oracle数据库层发现根因——一条核心SQL的执行计划偏差。更新统计信息+加复合索引，2小时搞定，花费0元。本文完整拆解这套方法论，让IT架构选型从"拍脑袋"变成"有章可循"。

一、真实案例：50万采购单，零成本解决

1.1 故障现场

2024年，某三甲医院。

HIS系统越来越慢，门诊高峰期挂号窗口排长队，医生工作站响应超过10秒。

信息科的判断是：虚拟化平台用了5年，75台VM跑在6台ESXi主机上，资源争抢严重。建议整体升级——加CPU、加内存、换全闪存储。

厂商反应很快，方案3天就送到了：两台高配服务器 + 全闪存储阵列，报价50万。

采购流程已经走到一半，领导准备签字了。

1.2 董工介入：不看方案，先看数据

我到现场后，没看设备清单，没看厂商方案，先问了一个问题：

"系统慢的时候，你们看过数据库的等待事件吗？"

没人看过。

我花了2个小时做了三件事：

第一步：拉Oracle AWR报告

-- 生成AWR报告（取高峰时段快照） @?/rdbms/admin/awrrpt.sql -- 选择最近1小时的快照区间 -- 重点关注：Top 5 Timed Events

AWR报告结果：

第二步：检查VMware资源利用率

# 在ESXi主机上执行esxtop，按c看CPU，按m看内存，按d看磁盘 esxtop # 关键指标： # %USED - CPU利用率 # %SWPWT - 内存交换等待 # DAVG - 磁盘平均延迟（ms） # KAVG - 内核延迟（ms）

esxtop结果：

• CPU %USED: 平均32%，峰值58%
• 内存：无swap，balloon=0
• 磁盘DAVG: 3.2ms（正常范围 < 20ms）

第三步：定位SQL执行计划

-- 查找高IO消耗的SQL SELECT sql_id, sql_text, executions, disk_reads, buffer_gets, elapsed_time/1000000 as elapsed_sec FROM v$sql WHERE elapsed_time > 10000000 -- 执行时间>10秒 ORDER BY disk_reads DESC; -- 查看具体SQL的执行计划 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('sql_id_here'));

找到了！一条门诊挂号的核心SQL，执行计划走了全表扫描。

继续追查原因：

-- 检查统计信息更新时间 SELECT table_name, last_analyzed, num_rows FROM dba_tables WHERE owner = 'HIS_SCHEMA' ORDER BY last_analyzed; -- 结果：核心业务表的统计信息3个月没更新

1.3 修复方案：2小时，0元

-- 1. 更新统计信息 EXEC DBMS_STATS.GATHER_TABLE_STATS( ownname => 'HIS_SCHEMA', tabname => 'T_OUTPATIENT_REG', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE ); -- 2. 添加复合索引 CREATE INDEX IDX_REG_DEPT_DATE ON T_OUTPATIENT_REG( dept_code, reg_date, patient_status ); -- 3. 验证执行计划 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('目标SQL的sql_id')); -- 确认：全表扫描 → 索引范围扫描

修复效果：

50万的采购单，撤回了。

二、为什么50万的决策差点做错？——DG4需求决策四问

这个案例最值得反思的不是技术问题，而是决策问题。

在厂商给出50万方案的时候，没有人问过四个最基本的问题。我在20年医院IT实战中，把这四个问题总结为DG4 需求决策四问——DG Framework的第一核心工具。

2.1 第1问：为什么要做？（业务驱动力）

IT项目先要有业务驱动力，才有存在价值。厂商主推的、领导拍脑袋的，都不算驱动力。

本案分析：系统变慢，但不是每天卡，高峰才出现，没有评级或政策压力。驱动力评分——3分（低）。

2.2 第2问：谁来用？（用户规模与场景）

本案分析：HIS是全院使用，门诊+住院+急诊，几千人并发。使用面广，评分——5分（高）。

2.3 第3问：不做有什么影响？（风险与代价）

本案分析：系统慢但能跑，没有停摆风险，不影响接诊。不做的代价——3分（低）。

2.4 第4问：怎么算成功？（可量化标准）

本案分析：只有一个目标——"提升体验"。不量化、不可验收。评分——3分（低）。

2.5 四问总分 → 立项结论

本案总分：3+5+3+3 = 14分 → 暂缓。

四问一算，答案很清楚：这个50万的项目，根本不该立项。

三、问题到底在哪一层？——DG-5五层定位法

四问回答了"该不该做"，但还需要回答"问题在哪"。

很多IT团队的通病是：问题混在一起讨论，CPU、网络、数据库、应用一起猜，最后谁声音大听谁的。

DG-5五层定位法的核心思想是：先落层，再分析。问题在哪层，方案就在哪层。

3.1 五层模型

┌─────────────────────────────────────────┐ │ L1 业务连续性 │ 接诊流程、业务影响面 │ ├─────────────────────────────────────────┤ │ L2 业务系统 │ HIS模块配置、接口调用 │ ├─────────────────────────────────────────┤ │ L3 数据库 │ Oracle等待事件、SQL计划 │ ← 本案根因 ├─────────────────────────────────────────┤ │ L4 虚拟化 │ ESXi主机、vSAN集群 │ ├─────────────────────────────────────────┤ │ L5 基础设施 │ 服务器CPU/内存/磁盘健康 │ └─────────────────────────────────────────┘

3.2 本案逐层排查过程

L5 基础设施层：

# 检查服务器硬件健康 ipmitool sensor | grep -i "temp\|fan\|voltage" # 结果：所有传感器正常，无告警 # 检查磁盘SMART状态 smartctl -a /dev/sda | grep -i "health\|error" # 结果：SMART Health Status: PASSED

L4 虚拟化层：

# ESXi主机CPU Ready Time esxtop # 按c，查看%RDY（应<5%） # 结果：%RDY平均1.2%，正常 # vSAN健康检查 esxcli vsan health cluster list # 结果：所有组件健康，无降级

L3 数据库层（根因所在）：

-- 查看Top等待事件 SELECT event, total_waits, time_waited/100 as time_sec FROM v$system_event WHERE event NOT LIKE 'SQL*Net%' AND event NOT LIKE 'rdbms ipc%' ORDER BY time_waited DESC FETCH FIRST 10 ROWS ONLY; -- 查看当前活跃会话的等待 SELECT sid, event, state, seconds_in_wait, sql_id FROM v$session WHERE status = 'ACTIVE' AND wait_class != 'Idle' ORDER BY seconds_in_wait DESC; -- 找到问题SQL后，查看执行计划 SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('问题SQL的sql_id', 0, 'ALL'));

L2 业务系统层：HIS模块配置正常，接口调用无超时。

L1 业务连续性层：门诊接诊流程受影响，高峰期排队严重——这是症状，不是根因。

3.3 定位结论

问题明确落在L3 数据库层。根因是一条核心SQL的执行计划偏差，原因是统计信息3个月未更新。

不需要加CPU，不需要扩内存，不需要换存储，不需要花一分钱。

四、DG Framework完整决策流水线

上面的案例展示了DG Framework的两个核心工具。完整的DG Framework包含六大工具，形成一条决策流水线：

需求决策 → 问题定位 → 风险检查 → 演进规划 → 执行落地 → 经验沉淀 DG4 DG-5 DG Check EVO ACT INS

4.1 本案的完整DG闭环

DG4（该不该做？）→ 四问总分14分，暂缓，不立项。

DG-5（问题在哪？）→ L3数据库层，SQL执行计划偏差。

DG Check（方案能不能上？）→ 不需要上方案，优化即可。

DG Action（怎么做？）→ 更新统计信息 + 加复合索引。

DG Insight（学到了什么？）→

DGI-2026-001：90%的"性能问题"不是资源问题，而是执行计划问题。在讨论硬件升级之前，先看完AWR报告的Top 5 Timed Events。

五、跨行业验证：同样的陷阱，不同的行业

这个"跳过定位直接上方案"的陷阱，不只存在于医院IT。

5.1 制造业ERP卡顿

某汽车零部件厂的SAP ERP系统卡顿，IT部门要换全闪存储，预算80万。

排查后发现：ABAP代码中一个报表查询用了嵌套循环，数据量从10万涨到500万后性能崩塌。优化ABAP代码，0元解决。

5.2 金融交易系统抖动

某证券公司的交易系统间歇性抖动，运维要加网络带宽，预算30万。

排查后发现：中间件的JDBC连接池maxActive设成了50，高峰期并发200+，大量请求排队等待。调大连接池到200，0元解决。

5.3 共性规律

所有行业的IT问题，都有同一个模式：

1. DBA说："不是数据库的问题。"
2. 运维说："不是服务器的问题。"
3. 网络说："不是网络的问题。"
4. 厂商说："建议升级。"

所有人都"没问题"，但系统就是有问题。

根本原因不是技术不行，而是没有统一的定位标准。每个人用自己的视角解释世界，结果就是问题被无限拉扯，而不是收敛。

DG Framework要解决的不是技术问题，而是判断权的问题——谁有资格定义"问题是什么"。

六、董工建议：三条可以直接用的原则

原则一：先定位，再讨论方案。

不要一上来就比方案、比报价。先用五层定位法（L5基础设施→L4虚拟化→L3数据库→L2应用→L1业务），搞清楚问题在哪一层。

原则二：立项之前，先回答DG4四问。

为什么要做？谁来用？不做有什么影响？怎么算成功？四个问题答不上来，就不该立项。

原则三：用数据说话，不用感觉。

"系统慢了"——慢多少？CPU多少？IO多少？等待事件是什么？有数据，才能做判断。没数据，就只能靠厂商推荐。

七、与传统决策方式对比

八、写在最后

做了20年IT基础设施，从Oracle RAC集群瘫痪到HIS全院卡顿，从vSAN间歇性IO抖动到超融合采购被厂商牵着走——我见过50多家医院的IT故障，一个最深的体会是：

医院IT最大的浪费，从来不是预算超了，而是没回答"DG4四问"就立了项。

技术方案会过时，Oracle可能会被替换，VMware可能会被替代，但"先判断、再定位、再决策、再复盘"这个逻辑，永远不过时。

关注【董工IT急诊室】，回复以下关键词领取资料：

• 回复"DG"→ 《DG4需求决策评估表》（A4单页，打印带着去开会）
• 回复"CHECK"→ 《DG Check巡检评分卡》（一套标准评估自己的系统）
• 回复"CASE"→ 《医院IT十大DG案例分析》

DG Framework — Hospital IT Decision Governance董工IT急诊室 · 2026