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

劉曉輝，姚惠東

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

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

【作 者】劉曉輝，姚惠東

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

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

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

醫(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ù)庫間的整合和數(shù)據(jù)交流為基礎(chǔ)， 在系統(tǒng)的結(jié)構(gòu)上還是以傳統(tǒng)的C/S結(jié)構(gòu)為主。HIS具有的這些特點(diǎn)，使HIS數(shù)據(jù)庫規(guī)模不斷擴(kuò)大，用戶數(shù)量不斷增加，對數(shù)據(jù)庫的可用性需求變得愈加重要。在眾多的解決方案中，ORACLE數(shù)據(jù)庫的實時應(yīng)用集群（RAC）技術(shù)是提高數(shù)據(jù)庫可用性，保障不斷增長醫(yī)院業(yè)務(wù)需求的非常有效的手段之一。

1 RAC工作原理

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

2 RAC實施方案

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

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

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

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

圖2 實際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實施的關(guān)鍵問題

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

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

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

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

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

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

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

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

4.2 分頁文件使用

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

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

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

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

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

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

圖9 數(shù)據(jù)庫會話數(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ù)庫實例1及實例2會話及等待事件Fig.11 After RAC: sessions and waiting in database

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

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

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

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

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

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

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

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

[5] 姜文, 胡順福, 等. 實現(xiàn)醫(yī)院信息系統(tǒng)高可用性設(shè)計[J]。中國醫(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