解决HIS集群系统的性能问题一例

摘要

我院在 年 月 日成功将HIS系统从win oracle 升级到两台IBM P A ( *** 作系统AIX) oracle RAC组成的并行集群系统 随着一个新大楼的启用 客户端的电脑从 台增加到了 多台 集群系统出现了严重的性能问题 在业务高峰期经常死机 经过半个月左右的调试 终于彻底解决了性能问题 满足了医院医院业务发展的要求

关键词

ORACLE RAC (ORACLE Real Application Clusters): ORACLE 真正应用集群

新疆维吾尔自治区人民医院是新疆最大的三级甲等医院 病床 张以上 日门诊量 左右 为了满足医院发展的需要 自 年新HIS系统上线 医院的信息化得到了全面的提升 客户端工作站达到了 左右 其中HIS工作站近 台 随着客户数的增加 我院的系统表现出了扩展性不足的问题 这主要是WINDOWS 位 *** 作系统 G内存限制造成 虽然我们经过参数修改 服务器内存升级为 G 但由于系统核心 位限制 当高峰期客户数达到 左右 前端工作站就不能继续连接 且一些大的统计分析不能执行 一些已连接用户也陆续不能使用 最后服务器上数据库DBA用户也不能连接 这时候只有重新启动服务器 才能解决问题 据了解全国一些大医院也面临我院同样的问题

在这种情况下 我院经过充分考证 借鉴电信和银行的小机 ORACLE RAC并行集群系统成功经验 经过尽一年的准备 成功采用两台IBM小机(IMB P A 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 SYS ALL_SYNONYMS WHERE OWNER = PUBLIC AND SYNONYM_NAME = 表名称

这些语句应该是ORACLE 内部处理事件 SYS ALL_SYNONYMS是内部系统视图 表名称 是我们存放数据的表 我对比了ORACLE 的SYS ALL_SYNONYMS视图定义和我们现在ORACLE 的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# =

and o owner# = u user#

and (

o owner# in (USERENV( SCHEMAID ) / 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 ( / LOCK ANY TABLE /

/ SELECT ANY TABLE /

/ INSERT ANY TABLE /

/ UPDATE ANY TABLE /

/ DELETE ANY TABLE /) ))

以上为ORACLE SYS ALL_SYNONYMS视图定义 ORACLE 在以上基础上增加了以下部分

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# =

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 和oracle 对以下查询语句的执行计划进行了分析: Select from SYS ALL_SYNONYMS发现ORACLE 执行计划的效率比ORACLE 执行计划的效率差了几十倍 我们HIS系统的对所有表都建了同义词(SYNONYM) 所有表的访问都是通过同义词 所以可以确定 性能的严重下降是由于SYS ALL_SYNONYMS系统视图定义改变造成的

对此我们首先采用了采用了 移花接木 方法 增加私有同义词以跳过sys all_synonms的处理 CREATE OR REPLACE FORCE VIEW sys ALL_SYNONYMS_ as (select ……注ORACLE sys all_synonms定义) 在公共用户下创建了同义词CREATE SYNONYM puba ALL_SYNONYMS FOR SYS ALL_SYNONYMS_ 我们HIS系统所有的访问都是通过PUBA用户下建的同义词来玩成访问 ORACLE 数据库中用户下的同义词优先级要高于系统同义词 即PUBA ALL_SYSNONYMS的优先级要高于sys all_synonms完成此 *** 作 系统应该启用ORACLE 下的sys all_synonms系统视图代替ORACLE 下的sys all_synonms系统视图 通过SQLPLUS 和PL/SQL等工具测试 均达到了我们目的 但我们HIS系统依然性能没有改变 从我做的性能报告分析 系统对同义词的处理没用采用我们建的私有同义词 我们分析 也许是我们HIS系统开发工具是POWERBUILD 它是一种专用的数据库开发工具 也许它可以绕过我们建的私用同义词 直接访问ORACLE 系统同义词

到此 可以采用的间接方法 已经没有了 我想直接修改ORACLE 中sys all_synonms视图定义为ORACLE 视图定义 即去掉新增加那部分语句 由于sys all_synonms是ORACLE 数据库内部系统视图 修改定义具有很大的风险 而且我们这是负载很高很重要的生产系统 我不敢冒然行事 我把自己自己处理经过和分析和ORACLE 支持工程师进行了沟通 并且咨询是否可以把ORACLE 中SYS ALL_SYNONYMS定义变成ORACLE SYS ALL_SYNONYMS的定义 由于SYS ALL_SYNONYMS是ORACLE 内部很重要系统视图 ORACLE 技术支持工程师也不清楚这样是否可行 他表示要与美国公司开发工程师咨询 最后 ORACLE 公司给出了明确的答复 系统视图改变是因为 如果对同义词再建同义词 ORACLE 有一个严重BUG 因此他们在ORACLE G对视图进行了修改 如果我们系统中没有使用对同义词再建同义词 我们可以修改视图 我们系统没有他们说的那种BUG 因此我们立即修改了视图 效果立竿见影 高峰期两台小机的负载从 %~ %下降到了 %~ % 所有的功能的性能都得到了显著的提升 困扰我们小机性能问题终于得到了完美的解决

lishixinzhi/Article/program/Oracle/201311/18849

看应用情况了，像大型的应用都是一个团队或多个团队维护一个数据库

中小型的应用 一般情况是主要业务数据库一个，其它数据库若干个。

再小型的应用就像数据中心那种，就是一组人负责N个数据库

一般DBA只负责数据库的性能监控，出现问题快速排查。

我这边是主要业务数据库一个，其它小应用有七八个。

感觉有忙起来也很忙的，清闲时候大多时候要看一些资料文档什么。

经常会有人问我数据库是干啥的，其实一开始我是拒绝回答的，因为我也不能做到通俗易懂的表达出来，毕竟我接触这个概念也没有多长时间，但随着问的人多了，我觉得是时候脑补一下我的第一堂课了，万一哪天冒出来个货跟你掰扯这事儿，你没分分钟给他说清，最后弄个丢里儿丢面儿，好尴尬呀。

数据库，说白了就是按照数据结构来组织、存储和管理数据的仓库，这些数据是结构化的，并可为多种应用服务。也就是说，数据库是使用计算机服务器来存储数据的，专门用来提供各种数据服务。可以这样想像，过去一个公司的所有财务数据都是放在保险柜里面，而现在我们就可以针对这些财务数据搭建一个数据库放在某台计算机或服务器上面;再比如，企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表中，这张表就可以看成是一个数据库。有了这个"数据仓库"我们就可以根据需要随时查询某职工的基本情况，也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行，那我们的人事管理就可以达到极高的水平。此外，在财务管理、仓库管理、生产管理中也需要建立众多的这种"数据库"，使其可以利用计算机实现财务、仓库、生产的自动化管理。最常见的数据库有：银行储蓄系统、手机话费系统、美容美发会员系统、超市会员积分系统、水电费系统、机票或火车票系统等，这些都需要后台数据库基础设施的支撑。举了这么多例子，应该是把数据库说明白了，至少能在大脑里面有个概念，知道这个东西是干啥的。

现在大数据被炒的红得发紫，而大数据的基础也是数据，由此可见，数据是一个企业的核心资源，说它是企业的立身之本、发展之基都不为过，因此，维护数据库的数据库管理员(DBA)是企业不可或缺的。

目前市面上的数据库产品有很多，单从规模上分可分为大型、中型、小型几种，典型的数据库产品如下：

大型数据库：Oracle、DB2、Sybase;

中型数据库：MySQL、SQLServer、Infomix;

小型数据库：Access、VisualFoxpro。在众多的数据库产品中，Oracle数据库一直处于行业领导先地位，也是当今最流行的关系型数据库。Oracle可翻译成"甲骨文"，它是一家以数据库为主业的全球化公司，是全球第二大软件公司(第一名是微软公司)，目前Oracle在数据库软件市场已经排名第一，数据库软件市场份额达到486%，遥遥领先于第二名占有率仅为207%的IBM公司的DB2。在中国市场上的计算机专业系统后台所使用的数据库尤以Oracle数据库居多。但是购买Oracle数据库需要很大一笔费用，一般的大型企业使用，需要有专业人员进行管理和维护，中小企业承担不起。中小企业为了节省成本，一般使用MySQL、PostgreSQL这类免费开源的数据库，所以Oracle数据库相关的工作岗位一般是在大型企业中。

对于为什么选择Oracle数据库，而不是其他的数据库

第一，是因为Oracle数据库占据最大的市场份额，并且越来越大，市场需要很多Oracle数据库方面的人才，中国有句老话说"做对事，选对人"，是同样的道理;第二，是很多非Oracle数据库的老系统正往Oracle数据库迁移，其他数据库市场占有率在减少，其他数据库工作者有面临失业的风险;第三，Oracle有大量的官方学习文档，还有部分中文文档，可以有效地进行学习;第四，Oracle有大量的从业人员，有共同方向的朋友可以互相帮助，不再是孤胆英雄;第五，是可以很容易地从Oracle官方网站下载功能齐全的数据库最新版本进行学习，可以让你了解数据库方面的最新发展趋势等。

在此说明，以后的所有内容都是基于Oracle11g数据库产品的，下面我们就简单介绍一下Oracle11g的系列产品：

企业版(EnterpriseEdition)此版本包含了数据库的所有组件，并且能够通过购买选项和程序包来进一步对其增强。

能支持例如大业务量的在线事务处理OLTP(On-LineTransactionProcessing联机事务处理系统)环境、查询密集的数据仓库和要求苛刻的互联网应用程序。

标准版1(StandardEditionOne)此版本为工作组、部门级和互联网、内联网应用程序提供了前所未有的易用性和性价比。从针对小型商务的单服务器环境到大型的分布式部门环境，该版本包含了构建重要商务应用程序所必需的全部工具。它仅许可在最高容量为2个处理器的服务器上使用，支持Windows/Linux/UNIX *** 作系统，并支持64位平台 *** 作系统。

标准版(StandardEdition)此版本提供了StandardEditionOne所不具有的易用性、能力和性能，并且利用真正的应用集群(RAC)提供了对更大型计算机和服务集群的支持。它可以在最高容量为4个处理器的单台服务器上、或者在一个支持最多4个处理器的集群上使用，可支持Windows、Linux和UNIX *** 作系统，并支持64位平台 *** 作系统。

简化版此版本支持与标准版1、标准版和企业版完全兼容的单用户开发和部署。通过将Oracle数据库获奖的功能引入到个人工作站中，该版本提供了结合世界上最流行的数据库功能的数据库，并且该数据库具有桌面产品通常具有的易用性和简单性，可支持Linux和Windows *** 作系统。

从存储结构上来说，目前流行的数据库主要包含以下两种：

RDBMS：关系型数据库，是指采用了关系模型来组织数据的数据库;

NoSQL数据库，是指那些非关系型的、分布式的数据库。简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

关系型数据库优点：

1、容易理解

二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解。

2、使用方便

通用的SQL语言使得 *** 作关系型数据库非常方便。

3、易于维护

丰富的完整性大大减低了数据冗余和数据部移植的概率。

4、事务安全

所有关系型数据库都不同程度的遵守事物的四个基本属性，因此对于银行、电信、证券等交易型业务是不可或缺的。

关系型数据库的瓶颈：

1、高并发读写需求

网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统型数据库来说，硬盘I/O是一个很大的瓶颈。

2、海量数据的高效率读写

互联网上每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的。

3、高扩展性和可用性

在基于WEB的结构中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像WEBServer和APPLICATIONServer那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

NoSQL数据库

NoSQL一词首先是CarloStrozzi在1998年提出的。2009年再次提出了NoSQL一词，用于指那些非关系型的、分布式的，且一般不保证遵循ACID原则的数据存储系统。

NoSQL具有以下特点：

1、可以弥补关系型数据库的不足

2、针对某些特定的需求而设计，可以具有极高的性能

3、大部分都是开源的，由于成熟度不够，存在潜在的稳定性和维护性问题。

关系型数据库适用于结构化数据，而非关系型数据库适用于非结构化数据，二者优势互补，相得益彰。

Oracle数据库未来的发展方向是提供结构化、非结构化、半结构化的解决方案，实现关系型数据库和NoSQL共存互补。值得强调的是，目前关系型数据库仍是主流数据库。

虽然NoSQL数据库打破了关系型数据库存储的观念，可以很好地满足WEB20时代数据的存储要求，但NoSQL数据库也有自己的缺陷。在现阶段的情况下，可以将关系型数据库和NoSQL数据库结合使用，相互弥补各自的不足。

关于数据库及其代表产品Oracle今天就介绍这么多，有兴趣的可以继续深挖，希望我的介绍能让你对数据库有一个更深入的认识。如果有志于在这方面发展的话，就让我们一起跟往事干杯从头再来。

我是来混分的

我的意见是

创建索引， 移除历史数据到备份表中

下面的内容来自别人总结的， 呵呵

1、1、调整数据结构的设计。这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。

2、2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。

3、3、调整数据库SQL语句。应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row-level manager）来调整优化SQL语句。

4、4、调整服务器内存分配。内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（PGA区）的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用 *** 作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。

5、5、调整硬盘I/O，这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。

6、6、调整 *** 作系统参数，例如：运行在UNIX *** 作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。

实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。

ORACLE数据库性能优化工具

常用的数据库性能优化工具有：

1、1、ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。

2、2、 *** 作系统工具，例如UNIX *** 作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现在什么地方有时候很有用。

3、3、SQL语言跟踪工具（SQL TRACE FACILITY），SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个 *** 作系统的文件，管理员可以使用TKPROF工具查看这些文件。

4、4、ORACLE Enterprise Manager（OEM），这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。

5、5、EXPLAIN PLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。

ORACLE数据库的系统性能评估

信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。

1、1、在线事务处理信息系统（OLTP），这种类型的信息系统一般需要有大量的Insert、Update *** 作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数：

l l 数据库回滚段是否足够？

l l 是否需要建立ORACLE数据库索引、聚集、散列？

l l 系统全局区（SGA）大小是否足够？

l l SQL语句是否高效？

2、2、数据仓库系统（Data Warehousing），这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数：

l l 是否采用B-索引或者bitmap索引？

l l 是否采用并行SQL查询以提高查询效率？

l l 是否采用PL/SQL函数编写存储过程？

l l 有必要的话，需要建立并行数据库提高数据库的查询效率

SQL语句的调整原则

SQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAIN PLAN语句来比较各种实现方案，并选出最优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则：

1、1、尽量使用索引。试比较下面两条SQL语句：

语句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN

(SELECT deptno FROM emp);

语句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS

(SELECT deptno FROM emp WHERE deptdeptno = empdeptno);

这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。

2、2、选择联合查询的联合次序。考虑下面的例子：

SELECT stuff FROM taba a, tabb b, tabc c

WHERE aacol between :alow and :ahigh

AND bbcol between :blow and :bhigh

AND cccol between :clow and :chigh

AND akey1 = bkey1

AMD akey2 = ckey2;

这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。

3、3、在子查询中慎重使用IN或者NOT IN语句，使用where (NOT) exists的效果要好的多。

4、4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询最好都分解为对数据表的直接查询效果要好一些。

5、5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。

6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。

CPU参数的调整

CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90％以上。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。

使用 *** 作相同命令可以看到CPU的使用情况，一般UNIX *** 作系统的服务器，可以使用sar –u命令查看CPU的使用率，NT *** 作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。

数据库管理员可以通过查看v$sysstat数据字典中“CPU used by this session”统计项得知ORACLE数据库使用的CPU时间，查看“OS User level CPU time”统计项得知 *** 作系统用户态下的CPU时间，查看“OS System call CPU time”统计项得知 *** 作系统系统态下的CPU时间， *** 作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占 *** 作系统总的CPU时间90％以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。

数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。

出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。

1、数据库管理员可以执行下述语句来查看SQL语句的解析情况：

SELECT FROM V$SYSSTAT

WHERE NAME IN

('parse time cpu', 'parse time elapsed', 'parse count (hard)');

这里parse time cpu是系统服务时间，parse time elapsed是响应时间，用户等待时间

waite time = parse time elapsed – parse time cpu

由此可以得到用户SQL语句平均解析等待时间＝waite time / parse count。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句

SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA

ORDER BY PARSE_CALLS;

来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。

2、数据库管理员还可以通过下述语句：

SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA;

查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。

3、3、数据库管理员可以通过v$system_event数据字典中的“latch free”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latch free查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。

内存参数的调整

内存参数的调整主要是指ORACLE数据库的系统全局区（SGA）的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。

1、 1、 共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句：

select (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache;

来查看共享SQL区的使用率。这个使用率应该在90％以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句：

select (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache;

查看数据字典缓冲区的使用率，这个使用率也应该在90％以上，否则需要增加共享池的大小。

2、 2、 数据缓冲区。数据库管理员可以通过下述语句：

SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');

来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。

这个命中率应该在90％以上，否则需要增加数据缓冲区的大小。

3、 3、 日志缓冲区。数据库管理员可以通过执行下述语句：

select name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率：

申请失败率＝requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。

在ASP中优化数据库处理

ASP是一个WEB服务器端的开发环境，它提供了一种简单易学的脚本（VBScript或Jscript），并带有许多内置的对象，从而提供了一条简捷的编程之路。更为重要的是，ASP中提供了ADO对象，让程序员可以轻松 *** 作各种数据库，从而可以产生和运行动态的、交互的WEB服务应用程序。目前，国内很多电子商务站点都采用了ASP技术来与数据库交互，为用户提供各类服务。

由于电子商务站点的大部分信息都存放在数据库中，要提高WEB的响应速度，建立高性能的电子商务站点，很大一部分取决于ASP与数据库之间的处理性能。因此，在ASP编写时，要注意数据库处理方法。

1、 使用Connection pool机制

在数据库处理中，资源花销最大的是建立数据库连接，而且用户还会有一个较长的连接等待时间。若每一个用户访问时，都重新建立连接，不仅用户要长时间等待，而且系统有可能会由于资源消耗过大而停止响应。如果能够重用以前建立的数据库连接，而不是每次访问时都重新建立连接，则可以很好地解决这些问题，从而提高整个系统的性能。在IIS+ASP处理体系中，采用了Connection pool机制来保证这一点。

Connection pool的原理是，IIS+ASP体系中维持了一个连接缓冲池，建立好的数据库连接在ASP程序中的断开都是逻辑断开，而实际的物理连接被存储在池中并被维护。这样，当下一个用户访问时，直接从连接缓冲池中取得一个数据库连接，而不需重新连接数据库，因此，可以大大地提高系统的响应速度。

为了正确使用Connection pool时，必须注意以下几点：

a) 在MDAC20以前的版本中，必须经过数据库驱动程序的配置才能使用Connection Pool；在以后的版本中（比如MDAC21），缺省是使用Connection Pool机制。具体配置情况可以参见微软公司的站点（）。

顺便提一句，在使用ORACLE数据库时，最好使用微软提供的驱动程序。

b) 每次数据库连接串参数必须相同，否则会被认为是不同的连接而重新去连接数据库，而不是使用缓冲池中的连接。最好的做法是将连接串存储在Application变量中，所有的程序在建立连接时使用Application变量的值。

c) 为了更好地使用和维护连接缓冲池，建议在程序中使用以下的方法对数据库连接进行 *** 作，因为隐式使用数据库连接时不能利用缓冲池的机制：

¨ 显示地创建连接对象: Set conn=ServerCreateObject(“Adodbconnection”)

¨ 建立数据库连接：connopen Application(“connection_string”),…

¨ 进行数据库 *** 作：…

¨ 显式地关闭连接对象：connclose

2、 利用直接的Ole DB驱动程序

在Asp中，通过ADO可以使用两种方式连接数据库，一种是传统的ODBC方式，一种是Ole DB方式。由于ADO是建立在Ole DB技术上的，为了支持ODBC，必须建立相应的Ole DB 到ODBC的调用转换（如MS Oledb provider for ODBC）。而使用直接的Ole DB方式（如MS Oledb provider for Sql, Oracle），则不需转换，从而提高处理速度，同时，还能利用Ole DB的新特性。

3、 在内存中缓存ADO对象或其内容

通常，在ASP程序中，都会涉及到一些存储在数据库中的常用信息，如省份列表，商品分类等，这些信息对于每一个访问用户都是相同的。若每一个用户访问时，都要去数据库里取出来，然后显示给用户，不仅会使数据库服务器负载加重，无法快速服务于更重要的事务处理，而且WEB服务器也必须不停地创建ADO对象，消耗大量资源，导致了当用户很多时几乎失去响应。若能把一些常用信息事先存储在内存中，当用户访问时，直接从内存中取出，显示给用户，则可以大大减小系统的压力，提高响应速度。

比如，我们可以把已经取得了数据的RecordSet对象存储在Application变量中，当用户访问时，从Application变量中取得RecordSet对象，而不需再次建立数据库连接；也可以将RecordSet对象里的数据以其他方式存储，比如存储在数组中，然后再将数组存储在Application变量中，使用时用数组的方式读取。

需要注意的是，一个对象要存储在Application变量中，线程模式必须是Both；对于不满足该条件的对象，必须以其他方式，比如转换成数组的方式存储在Application变量中，这也是上面所说的将内容存储在数组中的原因。

4、 使用数字序列

在Asp程序中，从诸如RecordSet中读取数据时，为了方便，常使用数据库列名的方式进行：

Responsewrite rs(“fieldnameN”)

而很少采用该数据库列名所在的数字序列来读取，即：

Responsewrite rs(N)

其实，为了从RecordSet得到列值，ADO必须将列名转化为数字序列，因此，若直接使用数字序列，则可以提高读取速度。若感觉使用数字序列，程序可读性不直观，可以采用建立常量的方法，定义：

const FIELDNAME1 1

5、 使用数据库过程(procedure)

在电子商务站点中，尤其是要进行交易的站点，为了完成交易，可能需要多次查询大量的信息，用于判定是非，然后更新入库。若在编写Asp时，直接在一个程序中作多次数据库 *** 作，不仅IIS要创建很多ADO对象，消耗资源，而且加重了数据库服务器的负担，增大了网络流量。若把多次数据库 *** 作流程定义为一个数据库过程，用如下方式调用：

connectionexecute “”

则可以利用数据库的强大性能，大大减轻Web系统的压力，而且由于页面内容与业务分开，管理维护也变得方便。

6、 使用优化过的sql语句

对于电子商务网站，最主要的就是要保证，不论访问用户的多少，系统都要有足够快的响应速度。由于在Asp技术中，ADO对象消耗的资源是非常大的，若一个sql语句要执行很长的一段时间，对整个资源也将一直占用，使系统没有足够的资源服务于其它用户。因此，尽量使用优化过的sql语句，减少执行时间。比如，不使用在in语句中包含子查询的语句，充分利用索引。

7、 利用数据库的特性

ADO是一套通用的对象控件，本身没有利用数据库的任何特性。但若在Asp程序编写时，有意识地考虑结合数据库的特性，往往可以有很好的效果。

比如，Oracle数据库服务器对于执行过的sql语句，通常都经过了分析优化，并存储在一个sql内存缓冲区中，当下次同样的sql语句请求时，直接从内存缓冲区取出执行，不再进行分析优化，从而可以大幅度提高性能。这就要求在Asp程序编写时，尽量使用相同的Sql语句，或者参数化的Sql语句：

Set cmd=Servercreateobject(“adodbcommand”)

cmdCommandText=”select from product where productcode=”

8、 用时创建，用完释放

在前面也提到过，ADO对象是非常消耗资源的，因此一定要牢牢记住，只在用到ADO对象时才创建，用完后马上释放：

set rs=Servercreateobject(“adodbrecordset”)

…

rsclose

set rs=nothing

愿您愉快地编程，让人们享受社会信息化所带来的好处。

Oracle 在执行SQL语句时，有两种优化方法：即基于规则的RBO和基于代价的CBO。 在SQL执教的时候，到底采用何种优化方法，就由Oracle参数 optimizer_mode 来决定。

SQL> show parameter optimizer_mode

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

optimizer_mode string CHOOSE

optimizer_mode 参数值共有以下四个：

第一：CHOOSE

这个是Oracle的默认值。采用这个值时，Oracle即可以采用基于规则RBO，也可以采用基于代价的CBO，到底使用那个值，取决于当前SQL的被访问的表中是不是有可以使用的统计信息。

如果有多个被访问的表，其中有一个或多个有统计信息，那么Oralce会对没有统计信息的表进行采样统计（即不全部采样），统计完成后，使用基于代价的优化方法CBO。

如果所有被访问的表都没有统计信息，Oracle就会采用基于规则的优化方法RBO。

第二：ALL_ROWS

不管是不是有统计信息，全部采用基于成本的优化方法CBO。

第三：FIRST_ROWS_n

不管是不是有统计信息，全部采用基于成本的优化方法CBO，并以最快的速度，返回前N行记录。

第四：FIRST_ROWS

使用成本和试探法相结合的方法，查找一种可以最快返回前面少数行的方法；这个参数主要用于向后兼容。

第五：RULE

这个参数正好和ALL_ROWS相反，不管是不是统计信息，全部采用基于规则的优化方法。

如何更改 optimizer_mode 的参数呢？可以用以下的方法。

SQL> alter session set optimizer_mode='RULE';

设定选用哪种优化模式：

A、Instance级别我们可以通过在initSIDora文件中设定OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS如果没设定OPTIMIZER_MODE参数则默认用的是Choose方式。

B、Sessions级别通过ALTER SESSION SET OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS来设定。

以上就是关于解决HIS集群系统的性能问题一例全部的内容，包括:解决HIS集群系统的性能问题一例、业界平均一个DBA（Oracle or DB2)管理多少套数据库工作负载合适 最好有知名公司的实际情况。、数据库是什么Oracle又是啥玩意等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！