1. 摘要

目的：通过详细记录和分析某大型三甲医院将医院信息系统（HIS）数据库服务器从 AIX（advanced interactive executive）小型机迁移至国产x86服务器的过程，为同类医疗机构提供可参考的实践经验。

方法：概述迁移项目的背景与动因，阐述迁移规划与执行过程。

结果： 迁移后系统性能显著提升，数据处理能力增强，运营成本降低，用户体验改善。结论 迁移项目取得了圆满成功，提升了HIS系统性能与效率，为国产化和国家信息技术应用创新（信创）转型提供了实践基础。

医院信息系统（hospital information system，HIS）作为现代医疗机构的核心支撑系统，其性能和可靠性直接影响医疗服务质量和运营效率。随着医疗需求的不断增长和信息技术的快速发展，传统 HIS 系统面临着前所未有的挑战［1］。本文所研究的西北地区某知名三甲医院，根据其门诊管理报表统计，2024年上半年日均门诊量约为17 000人次，较2023年同期增长了6%。面对日益增长的数据处理需求和国家信息技术应用创新（信创）政策的推动，该院决定将HIS系统数据库服务器从AIX（advanced interactive executive）小型机迁移至国产x86架构服务器，以提升系统性能、优化成本结构。本研究旨在通过详细记录和分析迁移过程，为同类医疗机构提供可参考的实践经验。

2. 迁移背景和原因

2.1. 现有系统的局限性

原HIS系统采用两台AIX小型机，运行Oracle 11.2.0.4版本数据库，采用RAC架构。每台小型机配置16核CPU和256 GB内存。通过为期30 d的系统监控，使用Oracle Enterprise Manager和自主开发的监控工具，发现存在以下问题。

1. 性能瓶颈

数据库大小约为14TB（来源于Oracle Enterprise Manager），全量备份平均时间为47.5 h（来源于Oracle Enterprise Manager），日常查询平均响应时间为2.3 s（来源于Oracle AWR报告分析）。

2. 扩展性受限

CPU使用率：工作日9：00—11：00平均为91%（topas监控工具记录）。内存使用率：峰值时段达到95.7%（topas监控工具记录）。

3. 高成本

年度维护费高达145万元（根据维保合同）。由于数据收集的限制，年度电费支出的具体数额暂无法提供准确统计。

2.2. 业务需求的增长

HIS 系统现有8000台终端，高峰期数据库单节点会话数达4300个。根据医院终端增长计划及过去两年的增长趋势，预计数据库会话数将增长25%，数据量每年将增加约3TB。

2.3. 国家信创政策的影响

为响应国家信创战略，医院决定逐步实现核心IT基础设施的国产化替代，提升信息安全水平和自主可控能力［2］。

3. 迁移规划

3.1. 目标和要求

1.性能提升，显著提高数据处理能力和系统响应速度。

2.扩展性增强，支持更多终端接入，满足未来3~5年的业务增长需求。

3.资源效益，降低硬件采购和日常维护成本。

4.国产化推进，选用国产硬件，为后续采用国产数据库奠定基础。

5.业务连续性，确保迁移过程中的数据安全，并将业务中断影响降至最低。

3.2. 硬件平台测试评估

1. 硬件类型

经过深入评估，医院选择了3台浪潮TS860M5国产x86架构服务器作为新的数据库服务器，其主要硬件规格如下。

（1）处理器：8颗高性能CPU，型号为Intel（R）Xeon（R）Platinum 8260 CPU @ 2.40GHz，每个处理器24核，每核2线程，总核心数384。

（2）内存：1 024 GB。

（3）存储：高性能固态硬盘阵列。

虽然该服务器采用了英特尔处理器等国际组件，但作为浪潮公司推出的国产品牌服务器，其设计和制造过程均在中国完成，充分体现了国产厂商在高性能计算领域的技术积累和创新能力。这不仅展示了国内厂商在全球IT产业链中的竞争力，也为国产化替代提供了重要的基础。

值得注意的是，随着国产芯片技术和存储技术的不断进步，医院后期也计划逐步使用全国产服务器作为核心业务的服务器。这一转变不仅能够进一步推动 HIS 的国产化进程，也有助于减少对外部供应链的依赖，从而增强信息技术的自主可控性，提升系统的安全性和稳定性。

2. 测试评估

我们从以下方面对硬件平台进行了基础测试评估。

（1）测试环境。依托选定的硬件架构，搭建测试环境。操作系统：Red Hat Enterprise Linux（RHEL）7.9 x86_64，数据库：Oracle 11.2.0.4，集群软件：Oracle Grid Infrastructure 11 g R2（11.2.0.4）。

（2）数据库基础测试。创建与生产环境相近的测试数据库（约12 TB），执行基础的数据库操作，包括大表全表扫描、批量数据插入、复杂查询执行、数据库会话处理。测试结果见表1。

表1 目标平台数据库基础测试结果

 （3）系统资源监控。使用操作系统自带工具（top、vmstat、iostat）进行监控，使用Oracle AWR报告分析数据库性能。监控结果见表2。

表2 目标平台系统资源监控结果

 （4）评估结果。目标平台测试评估结果见表3。基于评估结果，我们认为目标硬件平台能够满足医院 HIS 系统的性能需求。此外，选择 x86 架构的主要考虑因素包括：

①标准化组件降低了采购和维护成本［3］。

②模块化设计便于未来升级。

③有丰富的软件支持和技术社区。

④现代x86处理器在数据库工作负载上表现优异。

⑤先进的电源管理技术提高了能效。

⑥符合国家信创政策的要求，确保了系统的自主可控性和安全性。

表3 目标平台测试评估结果 

3.3.  迁移软件和迁移方式

通过选用 OGG（Oracle GoldenGate）作为迁移工具，能够以高效且安全的方式完成 HIS 系统数据库服务器的迁移任务，确保数据的实时同步与系统的持续稳定运行。选用 OGG 作为核心数据迁移工具，主要基于以下考虑。

1.高效数据同步：支持大规模数据的实时复制，确保在迁移过程中数据的持续一致性［4-5］。

2.跨平台兼容性：适用于从AIX到x86的异构环境迁移，确保在不同平台之间的平稳过渡［6-7］。

3.最小化停机时间：支持在线迁移，减少对医院正常业务运营的影响，确保业务连续性。

4.数据一致性保障：内置的冲突检测和解决机制，能够在迁移过程中实时监控和处理数据一致性问题。

3.4. 迁移方案设计

1. 迁移时间安排

为最大程度减少对医院日常运营的影响，迁移将分为四个阶段。

（1）数据同步准备阶段：耗时约2周，涵盖系统检查和数据一致性比对。

（2）增量数据同步阶段：耗时约1周，确保实时捕获变更数据。

（3）业务切换阶段：利用医院业务低峰期（通常在夜间或周末），预计在5 h内完成系统切换。

（4）后续调试阶段：迁移后的1~2 d内密切监控系统性能，进行必要的性能优化。

2. 人员分工安排

项目实施过程中，将明确职责分工，确保各部门协调一致。

（1）项目经理：由医院信息部门负责人担任，负责整体项目的协调与进度跟踪，确保各方协同工作，保障迁移的顺利进行。

（2）数据库管理员：负责 Oracle 数据库的配置、迁移以及 OGG 工具的使用。

（3）系统管理员：负责 AIX 和 x86 服务器的硬件和操作系统的环境配置。

（4）网络管理员：确保网络连接的稳定性和数据传输的连续性。

（5）业务部门：由医院业务部门代表和HIS系统软件开发人员担任，确保业务需求在迁移中的及时反馈。

3. 数据同步准备阶段

包括：

（1）环境部署。迁移依托选定的硬件架构，部署流程如图1。在目标 x86 服务器上安装所需的操作系统，安装数据库软件及补丁，部署集群环境，安装迁移工具 OGG 软件，确保新环境配置与原环境相匹配。存储系统基于华为OceanStor v6全闪存储平台，确保读写性能和数据稳定性。

（2）初始数据同步。使用 OGG 的初始数据加载功能，进行全量数据同步。在此过程中，通过 RMAN 工具对源数据库进行全量备份，并将数据迁移至目标平台。在同步完成后，进行数据一致性校验，确保目标数据库与源数据库的完整性和一致性。

注：HIS为医院信息系统；CDP 为临床数据平台；TCP 为传输控制协议；IP 为网际协议；ADG 为主动数据保护

图1 医院信息系统（HIS）网络拓扑图

4. 增量数据同步阶段

在初始数据同步完成后，配置 OGG 进行增量数据同步，捕获在迁移期间的所有变更数据，确保目标数据库实时反映源数据库的最新状态。

设定 OGG 的延迟控制参数，确保数据同步延迟在5s以内，最大程度减少因数据更新导致的业务中断。

5. 业务切换阶段

包括：

（1）切换准备。在业务低峰期进行业务系统的停机，并确认所有数据已完成同步，暂停 OGG 的增量同步功能。

（2）数据切换。更新业务系统中的数据库连接配置，使其指向新的目标 RAC 集群，保持数据库的 SCAN IP 和实例名不变，以避免客户端配置更改。

（3）业务系统验证。切换完成后，立即进行关键业务系统的验证测试，由业务部门对登录、开立医嘱、书写病历、药房管理等核心功能进行检查，确保系统切换后正常运行。如验证过程中发现问题，可快速回退至原系统。

6. 后期调试阶段

包括：

（1）在迁移结束后，使用数据库层面的校验工具（如Oracle Data Pump或第三方工具如Quest Toad for Oracle），确认数据的一致性，确保迁移后数据与源数据完全一致。

（2）迁移后立即进行系统压力测试（如Real Application Testing）和性能监控（如Oracle Enterprise Manager），确保新环境下数据库系统的各项性能指标达到预期。

（3）使用数据库层面的工具再次确认数据的一致性，包括表结构、索引、触发器等关键业务数据的完整性。

（4）基于性能测试和用户反馈，调整数据库参数（如调整DB_CACHE_SIZE和SHARED_POOL_SIZE等参数，以提高缓存命中率和SQL执行效率），进行必要的系统优化，以确保长时间稳定运行。

7. 应急预案和回退策略

包括：

（1）准备回退脚本，支持30 min内快速回退。

（2）建立24 h专家支持团队，包括数据库、网络和应用专家。

（3）设置关键检查点，每个检查点都有明确的评估标准。

（4）每个关键检查点都将进行数据一致性检查，一旦发现异常问题，将快速恢复至原平台，并根据需求重新评估切换时间。

（5）为防止迁移期间出现网络中断或同步失败，预设备用线路，保证业务不中断。

（6）所有数据同步过程均设置本地和异地备份，确保系统即使在故障情况下也能恢复。

4. 迁移执行过程

4.1. 实际执行时间线

本次迁移执行过程记录见表4。

表4 迁移执行过程记录表

注：SQL为结构化查询语言

4.2. 关键问题及解决方案

1. 数据一致性问题

在迁移过程中，定期进行数据一致性检查，确保源数据库与目标数据库的数据完全一致，使用数据校验工具，及时发现并解决潜在的数据不一致性问题。

2. 数据同步性能问题

存在的问题：全量同步速度仅为200 GB/h。解决方案：优化网络配置，检查带宽配置；优化 OGG 参数配置，增加线程数和提交大小，提高数据传输效率［8］。

3. RAC 节点间通信问题

存在的问题：节点间心跳丢失。解决方案：调整内核参数，优化TCP连接参数以确保节点间通信稳定。

4. 视图失效问题

存在的问题：迁移后部分视图无法正常工作。解决方案：重新编译问题视图，并检查视图所依赖的对象是否正确迁移且可用。检查视图权限相关问题，调整数据库用户权限或角色分配。

5. DBLink 失效问题

存在的问题：迁移后原有的DBLink不再有效。解决方案：验证DBLink指向的数据库实例是否正确时，发现部分DBLink指向了错误的地址而非数据库的SCAN IP。重新创建这些DBLink，并确保它们指向新的数据库实例。同时，确认DBLink使用的用户名和密码仍然有效。

6. SYSTEM 表空间占用问题

存在的问题：迁移后 SYSTEM 表空间迅速被占满。解决方案：分析 SYSTEM 表空间的使用情况，确认是否有不必要的对象或日志文件占据过多空间。考虑扩大 SYSTEM 表空间容量或者清理不必要的数据。如果是由于临时对象导致的空间增长，可以通过调整会话级别的TEMP表空间来缓解。

7. 客户端问题

存在的问题：部分客户端连接新数据库失败。解决方案：部分客户端的tnsnames.ora文件中配置了错误的数据库SCAN IP，更新这些客户端的tnsnames.ora文件以指向正确的SCAN IP后，重启客户端应用程序。

根据上述验证结果，我们编制了详细的迁移报告，总结了整个迁移过程中的关键步骤、遇到的问题及解决方案（表4）。报告还包括了后续运维建议和持续优化措施，以确保系统的长期稳定运行。

5. 迁移成果及影响

5.1. 性能和容量提升

通过系统监控和性能测试，新平台在多个关键指标上均实现显著提升。

1. 系统响应能力

数据库查询响应时间从平均2.3 s降至0.8 s。日常报表生成时间缩短62%，从15 min减少到5.7 min。高峰期CPU使用率从91%降至45%，为未来扩展预留充足空间。

2. 数据处理效率

全量数据备份时间从47.5 h缩短至11.8 h。批量数据导入速度提升3.5倍，每小时处理记录条数从80万条提升至280万条。支持的并发用户数从4 300提升至12 000，满足未来3~5年扩展需求。

5.2. 成本优化与业务价值

迁移项目在多个层面实现了显著的成本优化。

1. 直接成本节省

x86 架构的服务器相比传统 AIX 小型机，采购成本显著降低［9］。原有2台 AIX 小机总投资约220万元，新采购的3台x86服务器总投资约150万元，成本节约31.82%。根据既往维修清单统计，年度维保费用预估节省60%。

2. 间接成本优化

制冷需求减少28%，相应降低空调运行成本。得益于新设备的紧凑设计，机房空间利用率提高35%，为未来扩展预留空间。标准化硬件平台降低了技术培训成本，提高了运维效率。

5.3. 临床应用效果

1. 门诊部分

门诊医生工作站响应速度提升30%，临床满意度提高，日均可多接诊5~8例患者。

2. 其他

护理系统、临床路径管理系统、单病种管理系统等多个与HIS系统频繁交互的系统运行效率得到了显著提升，极大地改善了医护工作流程。

5.4. 运维效果分析

1. 系统维护特点对比

（1）系统稳定性：原 AIX 平台以其卓越的稳定性著称，操作系统本身几乎不需要日常维护；x86平台通过冗余设计保障可用性，定期进行预防性维护。

（2）应用层面改善：HIS 系统响应速度显著提升，用户报修频次大幅下降。门诊医生站报修 HIS 系统卡顿问题从日均20次降至10次以下；住院医生每日晨交班报修HIS无响应问题从每周约10例降至5例以下。

2. 运维工作转变

（1）维护重点转移：从传统的硬件维护转向应用性能优化，更注重业务连续性保障和用户体验改善。

（2）运维效率提升：标准化平台简化了日常巡检流程。故障定位更直观，平均故障解决时间从3 h缩短至1.5 h。可利用更丰富的开源监控工具，提升监控精确度［10-11］。

3. 新增挑战及应对

（1）对系统监控要求提高，故部署了更全面的监控体系，覆盖硬件到应用各个层面。建立了专门的性能优化小组，定期进行系统调优。

（2）对技术团队的能力要求提升，故加强了对数据库性能优化的培训，制定了更完善的应用监控和故障处理流程。

6. 结论

6.1. 战略层面的意义

本次HIS数据库服务器迁移项目不仅解决了HIS的技术瓶颈，更具有深远的战略意义，这是医院信息化建设的里程碑，标志着医院核心信息系统向国产化、自主可控方向转型的一步［12］，为医院未来3~5年的信息化发展奠定了技术基础，同时也具有行业示范效应，为同类医疗机构提供了可借鉴的经验和实践。

6.2. 经验总结与启示

通过项目实施，我们总结出以下关键经验：

（1）成功要素。充分的前期评估和详细的迁移规划是项目成功的基础。采用 OGG 工具进行实时数据同步，最大限度降低了业务中断时间。建立多层次的应急预案，确保在遇到问题时能快速响应。

（2）主要挑战及解决之道。大规模数据迁移的性能瓶颈可通过优化网络配置和采用并行处理策略解决。系统兼容性问题可通过详细的测试和及时的问题修复确保系统稳定。

6.3. 对未来的建议和展望

基于本次迁移的经验，我们对医疗信息化建设提出以下建议：

1. 技术路线选择

建议医疗机构在选择技术路线时，充分考虑国产化趋势和信创政策要求［13］。在确保性能和稳定性的同时，重视系统的可扩展性和未来升级空间。关注技术生态系统的完整性，包括配套工具、技术支持和人才供给。

2. 实施策略建议

建议采用渐进式迁移策略，降低风险，积累经验。建立完善的监控体系，及时发现和解决问题。注重知识沉淀和经验总结，为后续项目提供参考。

3. 未来发展趋势

预计更多医疗机构将开展类似的系统迁移项目。国产化替代进程将进一步加快，带动相关技术的快速发展。医疗信息化建设将更注重标准化、规范化和可持续发展。

6.4. 研究展望

本研究尚存在一些有待深入探讨的方向。

1. 技术优化方向

如何进一步优化大规模医疗数据的迁移效率。探索更多元化的系统架构，提升系统的可扩展性和灵活性，如微服务、容器化等技术。

2. 国产化方向

更换数据库为国产数据库，如达梦数据库、人大金仓、华为云GaussDB等。研究医疗信息系统在云环境下的部署和运维模式，如自动化部署工具、灾难恢复计划等。

综上所述，通过本次成功的迁移实践，我们不仅解决了当前HIS技术瓶颈，更为医院未来的信息化建设指明了方向。随着技术的不断进步和实践经验的积累，医疗信息化建设将会迈向更高的水平，为提升医疗服务质量和效率作出更大贡献。