|
摘要 我院在年月日成功将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因此我们立即修改了视图效果立竿见影高峰期两台小机的负载从%~%下降到了%~%所有的功能的性能都得到了显着的提升困扰我们小机性能问题终于得到了完美的解决 现在随着信息化的发展很多医院的软硬件都在升级升级过程中都会或多或少碰到问题要善于抓住问题的重点(我个人认为一般软件的问题可能性大些因为硬件性能越来越好)对系统内部修改一定要与软件厂商进行沟通 最后希望我们医院经验可以对医院同行带来一些帮助 |
