【转载】解决HIS集群系统的性能问题一例

转自：http://blog.itpub.net/16396910/viewspace-1029636/

我院在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%，所有的功能的性能都得到了显著的提升，困扰我们小机性能问题终于得到了完美的解决。

　　现在随着信息化的发展，很多医院的软硬件都在升级，升级过程中都会或多或少碰到问题，要善于抓住问题的重点(我个人认为，一般软件的问题可能性大些,因为硬件性能越来越好),对系统内部修改一定要与软件厂商进行沟通。
最后希望我们医院经验可以对医院同行带来一些帮助。