性能调优

性能优化：
1.1.2.1 性能优化原则

找出影响最大的瓶颈，做适当的调整来减小或者排除这个瓶颈的影响。

1.1.2.2
熟悉自己的系统，一些消耗较大的batch的运行时间。排除是因为运行batch导致系统消耗。

1.1.2.3
物理读很慢
   导致原因，可能是磁盘配置有问题，或者由较差的sql语句造成。
latch竞争
    很少是由实例引起的，而是通过改变应用来优化。
过多的CPU使用率
    系统配置低？没有优化的sql?效率低的应用程序代码。
1.1.2.4 怎么样消除瓶颈
    通常通过以下方法来解决问题：
     .修改应用
     .修改oracle参数
     .提升主机硬件配置
1.1.3 sql优化
1.1.3.1 查询优化器和执行计划
优化器根据系统收集的数据信息来决定最快的查询方法。可以通过在sql语句里插入hint语句来指定查询优化器的执行计划。
1.2 性能调优的工具
重要数据收集参数：statics_level=typical or all ,数据库通过这个参数，利用后台进程来自动收集和性能有关的数据信息。
1.2.1自动性能优化
oracle自动性能优化工具：

   .AWR http://blog.csdn.net/juliaputao/article/details/8708506

10 通过动态性能试图优化实例

10.1.2  先检查主机系统

操作系统，I/O子系统，网络数据，找出系统瓶颈。有利于进一步的调查。

10.1.2.1 cpu使用情况

如果有大量的cpu空闲，那么可能是i/o,应用,数据库瓶颈，注意大量的等待i/o可能造成CPU空闲。

如果CPU负荷很高，检查一下CPU是否被有效的利用，一种情况：大部分cpu资源被小量进程耗尽，另一种情况cpu资源被所有进程分布消耗。

如果是小量进程在大量使用CPU,那么检查一下这些进程来找原因，检查是不是有哪个进程消耗一个cpu的所有处理能力。

10.1.2.1.1 非 oracle进程

如果是非oracle进程，check那些进程是不是合法的利用cpu资源，如果是，是否可以避免这些进程在高峰期运行。

10.1.2.1.2 oracle进程

如果是几个oracle process消耗大量CPU, 使用sql_trace 和tkprof来找到相关的sql或pl/sql，例如：一个select语句包含大量的逻辑读到cache中可能消耗大量的CPU.可以通过sql优化来解决。

10.1.2.1.3 oracle 数据库cpu统计信息

v$sysstat -所有会话使用的cpu资源

v$sesstat -当个会话使用的cpu资源。用来查看哪个会话占用的cpu资源最多

v$rsrc_consumer_group ?????乱码了吗，不是。每个消耗组使用的cpu资源，当oracle database resource manager is running。

10.1.2.2 查看i/o问题

如果磁盘的i/o队列请求大于2 或者disk的读写时间超过20-30ms（毫秒），说明这是一个i/o请求过高的系统。查找热点盘，分散i/o请求到多个盘。如果是由oracle数据库消耗大量i/o资源，可以优化数据库的i/o。

i/o问题可以通过v$试图，或者操作系统工具来诊断。

SQL statements that perform many physical reads by querying the V$SQLAREA view, or by reviewing the "SQL ordered by Reads" section of the Automatic Workload Repository report

10.1.3.3 包含等待事件的动态性能视图

v$activ_session_history

展示活动的数据库session，每秒抽样

v$session_wait -每个session当前的或最近几次session等待事件

v$session-包含了v$session_wait的一些等待信息，而且该视图包含了session所等待的对象的具体信息，ie 对象number,block number ,file number ，row number 。

v$session_event-每个session自启动以来所等待的事件的汇总信息。

v$session_wait_class

v$session_wati_history

v$system_event-记录自实例启动以来，数据库所经历的等待事件的汇总信息。

v$event_histogram

v$file_histogram

v$system_wait_class-实例在每种等待时间，总共等待次数，总共等待的时间。

v$temp_histogram

10.1.3.4系统数据

系统数据通常和等待事件结合在一起，来进一步确认问题的起因

v$active_session_history

v$sysstat

v$filestat

v$rollstat

v$enqueue_stat

v$latch

10.2.2

使用等待事件数据来找到瓶颈

当数据库系统在等待什么东西的时候，它会把等待事件按照等待种类来记录。

分两种等待：空闲等待，没有事情可做，等待着处理更多的工作。

非空闲等待 ：正在等待其他资源可得或者其他活动被完成才能继续工作。

最有效利用等待时间，就是把他们按等待时间排序。

查看数据库把时间都花在了什么地方：

1.v$system_event, 对可疑的事件进行排序，当然按照等待时间排序。

容易找出等待时间最长的那个等待事件。

也可以通过AWR报告，找出TOP 5等待事件。

10.2.3 等待事件列表和潜在的问题

Table 10-1 Wait Events and Potential CausesWait EventGeneral AreaPossible CausesLook for / Examine

buffer busy waits

Buffer cache, DBWR

Depends on buffer type. For example, waits for an index block may be caused by a primary key that is based on an ascending sequence.

Examine V$SESSION while the problem is occurring to determine the type of block in contention.

free buffer waits

Buffer cache, DBWR, I/O

Slow DBWR (possibly due to I/O?)

Cache too small

Examine write time using operating system statistics. Check buffer cache statistics for evidence of too small cache.

db file scattered read

I/O, SQL statement tuning

Poorly tuned SQL

Slow I/O system

Investigate V$SQLAREA to see whether there are SQL statements performing many disk reads. Cross-check I/O system andV$FILESTAT for poor read time.

db file sequential read

I/O, SQL statement tuning

Poorly tuned SQL

Slow I/O system

Investigate V$SQLAREA to see whether there are SQL statements performing many disk reads. Cross-check I/O system andV$FILESTAT for poor read time.

enqueue waits (waits starting withenq:)

Locks

Depends on type of enqueue

Look at V$ENQUEUE_STAT.

library cache latch waits:librarycache,library cache pin, andlibrarycache lock

Latch contention

SQL parsing or sharing

Check V$SQLAREA to see whether there are SQL statements with a relatively high number of parse calls or a high number of child cursors (columnVERSION_COUNT). Check parse statistics inV$SYSSTAT and their corresponding rate for each second.

log buffer space

Log buffer, I/O

Log buffer small

Slow I/O system

Check the statistic redo buffer allocationretries inV$SYSSTAT. Check configuring log buffer section in configuring memory chapter. Check the disks that house the online redo logs for resource contention.

log file sync

I/O, over- committing

Slow disks that store the online logs

Un-batched commits

Check the disks that house the online redo logs for resource contention. Check the number of transactions (commits +rollbacks) each second, fromV$SYSSTAT.

10.2.4 其他的统计信息

10.2.4.1 等待redo log空间

v$systat  表中redo log space request 表明服务器进程对redo log 空间的请求次数，而不是对online redo buffer的空间需求。该等待说明需要对checkpoint，DBWR,or archive进行调优，而不是LGWR，增大log buffer 也没有用。

10.2.4.2 读一致性 read consistency

系统可能过多的花时间去回滚数据块来获得读一致性。如果v$waitstat有 waits for buffers of class 'undo header'说明可可能rollback segments太小，oracle建议解决方法 使用自动undo 管理。

10.2.4.3 table fetch by continued row

10.3 等待事件统计信息

v$session,v$session_wait,v$session_history,v$session_event,v$system_event提供了数据库等待哪些资源的信息。如果timed_statistics set to true ，会记录每个资源等待了多久。

对于活动的事件的性能调优可以通过调查这些等待事件来找出性能瓶颈。

v$session 每个活动的session，现在正在等待的或者上次等待的resource。

v$session_wait 和v$session差不多

v$session_wait_history 每个活动session最近10次的等待事件。

v$session_event 每个session的历史等待记录

v$system_event 整个实例的等待事件和等待时间（也就是所有session等待事件）。