数据库性能优化有哪些措施？

1、调整数据结构的设计

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

2、调整应用程序结构设计

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

3、调整数据库SQL语句

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

4、调整服务器内存分配

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

5、调整硬盘I/O

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

6、调整 *** 作系统参数

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

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

一、ORACLE数据库性能优化工具

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

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

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

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

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

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

二、ORACLE数据库的系统性能评估

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

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

数据库回滚段是否足够?

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

系统全局区(SGA)大小是否足够?

SQL语句是否高效?

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

是否采用B*-索引或者bitmap索引?

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

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

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

三、SQL语句的调整原则

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

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

语句A：SELECTdname,deptnoFROMdeptWHEREdeptnoNOTIN

(SELECTdeptnoFROMemp)

语句B：SELECTdname,deptnoFROMdeptWHERENOTEXISTS

(SELECTdeptnoFROMempWHEREdept.deptno=emp.deptno)

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

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

SELECTstuffFROMtabaa,tabbb,tabcc

WHEREa.acolbetween:alowand:ahigh

ANDb.bcolbetween:blowand:bhigh

ANDc.ccolbetween:clowand:chigh

ANDa.key1=b.key1

AMDa.key2=c.key2

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

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

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

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

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数据字典中“CPUusedbythissession”统计项得知ORACLE数据库使用的CPU时间，查看“OSUserlevelCPUtime”统计项得知 *** 作系统用户态下的CPU时间，查看“OSSystemcallCPUtime”统计项得知 *** 作系统系统态下的CPU时间， *** 作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占 *** 作系统总的CPU时间90%以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。

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

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

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

SELECT*FROMV$SYSSTATWHERENAMEIN

('parsetimecpu','parsetimeelapsed','parsecount(hard)')

这里parsetimecpu是系统服务时间，parsetimeelapsed是响应时间，用户等待时间，waitetime=parsetimeelapsed_parsetimecpu

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

SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREA

ORDERBYPARSE_CALLS

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

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

SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA

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

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

五、内存参数的调整

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

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

select(sum(pins-reloads))/sum(pins)"LibCache"fromv$librarycache

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

select(sum(gets-getmisses-usage-fixed))/sum(gets)"RowCache"fromv$rowcache

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

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

SELECTname,valueFROMv$sysstatWHEREnameIN('dbblockgets','consistentgets','physicalreads')

来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。

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

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

selectname,valuefromv$sysstatwherenamein('redoentries','redologspacerequests')

查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率：

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

昆明北大青鸟java培训班转载自网络如有侵权请联系我们感谢您的关注谢谢支持

你最好买一本专门讲ORACLE性能优化的书，好好看看\x0d\x0a1、调整数据库服务器的性能\x0d\x0aOracle数据库服务器是整个系统的核心，它的性能高低直接影响整个系统的性能，为了调整Oracle数据库服务器的性能，主要从以下几个方面考虑： \x0d\x0a1.1、调整 *** 作系统以适合Oracle数据库服务器运行\x0d\x0aOracle数据库服务器很大程度上依赖于运行服务器的 *** 作系统，如果 *** 作系统不能提供最好性能，那么无论如何调整，Oracle数据库服务器也无法发挥其应有的性能。 \x0d\x0a1.1.1、为Oracle数据库服务器规划系统资源 \x0d\x0a据已有计算机可用资源, 规划分配给Oracle服务器资源原则是：尽可能使Oracle服务器使用资源最大化,特别在Client/Server中尽量让服务器上所有资源都来运行Oracle服务。 \x0d\x0a1.1.2、调整计算机系统中的内存配置 \x0d\x0a多数 *** 作系统都用虚存来模拟计算机上更大的内存，它实际上是硬盘上的一定的磁盘空间。当实际的内存空间不能满足应用软件的要求时， *** 作系统就将用这部分的磁盘空间对内存中的信息进行页面替换，这将引起大量的磁盘I/O *** 作，使整个服务器的性能下降。为了避免过多地使用虚存，应加大计算机的内存。 \x0d\x0a1.1.3、为Oracle数据库服务器设置 *** 作系统进程优先级 \x0d\x0a不要在 *** 作系统中调整Oracle进程的优先级，因为在Oracle数据库系统中，所有的后台和前台数据库服务器进程执行的是同等重要的工作，需要同等的优先级。所以在安装时，让所有的数据库服务器进程都使用缺省的优先级运行。 \x0d\x0a1.2、调整内存分配\x0d\x0aOracle数据库服务器保留3个基本的内存高速缓存，分别对应3种不同类型的数据：库高速缓存，字典高速缓存和缓冲区高速缓存。库高速缓存和字典高速缓存一起构成共享池，共享池再加上缓冲区高速缓存便构成了系统全程区(SGA)。SGA是对数据库数据进行快速访问的一个系统全程区，若SGA本身需要频繁地进行释放、分配，则不能达到快速访问数据的目的，因此应把SGA放在主存中，不要放在虚拟内存中。内存的调整主要是指调整组成SGA的内存结构的大小来提高系统性能，由于Oracle数据库服务器的内存结构需求与应用密切相关，所以内存结构的调整应在磁盘I/O调整之前进行。 \x0d\x0a1.2.1、库缓冲区的调整 \x0d\x0a库缓冲区中包含私用和共享SQL和PL/SQL区，通过比较库缓冲区的命中率决定它的大小。要调整库缓冲区，必须首先了解该库缓冲区的活动情况，库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect sum(pins),sum(reloads) from v$librarycache \x0d\x0a \x0d\x0aPins列给出SQL语句，PL/SQL块及被访问对象定义的总次数；Reloads列给出SQL 和PL/SQL块的隐式分析或对象定义重装载时在库程序缓冲区中发生的错误。如果sum(pins)/sum(reloads) ≈0，则库缓冲区的命中率合适；若sum(pins)/sum(reloads)>1, 则需调整初始化参数 shared_pool_size来重新调整分配给共享池的内存量。 \x0d\x0a1.2.2、数据字典缓冲区的调整 \x0d\x0a数据字典缓冲区包含了有关数据库的结构、用户、实体信息。数据字典的命中率，对系统性能影响极大。数据字典缓冲区的使用情况记录在动态性能表v$librarycache中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect sum(gets),sum(getmisses) from v$rowcache \x0d\x0a \x0d\x0aGets列是对相应项请求次数的统计；Getmisses 列是引起缓冲区出错的数据的请求次数。对于频繁访问的数据字典缓冲区，sum(getmisses)/sum(gets)<10%～15%。若大于此百分数，则应考虑增加数据字典缓冲区的容量，即需调整初始化参数shared_pool_size来重新调整分配给共享池的内存量。 \x0d\x0a1.2.3、缓冲区高速缓存的调整 \x0d\x0a用户进程所存取的所有数据都是经过缓冲区高速缓存来存取，所以该部分的命中率，对性能至关重要。缓冲区高速缓存的使用情况记录在动态性能表v$sysstat中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect name,value from v$sysstat where name in ('dbblock gets','consistent gets','physical reads') \x0d\x0a \x0d\x0adbblock gets和consistent gets的值是请求数据缓冲区中读的总次数。physical reads的值是请求数据时引起从盘中读文件的次数。从缓冲区高速缓存中读的可能性的高低称为缓冲区的命中率，计算公式： \x0d\x0a \x0d\x0aHit Ratio=1-(physical reds/(dbblock gets+consistent gets))\x0d\x0a \x0d\x0a如果Hit Ratio<60%～70%，则应增大db_block_buffers的参数值。db_block_buffers可以调整分配给缓冲区高速缓存的内存量，即db_block_buffers可设置分配缓冲区高速缓存的数据块的个数。缓冲区高速缓存的总字节数=db_block_buffers的值*db_block_size的值。db_block_size 的值表示数据块大小的字节数，可查询 v$parameter 表： \x0d\x0a \x0d\x0aselect name,value from v$parameter where name='db_block_size' \x0d\x0a \x0d\x0a在修改了上述数据库的初始化参数以后，必须先关闭数据库，在重新启动数据库后才能使新的设置起作用。

在Oracle数据库中 创建索引虽然比较简单 但是要合理的创建索引则比较困难了 笔者认为 在创建索引时要做到三个适当 即在适当的表上 适当的列上创建适当数量的索引 虽然这可以通过一句话来概括优化的索引的基本准则 但是要做到这一点的话 需要数据库管理员做出很大的努力 具体的来说 要做到这个三个适当有如下几个要求

一 根据表的大小来创建索引

虽然给表创建索引 可以提高查询的效率 但是数据库管理员需要注意的是 索引也需要一定的开销的 为此并不是说给所有的表都创建索引 那么就可以提高数据库的性能 这个认识是错误的 恰恰相反 如果不管三七二十一 给所有的表都创建了索引 那么其反而会给数据库的性能造成负面的影响 因为此时滥用索引的开销可能已经远远大于由此带来的性能方面的收益 所以笔者认为 数据库管理员首先需要做到 为合适的表来建立索引 而不是为所有的表建立索引

一般来说 不需要为比较小的表创建索引 如在一个ERP系统的数据库中 department表用来存储企业部门的信息 一般企业的部分也就十几个 最多不会超过一百个 这 条记录对于人来说 可能算是比较多了 但是对于计算机来说 这给他塞塞牙缝都还不够 所以 对类似的小表没有必要建立索引 因为即使建立了索引 其性能也不会得到很大的改善 相反索引建立的开销 如维护成本等等 要比这个要大 也就是说 付出的要比得到的多 显然违反常理

另外 就是对于超大的表 也不一定要建立索引 有些表虽然比较大 记录数量非常的多 但是此时为这个表建立索引并一定的合适 如系统中有一张表 其主要用来保存数据库中的一些变更信息 往往这些信息只给数据库管理员使用 此时为这张表建立索引的话 反而不合适 因为这张表很少用到 只有在出问题的时候才需要查看 其次其即使查看 需要查询的纪录也不会很多 可能就是最近一周的更新记录等等 对于对于一些超大的表 建立索引有时候往往不能够达到预计的效果 而且在打表上建立索引 其索引的开销要比普通的表大的多 那么到底是否给大表建立索引呢?笔者认为 主要是看两个方面的内容 首先是需要关注一下 在这张大表中经常需要查询的记录数量 一般来说 如果经常需要查询的数据不超过 %到 %的话 那就没有必要为其建立索引的必要 因为此时建立索引的开销可能要比性能的改善大的多 这个比例只是一个经验的数据 如果数据库管理员需要得出一个比较精确的结论 那么就需要进行测试分析 即数据库管理员需要测试一下全表扫描的时间 看看其是否比建立索引后的查询时间要长或者短 如果是长的话 则说明有建立索引的必要 但是如果没有的话 则说明还是全表扫描速度来的快 此时也就没有必要建立索引了

总之 在考虑是否该为表建立索引时 一般来说小表没有建立索引的必要 而对于打表的话 则需要进行实际情况实际分析 简单一点的 可以根据大致的比率来确定 如果要精确一点的 则可以进行全表扫描性能分析 以判断建立索引后是否真的如预期那样改善了数据库性能

二 根据列的特征来创建索引

列的特点不同 索引创建的效果也不同 数据库管理员需要了解为哪些列创建索引可以起到事倍功半的效果 同时也需要了解为哪些列创建索引反而起到的是事倍功半的效果 这有利于他们了解到底给为怎么样的字段建立索引

根据笔者的经验 往往为如下特征的列创建索引能够起到比较明显的效果 如对于一些重复内容比较少的列 特别是对于那些定义了唯一约束的列 在这些列上建立索引 往往可以起到非常不错的效果 如对于一些null值的列与非Null值的列混合情况下 如果用户需要经常查询所有的非Null值记录的列 则最好为其设置索引 如果经常需要多表连接查询 在用与连接的列上设置索引可以达到事半功倍的效果

可见 索引设置的是否恰当 不仅跟数据库设计架构有关 而且还跟企业的经济业务相关 为此 对于一些套装软件 虽然一开始数据库管理员已经做了索引的优化工作 但是随着后来经济数据的增加 这个索引的效果会越来越打折扣 这主要是因为记录的表化影响到了索引优化的效果 所以笔者建议各位数据库管理员 即使采用的是大牌软件公司的套装软件 也需要隔一段时间 如一年 对数据库的索引进行优化 该去掉的去掉 该调整的调整 以提高数据库的性能

如在数据库中有一张表是用来保存用户信息的 其中有个字段身份z号码 这是一个唯一的字段 在数据库设计时 给这个字段创建了索引 但是当这个数据库投入使用之后 用户不怎么输入用户的身份z号码 而且平时也基本不按这个号码来进行查询 当记录月来月多时 这个身份z号码上的索引字段不但不能够改善数据库的查询性能 反而成了鸡肋 对于这些有很多NULL值的列 而且不会经常查询所有的非NULL值记录的列 数据库管理员要下决心 即使清除这些列上的索引

所以说索引的优化与调整是一个动态的过程 并不是说数据库设计好之后就不需要经过调整 数据库管理员往往需要根据记录的变化情况 来进行适当的变更 以提高索引的效果

三 在一个表上创建多少索引合适?

虽然说 在表上创建索引的数量没有限制 但是决不是越多越好 也就是说 在创建索引这项事情上 + 〉 往往不成立 有时候 创建索引越多 其可能会得到适得其反的效果 那么在一个表上 到底给创建多少索引合适呢?这个没有一个明确的标准 而是需要数据库管理员根据实际的用途以及数据库中记录的情况 来进行判断

通常来说 表的索引越多 其查询的速度也就越快 但是 表的更新速度则会降低 这主要是因为表的更新(如往表中插入一条记录)速度 反而随着索引的增加而增加 这主要是因为 在更新记录的同时需要更新相关的索引信息 为此 到底在表中创建多少索引合适 就需要在这个更新速度与查询速度之间取得一个均衡点 如对于一些数据仓库或者决策型数据库系统 其主要用来进行查询 相关的记录往往是在数据库初始化的时候倒入 此时 设置的索引多一点 可以提高数据库的查询性能 同时因为记录不怎么更新 所以索引比较多的情况下 也不会影响到更新的速度 即使在起初的时候需要导入大量的数据 此时也可以先将索引禁用掉 等到数据导入完毕后 再启用索引 可以通过这种方式来减少索引对数据更新的影响 相反 如果那些表中经常需要更新记录 如一些事务型的应用系统 数据更新 *** 作是家常便饭的事情 此时如果在一张表中建立过多的索引 则会影响到更新的速度 由于更新 *** 作比较频繁 所以对其的负面影响 要比查询效率提升要大的多 此时就需要限制索引的数量 只在一些必要的字段上建立索引

笔者在平时数据库优化时 往往会根据这些表的用途来为列设置索引 可以查询相关的动态视图 看看对于这张表的 *** 作 是更新 *** 作(包括更新 删除 插入等等)占的比例大 还是查询 *** 作占的比例大 当过多的索引已经影响到更新 *** 作的速度时 则数据库管理员就需要先禁用某些索引 以提高数据库的性能

lishixinzhi/Article/program/Oracle/201311/18407

---