医院 HIS 数据库损坏，正确顺序是先停写入保住现场，再判断是硬件故障还是逻辑损坏，最后才修，业务同步降级。

医院数据库报错之后，为什么第一步是停下来而不是修

因为损坏的判定需要原始现场，而绝大多数「先修一下试试」的操作都会覆盖掉判断依据。数据库文件出现坏页时，SQL Server 仍然可能正常启动，只是查询到某个区间才报错，这种状态下继续让业务写入，新事务会落在坏页附近，页分裂和日志增长会进一步扩散污染范围。停下来的目的是把「哪一页坏了」这个事实固定住。

要停的具体动作有四个：先通知业务侧停止录入，把挂号收费切到纸质流程；再停掉数据库服务，避免后台作业继续扫表；然后断开这台服务器与备份服务器的连接，防止损坏的库被正常备份覆盖掉历史好副本；最后把服务器、存储、备份介质逐一登记，记录发现时间和原始状态。这四步做完，才算具备后续判断的条件。

反过来，有四类操作在损坏现场绝对不能做：不要重装数据库再重新附加，附加过程中的日志重建会改写文件头；不要对故障盘做磁盘检查或碎片整理，写操作会让坏道扩散；不要用可疑的第三方修复工具在线修，多数工具会直接改写原文件；不要反复重启试图「重启就好了」，每次重启都会重放日志，坏页位置可能变化。原件只有一份，任何写操作都不可逆。

怎么用报错码判断是硬件故障还是数据库逻辑损坏

判断依据是报错码的归属，而不是错误提示的中文描述。SQL Server 的报错分两类：一类指向存储层，典型是 823（执行 I/O 操作时发生操作系统错误）、5120 与 5121（文件或页无法读取、介质只读），这类错误的本质是磁盘读不出来；另一类指向页结构，典型是 824（逻辑一致性错误，页校验和不匹配）、8909（页校验和失败）、8928 与 8939（CHECKDB 发现一致性错误），这类错误说明磁盘读得出来，但页内数据自相矛盾。

这两类的处置方向完全不同。823 与 5120 要先转到硬件层，检查阵列是否有掉盘、坏道是否成片、RAID 是否处于降级状态，此时继续在数据库层修是徒劳的，因为读都读不出来。824 与 8909 才是数据库层的活，需要定位是聚簇索引页、非聚簇索引页还是分配页损坏，索引页损坏的数据往往还在，重建索引即可恢复；数据页损坏才会真正丢行。

第三类容易误判的是日志异常。附加数据库时报 9003 或 1813，本质是日志文件缺失或被截断，数据文件本身可能是完好的。这类情况不必重整库，先确认能否只读挂载、能否从文件层直接提取表数据，比重建日志安全。Oracle 的对应信号是 ORA-01578 数据块损坏，可用 RMAN 做块级恢复，前提是有完整备份链。

EMERGENCY 模式到底能抢回多少数据

EMERGENCY 模式解决的是「库能不能挂上」，不解决「数据是否完整」，这两件事必须分开看。执行 ALTER DATABASE 将库置为 EMERGENCY 之后，数据库变为只读、只有 sysadmin 能访问，即使日志文件不可用也允许访问，这是它唯一的作用。也就是说，它让一个原本无法打开的库变得可读，让管理员有机会把还能读出来的表导走。

抢数据的正确做法是「先导出、后修复」，而不是反过来。在 EMERGENCY 模式下先做一次完整的数据导出：把关键业务表按表逐个 SELECT 到新库或平面文件，一边导出一边记录哪些表报错、报错在第几页。导出的目的是保住已经确认可读的部分，而不是试图修好原库。等到可读数据全部落地，再考虑对原库执行 DBCC CHECKDB 的修复选项，顺序是先 REPAIR_REBUILD 重建索引，实在不行才用 REPAIR_ALLOW_DATA_LOSS，后者会删掉坏页上的行来换取库可用。

能抢回多少取决于三件事：坏页落在索引页还是数据页、分布集中还是散布、日志是否完整。索引页损坏重建即可，几乎不丢业务行；数据页损坏丢的是页内那几条记录；日志不完整则检查点之后的事务无法重放。任何「固定恢复率」的说法都不成立，比例只能在导出完成后清点得出。若有完整备份链且为企业版，还可对单个坏页做页级还原，可行性取决于现场备份策略。

挂号收费停摆时，业务侧有哪些可用的降级方案

降级方案的核心是把「系统停摆」降级成「效率下降」，而不是让患者卡在窗口。医院 HIS 的模块有明确的优先级：急诊、门诊挂号、门诊收费、住院登记、药房发药这几块直接决定患者能否看上病，统计报表、医保对账、绩效核算可以延后。降级时应当只保留前几块的手工流程，其余模块明确公告暂停。

纸质流程要解决的是唯一标识问题。手工单必须固定一组最小字段：患者姓名、性别、年龄、身份证号或就诊卡号、就诊科室、接诊医生、收费项目、金额、发生时间、经办人签名。其中身份证号或就诊卡号是不可省的，它是系统恢复后补录时去重的唯一依据，缺了它补录时必然产生重号病历和重复收费，事后清理的成本远高于当场多写一行字。

还有两件事容易被忽略。手工单编号必须连续唯一，建议按日期加窗口号加流水号编，纸质单与系统补录记录要能一一对应；检验检查这类有外部接口的业务，接口中断期间出具的报告要有单独登记簿，否则恢复后报告与就诊记录对不上。

和业务科室协同时要固定哪几件事

协同的第一条是信息出口唯一。故障期间必须指定一个人统一对外说明进展和预计时间，其他人不单独承诺时间点。多头表态是医院信息科在故障中最常见的次生问题：临床科室按 A 的说法调整了排班，财务按 B 的说法准备了手工账，最后两套口径对不上，恢复后核算全部要重做。

第二条是操作留痕。从停机开始，对生产服务器的每一次动作都要记录时间、操作人、动作内容和目的，包括只读挂载、复制文件、尝试附加。这份记录在判断损坏是否被二次扩大时是唯一凭据，也是事后复盘和向院方说明责任边界的依据。第三条是科室优先级清单要提前定好并书面确认，不能在故障当天临时讨论，临时排序的结果通常是声音大的科室优先，而不是业务影响大的科室优先。

第四条是数据核对的责任划分。恢复完成后，信息科负责证明「库里有什么」，业务科室负责确认「这些是不是对的」，两边都要签字。核对的重点是三类：门诊量与收费金额的日结是否对得上、住院在院人数与床位占用是否一致、检验检查报告数与申请单数是否匹配。这三组数字对上了，才能说业务真正恢复。

常见问题

医院数据库损坏后，能不能先让系统带病运行到下班再处理

不建议。带病运行期间的新写入会落在损坏区域附近，页分裂会让坏页周边结构一起变化，原本可以整页提取的数据可能变得不可读。更重要的是，只要业务还在写，备份作业就会把损坏状态的数据写进备份介质，几轮之后干净的历史副本被自然覆盖，等于主动放弃了退路。真要撑到下班，至少要先停掉备份作业并做一份离线快照。

没有备份的医院数据库损坏，还有恢复的可能吗

取决于损坏层级。如果是索引页损坏或日志文件缺失，数据文件本身完好，不依赖备份也能把表数据提取出来；如果是磁盘物理坏道成片、文件头被覆盖，或者数据页大范围损坏，没有备份就没有完整的恢复路径，只能按页提取残留记录，取回的内容不保证完整。这种情况下越早停止写入，可提取的比例越高。

数据库修复工具能不能自己下载来用

要区分两类工具。索引重建、一致性检查这类操作是数据库产品自带的功能，属于官方公开能力，可以在确认有完整副本的前提下使用。但市面上宣称能修复任意损坏文件的工具，多数是靠猜测页结构拼接数据，对结构已知的页有效，对头部被覆盖的文件无能为力，而且不少工具会直接以写模式打开原文件。在原件上试用未知工具，风险大于收益。

恢复之后怎么确认数据是真的恢复完整了

做三项校验。第一项是结构校验，对恢复后的库跑一次完整的 CHECKDB，确认没有残留的一致性错误；第二项是业务校验，取故障前最后一个正常日结的业务数字，与恢复后的库逐一比对门诊量、收费金额、在院人数；第三项是连续性校验，检查自增主键与单据号有没有断号、重号，断号说明有记录丢失，重号说明补录时产生了重复。三项都过，才能把系统交回业务侧正常使用。

漳州及闽南地区的医院信息科如果遇到数据库无法打开的情况，可以先停止写入并保留现场，再联系我们评估损坏层级。联系电话 0592-8061158，邮箱 32518962@qq.com。