HIT专家网
来源：HIT专家网 供稿：达梦数据
【编者按】
由HIT专家网联合达梦数据发布的《医疗信创 100 问》（数据库篇）开启内容连载，欢迎读者朋友关注！本期内容为《医疗信创 100 问》（数据库篇）的“读者问答”篇（下篇）。
为聚焦国产数据库落地关键痛点，贴合医院信息科实际工作关切，提升专题实用性与指导性，HIT专家网通过问卷调研，重点面向医疗信息化从业人员征集其关心的问题，并特别邀请本期专辑联席主编厦门大学附属成功医院信息科原主任、正高级工程师王继伟，中部战区总医院信息科主任夏慧与达梦数据库技术专家，分别对相关问题进行解答。
本次调研共覆盖26家医院，回收有效问卷116份，经筛选整理出最具代表性的29个问题（参见附表）。鉴于本专题由达梦数据提供技术支持，部分答案仅以达梦产品为例进行说明，谨供读者参考。
相信随着医疗领域国产升级实践的持续开展，医疗行业对于国产数据库应用的认识将不断深化。欢迎业界踊跃提问，我们将继续组织相关专家共同探讨（邮箱：gong_chen@HIT180.com）。
此篇为“读者问答”（下篇），中篇与上篇请见文末链接。
国产数据库的生态工具与适配场景已具备支撑医疗行业核心业务生产运行的能力，且正处于从“可用”向“好用”快速演进的关键阶段。
在生态工具链方面，国产数据库已提供相对完善的解决方案：数据迁移工具能有效应对从国外数据库向国产数据库平滑过渡的挑战；高可用与容灾工具满足HIS等核心业务对7×24小时连续性的严苛要求；智能运维监控平台则帮助医院信息科降低异构数据库环境下的管理门槛。同时，分布式、云原生及数据库一体机等产品形态，也较好地匹配了互联网医院高并发、PACS海量影像数据存储等不同医疗场景的架构需求。
在生态适配场景方面，主流国产数据库已与国产芯片、操作系统、中间件完成了基础软硬件的深度适配。尤为关键的是，在与核心医疗ISV的协同上，双方已打通HIS、EMR等核心系统的兼容性壁垒，在三甲医院和区域医疗平台积累了丰富的落地案例。
作为技术从业者，我们也需客观看待：目前部分复杂医疗场景下的性能调优、历史遗留复杂SQL的改造，以及与医疗ISV应用底层的深度联合优化仍在持续打磨中。但整体而言，国产数据库在医疗行业的全栈落地生态已基本成型，具备较强的实际生产支撑能力。
（达梦数据库专家）
建议医院从以下十个维度建立评估框架，逐项打分后综合对比各家产品：
（1）内核自主度：是否具备内核级自主研发能力，是否通过国家安全可靠测评（查询网址：https://www.itsec.gov.cn/）。
（2）Oracle兼容性：PL/SQL语法兼容率、存储过程可迁移比例、数据类型兼容度（建议进行自有系统PoC测试）。
（3）医疗落地案例：是否有与本院规模相当的医院核心HIS稳定运行案例，建议实地考察并索取性能数据。
（4）HIS厂商适配：主流HIS厂商是否已完成适配认证，适配版本号和互认证报告是否可查。
（5）高可用能力：共享存储集群（多活）、数据守护（主备容灾）的RPO/RTO实测指标。
（6）安全合规：国密算法支持（SM2/SM3/SM4）、等保三级、TDE透明数据加密。
（7）原厂服务：本地化服务团队规模、SLA响应时效、驻场支持能力。
（8）生态工具链：迁移评估工具、数据校验工具、监控运维平台的完善程度。
（9）成本合理性：授权费用+年度维保+实施服务的TCO（建议做5年总拥有成本测算）。
（10）持续迭代：数据库企业的研发投入规模、版本迭代频率、产品路线图清晰度。
建议医院在选型阶段，按照上述维度编制评估打分表，邀请候选厂商逐一回应，并结合PoC测试结果综合决策。
（夏慧）
23. 数据库迁移完成后，每年的运维成本是多少？与原Oracle维保相比是升是降？
迁移后的年度运维成本主要包括以下几部分：
（1）数据库年度维保：通常为授权费用的15%—20%/年，包含基础技术支持和版本升级。
（2）原厂高级服务（可选）：如需7×24小时驻场或专属SLA（服务水平协议），需额外采购服务包。
（3）人员培训成本：运维团队的国产数据库培训认证费用（通常为一次性投入，首年较高）。
（4）工具平台费用：监控运维平台的授权或订阅费用（部分厂商含在维保中）。
（5）数据库维保：Oracle年度维保通常为初始授权费用的22%，国产数据库年度维保通常为初始授权费用的15%—20%。
综合来看，国产数据库的年度运维成本通常低于原Oracle维保费用，但初期培训和学习成本较高。建议医院在制订国产升级预算规划时，编制5年TCO（总拥有成本）测算表，将授权费、维保费、培训费、硬件更新等纳入全周期考量。
（达梦数据库专家）
24. 国产数据库迁移通常需要多长时间？不同规模医院的典型工期如何估算？
国产数据库迁移的工期因医院规模、系统复杂度和迁移策略而异。以下为基于已有项目经验的典型工期参考（含评估、适配、测试、割接全流程）：
小型专科医院（床位<300张，系统数量<20个）
典型工期：4—8个月
关键节点：评估1个月→ 适配改造2—3个月→ 联调测试1—2个月→ 割接上线（1—2天窗口）
参考案例：部分口腔、眼科专科医院已实现快速迁移
中型三甲医院（床位500—1500张，系统30—60个）
典型工期：8—14个月
关键节点：评估2个月→ 适配改造3—5个月→ 联调测试2—3个月→ 多轮割接演练1—2个月→ 割接上线
典型工期：厦门大学附属成功医院（1080张床位、89个系统，从整体评估到全栈应用约14个月）
大型医疗集团（床位>2000张，系统数量>60个，多院区）
典型工期：12—18个月
典型工期：评估2—3个月→ 适配改造4—6个月→ 联调测试3—4个月→ 试点先行验证→ 分批推广→ 全面上线
典型工期：福州市第一总医院（5家医院、8大院区、60余套系统，系统切换耗时约2个月）
影响工期的关键变量包括：
（1）源数据库类型：Oracle迁移通常比SQL Server/MySQL快，因兼容度更高。
（2）应用系统是否同期升级：若应用软件同步升级，工期会相应延长。
（3）HIS厂商配合度：厂商投入的开发资源和响应速度直接影响适配改造周期。
（4）数据量：历史数据量越大，迁移和数据校验耗时越长。
建议医院在项目启动阶段即制定全流程甘特图，明确各里程碑节点和交付物，预留20%的缓冲时间以应对意外情况。
（达梦数据库专家）
25. 数据库割接失败如何回退？数据会丢失吗？回退窗口多长？
这是医院信息科最核心的关切之一。割接回退方案必须在项目启动阶段就完成设计，而非割接前临时准备。以下为经过医疗行业实战验证的回退保障体系：
第一层：双轨并行机制
在正式割接前，源数据库（如Oracle）与目标数据库（达梦）至少并行运行4—8周。其间通过数据实时同步工具（如达梦DMDRS）实现双向或单向同步，确保两套环境数据一致。这相当于在割接前就已经有了一份“热备份”。
第二层：数据双写机制
割接过程中，业务数据同时写入达梦数据库和备用Oracle环境。一旦发现达梦环境出现不可接受的性能波动或数据异常，可在预定时间内回退到Oracle环境。福州市第一总医院在割接期间采用了“达梦+Oracle双写”和“Oracle备用环境双轨并行”两套机制，形成了最后一道安全闸门。
第三层：回退窗口与数据保障
回退窗口：典型割接方案中预留3个回退决策点——割接前30分钟（确认状态）、切换完成后5分钟（观察期）、上线后24小时（持续监测期）。割接后24小时内一旦触发回退条件，可在5—15分钟内完成回切（具体取决于数据量和网络条件）。
数据保障：由于采用了双写+实时同步，回退时源端Oracle保留了完整的最新数据，不会出现数据丢失。回退后仅需恢复网络指向和DNS解析，业务几乎无感知。
第四层：应急响应机制
若超过24小时后出现问题，启动数据库层面的应急处理（如内核修复、参数调优），而非直接回退。达梦在福州市第一总医院项目中，48小时内完成内核级适配修复的实例证明，多数问题可在不触发完整回退的情况下解决。
【为什么一般不轻易回退】
回退本身也有成本和风险：应用需要重新指向原数据库、已同步的数据需要校验、业务中断窗口可能延长。因此，我们的策略是“以不回退为目标，以能回退为底线”，也即做好万全准备来确保割接成功，但同时保留随时回退的能力。
（达梦数据库专家）
26. 国产数据库的授权模式有哪些？如何选择最经济的采购方案？
当前主流国产数据库的授权模式主要包括以下几种，医院可根据自身规模和预算特点选择。
（1）按CPU核数授权
适用场景：明确知道所需计算能力的医院，一般为中小型部署。
计费方式：按服务器CPU物理核数计算，通常设有最低起购核数。
优势：费用与性能直接挂钩，避免资源浪费。
注意：需区分“物理核”与“逻辑核”（超线程），合同签订前需明确。
（2）场地授权（Site License）
适用场景：大型医疗集团、多院区统一采购。
计费方式：一次性支付固定费用，授权覆盖医疗机构全部院区和指定数量的数据库实例。
优势：多院区场景下单位成本最优，运维管理统一。
参考价格：三级医院场地授权通常在100万元—300万元（一次性，受具体部署规模和产品选型影响）。
（3）订阅制（年度付费）
适用场景：初期试点、预算有限、希望灵活调整的医院。
计费方式：按年付费，通常包含软件授权+基础技术支持。
优势：初期投入低，可灵活扩缩，风险是长期累计成本可能高于一次性采购。
（4）与硬件捆绑的一体机授权
适用场景：超大型三甲医院、对性能有极致要求的场景。
计费方式：软硬件捆绑报价。
优势：预装预调优，开箱即用；总成本通常高于纯软件方案。
【国产数据库的授权模式选型建议】
单体三甲医院：建议优先选择按核数授权，业务稳定后评估是否需要场地授权。
多院区医疗集团：场地授权通常是最经济的选择。
专科医院/县级医院：可考虑订阅制起步，后续根据使用情况调整。
注意：无论哪种模式，合同签订时建议争取包含至少1年的原厂技术支持服务。
（达梦数据库专家）
27. 国产数据库的数据备份和灾难恢复方案，与传统Oracle架构有什么不同？
以达梦为例，达梦数据库DM8在备份与灾难恢复的能力维度上，已可逐项对标Oracle。达梦以DMDSC（高可用）+数据守护（容灾）+ dmrman/dexp（备份）的组合，完整对应Oracle的RAC + Data Guard + RMAN（表1），可支撑相同等级的容灾架构（含两地三中心）。
表1
（达梦数据库专家）
28. 医院如何评估自己是否做好了迁移准备？请列举一份割接前自检清单。
数据库迁移不是“准备好了再开始”，而是“边准备边推进，以清单确保不漏项”。以下自检清单已在多个项目中验证有效，建议信息科在割接前逐项确认。
【技术准备】（7项）
是否完成全部存储过程的兼容性扫描，标记需手动修改的部分，并完成修改和测试
是否在镜像环境中完成至少两轮全量业务压测，压测覆盖了高峰时段的TPS/QPS
性能压测结果是否达到预期指标（建议：核心HIS事务响应时间与迁移前差距<10%）
是否完成数据迁移的全链路校验（迁移前+迁移中+迁移后+运行中四步闭环）
是否与HIS厂商确认割接期间的技术支持人员排班，是否有备用联系方案
是否完成至少1次全流程割接演练（含回退演练），总耗时与预期是否一致
是否验证备份恢复流程，恢复时间是否符合RTO要求
【业务准备】（5项）
是否与医务科、护理部、药房等关键科室沟通割接窗口，是否选定对业务影响最小的时段（建议周六夜间）
是否制定割接期间的手工应急方案（如手工挂号、手工发药流程），相关人员是否已培训
是否提前通知医保接口、电子健康卡等外部系统的对接方
是否安排割接后72小时的业务密集观察期，是否安排信息科和HIS厂商人员值守
是否在割接前完成关键数据的离线备份（作为最后一道防线）
【组织准备】（3项）
是否成立割接指挥部，明确总指挥、技术负责人、业务协调人的职责
是否制定割接runbook，每个步骤标注负责人、预计耗时、回退触发条件
是否进行割接前的全员动员和分工确认，每个人都清楚自己的职责和时间节点
【一个简单的“绿灯测试”】
如果以下三个问题答案都为“是”，说明医院基本做好了迁移准备：
镜像环境中的业务压测通过率>95%
至少进行过1次完整的割接+回退全流程演练
数据库厂商和HIS厂商都已派人在割接现场待命
（夏慧）
29. 国产数据库迁移后如果性能不达标，谁负责优化？厂商与医院的责任边界在哪里？
这是一个非常现实的问题。根据行业实践，建议在合同中明确以下责任划分：
（1）厂商责任（厂商应免费解决）
·数据库内核Bug导致的性能问题
·数据库默认参数配置不当（如连接池大小、缓存配置）
·存储过程兼容性问题
·驱动层或适配层的性能瓶颈
·厂商提供的迁移方案中的技术缺陷
·性能问题（约定验收标准，如核心HIS挂号业务的P99响应时间不超过迁移前水平的110%）：
P1（核心业务严重卡顿）→ 4小时内提供解决方案
P2（非核心模块性能下降但可降级运行）→ 24小时内提供解决方案
（2）医院责任（医院自行承担或另行采购服务）
·应用层SQL优化（开发商在HIS中编写了低效SQL，需由HIS厂商修改代码）
·硬件资源配置不足（如CPU核心数、内存容量、存储I/O未按建议配置）
·运维层面的参数持续调优（日常运维中的监控和微调）
（3）灰色地带——最容易产生争议的部分
·“慢查询本来就有，迁移后暴露了”：建议在迁移前对Oracle环境的慢查询进行摸底，建立基线，迁移后只比对这个基线。
【问题解决路径】
如果上线后遇到性能问题，建议按以下顺序排查：
先确认硬件资源是否达标（CPU/内存/IO利用率）
排查数据库参数配置是否最优（可请达梦原厂协助）
分析慢SQL执行计划，优化索引或SQL
如确认是数据库内核问题，由原厂提交修复补丁
以上均无效时，考虑架构调整（如引入读写分离、增加节点）
1.哪些是国产数据库？到哪里查询？
2.医院如何根据自身业务规模（门诊量、床位、系统复杂度）选择合适的数据库？
3.缺少第三方专业咨询，医院如何制定数据库国产升级实施计划与落地方案？
4.原使用Oracle数据库的三甲医院，哪些国产数据库可最小改动以实现便捷迁移？
5.已适配某一款国产数据库的业务系统，再换另一款同类数据库，工作量是否依然很大？
6.国产升级项目资金压力大，医院如何解决资金难题？
7.相比传统医疗信息化项目，国产升级项目的整体投入需增加多少？
8.医疗国产数据库如何衡量性价比？如何兼顾成本与长期投资价值？
9.从Oracle/MySQL/SQL Server迁移到国产数据库，性能差异有多大？并发、稳定性对比如何？
10.国产数据库是否支持系统函数、自定义函数、存储过程、定时任务？
11.在数据库国产升级改造中，使用读写分离会带来哪些新问题？如何解决？
12.使用国产数据库后，大型三甲医院核心系统如何实现高并发、高可用、高可靠？
13.除合理选型外，还有哪些必要的工作需要提前规划设计，才能平稳完成从传统数据库到国产数据库的过渡？
14.迁移中因数据类型、字符集不兼容导致数据丢失或损坏问题，应如何建立全链路数据校验？
15.国产数据库在服务器、操作系统层面如何调优，以支撑高并发？
16.测试环境授权受限、无免费方案，如何安全测试与应急切换？
17.国产数据库在运维、安全方面有哪些痛点？
18.如何处理死锁？有无可视化监控与处理工具？
19.医院如何建立保障体系？在性能、故障、安全方面的可观测性与监控指标如何建设？
20.国产数据库的持续可用性如何保证？出问题是否只能依赖厂商？
21.国产数据库的生态工具、生态适配场景是否完善？
22.医院在选型国产数据库时，应该从哪些维度进行评估？
23.数据库迁移完成后，每年的运维成本是多少？与原Oracle维保相比是升是降？
24.国产数据库迁移通常需要多长时间？不同规模医院的典型工期如何估算？
25.数据库割接失败如何回退？数据会丢失吗？回退窗口多长？
26.国产数据库的授权模式有哪些？如何选择最经济的采购方案？
27.国产数据库的数据备份和灾难恢复方案，与传统Oracle架构有什么不同？
28.医院如何评估自己是否做好了迁移准备？请列举一份割接前自检清单。
29.国产数据库迁移后如果性能不达标，谁负责优化？厂商与医院的责任边界在哪里？
【《医疗信创100问》（数据库篇）电子版开放申领】
HIT专家网从9月开始陆续刊载专辑核心内容，以飨读者。同时，《医疗信创100问》（数据库篇）电子版正式开放申领，有需要的读者朋友可填写以下问卷索取，我们将在收到问卷的一周内发送电子版。
如您未在一周内成功收到邮件，请联系HIT专家网内容服务部，电话：010-82373062。
【往期回顾】
精彩不容错过！
我们将尽快与您联系！
【责任编辑：陈曦 版式：明超】
评论前必须登录！
注册