tuning 第十章（一）

第十章 使用性能视图进行调优

一、实例调优步骤
1.定位问题
2.检查主机操作系统和数据库的统计信息，通过数据分析问

题
3.搞清楚修改方法以及预期的效果
4.查看问题是否解决了，若未解决则继续

oracle推荐的性能分析工具是awr和addm报告，如果没有，

则使用statspack收集实例的统计信息。
本段简述如何用动态性能视图实现性能监测和解决。

1.定位问题
需要收集的数据包括：
（1）调优目标
什么样的性能可以接受？每小时、每秒多少事务，响应时间

达到什么水平？
（2）问题的范围
系统缓慢的范围？是整个实例还是某些特定事务、某个用户

？
（3）问题发生的时间
只在负载高峰时段发生吗？还是整天？还是一个月中的某几

天？
（4）缓慢的数量
分段进行分析，与运行良好时相比响应时间上差了多少？
（5）找到修改方法
明确自从性能良好到出问题，发生了什么？缩小查找范围。
比如是否做了升级？是否导入了大量数据？是否有大量用户

登录？

2.查看主机系统
查看服务器负载，考虑操作系统、i/o、网络数据。
查看服务器硬件配置

（1）cpu
如果cpu很空闲的时候发生问题，可能是i/o、应用或数据库

瓶颈。
如果cpu利用率很高，需要确认cpu是否被有效使用了。是否

存在大量cpu资源被某个程序占用？还是平均分布？
如果是oracle以外的程序占用了资源，确认此程序是否真的

需要这么多资源？如果需要，可否放到非高峰时段？
如果是oracle程序中某些程序占用大量cpu资源，使用

sql_trace和tkprof定位到语句或者pl/sql。进一步查询

查看oracle占用的cpu，可以通过视图：
v$sysstat：所有会话的cpu使用情况；（按分类统计cpu使

用的总量）
v$sesstat：每个会话的cpu使用情况；（每个会话是否使用

了v$sysstat中的某类cpu资源）
v$rsrc_consumer_group：oracle资源管理器开启时表示每

个资源消耗组使用的cpu资源情况

需要区分cpu时间和实际时间。比如八核的cpu，在某个时间

点有八个cpu时间。
因此，所有会话所使用的平均cpu时间可能比实际时间要长

。

找到那些进程在花费cpu时间，原因以及调优方式

如果cpu使用是分布在很多oracle进程上的，查看

v$sys_time_model得到精确的信息。

（2）i/o问题
i/o使用是否存在问题可以通过磁盘的队列长度来确定，如

果队列长度大于2，或者时间超过20~30ms，就说明存在i/o

过于频繁的问题（An overly active I/O system can be

evidenced by disk queue lengths greater than two, or

disk service times that are over 20-30ms）。
如果i/o频繁，检查是否有潜在的热点，可否将其分离到不

同的磁盘来改善i/o？
如果i/o问题是oracle引起的，就需要i/o调优。
如果oracle没有可用的i/o资源了，定位到哪些进程用光了

i/o，什么原因，然后再调整。
i/o问题可以通过v$系列视图查看和监控。

定位i/o问题：
v$system_event：top wait events是否是i/o相关的。
i/o相关事件包括db file sequentila read，db file

scattered read，db file single write，db file

parallel write、log fileparallel write。如果这些事件

出现在top event中，就应该查看i/o。
i/o问题也可能不是i/o相关相关的等待事件。比如，在

buffer cache中查找空闲缓存困难或者日志写入磁盘的等待

事件很长也会引起i/o出问题的现象。在检查i/o是否需要重

设前，先确认i/o的负载是否能够减少。

对于oracle引起的i/o问题，查看以下视图：
v$iostat_consumer_Group
资源消耗组的i/o信息。如果oracle资源管理器开启，所有

consumer groups的i/o数据都作为当前可用资源而被占用。
v$iostat_file
捕获正在或已经被访问的数据库文件的i/o统计信息
分析潜在数据，还需要将timed_statistics设为true
v$iostat_function
数据库函数（比如LGWR、DBWR）的i/o累积统计数据
这些v$iostat系列的视图包括了单块、多块的读或写操作的

统计信息。
单块操作指i/o小于128K的操作，多块操作时i/o大于128K的

操作。
都需要收集如下数据：
标示符identifier
总的等待事件ms
等待次数
每个操作的请求次数
单块和多块读的数量
单块和多块写的数量

（3）网络问题
如果网络存在很大的延迟（响应时间慢），需要查看原因。
为了定位远程连接数据库文件的网络i/o问题，查看

v$instat_network视图。
该视图包含了访问远程数据库实例中文件的i/o数据，包括

：
客户端工具
读写操作数量
读写的字节数
读操作的总等待事件
写操作的总等待事件

找到网络问题后，可以通过在空闲时段进行网络负载较大的

操作或将代码中的远程操作改为批量进行的方式解决。

3.查看数据库统计信息
应该查看数据库统计信息，并与oracle的统计信息对比，来

确定是否从某个方面进行调优。
操作系统的统计信息能够告诉我们需要从何开始调优。
但如果调优的目标是数据库，就需要查看数据库统计信息来

找到瓶颈了。

以下是oracle数据库调优时相关的资源
（1）设置统计信息收集的级别
statistics_level控制统计信息收集和管理的级别。应该确

认和搜集了如下信息：
basic 没有警告信息或统计信息被收集。监控和其他自动特

性被禁用。oracle不推荐
typical 默认模式。手机了所有性能相关的主要信息，对于

大多数环境已经足够了
all  所有信息都收集。除了typical的信息外，还有当前操

作系统信息和数据行的执行信息

v$statistics_level视图列出了statistics_level控制的信

息状态

（2）等待事件
包含了很多性能相关的症状，比如latch contention、

buffer contention、i/o contention。这些只是症状，不

是原因。
等待事件包括的类有：Administrative, Application,

Cluster, Commit, Concurrency, Configuration, Idle,

Network, Other, Scheduler, System I/O, and User I/O.

一个服务器进程可能等待：
资源成为可用状态，比如缓存或闩
一个动作的完成，比如i/o
其他工作的完成，比如等待客户端提供下一个需要执行的语

句

为了减少用户响应时间，应该减少服务器进程等待事件的时

间。并非所有等待事件都有相同的等待事件，因此着重于查

看等待事件长的事件。通常来说最好将动态参数

timed_statistics设置为true，至少在性能监控时。

包含等待事件数据的动态性能视图
v$active_session_history
v$sess_time_model、v$sys_time_model
v$session_wait
v$session
v$session_event
V$session_wait_class
v$session_wait_history
v$system_event
v$event_histogram
v$file_histogram
v$system_wait_class
v$temp_histogram

（4）操作系统统计数据
和等待事件数据一起用于进一步定位性能问题
主要包括视图有：
v$active_session_history
v$sysstat
v$filestat  文件的i/o
v$rollstat  rollback和undo段的信息
v$enqueue_stat  每个序列的数据
v$latch

（5）段级统计信息
segment-level statistics可以帮助解决单个段的性能问题

。

v$segstat_name
v$segstat
v$segment_statistics

4.执行更改
进行上述几步后，通常可以得到两三个可以修改以提高性能

的措施。建议逐一进行。
如果几个措施一起进行修改，可能即使问题解决了，也不知

道是哪个修改方案起的作用。再次遇到相似问题时仍然无法

直接解决。

二、oracle统计信息的理解

如果出现性能问题前收集了baseline，就可以通过比较更好

地认识问题。

1.检查负载
通常等待事件是首先需要检查的，如果有baseline报告，可

以看看负载是否变化了。不管有没有baseline，都应该看看

资源使用率是否很高。
负载相关的信息包括：redo size, session logical

reads, db block changes, physical reads, physical

read total bytes, physical writes, physical write

total bytes, parse count (total), parse count

(hard), and user calls.
这些数据可以从v$sysstat得到，最好是按时间和事务进行

规范查询。
还可以使用总的物理读和物理写数量来监测i/o情况。

2.使用等待事件数据解决瓶颈
将等待事件按照等待事件进行排列可以更好地反映问题，前

提是timed_statistics=true。否则只能按照等待次数排序

。

检查等待的时间花在什么事务上的步骤：
1）查看v$system_event，按照等待事件排序，找到除空闲

事务外等待最长的。空闲事务包括Null event, SQL*Net

message from client, SQL*Net message to client, and

SQL*Net more data to client。
找到前五个，称为top 5 timed events。
2）查看这些事务的等待次数和平均等待事件
3）根据top wait events进行后面的调查
4）根据等待事件相关的数据，看看这些数据提供了什么信

息。一般能够找到潜在的瓶颈
5）为了确定自己的假设是否合理，将数据相互比对进行校

验，看是否能够支持自己的假设。并进行调整。

3.等待事件表和潜在问题
238页的表说明了各个等待事件的产生位置和如果等待时机

过长的原因
供参考

4.其他数据
还有一些信息能够说明性能问题，但在等待事件中没有。包

括：
（1）redo log space requests statistics
v$sysstat中的redo log space requests表示一个服务器进

程需要等待在线重做日志文件多长时间才能获得空间（进行

写入），不是重做日志缓存的空间。这个信息以及等待事件

可以作为需要调整检查点、DBWR、归档活动的依据。

（2）读一致性
为了进行一致性读，系统可能花费大量时间回滚修改的块。

可能发生如下情况
如果一张表上有很多小事务和一个正在执行的查询在后台运

行，当修改发生时，查询可能需要经常进行回滚来保证数据

的读一致镜像。可以通过v$sysstat的数据来确认是否发生

了此问题。
–consistent: changes statistic indicates the number

of times a database block has rollback entries

applied to perform. a consistent read on the block.

Workloads that produce a great deal of consistent

changes can consume a great deal of resources.
–consistent gets: statistic counts the number of

logical reads in consistent mode.

If there are few very, large rollback segments, then

your system could be spending a lot of time rolling

back the transaction table during delayed block

cleanout in order to find out exactly which system

change number (SCN) a transaction was committed.

When Oracle Database commits a transaction, all

modified blocks are not necessarily updated with the

commit SCN immediately. In this case, it is done

later on demand when the block is read or updated.

This is called delayed block cleanout.

The ratio of the following V$SYSSTAT statistics

should be close to one:
ratio = transaction tables consistent reads - undo

records applied /
transaction tables consistent read rollbacks

如果回滚段不足，可能存在争用，可以通过以下方法确认：
比较v$rollstat中waits和gets的值，平均等待应该比gets

小；
查看v$waitstat中是否有很多waits是对缓存类‘undo

header’的

（3）table fetch by continued row
查看v$sysstat中的table fetch continued row确实是否迁

移或进行行链接。
少量的，一般小于1%的行链接不会影响性能，但大量行链接

显著影响性能。

在行记录长度大于块长度时，行链接是不可避免的，可以考

虑增大表空间的块大小来解决。

对于长度较短的行，使用合理的空间参数和好的应用设计可

以避免行链接。比如，不要先插入主键，其他字段置空，再

更新其他列的方法插入数据，而应该直接填充所有字段。

如果更新操作增加了行的长度，使其超过数据块大小，数据

库会尝试找到其他空间较大的块存储该数据行，如果找到了

，就将数据移动过去（行迁移），如果没找到，就将该数据

行分割存储，叫做行链接。
数据可也可能在数据插入时就进行行链接了。

行迁移和行链接造成数据更新时性能很差，查询需要进行额

外的操作。

增加pctfree可以减少行迁移。在块中留了足够的可用空间

，数据行就有空间进行长度增长了。

（4）parse-related statistics
应用的解析越多，争用的可能性就越高，等待事件就越长。

如果parse time CPU占cpu时间的比例很大，那么更多的时

间用在了解析，而不是执行语句上。发生这种现象，一般是

由于sql和pl/sql没有被共享，或者共享池配置不合理。

SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME IN ( 'parse time cpu', 'parse time

elapsed',
'parse count (hard)', 'CPU used by this session' );

parse time cpu/parse time elapsed的比率说明多长的解

析时间是由于操作本身的解析造成，而不是资源等待造成的

。比率是1表示非常好。

parse time cpu/cpu used by this session
这个比率说明总cpu中多少被用来解析相关的操作上。接近

零是理想值，表示大多数cpu没有花费在解析上。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26451536/viewspace-752774/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26451536/viewspace-752774/