RAC技术在医院信息系统中的应用研究
2010-03-24刘晓辉姚惠东
刘晓辉，姚惠东
广州军区广州总医院信息科，广东省，广州，510010
RAC技术在医院信息系统中的应用研究
【作 者】刘晓辉，姚惠东
广州军区广州总医院信息科，广东省，广州，510010
描述了RAC技术在医院的实施方案，并对实施的关键技术进行了研究。结果表明，RAC技术可大幅改善了数据库性能。
RAC；医院信息系统；数据库
医院信息化的发展已经有10多年的历史，从初期以收费为主的HIS系统，到现在已经发展为以电子病历为基础的多临床信息系统整合的综合性医院信息系统。目前的医院信息系统具有子系统多、数据量大和功能多样化的特点，在数据的整合上以数据库间的整合和数据交流为基础， 在系统的结构上还是以传统的C/S结构为主。HIS具有的这些特点，使HIS数据库规模不断扩大，用户数量不断增加，对数据库的可用性需求变得愈加重要。在众多的解决方案中，ORACLE数据库的实时应用集群（RAC）技术是提高数据库可用性，保障不断增长医院业务需求的非常有效的手段之一。
1 RAC工作原理
实时应用集群（RAC）是oracle9i开始提出的一种数据库集群方案。在一个集群数据库中可以有两个以上的节点存在，并且要有一个共享的存储设备.这些设备组成一个典型的SAN结构，其中任意一个节点的失效不会影响客户端会话或集群自身的可用性，直到集群中最后一个节点失效，数据库才变得不可用。集群中每一个节点都是一个单独的实例，有着自己独立的实例名和SGA区，所有节点访问同一个物理数据库，所有节点间的通讯是在集群软件管理下通过服务器间的心跳线实现。在RAC中的每一个节点上有一个全局缓存服务，用来减少各个节点间的I/O通讯。RAC的结构如图1所示。
2 RAC实施方案
图1 RAC结构Fig.1 RAC structure
我院旧的架构已经是SAN结构。在新的RAC架构设计中，服务器与存储的位置和连接方式，依然是两节点的SAN结构，只是每台服务器分别添加了两条到核心交换机的私有网络线路，用于RAC的私有网络线路（private network）。每台服务器有两条出口，一条为主，另一条为冗余，防止因网络的单点故障造成RAC私有网络中断引起某一节点重启。
新架构中私有网卡将通过光纤网络连接到核心交换机上。私有网络在实现上采用IBM的etherchannel技术，将两个网络接口绑成一个网络接口，模式是一主一备，如图2所示。在核心交换机上需要将这些连接私有网络接口配置在一个VLAN中，减小广播影响。
新架构中客户端的连接串需要重新设置，使客户端能在服务器出现单点故障时实现自动透明切换工作，并且在连接数据库时自动选择负载低的数据库，实现负载均衡。具体配置如下：
图2 实际RAC拓扑结构Fig.2 RAC topology
dbserver =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.2)(PORT = 1521))
(LOAD_BALANCE = on)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
)))
dbservermz =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.2)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orclmz)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
)))
dbserverzy =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.2)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orclzy)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
)))
3 RAC实施的关键问题
3.1 以应用为基础划分服务器功能
实时应用集群（RAC）有几个节点就有几个数据库实例运行,实例之间通过私有网络实现通讯。为了维护数据库各实例间读一致性和高可用性，登录到不同实例上的用户操作相同数据记录时，RAC将通过私有网络传递和维护这些数据的一致性。在一般性应用时，数据库私有网络间的流量非常大，因此在RAC的建设上，ORACLE厂商都建议私有网络采用千兆光纤网，预防RAC的瓶颈问题。
减少私有网络间的数据交换，是降低RAC瓶颈产生的风险和提高RAC整体性能的有效途径。如果客户端A只操作a、b两个表，客户端B只操作c、d两个表，强制客户端A登录服务器1，客户端B登录服务器2的话，私有网络间的数据传递将会大大减少。基于以上考虑，实际应用中，我们取消了客户端负载平衡的登录方式，客户端按操作数据库表的不同和各模块功能的不同进行分类，分成门诊和住院两大类客户端。门诊包括门诊医生站、门诊收费、挂号、门诊药房、检验和检查等系统，住院包括住院医生站、住院登记、护士站、住院药房和各临床系统等。程序启动后，登录到各自指定的服务器上。这种安排，虽然两台服务器间的负载出现不均衡（一边400，一边800），但减少了私有网络间的流量，降低了服务器内部的开销，实际是节省了服务器资源。
3.2 保持网络稳定
无论是私有网络还是公共网络，RAC对网络故障是极度敏感的。在设定时间间隔内，如果服务器检测到网络出现故障时，或者网络因为繁忙而超时，从服务器上的实例将会自动切换到主服务器上，并根据网络故障的不同决定是否重启从服务器。虽然切换不会导致客户端的断开，但未提交事务将会失败，产生错误，影响业务的顺利进行。因此，保持网络稳定，控制网络流量，是保持RAC稳定的重要环境因素。在网络管理上要做好以下几个方面：① 公共网络与私有网络分开。公共网络与私有网络之间最好采用物理分开的方式部署，以减少它们之间的相互影响；② 降低网络流量。无论是公共网络还是私有网络，过高的网络流量都会导致RAC的不稳定。私有网络的流量可以通过应用程序分开来调节，公共网络则主要是对病毒的防控和网络带宽的物理升级。
4 RAC实施前后系统性能改善情况
由于RAC的实施是在原有架构和数据库版本基础上进行的，因此在数据库性能改善的评价上，前后具有一定的可比性。本研究主要从CPU使用率、操作系统分页文件使用情况、服务器I/O情况等服务器性能方面以及数据库性能等方面进行了数据采集，所有采集到的数据都是在真实在用数据库环境下得到的。
4.1 CPU使用率
图3 改造前ibmserver1 CPU使用率Fig.3 Before transformation: cpu usage of the ibmserver1
图4 改造后server1 CPU使用率Fig.4 After transformation: cpu usage of the server1
图5 改造后server2 CPU使用率Fig.5 After transformation: cpu usage of the server2
我们从前后的对比上看（见图3、图4、图5），RAC完成之后,在数据库用户数（session）基本不变的情况下，原来的连接负载由一台服务器分成了两台服务器分担，CPU使用率和等待大为减少，用户程序在高峰时刻明显减少了等待时间。同时，我们按功能区分数据库的使用，大量查询操作安排在server2服务器上，使用于门诊的SERVER1服务器即使在繁忙时段也能快速响应。
4.2 分页文件使用
RAC应用之前，单台服务器server1高峰期分页使用频繁， 内存数据经常被交换到硬盘分页文件中，对服务器整体性能影响较大。应用RAC后，server1和server2服务器上的用户数量减少，内存使用率保持在90%以下，几乎没有页面交换，由于分页文件的使用大为减少，系统的整体性能有显著提高，见图6、图7和图8所示。
图6 RAC应用之前server1内存与分页文件之间的换页情况Fig.6 Before RAC: paging ibmserver1 ibmserver1:
图7 RAC状态 server1换页情况Fig.7 After RAC: paging ibmserver1 ibmserver2:
图8 RAC状态server2换页情况Fig.8 After RAC: paging ibmserver2
4.3 数据库性能情况
通过来自数据库EM工具的性能记录中可以看出（见图9和图10），在RAC应用之前，在业务高峰期（上午9时至12时），数据库等待事件集中出现，主要事件类型是concurrency。进一步分析等待事件发现，出现最多的等待是latch:library cache。我们认为，出现该等待事件的根本原因是因为物理内存空间不足，导致计算内存换页至页面文件所致，出现该等待事件时系统的速度会出现短暂缓慢。内存和页面文件的交互造成了长时间的CPU等待。
图9 数据库会话数及等待Fig.9 Before RAC: sessions and waiting in database
图10 等待分析Fig.10 Before RAC: waiting analysis in database
图11 RAC状态数据库实例1及实例2会话及等待事件Fig.11 After RAC: sessions and waiting in database
在完成系统RAC改造之后，使用压力分散到两台服务器上，数据库等待事件大量减少，并发会话数也在减少（见图11）。
在业务高峰期（上午9时至12时），数据库实例等待事件出现的主要类型是user i/o。进一步分析等待事件，其中db_file_scattered_read和db_file_sequential_read所占比例最大（见图12）。
图12 实例1与实例2的USER I/O情况Fig.12 After RAC: user I/O
总之，与单机单数据库时相比，RAC数据库的主要等待类型已经由并发等待转变I/O操作等待。而且，在总会话数不变的情况下，每个实例上的并发会话数量相应得到了减少，数据库服务器降低了负载，在业务高峰期也不再出现并发等待，数据库的整体性能得到提高。个别需要较大i/o读写的操作，不再对整体业务产生大的影响，CPU等待也大为减少。从RAC应用前后的性能对比看，RAC技术的应用对系统可扩展性的提高非常明显，使内存、CPU资源的紧张得以缓解，提高了系统的响应速度。因此，应用RA (oracel 2006)C技术实现数据库集群方案，是资金许可、拥有技术力量单位在改善数据库性能上可重点考虑的方案之一。
[1] oracel. oracle metalink site. 2006. http://oracle.metalink.com.
[2] 付社良. OracleRAC10g系统高可用性测试及分析[J]. 武汉理工大学学报（信息与管理工程版）, 2007年, 29（2）: 77-80.
[3] 缑文海. Oracle 10g RAC在HIS数据库中的应用[J]. 西南国防医药, 2009, l9(9): 917.
[4] 彭建明. 解决HIS集群系统的性能问题[J]. 医学信息, 2008, 21(12): 2180-2182.
[5] 姜文, 胡顺福, 等. 实现医院信息系统高可用性设计[J]。中国医疗器械杂志, 2008, 32(1)：62-67.
Research on the Application of RAC Technology in Hospital Information System
【Writers】Liu Xiaohui, Yao Huidong
the PLA Guangzhou general hospital, 510010, Guangzhou, Guangdong
This paper presents a way to carry out the RAC technology in hospital, researches the key technologies of RAC, the result shows that performance of database is greatly improved by RAC technology.
Real Applications Cluster (RAC) , hospital information system (HIS), database
R197.32
B
10.3969/j.isnn.1671-7104.2010.04.019
1671-7104(2010)04-0302-04
2010-04-12
刘晓辉，E-mail-flystone89@hotmail.com
