解決HIS叢集系統的效能問題一例

摘要

　　我院在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%，所有的功能的效能都得到了顯著的提升，困擾我們小機效能問題終於得到了完美的解決。

　　現在隨著資訊化的發展，很多醫院的軟硬體都在升級，升級過程中都會或多或少碰到問題，要善於抓住問題的重點(我個人認為，一般軟體的問題可能性大些,因為硬體效能越來越好),對系統內部修改一定要與軟體廠商進行溝通。 最後希望我們醫院經驗可以對醫院同行帶來一些幫助。

[@more@]