• 博客访问: 850612
  • 博文数量: 209
  • 用 户 组: 普通用户
  • 注册时间: 2008-08-08 15:04
个人简介

暂无介绍

文章分类

全部博文(209)

文章存档

2015年(5)

2014年(23)

2013年(8)

2012年(8)

2011年(38)

2010年(27)

2009年(100)

分类: Linux操作系统

2010-11-17 10:28:08

一、说明在这贴子,我希望和大家一起讨论YAPP,并提出自己的一点经验及见解.

引用请注明出处 

 现在,大部分DBA都不会只利用数据缓冲区命中率,latch free wait time等指标来做数据库性能调整。wait events是时下很流行性能指标,oracle推荐的respone time.STATSPACK(或以前版本的BSTAT/ESTAT)中包含了DBA所需要的大部分指标。但如何有效地利用这些数据调整性能?从那里开始调整?在本文我试用YAPPrespone time)结合STATSPACK提供的数据,并结合一个实际例子,做了个分析。欢迎大家指正.

第一部分:
YAPP
性能优化思想
1
.衡量数据库的性能指标Response time ,YAPPoracle早在1999就提供了另一种数据库性能调整方法,数据库的性能通过响应时间来衡量数据库的性能:  Response time = service time + wait time即用户面对的响应时间由服务时间和等待时间组成。服务时间是处理你的请求实际使用的CPU时间,等待时间即等待资源可用所花费的时间。例如如果执行一个需要查找索引的SQL语句,CPU时间可能包括buffer cache中的索引数据块的处理时间,扫描该数据块找到所需行的时间等,此过程中ORACLE可能需要从盘上读数据,此时可能出现磁盘等待。

2.
结合Oracle文档中的阐述,YAPP利用两个重要的规则。80/20规则,和量化原则。(我觉得不仅适用是oracle中,其实做大多数事很好的规则)。
80/20
规则:指的是很少的问题,影响大部分的性能。也就是***所说的主要矛盾。量化原则:不用解释从字面就知道却非常重要。一定要可度量的,这里当然主要指的respone time.  YAPP方法的主要思路是找出service timewait time的主要组成部分(量化),然后进行排序并调整主要部分(80/20规则)。另外用YAPP做优化时,你可以通过减少整个时间(如用更快的磁盘)或单位时间(如减少访问磁盘次数)。基本步骤如下:  (1)、得到服务时间和等待时间及其组成部分  (2)、将所有组成部分排序  (3)、依次优化每个部分  (4)、对表中的每一项,减少每次执行的代价或执行次数

三、ORACLE中的response time的量化 用户感知的响应时间由一系列时间成分组成,所谓性能优化就是优化最耗时的成分,依次类推。从ORACLE instance的角度,请求一般含三个部分:client(如SQLPLUSTUXEDO),前台进程(如LOCAL = NO的服务进程),后台进程(如DBWR)。所有的ORACLE进程(前台和后台)都会将所使用的CPU时间(service time)和各种等待事件所费时间记录下来,这些信息记录在SGA,用户可通过V$视图访问这些数据。这种数据分为session级和system级,用户可访问V$SYSTEMEVENTV$SESSION_EVENTV$SYSSTATV$SESSTAT等视图来获取这些信息。ORACLESTATSPACK工具(老版本中的BSTAT/ESTAT)就是查询这些视图来收集,计算和生成性能数据。要在ORACLE中产生时间记录,DBA必须在INIT.ORA中将TIMEDSTATISTICS设置为TRUE或通过ALTERSYSTEM将其定义为TRUE(8.15bug)8i以前的版本中时间单位为1/100秒。9i以后时间单位为1/1,000,000(微秒)  在基于时间的优化方法中,最重要的视图是V$SYSTEMEVENTV$SESSION_EVENTV$SYSSTATV$SESSTATV$LATCHV$SQLAREAV$SYSSTAT记录使用的CPU时间,V$SYSTEMEVENT记录进程等待时间花费的间,V$SQLAREA能用于找出最耗资源的SQL语句,而V$LATCH则可用于各种LATCH的等待信息。这些视图的详细结构和含义见ORACLE文档。
Response time = service time + wait time
Service time = parse time cpu + Recursive cpu usage +other CPU TIME
Service time
就是v$sysstat中的CPU used by this session(字面意义容易误导人)。 Recursive cpu usageparse time cpuCPU used by this session的组成部分(对应v$sysstat Recursive cpu usageparse time cpu,除此之外的CPU时间我们一律定义为other CPU.
Other CPU time:
大部分的是SQL化费的。9i之后,我们可以从v$sql,v$sqlareacpu_time可以看出。。一般而言,SQL语句花费的CPU时间与访问的缓冲区个数成比例,我们也可以从buffer
Gets
做一个估计。
Wait time:
主要从wait eventwait time来衡量。

四、在STATSPACK结合YAPP优化性能
STATSPACK
的基本思想  V$视图中记录的数据大都是系统启动后的累加值,从某一个时间点看这些累加值没有太大的实际意义。只有每隔一段时间对这些累加值取样,计算出抽样之间的差别对优化才有价值。ORACLESTATSPACK就是完成定期取样的工作。数据收集完成后,DBA可以运行STATSPACK带的SPREPORT生成某两个取样点之间的差别。STATSPACK生成的报告中含有大多数DBA所需要的数据,包括上述视图中的数据.关键是如何分析这些数据。
STATSPACK
的时间概念,是statspack非常重要参照参数,时间只有对比,才有意义。如:
30
分钟wait time在几十小时快照间隔不是问题,如果在45分钟间隔,就可能是问题。为什么说可能呢?其实,还有一个重要参考:有多少个session在连接。如有2000 session,那么这也不会是问题。下面用YAPP的方法来分析statspack  1、找出晌应时间组成部分,并量化.  基于时间的优化方法YAPP就是要找出最值得优化(最耗时)的成分。我们需找出前台进程使用的sevice time及等待事件花费的时间,service time信息可以从V$SYSSTAT中得到而事件等待花费的时间可从V$SYSTEMEVENT中得到。在STATSPACK报告中它们分别在Instance Activity Stats for DBWait Events for DB章节中找到。wait timeparse time cpuRecursive cpu usage 9i中最简单的方法就是找出Top5 Wait Events.有意思的是9iCPU time也会在Top5 Events中出现。如
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 3,722 79.45
db file sequential read 811,828 815 17.40
db file scattered read 202,998 114 2.44
log file sync 20,560 7 .14
log file sequential read 189 6 .12
-------------------------------------------------------------
值得请注意的是这里的CPU time实际就是service time,而不是wait events,很容易误解。下面是根据STATSPACK报告的数据,用基于YAPP方法的优化步骤:1)、在top timed events,比较service time, wait time优化最大比例。如上例就应当先优化service time (79.45%)2)、找出CPU used by this session的值,parse time cpu, Recursive cpu usage,
Other CPU time
找出最耗时优化。  (3wait time也是如此

四、实例说明这是我在实际中调整生产数据库的一个例子。

四、实例说明这是我在实际中调整生产数据库的一个例子。第一:查看wait time, service time
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 3,722 79.45
db file sequential read 811,828 815 17.40
db file scattered read 202,998 114 2.44
log file sync 20,560 7 .14
log file sequential read 189 6 .12
-------------------------------------------------------------
很显然,需要的调整的service time, CPU time占了79.45%,虽然其它也表现不好。下一步是找出CPU used by this session的值,parse time cpu, Recursive cpu usage.
Instance Activity Stats for DB: ORC6 Instance: orc6 Snaps: 21 -22

Statistic Total per Second per Trans
--------------------------------- ------------------ -------------- ------------
CPU used by this session 372,215 103.5 11.2
.
.
parse time cpu 56,253 15.6 1.7
.
. recursive cpu usage 299,266 83.2 9.0
由此:parse time CPU 56253/372215=15%
recursive cpu usage 299266/372215=80%
other cpu
5%.考虑到应用中有许多pl/sql,其部分的sql会在report表现。因此查看:
SQL ordered by Gets for DB: ORC6 Instance: orc6 Snaps: 21 -22
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100

CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
104,852,823 33,259 3,152.6 91.5 2977.30 3160.98 269479692
Module: autoscanservices.exe
begin CELL_NAMES_CELL_EXIST(CELLNAME=>:CELLNAME, TESTTYPE=>:TEST
TYPE, RESULT=>:RESULT); end;

104,476,590 33,265 3,140.7 91.2 2963.67 3144.84 4132718792
Module: autoscanservices.exe
SELECT count(*) from cell_names where CELL_NAME=:b1

130,701 105 1,244.8 0.1 1.22 1.18 1578495722
Module: autoscanservices.exe
UPDATE cell_names set cell_name_state='D',do_user=:b2,do_time=sy
sdate where machine_no=:b1
在这里我们找到了问题所在。CELL_NAMES_CELL_EXIST(CELLNAME=>:CELLNAME, TESTTYPE=>:TEST
TYPE, RESULT=>:RESULT);
它里面包含一个SELECT count(*) from cell_names where CELL_NAME=:b1语句。从上可知SELECT count(*) from cell_names where CELL_NAME=:b1产生大量的buffer gests有时竟达到总数的80-90%时。追踪该SQL得到其执行计划如下*****************************************************************************

SELECT count(*)
from
cell_names where CELL_NAME=:b1

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.07 0.07 0 3337 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.07 0.07 0 3337 0 1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 65

Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=3337 r=0 w=0 time=77558 us)
1 TABLE ACCESS FULL CELL_NAMES (cr=3337 r=0 w=0 time=77546 us)

******************************************************************************
从而得到原因,全表扫描引起的,大量的buffer get消耗大量的资源。这个表有三十多万多记录,在cell_name没有索引.原因,全表扫描引起的.解决方法:cell_namescell_name建立索引。随后的做report Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 536 51.76
db file sequential read 67,100 427 41.27
library cache load lock 28 23 2.19
library cache pin 20 15 1.49
db file scattered read 6,236 10 .97
-------------------------------------------------------------
同样在一个小时的间隔中cpu time ,wait time大量减少,达到提高response time的目的

阅读(2082) | 评论(0) | 转发(0) |
0

上一篇:ibm gpfs

下一篇:oracle latch优化

给主人留下些什么吧!~~

dingli12342010-11-18 10:27:45

由于自己想做个网站,我就找了几家IDC商去试用空间,结果试用天兴互联的空间不错,这款全能1G空间,不但送100M数据库,而且还送企业邮局,之前记得买个数据库就要一百多来,这款全能空间加上数据库才198元,价格真实惠,而且空间的稳定性和访问速度也都不错,去年买的一直用到现在,最值得一提的是那里的客服服务质量超好的,如果有需要的朋友可以直接联系这个客服QQ:1176343166,服务态度真的不错的!呵呵!希望可以帮助大家找到好的空间商!

评论热议
请登录后评论。

登录 注册