一、故障现象
周四上午 9 点半，门诊高峰，某三甲医院分院的 HIS 系统陆续有诊室报「挂号信息刷不出来」；后台 SQL Server 错误日志在刷 824 错误（数据页逻辑一致性校验失败）。几乎同时，PACS 系统部分历史影像调不出来，放射科医生对着空白的阅片工作站干着急。信息科测算过：停机维修，意味着当天 3000 多个门诊号源全部受影响------这个代价医院承受不起。
二、为什么不能乱动
数据库页损坏后有三个常见的坑：一是直接跑 DBCC CHECKDB 加 REPAIR_ALLOW_DATA_LOSS，它的「修复」方式是直接丢弃损坏页及上面的数据行------医疗数据丢不起，丢了也不知道丢了哪条；二是反复重启实例尝试联机，每次启动都触发崩溃恢复流程，在损坏页上继续写日志，可能把局部损坏拖成大面积损坏；三是拿上周的全备份直接还原，一周的门急诊数据没了，还覆盖了现有环境，连「回到坏之前」的机会都没有。正确思路是：先固定现场，再按页修补，能无损就不丢一条。
三、规范处置流程
- 应急并行（不停诊前提）：与信息科商定方案------新业务先切到应急库保证门诊照常，修复在后台进行，只占用两个夜间窗口的机房资源。
- 只读镜像：对数据库所在卷做扇区级只读镜像，后续所有分析和修补动作都在镜像副本上进行，原卷封存（只读操作，不改原盘）。
- 页级解析：按 8KB 页结构逐页扫描 1.1TB 数据库文件，定位损坏页 217 页，逐页分类：页头校验失败、撕裂页、槽位错乱。
- 多源修补：为每个损坏页找「健康副本」------来源依次是事务日志（LDF）日志链、前一天差异备份、镜像空闲页中的残留历史版本；实在找不到副本的系统页，按页结构手工重建页头与槽位数组。
- 日志链校验：修补完成后重放日志链，校验 LSN 连续性，确认事务一致性边界；随后 DBCC CHECKDB 全库扫描，零分配错误、零一致性错误。
- 业务验证：挂号、收费、药房发药、医技开单、PACS 影像索引五个模块逐一跑通；抽查 300 条门诊记录与收费汇总对账一致，院方签字确认。
四、量化结果
- 从进场到验证通过共 41 小时，全程不停诊，仅占用两个夜间维护窗口；
- 修复损坏数据页 217 页，涉及门诊记录 120 万+条，零丢失；
- PACS 历史影像索引重建后，前期「调不出」的 4.6 万份影像全部恢复调阅。
五、客户评价
「白天正常看病，夜里修库，早上上班系统是好的。对医院来说，这就是最理想的结果。」------某医院信息科科长（脱敏）
六、同类故障自查建议
- SQL Server 报 824 错误是什么？ 数据页逻辑一致性校验失败，多由磁盘坏道、异常掉电或存储链路问题引起，是物理层损坏的明确信号，应立即停写并镜像。
- 能直接跑 REPAIR_ALLOW_DATA_LOSS 吗？ 不建议作为第一选择。它以丢弃损坏页数据为代价换联机，应先做只读镜像，再尝试页级无损修补。
- PACS 影像调不出来就是影像丢了吗？ 不一定。多数是索引表或文件系统元数据损坏，影像本体还在，修复索引后即可恢复调阅。
- 医院数据恢复怎么保证合规？ 选可签保密协议（NDA）、有 ISO 27001 信息安全管理体系认证、能提供数据销毁证明的服务商，全程只读操作留痕。东方护航 15 年零数据泄露记录，服务由平安保险承保。
东方护航数据恢复（深圳）｜地址：深圳市福田区深南中路3039号国际文化大厦619室｜电话/VX 卡片联系｜官网 dfhkdr.com