ORACLE数据库性能参数

xkmj

Oracle注：以下指标取自Oracle的性能分析工具Statspack所提供的性能分析指标。

指标名称	指标描述	指标范围	指标单位
1．关于实例效率（Instance Efficiency Percentages）的性能指标
缓冲区未等待率 (Buffer Nowait %)	指在缓冲区中获取Buffer的未等待比率。	该指标的值应接近100%，如果该值较低，则可能要增大buffer cache。	%
Redo缓冲区未等待率 (Redo NoWait %)	指在Redo缓冲区获取Buffer的未等待比率。	该指标的值应接近100%，如果该值较低，则有2种可能的情况： 1.online redo log没有足够的空间； 2.log切换速度较慢。	%
缓冲区命中率 (Buffer Hit %)	指数据块在数据缓冲区中的命中率。	该指标的值通常应在90%以上，否则，需要调整。如果持续小于90%，可能要加大db_cache_size。但有时，缓存命中率低并不意味着cache设置小了，可能是潜在的全表扫描降低了缓存命中率。	%
内存排序率 (In-memory Sort %)	指排序操作在内存中进行的比率。当查询需要排序的时候，数据库会话首先选择在内存中进行排序，当内存大小不足的时候，将使用临时表空间进行磁盘排序，但磁盘排序效率和内存排序效率相差好几个数量级。	该指标的值应接近100%，如果指标的值较低，则表示出现了大量排序时的磁盘I/O操作，可考虑加大sort_area_size参数的值。	%
共享区命中率 (Library Hit%)	该指标主要代表sql在共享区的命中率。	该指标的值通常应在95%以上，否则需要考虑加大共享池（修改shared_pool_size参数值），绑定变量，修改cursor_sharing等参数。	%
软解析的百分比 (Soft Parse %)	该指标是指Oracle对sql的解析过程中，软解析所占的百分比。软解析（soft parse）是指当Oracle接到Client提交的Sql后会首先在共享池（Shared Pool）里面去查找是否有之前已经解析好的与刚接到的这一个Sql完全相同的Sql。当发现有相同的Sql就直接用之前解析好的结果，这就节约了解析时间以及解析时候消耗的CPU资源。	该指标的值通常应在95%以上，如果低于80%，那么就可能sql基本没被重用，sql没有绑定变量，需要考虑绑定变量。	%
闩命中率 (Latch Hit%)	指获得Latch的次数与请求Latch的次数的比率。	该指标的值应接近100%，如果低于99%，可以考虑采取一定的方法来降低对Latch的争用。	%
SQL语句执行与 解析的比率 (Execute to Parse %)	指SQL语句执行与解析的比率。SQL语句一次解析后执行的次数越多，该比率越高，说明SQL语句的重用性很好。	该指标的值应尽可能到高，如果过低，可以考虑设置 session_cached_cursors参数。	%
共享池内存使用率 (Memory Usage %)	该指标是指在采集点时刻，共享池（share pool）内存被使用的比例。	这指标的值应保持在75%~90%,如果这个值太低，就浪费内存，如果太高，会使共享池外部的组件老化，如果SQL语句被再次执行，则就会发生硬分析。	%

xkmj

2．关于等待事件（Wait events）的性能指标

文件分散读取

(db file scattered read(cs))
该等待事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。
如果这个等待事件比较显著，可能说明对于某些全表扫描的表，没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。
厘秒

文件顺序读取

(db file sequential read(cs))
该等待事件通常与单个数据块相关的读取操作有关。
如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，或者可能不合适地使用了索引。对于大量事务处理、调整良好的系统，这一数值大多是很正常的，但在某些情况下，它可能暗示着系统中存在问题。应检查索引扫描，以保证每个扫描都是必要的，并检查多表连接的连接顺序。另外DB_CACHE_SIZE也是这些等待出现频率的决定因素。
厘秒

缓冲区忙

(buffer busy(cs))
当一个会话想要访问缓存中的某个块，而这个块正在被其它会话使用时，将会产生该等待事件。这时候，其它会话可能正在从数据文件向缓存中的这个块写入信息，或正在对这个块进行修改。
出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著，则需要根据等待事件发生在缓存中的哪一块（如字段头部、回退段头部块、回退段非头部块、数据块、索引块等），采取相应的优化方法。


厘秒



(enqueue(cs))
enqueue是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue包括一个排队机制，即FIFO(先进先出)排队机制。注意：Oracle的latch机制不是FIFO。Enqueue等待通常指的是ST enqueue、HW enqueue、TX4 enqueue和TM enqueue。
如果enqueue等待事件比较显著，则需要根据enqueue等待类型，采取相应的优化方法。
厘秒

闩释放

(latch free(cs))
该等待事件意味着进程正在等待其他进程已持有的latch。

latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch就像是一种快速地被获取和释放的内存锁。latch用于防止共享内存结构被多个用户同时访问。
对于常见的Latch等待通常的解决方法：

1）Share pool latch：在OLTP应用中应该更多的使用绑定变量以减少该latch的等待。

2）Library cache latch：同样的需要通过优化sql语句使用绑定变量减少该latch的等待。
厘秒

日志文件同步

(log file sync(cs))
这个等待事件是指当一个会话完成一个事务（提交或者回滚数据）时，必须等待LGWR进程将会话的redo信息从日志缓冲区写到日志文件后，才能继续执行下去。
这个等待事件的时间过长，可能是因为commit太频繁或者lgwr进程一次写日志的时间太长（可能是因为一次log io size太大），可调整_log_io_size，结合log_buffer,使得(_log_io_size*db_block_size)*n = log_buffer，这样可避免和增大log_buffer引起冲突，或者可以将日志文件存放在高速磁盘上
厘秒

xkmj

【IT168 技术文档】随着网络应用和电子商务的不断发展，各个站点的访问量越来越大，如何使有限的计算机系统资源为更多的用户服务？如何保证用户的响应速度和服务质量？这些问题都属于服务器性能优化的范畴。作为较成功的数据库厂商，Oracle公司数据库的性能优化是如何进行的

　　 优化策略

　　 为了保证Oracle数据库运行在最佳的性能状态下，在信息系统开发之前就应该考虑数据库的优化策略。优化策略一般包括服务器操作系统参数调整、数据库参数调整、网络性能调整、应用程序SQL语句分析及设计等几个方面，其中应用程序的分析与设计是在信息系统开发

　　 分析评价Oracle数据库性能主要有数据库吞吐量、数据库用户响应时间两项指标。数据库用户响应时间又可以分为系统服务时间和用户等待时间两项，即：

　　 数据库用户响应时间=系统服务时间＋用户等待时间

　　 因此，获得满意的用户响应时间有两个途径：一是减少系统服务时间，即提高数据库的吞吐量；二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。

　　 数据库性能优化包括如下几个部分：

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

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

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

　　 4. 调整服务器内存分配 内存分配是在信息系统运行过程中优化配置的。数据库管理员根据数据库的运行状况不仅可以调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小，而且还可以调整程序全局区（PGA区）的大小。

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

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

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

xkmj

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

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

　　 2. 操作系统工具 例如使用Unix操作系统的Vmstat、 Iostat等命令可以查看到系统级内存和硬盘I/O的使用情况，这些工具能够帮助管理员弄清楚系统瓶颈出现在什么地方。

　　 3. SQL语言跟踪工具（SQL Trace Facility）

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

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

　　 5. Explain Plan??SQL语言优化命令 使用这个命令可以帮助程序员写出高效的

　　 系统性能评估

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

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

　　 数据库回滚段是否足够？

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

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

　　 SQL语句是否高效？

　　 2. 数据仓库系统（Data Warehousing） 这种信息系统的主要任务是从Oracle的海量数据中进行查询，以得到数据之间的某些规律。数据库管理员需要为这种类型的Oracle数据

　　 是否采用B＊?索引或者Bitmap索引？

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

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

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

1

xkmj

1. 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数据库无法

　　  2. 内存参数

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

　　 共享池由两部分构成：共享SQL区和数据字典缓冲区。共享SQL区是存放用户SQL命令

　　 结束语

　　 Oracle数据库的性能优化调整是一个系统工程，涉及的方面很多。数据库管理员需要综合运用上面介绍的规律，认真分析Oracle在运行过程当中出现的各种问题，以保证Oracle数据库运行的高效率。还需要指出的是，上面给出的语句只是测得Oracle运行过程的某一个时间点的情况，数据库管理员不能仅仅根据一个点的情况就断定数据库运行性能的好坏，只有多运行一些时间点才能对数据库运行状况做出一个综合评估。

　　 由于单个时间点的监测是很麻烦的，且对于多个时间点的监测更是一项烦琐的工作，为此，笔者开发了Oracle数据库性能监测软件ORATUNE。这个软件不仅能够定时从数据库中读取各种参数并自动计算出各种比例，而且还能自动根据这些比例的好坏建议数据库管理员修改

　　 ORATUNE已经在清华大学、华北电力集团等多个单位得到了应用，对Oracle数据库的性能优化调整起到了良好的作用。

1

xkmj

当建立同Oracle会话时，会在服务器内存中划分出一个专门用来排序的区域，从而为会话提供排序空间。但是，这个排序空间毕竟有限，若记录数量超过这个排序空间的话，就需要进行磁盘排序。但是，我们都知道，磁盘排序的执行速度要比内存排序的执行速度慢1400倍。而且，磁盘排序会消耗临时表空间的资源，并且可能影响到正在进行的其他SQL排序，因为Oracle必须为临时表空间中的数据块分配缓冲池。而且，过多的磁盘排序会导致空闲缓冲等待，以及将执行其他任务的数据块从缓冲池中分页出去。对于数据库管理员来说，在内存中进行排序总是比磁盘排序更受欢迎。所以说，磁盘排序是影响Oracle数据库性能的罪魁祸首。在数据库优化的时候，我们应该想法设法降低数据库的磁盘排序。为此，笔者有如下建议。

一、合理设置Sort_area_size参数

虽然说Oracle10G以后的数据库会自动对内存进行管理。但是，在一些性能要求比较高或者排序频率比较高的数据库中，仍然有必要对一些影响内存分配的参数进行调整。其中，最重要的一个参数就是Sort_area_size。

Oracle数据库会为所有的链接Oracle会话分配Sort_area_size这个参数。所以，对于拥有大量用户的数据库来说，如果增加这个参数的值，会让磁盘排序的几率明显降低，不过数据库也要为此付出这个代价，很容易导致内存过载。但是，如果这个参数的值设置的过低的话，又会导致过多的磁盘排序。所以，这个参数并不是越大越好。因为这个参数如果设置的过大的话，其带来的性能收益反而会降低。因为为了提高有限几个查询的速度，可能会浪费大量的内存。这无疑是我们数据库管理员不希望看到的。

在实际工作中，我们往往需要在两者之间进行一个均衡。设置一个合理的参数，尽量让数据库减少磁盘排序的几率，同时也不能使得服务器内存过载。为此笔者有一个建议。数据库管理员应该每隔一段时间增加这个参数的值，并使用Statspack工具定时监控内存排序与磁盘排序的数据。在起初进行调整的时候最好每个小时查询一次。通过这些数据，我们就可以得到一个合理的参数值，在两这之间取得一个均衡。

前期调整完成后，在后期仍然需要进行监控。因为后期随着企业应用的改变，这个参数仍然需要根据实际情况进行调整，以提高数据库的性能

二、尽量减少不必要的磁盘排序

在某些情况下，尽管数据库管理员没有直接通过Order By等语句对数据库记录进行排序，可是Oracle数据库服务器仍然会对查询结果进行排序。因为这些语句需要起作用，必须要先对数据进行排序。所以，他们往往带有隐性的排序功能。

我们在数据库维护或者前台应用程序设计的时候，要尽量的减少这种不必要的排序。如Distinct关键字，它的作用就是取消重复的记录。但是，要实现这个目的的话，则数据库必须要先对记录进行排序，然后才能够去除重复的记录内容。故在设计的时候，尽量要避免使用Distinct关键字。其实，笔者在工作中，经常会碰到这种情况，某些记录其实不存在重复记录，但是程序开发人员为了保障数据的准确性，就在SQL语句中加入了Distinct关键字，从而造成了不必要的排序。

另外，在其他一些情况下，也会导致不必要的排序。如排序合并连接，也会导致不必要的排序。故无论何时，只要使用了排序合并连接，就会执行排序已连接关键值。故在数据库与应用程序设计的时候，要尽量避免排序合并连接。其实，在许多情况下，嵌套循环连接反而使更好的选择。因为这个嵌套循环连接，它更加有效而且不会导致不必要的排序以及不比要的全表扫描。

其次，有时候缺失索引也会导致一些并不要的排序。故数据库管理员在平时的工作中，要尽量的减少这些不必要的排序，以让宝贵的内存资源交给更重要的任务来适用，提高Oracle数据库性能。

xkmj

三、利用Statspack工具监控排序活动

Statspack工具是一款提高Oracle数据库性能的很好的辅助工具。因为它可以帮助我们收集很多有用的信息。故我们数据库管理员也可以利Statspack工具对数据库中的排序活动进行监控。

对于一个有经验的数据库管理员来说，对内存排序和磁盘排序保持必要的排需是非常必要的。因为我们无法左右用户的行为;而用户的行为又会有所调整。用户在调整的过程中，有可能又会增加额外的磁盘排序。当然，也有可能磁盘排序的几率会减少。但是，通常情况下，随着用户交易数据的增加，这个磁盘排序的几率在理论上仍然是往上爬的。而实际上也是往上升的，只是这个升的速度没有理论上那么快而已。这主要是看数据库管理员如何进行管理了。

根据笔者的了解，企业用户的操作往往会有一个周期性的变化，如按年或者按月进行周期性的变化。数据库管理员应该养成一个好习惯，每个月利用Statspack工具定期的对数据库进行监控。特别是要监控数据库的排序情况。Statspack工具还有额外的一个功能，就是自动监测与警告功能。也就是说，可以让Statspack这个工具在磁盘排序数量超过一个预设置的阀值时，自动给数据库管理员发送一个警告，如通过邮件形式发送给管理员等等。笔者通过监控发现，每到月底与月初的时候，磁盘排序的数量会大大的增加。这主要是因为在月底的时候，用户会对当月的交易数据进行统计。所以当月底月初的时候，由于交易记录比较多，所以，会有比较多的磁盘排序发生。在这种情况下，数据库管理员有必要对相关参数进行调整。不过这个调整是暂时的调整，等到这个周期过去后，仍然要把参数调回来。只有如此，数据库的整体性能才会有所保障。即不会因为内存过载而降低数据库性能;也不会因为磁盘排序而给数据库造成额外的负担。

所以，虽然排序是SQL语句执行中 很微小的一个部分，但是其对数据库性能影响却比较大，而且也是非常显著的。可惜的是，排序是SQL调整中往往被忽视的地方。在Oracle数据库中，排序对用户来说是透明的。也就是说，排序对用户很少有所限制，用户可以根据自己的需要来对数据进行随意地排序。但是，用户并不知道，什么样的操作会降低数据库的性能。故如何降低用户的不合理操作而产生额外的排序，甚至是磁盘排序，这是数据库管理员在平时工作中必须要考虑到的一个问题。通过以上三个方法，或许可以给数据库管理员找到一些解决问题的思路。相信通过以上方法，可以最大程度的减少磁盘排序的发生，不再让磁盘排序成为影响数据库性能的罪魁祸首。

junlong

楼主有没有使用案例，能不能以案例讲解下？