劉曉輝，姚惠東

廣州軍區(qū)廣州總醫(yī)院信息科，廣東省，廣州，510010

RAC技術(shù)在醫(yī)院信息系統(tǒng)中的應(yīng)用研究

【作 者】劉曉輝，姚惠東

廣州軍區(qū)廣州總醫(yī)院信息科，廣東省，廣州，510010

描述了RAC技術(shù)在醫(yī)院的實(shí)施方案，并對(duì)實(shí)施的關(guān)鍵技術(shù)進(jìn)行了研究。結(jié)果表明，RAC技術(shù)可大幅改善了數(shù)據(jù)庫(kù)性能。

RAC；醫(yī)院信息系統(tǒng)；數(shù)據(jù)庫(kù)

醫(yī)院信息化的發(fā)展已經(jīng)有10多年的歷史，從初期以收費(fèi)為主的HIS系統(tǒng)，到現(xiàn)在已經(jīng)發(fā)展為以電子病歷為基礎(chǔ)的多臨床信息系統(tǒng)整合的綜合性醫(yī)院信息系統(tǒng)。目前的醫(yī)院信息系統(tǒng)具有子系統(tǒng)多、數(shù)據(jù)量大和功能多樣化的特點(diǎn)，在數(shù)據(jù)的整合上以數(shù)據(jù)庫(kù)間的整合和數(shù)據(jù)交流為基礎(chǔ)， 在系統(tǒng)的結(jié)構(gòu)上還是以傳統(tǒng)的C/S結(jié)構(gòu)為主。HIS具有的這些特點(diǎn)，使HIS數(shù)據(jù)庫(kù)規(guī)模不斷擴(kuò)大，用戶數(shù)量不斷增加，對(duì)數(shù)據(jù)庫(kù)的可用性需求變得愈加重要。在眾多的解決方案中，ORACLE數(shù)據(jù)庫(kù)的實(shí)時(shí)應(yīng)用集群（RAC）技術(shù)是提高數(shù)據(jù)庫(kù)可用性，保障不斷增長(zhǎng)醫(yī)院業(yè)務(wù)需求的非常有效的手段之一。

1 RAC工作原理

實(shí)時(shí)應(yīng)用集群（RAC）是oracle9i開始提出的一種數(shù)據(jù)庫(kù)集群方案。在一個(gè)集群數(shù)據(jù)庫(kù)中可以有兩個(gè)以上的節(jié)點(diǎn)存在，并且要有一個(gè)共享的存儲(chǔ)設(shè)備.這些設(shè)備組成一個(gè)典型的SAN結(jié)構(gòu)，其中任意一個(gè)節(jié)點(diǎn)的失效不會(huì)影響客戶端會(huì)話或集群自身的可用性，直到集群中最后一個(gè)節(jié)點(diǎn)失效，數(shù)據(jù)庫(kù)才變得不可用。集群中每一個(gè)節(jié)點(diǎn)都是一個(gè)單獨(dú)的實(shí)例，有著自己獨(dú)立的實(shí)例名和SGA區(qū)，所有節(jié)點(diǎn)訪問同一個(gè)物理數(shù)據(jù)庫(kù)，所有節(jié)點(diǎn)間的通訊是在集群軟件管理下通過(guò)服務(wù)器間的心跳線實(shí)現(xiàn)。在RAC中的每一個(gè)節(jié)點(diǎn)上有一個(gè)全局緩存服務(wù)，用來(lái)減少各個(gè)節(jié)點(diǎn)間的I/O通訊。RAC的結(jié)構(gòu)如圖1所示。

2 RAC實(shí)施方案

圖1 RAC結(jié)構(gòu)Fig.1 RAC structure

我院舊的架構(gòu)已經(jīng)是SAN結(jié)構(gòu)。在新的RAC架構(gòu)設(shè)計(jì)中，服務(wù)器與存儲(chǔ)的位置和連接方式，依然是兩節(jié)點(diǎn)的SAN結(jié)構(gòu)，只是每臺(tái)服務(wù)器分別添加了兩條到核心交換機(jī)的私有網(wǎng)絡(luò)線路，用于RAC的私有網(wǎng)絡(luò)線路（private network）。每臺(tái)服務(wù)器有兩條出口，一條為主，另一條為冗余，防止因網(wǎng)絡(luò)的單點(diǎn)故障造成RAC私有網(wǎng)絡(luò)中斷引起某一節(jié)點(diǎn)重啟。

新架構(gòu)中私有網(wǎng)卡將通過(guò)光纖網(wǎng)絡(luò)連接到核心交換機(jī)上。私有網(wǎng)絡(luò)在實(shí)現(xiàn)上采用IBM的etherchannel技術(shù)，將兩個(gè)網(wǎng)絡(luò)接口綁成一個(gè)網(wǎng)絡(luò)接口，模式是一主一備，如圖2所示。在核心交換機(jī)上需要將這些連接私有網(wǎng)絡(luò)接口配置在一個(gè)VLAN中，減小廣播影響。

新架構(gòu)中客戶端的連接串需要重新設(shè)置，使客戶端能在服務(wù)器出現(xiàn)單點(diǎn)故障時(shí)實(shí)現(xiàn)自動(dòng)透明切換工作，并且在連接數(shù)據(jù)庫(kù)時(shí)自動(dòng)選擇負(fù)載低的數(shù)據(jù)庫(kù)，實(shí)現(xiàn)負(fù)載均衡。具體配置如下：

圖2 實(shí)際RAC拓?fù)浣Y(jié)構(gòu)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實(shí)施的關(guān)鍵問題

3.1 以應(yīng)用為基礎(chǔ)劃分服務(wù)器功能

實(shí)時(shí)應(yīng)用集群（RAC）有幾個(gè)節(jié)點(diǎn)就有幾個(gè)數(shù)據(jù)庫(kù)實(shí)例運(yùn)行,實(shí)例之間通過(guò)私有網(wǎng)絡(luò)實(shí)現(xiàn)通訊。為了維護(hù)數(shù)據(jù)庫(kù)各實(shí)例間讀一致性和高可用性，登錄到不同實(shí)例上的用戶操作相同數(shù)據(jù)記錄時(shí)，RAC將通過(guò)私有網(wǎng)絡(luò)傳遞和維護(hù)這些數(shù)據(jù)的一致性。在一般性應(yīng)用時(shí)，數(shù)據(jù)庫(kù)私有網(wǎng)絡(luò)間的流量非常大，因此在RAC的建設(shè)上，ORACLE廠商都建議私有網(wǎng)絡(luò)采用千兆光纖網(wǎng)，預(yù)防RAC的瓶頸問題。

減少私有網(wǎng)絡(luò)間的數(shù)據(jù)交換，是降低RAC瓶頸產(chǎn)生的風(fēng)險(xiǎn)和提高RAC整體性能的有效途徑。如果客戶端A只操作a、b兩個(gè)表，客戶端B只操作c、d兩個(gè)表，強(qiáng)制客戶端A登錄服務(wù)器1，客戶端B登錄服務(wù)器2的話，私有網(wǎng)絡(luò)間的數(shù)據(jù)傳遞將會(huì)大大減少。基于以上考慮，實(shí)際應(yīng)用中，我們?nèi)∠丝蛻舳素?fù)載平衡的登錄方式，客戶端按操作數(shù)據(jù)庫(kù)表的不同和各模塊功能的不同進(jìn)行分類，分成門診和住院兩大類客戶端。門診包括門診醫(yī)生站、門診收費(fèi)、掛號(hào)、門診藥房、檢驗(yàn)和檢查等系統(tǒng)，住院包括住院醫(yī)生站、住院登記、護(hù)士站、住院藥房和各臨床系統(tǒng)等。程序啟動(dòng)后，登錄到各自指定的服務(wù)器上。這種安排，雖然兩臺(tái)服務(wù)器間的負(fù)載出現(xiàn)不均衡（一邊400，一邊800），但減少了私有網(wǎng)絡(luò)間的流量，降低了服務(wù)器內(nèi)部的開銷，實(shí)際是節(jié)省了服務(wù)器資源。

3.2 保持網(wǎng)絡(luò)穩(wěn)定

無(wú)論是私有網(wǎng)絡(luò)還是公共網(wǎng)絡(luò)，RAC對(duì)網(wǎng)絡(luò)故障是極度敏感的。在設(shè)定時(shí)間間隔內(nèi)，如果服務(wù)器檢測(cè)到網(wǎng)絡(luò)出現(xiàn)故障時(shí)，或者網(wǎng)絡(luò)因?yàn)榉泵Χ瑫r(shí)，從服務(wù)器上的實(shí)例將會(huì)自動(dòng)切換到主服務(wù)器上，并根據(jù)網(wǎng)絡(luò)故障的不同決定是否重啟從服務(wù)器。雖然切換不會(huì)導(dǎo)致客戶端的斷開，但未提交事務(wù)將會(huì)失敗，產(chǎn)生錯(cuò)誤，影響業(yè)務(wù)的順利進(jìn)行。因此，保持網(wǎng)絡(luò)穩(wěn)定，控制網(wǎng)絡(luò)流量，是保持RAC穩(wěn)定的重要環(huán)境因素。在網(wǎng)絡(luò)管理上要做好以下幾個(gè)方面：① 公共網(wǎng)絡(luò)與私有網(wǎng)絡(luò)分開。公共網(wǎng)絡(luò)與私有網(wǎng)絡(luò)之間最好采用物理分開的方式部署，以減少它們之間的相互影響；② 降低網(wǎng)絡(luò)流量。無(wú)論是公共網(wǎng)絡(luò)還是私有網(wǎng)絡(luò)，過(guò)高的網(wǎng)絡(luò)流量都會(huì)導(dǎo)致RAC的不穩(wěn)定。私有網(wǎng)絡(luò)的流量可以通過(guò)應(yīng)用程序分開來(lái)調(diào)節(jié)，公共網(wǎng)絡(luò)則主要是對(duì)病毒的防控和網(wǎng)絡(luò)帶寬的物理升級(jí)。

4 RAC實(shí)施前后系統(tǒng)性能改善情況

由于RAC的實(shí)施是在原有架構(gòu)和數(shù)據(jù)庫(kù)版本基礎(chǔ)上進(jìn)行的，因此在數(shù)據(jù)庫(kù)性能改善的評(píng)價(jià)上，前后具有一定的可比性。本研究主要從CPU使用率、操作系統(tǒng)分頁(yè)文件使用情況、服務(wù)器I/O情況等服務(wù)器性能方面以及數(shù)據(jù)庫(kù)性能等方面進(jìn)行了數(shù)據(jù)采集，所有采集到的數(shù)據(jù)都是在真實(shí)在用數(shù)據(jù)庫(kù)環(huán)境下得到的。

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

我們從前后的對(duì)比上看（見圖3、圖4、圖5），RAC完成之后,在數(shù)據(jù)庫(kù)用戶數(shù)（session）基本不變的情況下，原來(lái)的連接負(fù)載由一臺(tái)服務(wù)器分成了兩臺(tái)服務(wù)器分擔(dān)，CPU使用率和等待大為減少，用戶程序在高峰時(shí)刻明顯減少了等待時(shí)間。同時(shí)，我們按功能區(qū)分?jǐn)?shù)據(jù)庫(kù)的使用，大量查詢操作安排在server2服務(wù)器上，使用于門診的SERVER1服務(wù)器即使在繁忙時(shí)段也能快速響應(yīng)。

4.2 分頁(yè)文件使用

RAC應(yīng)用之前，單臺(tái)服務(wù)器server1高峰期分頁(yè)使用頻繁， 內(nèi)存數(shù)據(jù)經(jīng)常被交換到硬盤分頁(yè)文件中，對(duì)服務(wù)器整體性能影響較大。應(yīng)用RAC后，server1和server2服務(wù)器上的用戶數(shù)量減少，內(nèi)存使用率保持在90%以下，幾乎沒有頁(yè)面交換，由于分頁(yè)文件的使用大為減少，系統(tǒng)的整體性能有顯著提高，見圖6、圖7和圖8所示。

圖6 RAC應(yīng)用之前server1內(nèi)存與分頁(yè)文件之間的換頁(yè)情況Fig.6 Before RAC: paging ibmserver1 ibmserver1:

圖7 RAC狀態(tài) server1換頁(yè)情況Fig.7 After RAC: paging ibmserver1 ibmserver2:

圖8 RAC狀態(tài)server2換頁(yè)情況Fig.8 After RAC: paging ibmserver2

4.3 數(shù)據(jù)庫(kù)性能情況

通過(guò)來(lái)自數(shù)據(jù)庫(kù)EM工具的性能記錄中可以看出（見圖9和圖10），在RAC應(yīng)用之前，在業(yè)務(wù)高峰期（上午9時(shí)至12時(shí)），數(shù)據(jù)庫(kù)等待事件集中出現(xiàn)，主要事件類型是concurrency。進(jìn)一步分析等待事件發(fā)現(xiàn)，出現(xiàn)最多的等待是latch:library cache。我們認(rèn)為，出現(xiàn)該等待事件的根本原因是因?yàn)槲锢韮?nèi)存空間不足，導(dǎo)致計(jì)算內(nèi)存換頁(yè)至頁(yè)面文件所致，出現(xiàn)該等待事件時(shí)系統(tǒng)的速度會(huì)出現(xiàn)短暫緩慢。內(nèi)存和頁(yè)面文件的交互造成了長(zhǎng)時(shí)間的CPU等待。

圖9 數(shù)據(jù)庫(kù)會(huì)話數(shù)及等待Fig.9 Before RAC: sessions and waiting in database

圖10 等待分析Fig.10 Before RAC: waiting analysis in database

圖11 RAC狀態(tài)數(shù)據(jù)庫(kù)實(shí)例1及實(shí)例2會(huì)話及等待事件Fig.11 After RAC: sessions and waiting in database

在完成系統(tǒng)RAC改造之后，使用壓力分散到兩臺(tái)服務(wù)器上，數(shù)據(jù)庫(kù)等待事件大量減少，并發(fā)會(huì)話數(shù)也在減少（見圖11）。

在業(yè)務(wù)高峰期（上午9時(shí)至12時(shí)），數(shù)據(jù)庫(kù)實(shí)例等待事件出現(xiàn)的主要類型是user i/o。進(jìn)一步分析等待事件，其中db_file_scattered_read和db_file_sequential_read所占比例最大（見圖12）。

圖12 實(shí)例1與實(shí)例2的USER I/O情況Fig.12 After RAC: user I/O

總之，與單機(jī)單數(shù)據(jù)庫(kù)時(shí)相比，RAC數(shù)據(jù)庫(kù)的主要等待類型已經(jīng)由并發(fā)等待轉(zhuǎn)變I/O操作等待。而且，在總會(huì)話數(shù)不變的情況下，每個(gè)實(shí)例上的并發(fā)會(huì)話數(shù)量相應(yīng)得到了減少，數(shù)據(jù)庫(kù)服務(wù)器降低了負(fù)載，在業(yè)務(wù)高峰期也不再出現(xiàn)并發(fā)等待，數(shù)據(jù)庫(kù)的整體性能得到提高。個(gè)別需要較大i/o讀寫的操作，不再對(duì)整體業(yè)務(wù)產(chǎn)生大的影響，CPU等待也大為減少。從RAC應(yīng)用前后的性能對(duì)比看，RAC技術(shù)的應(yīng)用對(duì)系統(tǒng)可擴(kuò)展性的提高非常明顯，使內(nèi)存、CPU資源的緊張得以緩解，提高了系統(tǒng)的響應(yīng)速度。因此，應(yīng)用RA (oracel 2006)C技術(shù)實(shí)現(xiàn)數(shù)據(jù)庫(kù)集群方案，是資金許可、擁有技術(shù)力量單位在改善數(shù)據(jù)庫(kù)性能上可重點(diǎn)考慮的方案之一。

[1] oracel. oracle metalink site. 2006. http://oracle.metalink.com.

[2] 付社良. OracleRAC10g系統(tǒng)高可用性測(cè)試及分析[J]. 武漢理工大學(xué)學(xué)報(bào)（信息與管理工程版）, 2007年, 29（2）: 77-80.

[3] 緱文海. Oracle 10g RAC在HIS數(shù)據(jù)庫(kù)中的應(yīng)用[J]. 西南國(guó)防醫(yī)藥, 2009, l9(9): 917.

[4] 彭建明. 解決HIS集群系統(tǒng)的性能問題[J]. 醫(yī)學(xué)信息, 2008, 21(12): 2180-2182.

[5] 姜文, 胡順福, 等. 實(shí)現(xiàn)醫(yī)院信息系統(tǒng)高可用性設(shè)計(jì)[J]。中國(guó)醫(yī)療器械雜志, 2008, 32(1)：62-67.

Research on the Application of RAC Technology in Hospital Information System

【W(wǎng)riters】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