我院在2007年9月21日成功將HIS系統從win2000,Oracle9.2.01升級到兩台IBM P55A (操作系統AIX),Oracle 10.2.01 RAC組成的並行集群系統，隨著一個新大樓的啟用，客戶端的電腦從550台增加到了800多台，集群系統出現了嚴重的性能問題，在業務高峰期經常死機，經過半個月左右的調試，終於徹底解決了性能問題，滿足了醫院醫院業務發展的要求。
關鍵詞
ORACLE RAC (ORACLE Real Application Clusters): Oracle 真正應用集群
新疆維吾爾自治區人民醫院是新疆最大的三級甲等醫院，病床2000張以上，日門診量4000左右，為了滿足醫院發展的需要，自2004年新HIS系統上線,醫院的信息化得到了全面的提升,客戶端工作站達到了900左右,其中HIS工作站近700台,隨著客戶數的增加,我院的系統表現出了擴展性不足的問題,這主要是Windows 32位操作系統4G內存限制造成,雖然我們經過參數修改,服務器內存升級為8G,但由於系統核心32位限制。當高峰期客戶數達到650左右,前端工作站就不能繼續連接,且一些大的統計分析不能執行.一些已連接用戶也陸續不能使用,最後服務器上數據庫DBA用戶也不能連接,這時候只有重新啟動服務器,才能解決問題。據了解全國一些大醫院也面臨我院同樣的問題。
在這種情況下,我院經過充分考證,借鑒電信和銀行的小機，Oracle RAC並行集群系統成功經驗,經過盡一年的准備,成功采用兩台IBM小機(IMB P55A 16G內存 4CPU),實施了ORACLE RAC並行集群系統,從理論上根本上解決了擴展性不足的問題,並且預留了充分的擴展空間。這次升級跨度很大，操作系統平台從win2000 (32位)升級為IBM AIX (64位)，數據庫從 oracle 9.2.01(32位)升級為oracle 10.2.01(64位) 使用了oracle RAC集群系統 . 我院在2007年9月21日進行了系統升級，由於准備的比較充分，系統升級比較順利，碰見了幾個小問題也很快的解決了.當時系統負載為客戶端為600左右，但新系統的性能並不像我們想象的哪麼理想,一些大的查詢和業務性能出現了下降，系統整體性能出了下降。由於當時性能可以滿足業務的要求，我們當時也沒找到具體原因。到了2008年3月，我院的新急救大樓投入了使用，HIS客戶端從600台增加到了800台,這時性能出現了更進一步的下降，更為嚴重的是，高峰期，集群系統經常死機。這嚴重影響了醫院正常工作。 由於系統的錯誤很特別，我們沒什麼方法可以解決，我把每次系統的錯誤都傳給了ORACLE 技術支持工程師，他們也分析不出原因，他們建議我們升級到 Oracle 10.2.03，也許可以解決我們的問題。費了很大力氣升完級，問題依舊，性能還是很差。由於新樓的科室不斷增加，情況越來越壞。 為了查清楚性能差的關鍵因素，我對數據庫做了6小時的性能分析報告(oracle awr報告)。報告顯示最耗資源的前SQL 語句(Oracle top 5 sql)均為:
SELECT OWNER, SYNONYM_NAME FROM SYS.ALL_SYNONYMS WHERE OWNER = 'PUBLIC' AND SYNONYM_NAME =‘表名稱’
這些語句應該是ORACLE 內部處理事件, SYS.ALL_SYNONYMS是內部系統視圖，‘表名稱’是我們存放數據的表。我對比了ORACLE 9.201的SYS.ALL_SYNONYMS視圖定義和我們現在Oracle 10.2.03的SYS.ALL_SYNONYMS視圖定義,發現SYS.ALL_SYNONYMS定義發生了變化
CREATE OR REPLACE FORCE VIEW "SYS"."ALL_SYNONYMS" ("OWNER", "SYNONYM_NAME", "TABLE_OWNER", "TABLE_NAME", "DB_LINK") AS
select u.name, o.name, s.owner, s.name, s.node
from sys.user$ u, sys.syn$ s, sys.obj$ o
where o.obj# = s.obj#
and o.type# = 5
and o.owner# = u.user#
and (
o.owner# in (USERENV('SCHEMAID'), 1 /* PUBLIC */) /* user's private, any public */
or /* user has any privs on base object */
Exists
(select null from sys.objauth$ ba, sys.obj$ bo, sys.user$ bu
where bu.name = s.owner
and bo.name = s.name
and bu.user# = bo.owner#
and ba.obj# = bo.obj#
and ( ba.grantee# in (select kzsrorol from x$kzsro)
or ba.grantor# = USERENV('SCHEMAID') ))
or /* user has system privileges */
exists (select null from v$enabledprivs
where priv_number in (-45 /* LOCK ANY TABLE */,
-47 /* SELECT ANY TABLE */,
-48 /* INSERT ANY TABLE */,
-49 /* UPDATE ANY TABLE */,
-50 /* DELETE ANY TABLE */) ))
以上為ORACLE 9.2.01 SYS.ALL_SYNONYMS視圖定義,Oracle 10.2.04在以上基礎上增加了以下部分：
union
select u.name, o.name, s.owner, s.name, s.node
from sys.user$ u, sys.syn$ s, sys.obj$ o, sys."_ALL_SYNONYMS_TREE" st
where o.obj# = s.obj#
and o.type# = 5
and o.owner# = u.user#
and o.obj# = st.syn_id /* syn is in tree pointing to Accessible base obj */
and s.obj# = st.syn_id /* syn is in tree pointing to Accessible base obj */
我使用 set autotrace traceonly分別在oracle 9.2.01和oracle 10.2.03對以下查詢語句的執行計劃進行了分析: Select * from SYS.ALL_SYNONYMS發現ORACLE 10.2.03執行計劃的效率比Oracle 9.201執行計劃的效率差了幾十倍。我們HIS系統的對所有表都建了同義詞(SYNONYM)，所有表的訪問都是通過同義詞,所以可以確定，性能的嚴重下降是由於SYS.ALL_SYNONYMS系統視圖定義改變造成的。
對此我們首先采用了采用了“移花接木”方法, 增加私有同義詞以跳過sys.all_synonms的處理,CREATE OR REPLACE FORCE VIEW sys.ALL_SYNONYMS_9201 as (select ……注ORACLE 9.2.01 sys.all_synonms定義),在公共用戶下創建了同義詞CREATE SYNONYM puba.ALL_SYNONYMS FOR SYS.ALL_SYNONYMS_9201 ，我們HIS系統所有的訪問都是通過PUBA用戶下建的同義詞來玩成訪問，ORACLE 數據庫中用戶下的同義詞優先級要高於系統同義詞,即PUBA.ALL_SYSNONYMS的優先級要高於sys.all_synonms完成此操作，系統應該啟用ORACLE 9.2.01下的sys.all_synonms系統視圖代替Oracle 10.2.03下的sys.all_synonms系統視圖，通過SQLPLUS 和PL/SQL等工具測試，均達到了我們目的，但我們HIS系統依然性能沒有改變。從我做的性能報告分析,系統對同義詞的處理沒用采用我們建的私有同義詞，我們分析，也許是我們HIS系統開發工具是POWERBUILD,它是一種專用的數據庫開發工具，也許它可以繞過我們建的私用同義詞，直接訪問Oracle 系統同義詞。
到此，可以采用的間接方法，已經沒有了。我想直接修改ORACLE 10.2.03 中sys.all_synonms視圖定義為ORACLE 9.2.01視圖定義，即去掉新增加那部分語句,由於sys.all_synonms是Oracle 數據庫內部系統視圖，修改定義具有很大的風險，而且我們這是負載很高很重要的生產系統，我不敢冒然行事。我把自己自己處理經過和分析和ORACLE 支持工程師進行了溝通，並且咨詢是否可以把ORACLE 10.2.03中SYS.ALL_SYNONYMS定義變成ORACLE 9.2.01 SYS.ALL_SYNONYMS的定義,由於SYS.ALL_SYNONYMS是ORACLE 內部很重要系統視圖,ORACLE 技術支持工程師也不清楚這樣是否可行，他表示要與美國公司開發工程師咨詢.最後,ORACLE 公司給出了明確的答復，系統視圖改變是因為，如果對同義詞再建同義詞,ORACLE 9.2.01有一個嚴重BUG，因此他們在Oracle 10G對視圖進行了修改，如果我們系統中沒有使用對同義詞再建同義詞，我們可以修改視圖。我們系統沒有他們說的那種BUG，因此我們立即修改了視圖，效果立竿見影,高峰期兩台小機的負載從80%~90%下降到了20%~30%，所有的功能的性能都得到了顯著的提升，困擾我們小機性能問題終於得到了完美的解決。
現在隨著信息化的發展，很多醫院的軟硬件都在升級，升級過程中都會或多或少碰到問題，要善於抓住問題的重點(我個人認為，一般軟件的問題可能性大些,因為硬件性能越來越好),對系統內部修改一定要與軟件廠商進行溝通。 最後希望我們醫院經驗可以對醫院同行帶來一些幫助。
