1  HIS系统数据迁移背景

HIS承载了医院挂号、收费等核心业务 ，其稳定、高效运转，对保障医疗质量，提升工作效率具有重要作用。很多早期建设的HIS，其设备可靠性、数据库性能等方面都已经到了支撑的极限，存在很大的宕机风险。但HIS往往与医院业务高度契合，直接更换系统会带来很大风险。因此保留HIS的功能不变，对数据库平台进行升级能快速解决性能和设备问题，降低系统更换风险，是较好的解决思路。但是出于HIS的重要性和对历史数据能否可靠、高效迁移的担忧，使得很多医院迟迟不敢决策，导致信息化建设出现瓶颈。

中山大学附属肿瘤医院也面临了相同的问题，现有HIS服务器已经运行8年多，设备老化严重，性能严重不足。现有DB2数据库和设备硬件已无法满足医院信息化建设的需要。为了保证医院系统的稳定性和效率，夯实医院未来信息化建设基础，医院要针对目前数据库进行升级，转为医疗行业更多厂商支持的、主流的oracle数据库。医院期望能够通过本项目彻底改善系统效率及稳定性方面的问题，为后续的信息化发展打下良好基础。

2  数据迁移的整体要求

对于HIS的跨平台迁移，医院最担心的问题就是数据库切换时发生宕机，或者各种问题导致的数据丢失，财务账目数据不平等灾难性[4]问题。中山大学附属肿瘤医院数据迁移经过反复的测试和论证，全面分析了整个升级过程的风险和难点，逐一做好应对措施和解决方案：通过多次迁移测试和核对，确保数据的一致性和完整性，制定数据不一致的应急方案；通过多次迁移方案对比和调优，确保切换过程的快速完成，为后续功能验证、接口测试预留充足时间；通过多次测试和演练，制定各种回退方案，确保升级过程平稳、风险可控。

3  技术难点和风险分析

本次迁移的数据库表有1200张，数据量为600G。数据类型基本覆盖关系数据库常见的各种类型，以及clob，blob等超大字段；数据库迁移还涉及普通视图、嵌套视图、物化视图、函数、存储过程、索引、触发器、序列等多种数据库对象和数百个系统接口；另外，oracle与DB2架构和技术也存在很多差异。这些原因导致本次跨平台的数据迁移存在着两方面的困难： HIS本身的复杂度引起的业务逻辑处理困难。不同数据库的技术差异导致的技术困难。在项目的实施过程中，经过多次测试和攻关，逐一克服了这些难点，主要经验总结如下。

3.1 关注异构平台技术差异，确保数据一致性 AIX操作系统和DB2数据库平台与LINIX操作系统ORACLE数据平台之间有很多技术差异，其中需要特别注意的技术问题包括以下几点。

3.1.1 磁盘空间的管理和划分 DB2和oracle数据库的磁盘管理策略、代码页分配等都不完全相同，需要提前测试评估迁移后的磁盘空间和管理策略，确保磁盘空间合理分配。

3.1.2 数据表列类型定义的映射 DB2和ORACLE数据库的列类型不同，因此需要对两个数据库的表的列类型逐一映射。

3.1.3 非空字段判定 DB2运行在非空约束中插入空字符串，且大量存在业务表中，但Oracle不允许此类数据存在。需要在转换过程中根据业务逻辑处理非空约束的字符串，例如根据业务数据，补充相应数据缺失项；无法确定的数据插入空格代替；添加默认值；剔除非空约束等。

3.1.4 数据库对象长度不同 在用DB2数据库存在较多超长的数据库对象名，但Oracle最多支持30个字符。需要根据业务规则，缩减表名长度，并结合应用程序进行调整。

3.1.5 关键字和保留字不同 DB2中部分列名为ORACLE关键字，如LEVER,ROWID等。在生成建表脚本时，需要通过添加引号强制建表；导入数据时，对关键字段添加标识（如_temp），并做好与源表的对应关系，待数据导入完成后再调整回来。另外，对于系统保留字段，如“ROWID”则只能通过调整字段名称调整。

3.1.6 自增列的迁移 DB2存在自增列，ORALE没有相关匹配。可以通过触发器和序列来实现自增列的效果。

3.1.7 存储过程、函数、触发器、序列等数据库对象 DB2与ORACLE的SQL语法不同，存在不同的内置函数，因此存储过程、函数、触发器、序列等都需要按照Oracle的语法重新编码、编译和测试，以确保功能正常。其中序列的迁移要特别注意初始值、最大值的设定，避免出现重复值等问题。关于序列的迁移，可采用批量生成Oracle建立序列脚本的方法处理，例如通过value(s.LASTASSIGNEDVAL,0) + s.CACHE处理序列当前值。

3.1.8 迁移后的性能调优 DB2与ORACLE的执行计划、统计信息收集规则、索引执行顺序不全相同。数据迁移后，需要重建索引，并对重要业务流程语句逐个检查访问计划和测试性能，以避免性能问题。

3.2 注重风险控制，确保迁移顺利实施 HIS包括挂号、缴费等保障医院正常运行的重要功能，电子病历、LIS、PACS等临床信息系统也均与其密切相关[8-9]，是医院运营的核心。因此提前识别项目风险并做到有效应对是本项目实施的重要内容。本项目的风险控制措施经验主要包括：①多次、多阶段测试确保迁移技术方案可行；②多途径、多层面检查数据，确保数据一致性；③加强与项目经理协商，提前安排，必要时协调相关高层资源，确保人员到位，职责分明；④准备好备用服务器、存储等硬件资源，准备好动态增加服务器硬件配置的技术方案，应对性能问题；⑤建立可靠多通道电力线路，保障切换期间电力供应通畅；⑥建立和测试回退机制，应对系统升级失败；⑦做好相关人员安排，协调数据库维护公司、与HIS有接口调用等相关公司人员提前测试，迁移期间现场全天候支持等。

3.3 强调迁移效率，减少对业务影响 HIS需要尽可能不间断运行，迁移后也需要预留足够的时间进行性能调优、第三方系统接口测试和异常问题处理。因此，预留给HIS系统的迁移维护窗口期很短。而HIS数据库一般都比较庞大（例如本次迁移的数据库在600Ｇ左右），需要多方面寻找更高效的解决方案。本次迁移主要从技术和业务两方面需求更快的迁移方案。

3.3.1 测试不同迁移技术方案，寻找最快、最准确的方案 在测试阶段，项目组主要对比了利用脚本半自动迁移和利用Data Exchange工具全自动迁移两种方案。迁移时间对比如表1所示，迁移后数据一致性如表2所示。结果表明，Data Exchange迁移工具在并发性能、数据准确性、一致性方面的处理更优。另外，Data Exchange能够自动处理Clob,Blob字段，能够自动进行列类型匹配，比手工半自动脚本处理更全面、更智能化。

  表1 手工脚本和Data Exchange工具迁移耗时对比

表2 手工脚本和Data Exchange工具迁移后数据一致性对比

3.3.2 寻找数据的业务特征，提前迁移固化的历史数据 尽管采用Data Exchange工具显著提升了迁移速度，但是将近7个小时的迁移时间还是不能满足医院的要求。项目组从业务逻辑出发，对业务数据进行了详细分析，发现最影响数据迁移速度的包括费用、药品、医嘱、日志等明细数据和患者图像等对象数据。从业务角度看，这些数据都不再变动，也不能再变动。因此项目组采取分阶段迁移策略，在正式停机迁移前先识别和迁移大批量的、固化的历史数据，迁移成功后删除这部分数据对正式库进行收缩；然后在正式停机维护期整体迁移收缩后的数据库。经过收缩，使用Data Exchange对数据迁移的时间控制在1个小时以内，重建索引、约束等耗时2个小时，整体迁移时间控制在3个小时以内。通过技术和业务的结合，大大缩短了迁移时间，最大限度降低了HIS中断导致的业务停顿影响。

4  结语

异构数据库之间的迁移切换，会面临很多难以预测的风险，影响整个迁移过程，甚至导致迁移失败。本次升级的过程中，结合业务逻辑和选用合适的数据库迁移工具，将迁移时间从18个小时降低为3个小时，最大程度降低了数据库迁移对业务开展的影响，发挥了关键性作用。另外，风险控制措施也起到了重要作用，从人员、管理、应急等多方面保障了项目的正常开展。从本次升级的经验看，在开展HIS数据库迁移时，需要综合考虑风险控制、技术方案和业务影响，持续优化升级方案才能取得更好的效果。

（来源：节选自《中国数字医学》杂志2016年第8期  作者及单位：李超峰 马嘉潜 中山大学附属肿瘤医院信息科）