AWR 是 Oracle 10g 版本 推出的新特性, 全称叫Automatic Workload Repository-自动负载信息库 AWR 是通过对比两次快照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分。
WORKLOAD REPOSITORY report for
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时间,说明数据库比较空闲。 db time= cpu time + wait time(不包含空闲等待) (非后台进程) 说白了就是db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间 DB time = cpu
time + all of nonidle wait event time
Hard parses:其中硬解析的次数,硬解析太多,说明SQL重用率不高。 每秒产生的硬解析次数, 每秒超过100次,就可能说明你绑定使用的不好,也可能是共享池设置不合理。 这时候可以启用参数cursor_sharing=similar|force,该参数默认值为exact。但该参数设置为similar时,存在bug,可能导致执行计划的不优。
Sorts:每秒/每事务的排序次数
Logons:每秒/每事务登录的次数
Executes:每秒/每事务SQL执行次数
Transactions:每秒事务数.每秒产生的事务数,反映数据库任务繁重与否。
Blocks changed per Read:表示逻辑读用于修改数据块的比例.在每一次逻辑读中更改的块的百分比。
本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit
Ratio 也称Cache Hit
Ratio, Library Hit
ratio也称Library
Cache Hit ratio。 同Load Profile一节相同,这一节也没有所谓“正确”的值,而只能根据应用的特点判断是否合适。 在一个使用直接读执行大型并行查询的DSS环境,20%的Buffer Hit Ratio是可以接受的,而这个值对于一个OLTP系统是完全不能接受的。 根据Oracle的经验,对于OLTP系统,Buffer Hit Ratio理想应该在90%以上。
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区。 STATEMENT在共享区的命中率,通常应该保持在95%以上,否则需要要考虑:加大共享池;使用绑定变量;修改cursor_sharing等参数。
Latch Hit:Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。 要确保Latch Hit>99%,否则意味着Shared Pool latch争用,可能由于未共享的SQL,或者Library
Cache太小,可使用绑定变更或调大Shared
Pool解决。 要确保>99%,否则存在严重的性能问题。当该值出现问题的时候,我们可以借助后面的等待时间和latch分析来查找解决问题。
Parse CPU to Parse
Elapsd:解析实际运行时间/(解析实际运行时间+解析中等待资源时间),越高越好。 计算公式为:Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time
elapsed)。 即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%,意味着CPU等待时间为0,没有任何等待。
Non-Parse CPU :SQL实际运行时间/(SQL实际运行时间+SQL解析时间),太低表示解析消耗时间过多。 计算公式为:% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小,表示解析消耗的CPU时间过多。 与PARSE_CPU相比,如果TOT_CPU很高,这个比值将接近100%,这是很好的,说明计算机执行的大部分工作是执行查询的工作,而不是分析查询的工作。
Execute to Parse:是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。 计算公式为:Execute to Parse =100 *
(1 - Parses/Executions)。 本例中,差不多每execution 5次需要一次parse。所以如果系统Parses > Executions,就可能出现该比率小于0的情况。 该值<0通常说明shared pool设置或者语句效率存在问题,造成反复解析,reparse可能较严重,或者是可能同snapshot有关,通常说明数据库性能存在问题。
SQL with executions>1:执行次数大于1的sql比率,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多SQL解析。 在一个趋向于循环运行的系统中,必须认真考虑这个数字。在这个循环系统中,在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。 在共享池中,在观察期间将有一组未被执行过的SQL语句,这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组,这个数字才会接近100%。
Memory for SQL w/exec>1:执行次数大于1的SQL消耗内存的占比。 这是与不频繁使用的SQL语句相比,频繁使用的SQL语句消耗内存多少的一个度量。 这个数字将在总体上与% SQL with
executions>1非常接近,除非有某些查询任务消耗的内存没有规律。 在稳定状态下,总体上会看见随着时间的推移大约有75%~85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期, 执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
SELECT p.* FROM v$sql_plan
p,v$sql s WHERE p.address = s.ADDRESS
AND p.hash_value =
s.HASH_VALUE
and p.hash_value = '&hash_value'
)
CONNECT BY PRIOR id =
parent_id
START WITH id = 0;
查看,分析,优化索引等在这里就不再一一描述了。
Complete List of SQL Text
SQL Id
SQL Text
04xtrk7uyhknh
select obj#, type#, ctime, mtime, stime, status, dataobj#,
flags, oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and
namespace=:3 and remoteowner is null and linkname is null and subname is null
0hhmdwwgxbw0r
select obj#, type#, flags, related, bo, purgeobj, con# from
RecycleBin$ where ts#=:1 and to_number(bitand(flags, 16)) = 16 order by
dropscn
0k8h717b8guhf
delete from RecycleBin$ where purgeobj=:1
0pvtkmrrq8usg
select file#, block# from seg$ where type# = 3 and ts# = :1
0v9t4qb1zb2b
select CUID_CUST_NO , CUID_ID_TYPE , CUID_ID_RECNO from CUID_TMP
where CHGFLAG='D'
104pd9mm3fh9p
select blocks, maxblocks, grantor#, priv1, priv2, priv3 from
tsq$ where ts#=:1 and user#=:2
update ICCIFNSACT set BORM_FACILITY_NO=:b0 where BORM_MEMB_CUST_AC=:b1
53saa2zkr6wc3
select intcol#, nvl(pos#, 0), col#, nvl(spare1, 0) from ccol$
where con#=:1
569r5k05drsj7
insert into CUMI select CUSV_CUST_NO , CUSV_EDUCATION_CODE ,
CHGDATE from CUMI_TMP where CHGFLAG<>'D'
5c4qu2zmj3gux
select * from ICCIPRODCODE where PRODCODE=to_char(:b0)
5ngzsfstg8tmy
select o.owner#, o.name, o.namespace, o.remoteowner, o.linkname,
o.subname, o.dataobj#, o.flags from obj$ o where o.obj#=:1
6769wyy3yf66f
select pos#, intcol#, col#, spare1, bo#, spare2 from icol$ where
obj#=:1
6z06gcfw39pkd
SELECT F.TABLESPACE_NAME, TO_CHAR ((T.TOTAL_SPACE -
F.FREE_SPACE), '999, 999') "USED (MB)", TO_CHAR (F.FREE_SPACE,
'999, 999') "FREE (MB)", TO_CHAR (T.TOTAL_SPACE, '999, 999')
"TOTAL (MB)", TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)),
'999')||' %' PER_FREE FROM ( SELECT TABLESPACE_NAME, ROUND (SUM
(BLOCKS*(SELECT VALUE/1024 FROM V$PARAMETER WHERE NAME =
'db_block_size')/1024) ) FREE_SPACE FROM DBA_FREE_SPACE GROUP BY
TABLESPACE_NAME ) F, ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES/1048576))
TOTAL_SPACE FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME ) T WHERE
F.TABLESPACE_NAME = T.TABLESPACE_NAME
78m9ryygp65v5
SELECT COUNT(*) FROM ALL_POLICIES V WHERE
V.OBJECT_OWNER = :B3 AND V.OBJECT_NAME = :B2 AND (POLICY_NAME LIKE '%xdbrls%'
OR POLICY_NAME LIKE '%$xd_%') AND V.FUNCTION = :B1
7gtztzv329wg0
select c.name, u.name from con$ c, cdef$ cd, user$ u where
c.con# = cd.con# and cd.enabled = :1 and c.owner# = u.user#
7ng34ruy5awxq
select i.obj#, i.ts#, i.file#, i.block#, i.intcols, i.type#,
i.flags, i.property, i.pctfree$, i.initrans, i.maxtrans, i.blevel, i.leafcnt,
i.distkey, i.lblkkey, i.dblkkey, i.clufac, i.cols, i.analyzetime,
i.samplesize, i.dataobj#, nvl(i.degree, 1), nvl(i.instances, 1), i.rowcnt,
mod(i.pctthres$, 256), i.indmethod#, i.trunccnt, nvl(c.unicols, 0),
nvl(c.deferrable#+c.valid#, 0), nvl(i.spare1, i.intcols), i.spare4, i.spare2,
i.spare6, decode(i.pctthres$, null, null, mod(trunc(i.pctthres$/256), 256)),
ist.cachedblk, ist.cachehit, ist.logicalread from ind$ i, ind_stats$ ist,
(select enabled, min(cols) unicols, min(to_number(bitand(defer, 1)))
deferrable#, min(to_number(bitand(defer, 4))) valid# from cdef$ where obj#=:1
and enabled > 1 group by enabled) c where i.obj#=c.enabled(+) and i.obj# =
ist.obj#(+) and i.bo#=:1 order by i.obj#
7v9dyf5r424yh
select NEWACTNO into :b0 from OLDNEWACT where OLDACTNO=:b1
7wwv1ybs9zguz
update ICCIFNSACT set BORM_ADV_DATE=:b0, BOIS_MATURITY_DATE=:b1,
BOIS_UNPD_BAL=:b2, BOIS_UNPD_INT=:b3, BOIS_BAL_FINE=:b4, BOIS_INT_FINE=:b5,
BOIS_FINE_FINE=:b6, BORM_LOAN_TRM=:b7, BORM_FIVE_STAT=:b8,
BOIS_ARREARS_CTR=:b9, BOIS_ARREARS_SUM=:b10 where BORM_MEMB_CUST_AC=:b11
update seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7,
maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13,
65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15,
hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18 where ts#=:1 and
file#=:2 and block#=:3
9vtm7gy4fr2ny
select con# from con$ where owner#=:1 and name=:2
a2any035u1qz1
select owner#, name from con$ where con#=:1
a7nh7j8zmfrzw
select CUSV_CUST_NO from CUMI_TMP where CHGFLAG='D'
Back to
SQL Statistics Back to Top
Instance Activity Statistics
Instance Activity Stats
Instance Activity Stats -
Absolute Values
Instance Activity Stats - Thread
Activity
Back to Top
Instance Activity Stats
Statistic
Total
per Second
per Trans
CPU used by this session
23,388
4.95
4.18
CPU used when call started
21,816
4.61
3.90
CR blocks created
2,794
0.59
0.50
Cached Commit SCN referenced
237,936
50.33
42.50
Commit SCN cached
3
0.00
0.00
DB time
583,424
123.41
104.22
DBWR checkpoint buffers written
402,781
85.20
71.95
DBWR checkpoints
9
0.00
0.00
DBWR fusion writes
255
0.05
0.05
DBWR object drop buffers written
0
0.00
0.00
DBWR thread checkpoint buffers written
221,341
46.82
39.54
DBWR transaction table writes
130
0.03
0.02
DBWR undo block writes
219,272
46.38
39.17
DFO trees parallelized
16
0.00
0.00
PX local messages recv'd
40
0.01
0.01
PX local messages sent
40
0.01
0.01
PX remote messages recv'd
80
0.02
0.01
PX remote messages sent
80
0.02
0.01
Parallel operations not downgraded
16
0.00
0.00
RowCR - row contention
9
0.00
0.00
RowCR attempts
14
0.00
0.00
RowCR hits
5
0.00
0.00
SMON posted for undo segment recovery
0
0.00
0.00
SMON posted for undo segment shrink
9
0.00
0.00
SQL*Net roundtrips to/from client
1,544,063
326.62
275.82
active txn count during cleanout
276,652
58.52
49.42
application wait time
1,620
0.34
0.29
auto extends on undo tablespace
0
0.00
0.00
background checkpoints completed
7
0.00
0.00
background checkpoints started
9
0.00
0.00
background timeouts
21,703
4.59
3.88
branch node splits
337
0.07
0.06
buffer is not pinned count
1,377,184
291.32
246.01
buffer is pinned count
20,996,139
4,441.37
3,750.65
bytes received via SQL*Net from client
7,381,397,183
1,561,408.36
1,318,577.56
bytes sent via SQL*Net to client
149,122,035
31,544.22
26,638.45
calls to get snapshot scn: kcmgss
1,696,712
358.91
303.09
calls to kcmgas
433,435
91.69
77.43
calls to kcmgcs
142,482
30.14
25.45
change write time
4,707
1.00
0.84
cleanout - number of ktugct calls
282,045
59.66
50.38
cleanouts and rollbacks - consistent read gets
55
0.01
0.01
cleanouts only - consistent read gets
2,406
0.51
0.43
cluster key scan block gets
21,886
4.63
3.91
cluster key scans
10,540
2.23
1.88
cluster wait time
2,855
0.60
0.51
commit batch/immediate performed
294
0.06
0.05
commit batch/immediate requested
294
0.06
0.05
commit cleanout failures: block lost
2,227
0.47
0.40
commit cleanout failures: callback failure
750
0.16
0.13
commit cleanout failures: cannot pin
4
0.00
0.00
commit cleanouts
427,610
90.45
76.39
commit cleanouts successfully completed
424,629
89.82
75.85
commit immediate performed
294
0.06
0.05
commit immediate requested
294
0.06
0.05
commit txn count during cleanout
111,557
23.60
19.93
concurrency wait time
515
0.11
0.09
consistent changes
1,716
0.36
0.31
consistent gets
5,037,471
1,065.59
899.87
由consistent gets,db block gets和physical reads这三个值,我们也可以计算得到buffer hit ratio,计算的公式如下: buffer hit ratio
= 100*(1-physical reads /(consistent gets+ db block gets)),例如在这里,我们可以计算得到:buffer hit ratio =100*(1-26524/(16616758+2941398))= 99.86
consistent gets - examination
2,902,016
613.87
518.40
consistent gets direct
0
0.00
0.00
consistent gets from cache
5,037,471
1,065.59
899.87
current blocks converted for CR
0
0.00
0.00
cursor authentications
434
0.09
0.08
data blocks consistent reads - undo records applied
1,519
0.32
0.27
db block changes
8,594,158
1,817.95
1,535.22
db block gets
11,611,321
2,456.18
2,074.19
db block gets direct
1,167,830
247.03
208.62
db block gets from cache
10,443,491
2,209.14
1,865.58
deferred (CURRENT) block cleanout applications
20,786
4.40
3.71
dirty buffers inspected
25,007
5.29
4.47
脏数据从LRU列表中老化,A value here indicates that the DBWR is not keeping up。如果这个值大于0,就需要考虑增加DBWRs。
dirty buffers inspected:
This is the number of dirty (modified) data buffers that were aged out on the
LRU list. You may benefit by adding more DBWRs.If it is greater than 0,
consider increasing the database writes.
short tables是指表的长度低于buffer
chache 2%(2%是有隐含参数_SMALL_TABLE_THRESHOLD定义的,这个参数在oracle不同的版本中,有不同的含义。在9i和10g中,该参数值定义为2%,在8i中,该参数值为20个blocks,在v7中,该参数为5个blocks)的表。这些表将优先使用全表扫描。一般不使用索引。_SMALL_TABLE_THRESHOLD值的计算方法如下(9i,8K): (db_cache_size/8192)*2%。
注意:_SMALL_TABLE_THRESHOLD参数修改是相当危险的操作
total number of times SMON posted
259
0.05
0.05
transaction lock background get time
0
0.00
0.00
transaction lock background gets
0
0.00
0.00
transaction lock foreground requests
0
0.00
0.00
transaction lock foreground wait time
0
0.00
0.00
transaction rollbacks
294
0.06
0.05
tune down retentions in space pressure
0
0.00
0.00
undo change vector size
1,451,085,596
306,952.35
259,215.00
user I/O wait time
11,992
2.54
2.14
user calls
1,544,383
326.69
275.88
user commits
812
0.17
0.15
user rollbacks
4,786
1.01
0.85
workarea executions - onepass
1
0.00
0.00
workarea executions - optimal
1,616
0.34
0.29
write clones created in background
0
0.00
0.00
write clones created in foreground
11
0.00
0.00
Back to
Instance Activity Statistics Back to Top
Instance Activity Stats - Absolute Values
Statistics
with absolute values (should not be diffed)
Statistic
Begin Value
End Value
session cursor cache count
3,024
3,592
opened cursors current
37
39
logons current
24
26
Back to
Instance Activity Statistics Back to Top
Instance Activity Stats - Thread Activity
Statistics
identified by '(derived)' come from sources other than SYSSTAT
在这里主要关注Av Rd(ms)列 (reads per
millisecond)的值,一般来说,大部分的磁盘系统的这个值都能调整到14ms以下,oracle认为该值超过20ms都是不必要的。如果该值超过1000ms,基本可以肯定存在I/O的性能瓶颈。如果在这一列上出现######,可能是你的系统存在严重的I/O问题,也可能是格式的显示问题。
关于OPTIMIZER_INDEX_COST_ADJ=n:该参数是一个百分比值,缺省值为100,可以理解为FULL SCAN COST/INDEX SCAN COST。当n%*
INDEX SCAN COST<FULL SCAN COST时,oracle会选择使用索引。在具体设置的时候,我们可以根据具体的语句来调整该值。如果我们希望某个statement使用索引,而实际它确走全表扫描,可以对比这两种情况的执行计划不同的COST,从而设置一个更合适的值。
5)检查并调整I/O设备的性能。
Tablespace IO Stats
ordered
by IOs (Reads + Writes) desc
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
ICCIDAT01
67,408
14
3.76
3.17
160,261
34
6
0.00
UNDOTBS1
10
0
12.00
1.00
57,771
12
625
0.02
TEMP
15,022
3
8.74
7.24
3,831
1
0
0.00
USERS
68
0
5.44
1.00
971
0
0
0.00
SYSAUX
263
0
5.48
1.00
458
0
0
0.00
SYSTEM
32
0
5.94
1.00
158
0
3
23.33
UNDOTBS2
6
0
16.67
1.00
6
0
0
0.00
显示每个表空间的I/O统计。根据Oracle经验,Av Rd(ms) [Average Reads in
milliseconds]不应该超过30,否则认为有I/O争用。
Back to
IO Stats Back to Top
File IO Stats
ordered
by Tablespace, File
Tablespace
Filename
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
ICCIDAT01
/dev/rora_icci01
5,919
1
4.30
3.73
15,161
3
1
0.00
ICCIDAT01
/dev/rora_icci02
7,692
2
4.12
3.18
16,555
4
0
0.00
ICCIDAT01
/dev/rora_icci03
6,563
1
2.59
3.80
15,746
3
0
0.00
ICCIDAT01
/dev/rora_icci04
8,076
2
2.93
3.11
16,164
3
0
0.00
ICCIDAT01
/dev/rora_icci05
6,555
1
2.61
3.31
21,958
5
0
0.00
ICCIDAT01
/dev/rora_icci06
6,943
1
4.03
3.41
20,574
4
0
0.00
ICCIDAT01
/dev/rora_icci07
7,929
2
4.12
2.87
18,263
4
0
0.00
ICCIDAT01
/dev/rora_icci08
7,719
2
3.83
2.99
17,361
4
0
0.00
ICCIDAT01
/dev/rora_icci09
6,794
1
4.79
3.29
18,425
4
0
0.00
ICCIDAT01
/dev/rora_icci10
211
0
5.31
1.00
6
0
0
0.00
ICCIDAT01
/dev/rora_icci11
1,168
0
4.45
1.00
6
0
0
0.00
ICCIDAT01
/dev/rora_icci12
478
0
4.23
1.00
6
0
0
0.00
ICCIDAT01
/dev/rora_icci13
355
0
5.13
1.00
6
0
0
0.00
ICCIDAT01
/dev/rora_icci14
411
0
4.91
1.00
6
0
1
0.00
ICCIDAT01
/dev/rora_icci15
172
0
5.29
1.00
6
0
1
0.00
ICCIDAT01
/dev/rora_icci16
119
0
7.23
1.00
6
0
1
0.00
ICCIDAT01
/dev/rora_icci17
227
0
6.26
1.00
6
0
1
0.00
ICCIDAT01
/dev/rora_icci18
77
0
8.44
1.00
6
0
1
0.00
SYSAUX
/dev/rora_SYSAUX
263
0
5.48
1.00
458
0
0
0.00
SYSTEM
/dev/rora_SYSTEM
32
0
5.94
1.00
158
0
3
23.33
TEMP
/dev/rora_TEMP
3,653
1
5.67
6.61
827
0
0
TEMP
/dev/rora_TEMP2
2,569
1
4.42
6.70
556
0
0
TEMP
/dev/rora_TEMP3
1,022
0
2.50
16.86
557
0
0
TEMP
/dev/rora_TEMP5
7,778
2
12.43
6.46
1,891
0
0
UNDOTBS1
/dev/rora_UNDO0101
10
0
12.00
1.00
57,771
12
625
0.02
UNDOTBS2
/dev/rora_UNDO0201
6
0
16.67
1.00
6
0
0
0.00
USERS
/dev/rora_USERS
68
0
5.44
1.00
971
0
0
0.00
Back to
IO Stats Back to Top
Buffer Pool Statistics
Standard
block size Pools D: default, K: keep, R: recycle
Default
Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
P
Number of Buffers
Pool Hit%
Buffer Gets
Physical Reads
Physical Writes
Free Buff Wait
Writ Comp Wait
Buffer Busy Waits
D
401,071
99
15,480,754
213,729
437,340
0
0
634
这里将buffer poll细分,列举default、keep、recycle三种类型的buffer的详细情况。在这份报告中,我们的系统中只使用Default size的buffer pool。这里的3个waits统计,其实在前面的等待时间中已经包含,所以可以参考前面的描述。关于命中率也已经在前面讨论。所以,其实这段信息不需要怎么关注。 Back to Top
Advisory Statistics
Instance Recovery Stats
Buffer Pool Advisory
PGA Aggr Summary
PGA Aggr Target Stats
PGA Aggr Target Histogram
PGA Memory Advisory
Shared Pool Advisory
SGA Target Advisory
Streams Pool Advisory
Java Pool Advisory
Back to Top
Instance Recovery Stats
B:
Begin snapshot, E: End snapshot
Targt MTTR (s)
Estd MTTR (s)
Recovery Estd IOs
Actual Redo Blks
Target Redo Blks
Log File Size Redo Blks
Log Ckpt Timeout Redo Blks
Log Ckpt Interval Redo Blks
B
0
11
369
2316
5807
1883700
5807
E
0
98
116200
1828613
1883700
1883700
5033355
Back to
Advisory Statistics Back to Top
Buffer Pool Advisory
Only
rows with estimated physical reads >0 are displayed
PGA
cache hit % - percentage of W/A (WorkArea) data processed only in-memory
PGA Cache Hit %
W/A MB Processed
Extra W/A MB Read/Written
87.91
1,100
151
Back to
Advisory Statistics Back to Top
PGA Aggr Target Stats
B:
Begin snap E: End snap (rows dentified with B or E contain data which is
absolute i.e. not diffed over the interval)
Auto
PGA Target - actual workarea memory target
W/A
PGA Used - amount of memory used for all Workareas (manual + auto)
%PGA
W/A Mem - percentage of PGA memory allocated to workareas
%Auto
W/A Mem - percentage of workarea memory controlled by Auto Mem Mgmt
%Man
W/A Mem - percentage of workarea memory under manual control
PGA Aggr Target(M)
Auto PGA Target(M)
PGA Mem Alloc(M)
W/A PGA Used(M)
%PGA W/A Mem
%Auto W/A Mem
%Man W/A Mem
Global Mem Bound(K)
B
1,024
862
150.36
0.00
0.00
0.00
0.00
104,850
E
1,024
860
154.14
0.00
0.00
0.00
0.00
104,850
Back to
Advisory Statistics Back to Top
PGA Aggr Target Histogram
Optimal
Executions are purely in-memory operations
Low Optimal
High Optimal
Total Execs
Optimal Execs
1-Pass Execs
M-Pass Execs
2K
4K
1,385
1,385
0
0
64K
128K
28
28
0
0
128K
256K
5
5
0
0
256K
512K
79
79
0
0
512K
1024K
108
108
0
0
1M
2M
7
7
0
0
8M
16M
1
1
0
0
128M
256M
3
2
1
0
256M
512M
1
1
0
0
Back to
Advisory Statistics Back to Top
PGA Memory Advisory
When
using Auto Memory Mgmt, minimally choose a pga_aggregate_target value
where Estd PGA Overalloc Count is 0
PGA Target Est (MB)
Size Factr
W/A MB Processed
Estd Extra W/A MB Read/ Written to Disk
Estd PGA Cache Hit %
Estd PGA Overalloc Count
128
0.13
4,652.12
2,895.99
62.00
0
256
0.25
4,652.12
2,857.13
62.00
0
512
0.50
4,652.12
2,857.13
62.00
0
768
0.75
4,652.12
2,857.13
62.00
0
1,024
1.00
4,652.12
717.82
87.00
0
1,229
1.20
4,652.12
717.82
87.00
0
1,434
1.40
4,652.12
717.82
87.00
0
1,638
1.60
4,652.12
717.82
87.00
0
1,843
1.80
4,652.12
717.82
87.00
0
2,048
2.00
4,652.12
717.82
87.00
0
3,072
3.00
4,652.12
717.82
87.00
0
4,096
4.00
4,652.12
717.82
87.00
0
6,144
6.00
4,652.12
717.82
87.00
0
8,192
8.00
4,652.12
717.82
87.00
0
Back to
Advisory Statistics Back to Top
Shared Pool Advisory
SP:
Shared Pool Est LC: Estimated Library Cache Factr: Factor
Note
there is often a 1:Many correlation between a single logical object in the
Library Cache, and the physical number of memory objects associated with
it. Therefore comparing the number of Lib Cache objects (e.g. in
v$librarycache), with the number of Lib Cache Memory Objects is invalid.
Shared Pool Size(M)
SP Size Factr
Est LC Size (M)
Est LC Mem Obj
Est LC Time Saved (s)
Est LC Time Saved Factr
Est LC Load Time (s)
Est LC Load Time Factr
Est LC Mem Obj Hits
304
0.43
78
7,626
64,842
1.00
31
1.00
3,206,955
384
0.55
78
7,626
64,842
1.00
31
1.00
3,206,955
464
0.66
78
7,626
64,842
1.00
31
1.00
3,206,955
544
0.77
78
7,626
64,842
1.00
31
1.00
3,206,955
624
0.89
78
7,626
64,842
1.00
31
1.00
3,206,955
704
1.00
78
7,626
64,842
1.00
31
1.00
3,206,955
784
1.11
78
7,626
64,842
1.00
31
1.00
3,206,955
864
1.23
78
7,626
64,842
1.00
31
1.00
3,206,955
944
1.34
78
7,626
64,842
1.00
31
1.00
3,206,955
1,024
1.45
78
7,626
64,842
1.00
31
1.00
3,206,955
1,104
1.57
78
7,626
64,842
1.00
31
1.00
3,206,955
1,184
1.68
78
7,626
64,842
1.00
31
1.00
3,206,955
1,264
1.80
78
7,626
64,842
1.00
31
1.00
3,206,955
1,344
1.91
78
7,626
64,842
1.00
31
1.00
3,206,955
1,424
2.02
78
7,626
64,842
1.00
31
1.00
3,206,955
Back to
Advisory Statistics Back to Top
SGA Target Advisory
SGA Target Size (M)
SGA Size Factor
Est DB Time (s)
Est Physical Reads
1,024
0.25
9,060
9,742,760
2,048
0.50
7,612
7,948,245
3,072
0.75
7,563
7,886,258
4,096
1.00
7,451
7,748,338
5,120
1.25
7,423
7,713,470
6,144
1.50
7,397
7,680,927
7,168
1.75
7,385
7,666,980
8,192
2.00
7,385
7,666,980
Back to
Advisory Statistics Back to Top
Streams Pool Advisory
No data exists for this section of the report.
Back to
Advisory Statistics Back to Top
Java Pool Advisory
No data exists for this section of the report.
Back to
Advisory Statistics Back to Top
Wait Statistics
Buffer Wait Statistics
Enqueue Activity
Back to Top
Buffer Wait Statistics
ordered
by wait time desc, waits desc
Class
Waits
Total Wait Time (s)
Avg Time (ms)
data block
3
0
23
undo header
616
0
0
file header block
8
0
0
undo block
7
0
0
Back to
Wait Statistics Back to Top
Enqueue Activity
only
enqueues with waits are shown
Enqueue
stats gathered prior to 10g should not be compared with 10g data
4) Library cache and shared
pool 争用: library cache是一个hash table,我们需要通过一个hash buckets数组来访问(类似buffer cache)。library cache latch就是将对library cache的访问串行化。当有一个sql(或者PL/SQL procedure,package,function,trigger)需要执行的时候,首先需要获取一个latch,然后library cache latch就会去查询library cache以重用这些语句。在8i中,library cache latch只有一个。在9i中,有7个child latch,这个数量可以通过参数_KGL_LATCH_ COUNT修改(最大可以达到66个)。当共享池太小或者语句的reuse低的时候,会出现‘shared pool’、‘library cache pin’或者 ‘library cache’ latch的争用。解决的方法是:增大共享池或者设置CURSOR_SHARING=FORCE|SIMILAR ,当然我们也需要tuning SQL statement。为减少争用,我们也可以把一些比较大的SQL或者过程利用DBMS_SHARED_POOL.KEEP包来pinning在shared pool中。 shared pool内存结构与buffer cache类似,也采用的是hash方式来管理的。共享池有一个固定数量的hash buckets,通过固定数量的library cache latch来串行化保护这段内存的使用。在数据启动的时候,会分配509个hash buctets,2*CPU_COUNT个library cache latch。当在数据库的使用中,共享池中的对象越来越多,oracle就会以以下的递增方式增加hash buckets的数量:509,1021,4093,8191,32749,65521,131071,4292967293。我们可以通过设置下面的参数来实现_KGL_BUCKET_COUNT,参数的默认值是0,代表数量509,最大我们可以设置为8,代表数量131071。 我们可以通过x$ksmsp来查看具体的共享池内存段情况,主要关注下面几个字段: KSMCHCOM—表示内存段的类型 ksmchptr—表示内存段的物理地址 ksmchsiz—表示内存段的大小 ksmchcls—表示内存段的分类。recr表示a
recreatable piece currently in use that can be a candidate for flushing when
the shared pool is low in available memory; freeabl表示当前正在使用的,能够被释放的段; free表示空闲的未分配的段; perm表示不能被释放永久分配段。 降低共享池的latch 争用,我们主要可以考虑如下的几个事件: 1、使用绑定变量 2、使用cursor sharing 3、设置session_cached_cursors参数。该参数的作用是将cursor从shared pool转移到pga中。减小对共享池的争用。一般初始的值可以设置为100,然后视情况再作调整。 4、设置合适大小的共享池