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