数据库一体机提升医院信息系统性能的探索与实践

梅 甜 林仁回 李 银 伊永菊

中山大学附属第六医院//广州市黄埔区中六生物医学创新研究院 广东广州 510065

1 引言

随着国家《电子病历系统应用水平分级评价》等政策的推动落实,医院信息系统作为重点考评对象,其功能日臻完善和丰富,应用范围也不断扩展和深入。某三甲医院的医院信息系统主要由应用软件、Oracle数据库、硬件等组成,包括了HIS系统(hospital information system)和EMR系统(Electronic Medical Record)等子系统。随着医院规模的扩大,系统用户量、终端数、医疗数据不断增长,信息系统之间交互日益频繁[1]。医院信息系统的数据库带来了前所未有的压力,引起了用户请求响应缓慢、死锁增多、系统服务挂起等问题,如何高效进行系统的运维和数据管理成为医院信息部门面临的重大挑战[2-3]。

近年来,各种一体机集成产品陆续发布,在金融、电信等在线并发事务量大的行业有着较多的使用案例,但是在医疗行业的应用报导相对较少[4-5]。某医院探索性引入了Exadata数据库一体机,从数据库软件和硬件结合的角度来改善医院信息系统的服务性能。本文结合某院的应用实践,总结了数据库一体机优化I/O的关键技术,硬件参数选型的要点、环境参数的配置处理、高可用测试以及数据迁移过程,并通过上线前后数据库的I/O 操作、SQL语句的执行和应用软件的加载三方面来评估系统的获益。性能问题一直都是信息系统建设中的难点,本文可为医院信息系统的性能改善提供一定的参考借鉴[6-7]。

2 数据库一体机简介

目前国内外的数据库一体机种类多样,比较典型的是Exadata数据库一体机[7]。2021年甲骨文公司发布的新型号数据库一体机版本是Exadata X9M型号,作为数据库软硬件一体化解决方案对应国产版本为神州数码登云数据库一体机。跟传统X86集成方式相比(详见表1),Exadata是在一个机架中集成数据库服务器、存储服务器、交换机、网络等硬件,对医院常规服务器部署来讲,部署整体较为简单。跟通用型一体机相比,Exadata部署有Oracle操作系统和数据库、支持在线的高可用性,并且存储层具备处理SQL能力,从而降低传输量。此外,ExadataX9M与前几代相比,服务器CPU、内存和存储均有所增加,并且支持多个Oracle数据库的整合。此外,其自带ILOM(IntegratatedLights Out Manager)监控系统,可以远程管理及监控检查各个部件的运行状态。Exadata数据库一体机优化I/O的关键技术如下:

表1 不同品牌一体机或硬件组成指标对比一览表

①分布式体系结构。其中智能存储及其存储管理软件提供了更高的并发处理能力,且具备非常灵活的扩展能力。

②内部互联采用100 Gb/S的RoCE(RDMA over converged ethernet)通道。聚合带宽可达880 Gb/s,可以在数据库服务器和存储服务器之间提供较高的带宽。

③智能存储的扫描技术。SQL指令下发给存储服务器并行执行,在存储层上进行计算,只将访问的结果数据传回给数据库服务器,因此可以很大程度上减少I/O传输。

④智能存储中采用了智能闪存缓存。智能闪存会自动缓存热点数据,同时利用闪存极大的消除数据库日志写的性能瓶颈。

⑤采用混合列压缩。典型的混合列压缩表的压缩率能达到10倍左右,相比较未压缩的数据,对I/O的使用率可以减少到原来的十分之一。

⑥在内存中生成并维护存储索引。存储索引在内存中保存了表数据若干列的最大值和最小值,大量I/O操作被自动替换为基于内存的扫描,进一步减少了I/O操作。

3 数据库一体机应用实践

3.1 硬件参数选型

Exadata数据库一体机提供了多种型号配置。某院结合硬件参数配置经验,按照不低于原医院硬件配置原则,考虑到未来的容量可扩展,选择了Exadata X9M型号的四分之一配置。具体参数如表2所示。

表2 Exadata数据库一体机与原生产库服务器硬件参数对比一览表

3.2 整体数据库架构设计

原医院信息系统的包含4个数据库(如图1),分别是由RAC(real application clusters)集群构成的原生产库作为主库,对外提供备份一体机、镜像库、容灾一体机的数据库取数服务,关于RMAN的备份方式可见笔者的前文描述[3,8]。新的架构变成让数据库一体机产生业务数据作为生产库,同时备份一体机通过新镜像库取数。变更后的架构实现了读写分离,有利于减轻生产库的对外供数压力,保证生产库的稳定性。

图1 数据库架构变更示意图

3.3 数据库一体机上线过程

为了确保医院信息系统的可用性、保证历史业务的连贯性,尽可能缩短停机窗口,需要合理有序开展上线过程中的操作。本项目中采取的上线过程如图2所示。在正式上线切换前,需要完成数据库版本升级、配置数据的同步以及高可用测试。正式上线时,需要验证数据同步情况无误后,停止医院系统的对外服务,再进行主库和备库的角色切换,也会涉及修改主库和备注IP地址。完成后,重启数据库并通过业务测试后,开始正式启用数据库一体机。

图2 数据库一体机上线过程流程图

3.3.1 数据库版本升级 在正式启用数据库一体机之前,需要考察数据库软件的版本。首先把原4个数据库的版本(Oracle 19.13.0.0)均通过补丁升级到与X9M(Oracle 19.15.0.0)一致。因Oracle RAC集群补丁支持滚动式升级,不需要停业务。

3.3.2 配置数据同步 为保证上线前后数据的连续性,需进行历史数据迁移。DataGuard技术为物理同步,数据库目标端物理结构,DBlink、表索引与源库完全一致,可最大程度地减少停机时间,有利于数据保护和灾难恢复[8-9]。需要提前配置数据库一体机与生产库之间的DataGuard,需准备的信息如下:数据库IP的相关文件;pfile和spfile初始化参数;密码文件;数据量大小;防火墙端口;外围系统连接数据库端口;备份及容灾一体机安装的插件。

3.3.3 高可用测试 高可用性是数据库的重要性能之一[10]。因数据库一体机具有数据库应用集群软件支持均衡负载和应用的透明切换,集群中任一节出现故障,应用无须中断或切换。为验证此高可用性,上线前期采取的测试方法为:

①检查数据库一体机的运行状态以及监听状态,包括Local Resources和Cluster Resources的状态是否正常。若Exadata缺少数据库EXADB的资源,可通过srvctl add命令添加。②分别模拟两个计算节点业务网卡故障,2分钟后,数据库连接恢复正常。③依次模拟其中一台存储节点故障:可对其中一个存储节点进行重启。数据库运行状态正常不间断,证明满足高可用性。

3.3.4 验证数据同步情况 ①在主库上查看主备库的系统改变号SCN(system change number),如果SCN一直在变,并且很接近,说明备库日志恢复正常。②在主库查看归档日志位置状态,status=VALID则归档位置正常,否则error字段会给出错误原因。

3.3.5 停止医院信息系统 为避免迁移过程中数据同步的差异,停止系统的相关服务、接口、自动作业,保证所有用户已下线。完成停库时,无须杀进程。数据库状态转为静止状态后,关闭生产库和备库的同步。

3.3.6 切换角色 ①原主库切换角色为备库后,再把原备库切换角色为主库。②检查DataGuard同步。③如果转换失败,可以尝试将主库再转换回原先状态。

3.3.7 修改IP地址 ①先关闭数据库,后停原RAC。②检查IP对应物理接口,Exadata一体机和原RAC集群所有节点禁用crs,并备份ocr。③修改/etc/hosts文件。④Exadata一体机修改IP配置,后修改原RAC集群修改IP配置。

3.3.8 正式启用 ①先主库启动,再启备库。②在主库打开实时应用状态模式,启用DataGuard同步,在主库所有实例执行日志切换。③观察备库日志应用情况,运行过程无报错信息,则说明新镜像库运行良好。④迁移完成后,需要测试验证医院信息系统客户端、端口是否正常。此外,医院信息系统的容灾、备份系统也需要更新配置。

4 使用效果评价

4.1 I/O 操作时间对比

数据库I/O是数据库性能的主要指标,主要有Buffer Cache Reads读写,指从磁盘读取到内存中或者将数据从磁盘写入磁盘;Direct Reads为直接路径物理读;DBWR 进程是将buffer cache中的脏数据块写到磁盘中;LGWR 进程是将日志缓冲内容写到磁盘的在线重做日志文件或组中[11]。

分别采集数据库一体机上线前后医院信息系统数据库的7天AWR报告,提取其中I/O操作的具体参数如表3所示,数据库一体机相比于原 RAC集群的平均每次读写时间,Buffer Cache Reads读写延时降低69%,Direct Reads直接路径物理读延时降低80%,DBWR数据库写进程操作延时降低63%,LGWR日志写进程操作延时降低95%,整体延时降低83.47%。表明整体等待操作情况大幅减少。

表3 具体I/O操作的平均时间对比 (us)

4.2 SQL语句执行时间对比

分别提取数据库一体机上线前后的AWR报告中执行总和时间前10的SQL语句,对比发现4处SQL编号相同(表4),其余6条原RAC集群都语句已不再入选前10。进一步对比得出4个语句的执行解析时间降幅在22%到56%之间。

表4 相同的SQL 语句的执行时间对比 (s)

4.3 系统界面加载时间对比

在上线数据库一体机前后,分别通过多次重复操作,记录加载时长较长的业务操作如表5所示。其中,住院终端确认列表、住院医生站患者列表的加载时长均降幅超过50%,住院收费日结报表查询降幅最大为65.35%,降幅最小的是非药品维护界面初始化7.88%,平均时长缩短43.74%。结果显示与数据库查询相关的系统操作均有不同程度的时长缩短。

表5 医院信息系统界面加载时间对比 (s)

5 讨论

医院的业务运转高度依赖信息系统,也对系统运行的稳定性、响应时间等提出了高要求[12-14]。硬件的质量和软件本身的设计共同决定了信息系统的性能,数据库一体机通过内置的服务器、存储和网络等硬件设备在一定程度上降低了端口连线等带来的硬件故障风险[15-16]。同时,数据库一体机又不同于单纯的硬件集成,更注重软件和硬件的融合,能够通过充分发挥利用数据库的自身性能,从而帮助实现以分析性数据仓库为主体的医院信息系统优化提速[17]。在成本投入上,某医院综合评估结果显示数据库一体机的显性成本与传统的集成方式相当,但运维的隐性成本有所降低。

总之,通过上线数据库一体机,满足了某大型三甲医院信息系统对硬件、数据库性能、容量增长、高可用等要求。与此同时,医院信息系统性能的进一步提升,还需要在IT基础构架选型、应用程序的组件加载、查询优化等方面多管齐下[18-20]。此外,未来可以按照上述模式继续迁入更多的医院系统,把数据库部署在数据库一体机上,进一步降低成本和运维复杂性。