学步园

WORKLOAD REPOSITORY report for Oracle

DB Name	DB Id	Instance	Inst num	Release	RAC	Host
ICCI	1314098396	ICCI1	1	10.2.0.3.0	YES	HPGICCI1

 

 

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	2678	25-Dec-08 14:04:50	24	1.5
End Snap:	2680	25-Dec-08 15:23:37	26	1.5
Elapsed:		78.79 (mins)
DB Time:		11.05 (mins)

DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间，说明数据库比较空闲。

在79分钟里（其间收集了3次快照数据），数据库耗时11分钟，RDA数据中显示系统有8个逻辑CPU（4个物理CPU），平均每个CPU耗时1.4分钟，CPU利用率只有大约2%（1.4/79）。说明系统压力非常小。

可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。

 指标公式:

 每个CPU耗时:=DB Time / 逻辑cpu个数=11.05/8=1.4

 CPU利用率:DB Time / (逻辑cpu个数*Elapsed)=11.05/(8*78.19) *100%=2%

 DB time<Elapsed x cpu_count  表明数据库负荷较小

 DB time=cpu time+wait time

注解:cpu time+wait time（都是指非后台进程），换句话说，db time就是前端用户进程所花费

Report Summary

1.Cache Sizes

	Begin	End
Buffer Cache:	3,344M	3,344M	Std Block Size:	8K
Shared Pool Size:	704M	704M	Log Buffer:	14,352K

显示SGA中每个区域的大小（在AMM改变它们之后），可用来与初始参数值比较。

shared pool主要包括library cache和dictionary cache。library cache用来存储最近解析（或编译）后SQL、PL/SQL和Java classes等。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。

指标公式:

shared pool=library cache+dictionary cache

2.Load Profile

	Per Second	Per Transaction
Redo size:	918,805.72	775,912.72
Logical reads:	3,521.77	2,974.06
Block changes:	1,817.95	1,535.22
Physical reads:	68.26	57.64
Physical writes:	362.59	306.20
User calls:	326.69	275.88
Parses:	38.66	32.65
Hard parses:	0.03	0.03
Sorts:	0.61	0.51
Logons:	0.01	0.01
Executes:	354.34	299.23
Transactions:	1.18

 

% Blocks changed per Read:	51.62	Recursive Call %:	51.72
Rollback per transaction %:	85.49	Rows per Sort:	########

      显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。

Redo size：每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。

Logical reads：每秒/每事务逻辑读的块数

Block changes：每秒/每事务修改的块数

Physical reads：每秒/每事务物理读的块数

指标：

Physical reads / Logical reads=68.26/3,521.77=1.9%的逻辑读导致了物理I/O，平均每个事物产生2,974.06（blocks）,这个数字应该越小越好。 Read的單位是block .

Physical writes：每秒/每事务物理写的块数

User calls：每秒/每事务用户call次数

Parses：SQL解析的次数

Hard parses：其中硬解析的次数，硬解析太多，说明SQL重用率不高。

Sorts：每秒/每事务的排序次数

Logons：每秒/每事务登录的次数

Executes：每秒/每事务SQL执行次数

Transactions：每秒事务数

Blocks changed per Read：

表示逻辑读用于修改数据块的比例，此数据高，表明DML更新操作的块占整个被操作的(逻辑读)的块的比例高。

 

Recursive Call：

递归调用占所有操作的比率，表明通过pl/sql来执行的

 

Rollback per transaction：

每事务的回滚率，例子中85.49值已经非常高，(表示每个事物产生0.85个回滚)，系统存在回滚方面的问题，因为回滚的代价非常昂贵，即平均每1.17（1/0.85）个事务就要产生一次回滚 。 结合前面的transactions 每秒为 1.18个，即每秒会有1.18/1.17 = 1 次回滚。 应该仔细检查系统为何产生如此高的回滚率。

公式：每秒回滚次数=transactions per sencend/(1/Rollback per transaction)=transactions per sencend*Rollback per transaction

 

Rows per Sort：每次排序的行数

注:

Oracle的硬解析和软解析

　　提到软解析(soft parse)和硬解析(hard parse)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：

　　1、语法检查(syntax check)

　　检查此sql的拼写是否语法。

　　2、语义检查(semantic check)

　　诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。

　　3、对sql语句进行解析(parse)

　　利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。

　　4、执行sql，返回结果(execute and return)

　　其中，软、硬解析就发生在第三个过程里。

　　Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache里查找是否存在该hash值；

　　假设存在，则将此sql与cache中的进行比较；

　　假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。

　　诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。

　　创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。

3.Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:	100.00	Redo NoWait %:	100.00
Buffer Hit %:	98.72	In-memory Sort %:	99.86
Library Hit %:	99.97	Soft Parse %:	99.92
Execute to Parse %:	89.09	Latch Hit %:	99.99
Parse CPU to Parse Elapsd %:	7.99	% Non-Parse CPU:	99.95

      本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio，Library Hit ratio也称Library Cache Hit ratio。同Load Profile一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的DSS环境，20%的Buffer Hit Ratio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。根据Oracle的经验，对于OLTPT系统，Buffer Hit Ratio理想应该在90%以上。

Buffer Nowait表示在内存获得数据的未等待比例。 期望值是100%

buffer hit表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存。期望值是100%

Redo NoWait表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。

library hit表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的library hit ratio会导致过多的解析，增加CPU消耗，降低性能。如果library hit ratio低于90%，可能需要调大shared pool区。

Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。

Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。

Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。

Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。

Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。

4.Shared Pool Statistics

	Begin	End
Memory Usage %:	47.19	47.50
% SQL with executions>1:	88.48	79.81
% Memory for SQL w/exec>1:	79.99	73.52

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。

SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。

Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。

5.Top 5 Timed Events

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
CPU time		515		77.6
SQL*Net more data from client	27,319	64	2	9.7	Network
log file parallel write	5,497	47	9	7.1	System I/O
db file sequential read	7,900	35	4	5.3	User I/O
db file parallel write	4,806	34	7	5.1	System I/O

      这是报告概要的最后一节，显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。例如如果‘buffer busy wait’是较严重的等待事件，我们应当继续研究报告中Buffer Wait和File/Tablespace IO区的内容，识别哪些文件导致了问题。如果最严重的等待事件是I/O事件，我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O，并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待，就需要察看详细的LATCH统计识别哪些LATCH产生的问题。

在这里，log file parallel write是相对比较多的等待，占用了7%的CPU时间。

通常，在没有问题的数据库中，CPU time总是列在第一个。

更多的等待事件，参见本报告 的Wait Events一节。

 

CPU time    :     CPU time其实不是真正的等待事件。是衡量CPU是否瓶颈的一个重要指标, 

Elapsed Time = CPU Time + Wait Time 。  一般来讲，一个良好的系统，CPU TIME 应该排在TOP 5 TIME Event的最前面，否则，就要进行调整以减少其他的WAIT TIME。 当然这也是相对的， 如果不存在显著的 latch wait 或过高的logical read  等,  CPU time 占的比例高才是令人放心的。 也就是说CPU在高效率干活是好事，但是是否因为低效的设置或SQL而消耗CPU时间就需要注意了。  

db file sequential read 与 db file scattered read.   

这两个事件是出现比较频繁的事件。 他们表明Oracle内核请求从磁盘读取数据块 (到buffer cache中), 他们的区别就是

sequential 是单块读（串行读），而scattered 表示多块读。(和是否全表扫描无关, 只是全表扫描一般表现为多块读) 。 这两个事件描述的是如何将数据块存储到内存中的, 而不是如何从磁盘进行读取。

db file scattered read 

一次获取的block被分散在buffer的不连续空间中，通常表示全表扫描过多，可检查应用程序是否合理的使用了索引，数据库是否合理的创建了索引 。 db file scattered read是用来表示顺序读取(例如,全表扫描)。
file sequential read 
通常暗示着通过索引获取数据量比较大（比如通过索引进行范围扫描获取表数据百分比过大或者错误的使用索引），多表连接的时候连接顺序不当，hash join时hash_area_size无法容纳hash table 等。db file sequential read是用来表示随机读取(例如,索引扫描)。

 

深入解析db file sequential read 及 db file scattered read ：

 定义

事件名db file sequential read与db file scattered read描述的是如何将数据块存储到内存中的,而不是如何从磁盘进行读取. 如果填充磁盘读取的内容的内存是连续的, 发生的磁盘读就是db file sequential read ,  当填充从磁盘读取的数据的内存的连续性无法被保证的时候,发生的磁盘读就是db file scattered read. 

 

db file sequential read 

Oracle 为所有的单块读取生成db file sequential read事件（既然是单个，当然是连续的，你可以发现db file sequential read 等待事件的P3参数一般都是1）. Oracle始终将单个数据块存储在单个缓存块(cache buffer)中,  因此单块读取永远不会产生db file scattered read事件.  对于索引块，如果不是快速全索引扫描，一般都是一个一个块读取的，所以说，这个等待事件很多时候都是索引读取引起的。 

这一事件通常显示与单个数据块相关的读取操作(如索引读取)。如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表; 或者可能说明不加选择地进行索引。 在大多数情况下我们说，通过索引可以更为快速的获取记录，所以对于一个编码规范、调整良好的数据库，这个等待很大是很正常的。但是在很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能会明显快于索引扫描，所以在开发中我们就应该注意，对于这样的查询应该进行避免使用索引扫描。

db file scattered read  

db file scattered read 一般都是等待同时读取多个块到内存中。为了性能和更有效的内存空间利用，oracle一般会把这些块分散在内存中。db file scattered read 等待事件的P3参数指出了每次I/O读取的块数。每次I/O读取多少个块， 由参数db_file_multiblock_read_count控制。 全表扫描或者快速全索引扫描时一般使用的这种读取块的方式，所以，该等待很多时候都是因为全表扫描引起的 ；在大部分情况下, 全表扫描与快速全索引扫描都会产生一次或多次db file scattered read. 不过, 有时 , 这些扫描只会产生db file sequential read.  

因为全表扫描被置于LRU（Least Recently Used，最近最少使用）列表的冷端（cold end），对于频繁访问的较小的数据表，可以选择把他们Cache到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 以及动态性能视图来进行诊断，该视图中记录了长时间（运行时间超过6秒的）运行的事物，可能很多是全表扫描操作（不管怎样，这部分信息都是值得我们注意的）。 

 

latch free 

latch是一种轻量级的锁。一般来说，latch由三种内存元素组成：pid（进程id），内存地址和内存长度。Latch保证对共享数据结构的排它性访问，以此来保证内存结构的完整性不受到损坏。在多个会话同时修改或者检视(inspect)sga中同一个内存结构时，必须串行化访问以保证sga中数据结构的完整性。 

Latch只是用来保护sga中的内存结构。对数据库中的对象的保护，使用的lock而不是latch。Oracle sga中有许多latch，用来保护sga中各种内存结构不会因为并发访问而损坏。常见的Latch Free等待事件是由于热块 (buffer cache中的latch争用) 及未使用绑定变量(shared pool中的latch争用)