192.168.3.90数据库性能综合分析报告
详细解读 3.90 STATSPACK 报告
1、报表头信息---------------------------------------------------------------2
2、实例负载档信息-----------------------------------------------------------2
3、实例有效性信息-----------------------------------------------------------3
4、TOP 5及其他等待事件信息-------------------------------------------------5
5、SQL统计信息-------------------------------------------------------------7
5.1 SQL统计信息－逻辑读-------------------------------------------------7
5.2 SQL统计信息－物理读------------------------------------------------13
5.3 SQL统计信息－执行次数----------------------------------------------14
5.4 SQL统计信息－调用、解析次数----------------------------------------17
5.5 SQL统计信息－共享内存占用------------------------------------------21
5.6 SQL统计信息－多版本缓存--------------------------------------------21
6、实例的活动信息----------------------------------------------------------21
7、I/O统计信息------------------------------------------------------------25
8、Buffer Pool统计信息----------------------------------------------------29
9、实例的恢复情况统计信息--------------------------------------------------29
10、Buffer Pool调整的Advisory---------------------------------------------30
11、Buffer Pool等待情况统计------------------------------------------------30
12、PGA统计信息 -----------------------------------------------------------30
13、PGA调整的Advisory-----------------------------------------------------30
14、队列的统计信息---------------------------------------------------------30
15、回滚段统计信息---------------------------------------------------------31
16、闩锁统计信息-----------------------------------------------------------32
17、共享池统计信息---------------------------------------------------------34
18、SGA内存分配 -----------------------------------------------------------36
19、资源限制统计信息-------------------------------------------------------38
20、初始化统计信息---------------------------------------------------------38
1、报表头信息
总结：数据库名ORCL,实例名orcl,数据库版本号9.0.1.0.0，是否集群NO，主机名server1,报告产生时间20分钟，并发数53，buffer cache大小92M，Shared pool size大小128M；
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
ORCL 1278871612 orcl 1 9.0.1.0.0 NO server1
Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 11 05-Sep-14 09:52:32 54 6.3
End Snap: 12 05-Sep-14 10:12:38 53 6.0
Elapsed: 20.10 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 92M Std Block Size: 4K
Shared Pool Size: 128M Log Buffer: 400K
2、实例负载档信息
总结：1 redo size:（标志数据变更频率, 数据库任务的繁重与否）每秒产生日志5.9K，每秒产生11个事物（反映数据库任务繁重与否）；
2 Logical reads:平均每秒产生逻辑读8099个block； Logical Reads= Consistent Gets + DB Block Gets
3 block changes:每秒block变化30个
4 physical reads:平均每秒从磁盘读取1268个block，数值过大，性能极差，应该增大buffer cache的值，提高性能
5 physical writes:平均每秒数据库写磁盘166个block;
6 user calls:每秒用户调用42次
7 parses:每秒解析23次
8 hard parses:每秒产生硬解析0.41次
9 sorts:每秒产生0.90次排序
10 logons:每秒登录次数为0
11 executes:每秒执行28.32次
12 transactions:每秒产生0.54次事务
13 % Blocks changed per Read：在每一次逻辑读中更改的块的百分比为0.37。
14 Rollback per transaction %:看回滚率是不是很高，因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
15 Recursive Call %:递归调用的百分比，如果有很多PL/SQL，那么这个值就会比较高。
16 Rows per Sort:平均每次排序操作的行数为1924。
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 6,057.96 11,291.96
Logical reads: 8,099.27 15,096.93
Block changes: 30.10 56.10
Physical reads: 1,268.93 2,365.26
Physical writes: 166.22 309.83
User calls: 42.33 78.90
Parses: 23.20 43.25
Hard parses: 0.41 0.77
Sorts: 0.90 1.67
Logons: 0.00 0.00
Executes: 28.32 52.79
Transactions: 0.54
% Blocks changed per Read: 0.37 Recursive Call %: 68.59
Rollback per transaction %: 7.57 Rows per Sort: 1924.14
3、实例有效性信息
总结：
/* 实例的有效性，这部分值越接近100越好，分项内容详细说明如下：
1)Buffer Nowait %：在缓冲区中获取Buffer的未等待比率99.99。Buffer Nowait的这个值一般需要大于99%。否则可能存在争用，可以在后面的等待事件中进一步确认。
2)Redo NoWait %：在Redo缓冲区获取Buffer空间的未等待比率100。当redo buffer达到1M时，就需要写到redo log文件，所以一般当redo buffer设置超过1M，不太可能存在等待buffer空间分配的情况。当前，一般设置为2M的redo buffer，对于内存总量来说，应该不是一个太大的值。
3)Buffer Hit %：数据块在数据缓冲区中的命中率84.66，通常应在95%以上。否则，小于95%，需要调整重要的参数，小于90%可能是要加db_cache_size。一个高的命中率，不一定代表这个系统的性能是最优的，比如大量的非选择性的索引被频繁访问，就会造成命中率很高的假相（大量的db file sequential read），但是一个比较低的命中率，一般就会对这个系统的性能产生影响，需要调整。命中率的突变，往往是一个不好的信息。如果命中率突然增大，可以检查top buffer get SQL，查看导致大量逻辑读的语句和索引，如果命中率突然减小，可以检查top physical reads SQL，检查产生大量物理读的语句，主要是那些没有使用索引或者索引被删除的。
4)In-memory Sort %：在内存中的排序率97.23。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。
5)Library Hit %：STATEMENT在共享区的命中率99.36，通常应该保持在95%以上，否则需要要考虑：加大共享池；使用绑定变量；修改cursor_sharing等参数。
6)Soft Parse %：sql在共享区的命中率98.23，小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用。
7)Execute to Parse %：一个语句执行和分析了多少次的度量18.07。计算公式为：Execute to Parse =100 * (1 - Parses/Executions)。本例中，差不多每execution 5次需要一次parse。所以如果系统Parses > Executions，就可能出现该比率小于0的情况。该值<0通常说明shared pool设置或者语句效率存在问题，造成反复解析，reparse可能较严重,或者是可能同snapshot有关，通常说明数据库性能存在问题。
8)Latch Hit %：100，要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。
9)Parse CPU to Parse Elapsd %：计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。
10)% Non-Parse CPU：计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的CPU时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。
11)Memory Usage %：正在使用的共享池的百分,93.91。这个数字应该长时间稳定在75%～90%。如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。
12)% SQL with executions>1：这是在共享池中有多少个执行次数大于一次的SQL语句的度量。在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。这里显示，在这个共享池中几乎有80%的SQL语句在14分钟的观察窗口中运行次数多于一次。剩下的20%的语句可能已经在那里了--系统只是没有去执行。
13)% Memory for SQL w/exec>1：这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与% SQL with executions>1非常接近，除非有某些查询任务消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
小结：通过ORACLE的实例有效性统计数据，我们可以获得大概的一个整体印象，然而我们并不能由此来确定数据运行的性能。当前性能问题的确定，我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，由此我们可以做到未雨绸缪。而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。
接下来，开始查看wait事件。
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.99 Redo NoWait %: 100.00
Buffer Hit %: 84.66 In-memory Sort %: 97.23
Library Hit %: 99.36 Soft Parse %: 98.23
Execute to Parse %: 18.07 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: % Non-Parse CPU:
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 93.91 93.39
% SQL with executions>1: 83.82 85.67
% Memory for SQL w/exec>1: 79.22 80.51
4、TOP 5及其他等待事件信息
总结：
1 db file sequential read 该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕（没有正确选择驱动行源），或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整。
2 db file scattered read Top 5 Wait Events该事件通常与全表扫描或者fast full index scan有关。因为全表扫描是被放入内存中进行的进行的，通常情况下基于性能的考虑，有时候也可能是分配不到足够长的连续内存空间，所以会将数据块分散(scattered)读入Buffer Cache中。该等待过大可能是缺少索引或者没有合适的索引(可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端(cold end)，对于频繁访问的较小的数据表，可以选择把他们Cache 到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 动态性能视图来进行诊断，该视图中记录了长时间(运行时间超过6 秒的)运行的事物，可能很多是全表扫描操作(不管怎样，这部分信息都是值得我们注意的)。
3 log file parallel write 从log buffer 写redo 记录到redo log 文件，主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员，当flush log buffer 时，写操作是并行的，这时候此等待事件可能出现。尽管这个写操作并行处理，直到所有I/O 操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率。改善这个等待的方法是将redo logs放到I/O快的盘中，尽量不使用raid5，确保表空间不是处在热备模式下，确保redo log和data的数据文件位于不同的磁盘中。
4 log file sync 当一个用户提交或回滚数据时，LGWR将会话的redo记录从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率, 为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG 文件访在不同的物理磁盘上，提高I/O的性能。
5 control file parallel write 当server 进程更新所有控制文件时，这个事件可能出现。如果等待很短，可以不用考虑。如果等待时间较长，检查存放控制文件的物理磁盘I/O 是否存在瓶颈。多个控制文件是完全相同的拷贝，用于镜像以提高安全性。对于业务系统，多个控制文件应该存放在不同的磁盘上，一般来说三个是足够的，如果只有两个物理硬盘，那么两个控制文件也是可以接受的。在同一个磁盘上保存多个控制文件是不具备实际意义的。减少这个等待，可以考虑如下方法:①减少控制文件的个数(在确保安全的前提下)。②如果系统支持，使用异步IO。③转移控制文件到IO 负担轻的物理磁盘。
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (s) Wt Time
-------------------------------------------- ------------ ----------- -------
db file sequential read 17,193 9 37.92
db file scattered read 198,888 5 19.68
log file parallel write 2,296 4 17.60
log file sync 1,428 2 10.47
control file parallel write 392 2 6.54
-------------------------------------------------------------
^LWait Events for DB: ORCL Instance: orcl Snaps: 11 -12
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read 17,193 0 9 1 26.6
db file scattered read 198,888 0 5 0 307.4
log file parallel write 2,296 0 4 2 3.5
log file sync 1,428 0 2 2 2.2
control file parallel write 392 0 2 4 0.6
direct path write 187,139 0 1 0 289.2
buffer busy waits 510 0 0 1 0.8
async disk IO 208,382 0 0 0 322.1
db file parallel read 2 0 0 110 0.0
latch free 11 8 0 8 0.0
log buffer space 5 0 0 9 0.0
direct path read 20,386 0 0 0 31.5
SQL*Net more data to client 984 0 0 0 1.5
control file sequential read 176 0 0 0 0.3
db file parallel write 358 358 0 0 0.6
SQL*Net break/reset to clien 4 0 0 0 0.0
LGWR wait for redo copy 2 0 0 0 0.0
row cache lock 1 0 0 0 0.0
SQL*Net message from client 50,961 0 46,227 907 78.8
SQL*Net message to client 50,959 0 0 0 78.8
SQL*Net more data from clien 558 0 0 0 0.9
-------------------------------------------------------------
^LBackground Wait Events for DB: ORCL Instance: orcl Snaps: 11 -12
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
log file parallel write 2,296 0 4 2 3.5
control file parallel write 392 0 2 4 0.6
db file scattered read 252 0 0 1 0.4
db file sequential read 25 0 0 0 0.0
control file sequential read 117 0 0 0 0.2
db file parallel write 358 358 0 0 0.6
LGWR wait for redo copy 2 0 0 0 0.0
rdbms ipc message 4,713 1,167 4,686 994 7.3
pmon timer 402 402 1,178 2929 0.6
smon timer 4 4 1,081 ###### 0.0
-------------------------------------------------------------
5、SQL统计信息
5.1 SQL统计信息－逻辑读
总结：
这一部分，通过Buffer Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程，因为存储过程执行的单独的语句的数目被总计出来。
在这里的Buffer Gets是一个累积值，所以这个值大并不一定意味着这条语句的性能存在问题。通常我们可以通过对比该条语句的Buffer Gets和physical reads值，如果这两个比较接近，肯定这条语句是存在问题的，我们可以通过执行计划来分析，为什么physical reads的值如此之高。另外，我们在这里也可以关注gets per exec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。
另外说明一点：大量的逻辑读往往伴随着较高的CPU消耗。所以很多时候我们看到的系统CPU将近100％的时候，很多时候就是SQL语句造成的，这时候我们可以分析一下这里逻辑读大的SQL。
^LSQL ordered by Gets for DB: ORCL Instance: orcl Snaps: 11 -12
-> 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
--------------- ------------ -------------- ------ -------- --------- ----------
907,935 3 302,645.0 9.3 0.00 0.00 1464371672
select sum(-s_txn_id.cr_flag*txn_amt) in_amt_sum from hist_trans
_m left join s_txn_id on hist_trans_m.txn_id=s_txn_id.txn_id lef
t join mch_info on mch_info.mid=hist_trans_m.mid where s_txn_id.
cr_flag=-1 and hist_trans_m.tran_status=:1 AND hist_trans_m.set
tle_date>=:2 AND hist_trans_m.settle_date<=:3 AND mch_info.mch
768,270 3 256,090.0 7.9 0.00 0.00 3312443568
select sum(s_txn_id.cr_flag*txn_amt) out_amt_sum from hist_trans
_m left join s_txn_id on hist_trans_m.txn_id=s_txn_id.txn_id lef
t join mch_info on mch_info.mid=hist_trans_m.mid where s_txn_id.
cr_flag=1 and hist_trans_m.tran_status=:1 AND hist_trans_m.sett
le_date>=:2 AND hist_trans_m.settle_date<=:3 AND mch_info.mch_
497,421 172 2,892.0 5.1 0.00 0.00 3766522002
select count(*) into :b0 from csr where ((teller=:b1 and org_c
ode=:b2) and tran_status=:b3)
345,823 28 12,350.8 3.5 0.00 0.00 2566304132
select count(*) from (select stat_mch.pay_date as pay_date,to_ch
ar( min(settle_date) ) || '-' || to_char( max(settle_date) ) as
period, u_issu_inst.issu_id,u_issu_inst.inst_name as inst_name,s
tat_mch.mid,mch_info.cname as cname , sum(cnt) as cnt,sum(txn_am
t) as txn_amt,sum(fee_amt) as fee_amt,sum(sett_amt) as sett_amt
345,823 28 12,350.8 3.5 0.00 0.00 4258184794
select * from (select a.*,rownum row_num from (select stat_mch.p
ay_date as pay_date,to_char( min(settle_date) ) || '-' || to_cha
r( max(settle_date) ) as period, u_issu_inst.issu_id,u_issu_inst
.inst_name as inst_name,stat_mch.mid,mch_info.cname as cname , s
um(cnt) as cnt,sum(txn_amt) as txn_amt,sum(fee_amt) as fee_amt,s
345,799 28 12,350.0 3.5 0.00 0.00 544447472
select sum(cnt) cnt_sum,sum(txn_amt) txn_amt_sum,sum(fee_amt) fe
e_amt_sum,sum(sett_amt) sett_amt_sum from stat_mch left join u
_issu_inst on u_issu_inst.issu_id=stat_mch.issu_id left join mch
_info on stat_mch.mid=mch_info.mid where mch_info.cname LIKE :1
AND stat_mch.pay_date IS NULL
208,938 9 23,215.3 2.1 0.00 0.00 4236780024
select * from (select a.*,rownum row_num from (select csr.acq_id
as acq_id,csr.audit_org as audit_org,csr.auditor as auditor,csr
.author as author,csr.card_amt as card_amt,card_client.add_date
as t01__add_date,card_client.auditor as t01__auditor,card_client
.cert_no as t01__cert_no,card_client.cli_addr as t01__cli_addr,c
141,760 4 35,440.0 1.5 0.00 0.00 2086847580
select count(*) from ((((((hist_trans_m left JOIN s_txn_id ON s_
txn_id.txn_id=hist_trans_m.txn_id) left JOIN u_issu_inst ON u_is
su_inst.issu_id=hist_trans_m.issu_id) left JOIN u_acq_inst ON u_
^LSQL ordered by Gets for DB: ORCL Instance: orcl Snaps: 11 -12
-> 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
--------------- ------------ -------------- ------ -------- --------- ----------
acq_inst.acq_id=hist_trans_m.acq_id) left JOIN s_card_type ON s_
card_type.card_type=hist_trans_m.card_type) left JOIN s_sub_type
73,122 30 2,437.4 0.7 0.00 0.00 2048733752
BEGIN :1 := p_preopen_check(:2,:3,:4,:5,:6,:7); END;
55,822 36 1,550.6 0.6 0.00 0.00 2601970352
select * from mch_info ORDER BY mch_info.mid asc
54,774 9 6,086.0 0.6 0.00 0.00 870942463
select count(*) from (((csr left JOIN u_issu_inst ON u_issu_inst
.issu_id=csr.issu_id) left JOIN u_acq_inst ON u_acq_inst.acq_id=
csr.acq_id) left JOIN card_client ON card_client.cust_no=csr.cus
t_no) left JOIN s_vouch_type ON s_vouch_type.vouch_type=csr.vouc
h_type where csr.tran_status IN(:1,:2) AND csr.cleared<>:3 AND
54,774 9 6,086.0 0.6 0.00 0.00 3269985298
select sum(card_num) as cnt,sum(payed_amt) as amt_total,sum(fq_a
mt) as fee_amt_total from (((csr left JOIN u_issu_inst ON u_issu
_inst.issu_id=csr.issu_id) left JOIN u_acq_inst ON u_acq_inst.ac
q_id=csr.acq_id) left JOIN card_client ON card_client.cust_no=cs
r.cust_no) left JOIN s_vouch_type ON s_vouch_type.vouch_type=csr
43,382 1 43,382.0 0.4 0.00 0.00 3376831664
BEGIN statspack.snap; END;
37,874 30 1,262.5 0.4 0.00 0.00 2148194035
SELECT count(*) from mk_card where pan >= :b3 and pan <= :b2
and issu_id = :b1 and mkcrd_flag = 4
37,176 6 6,196.0 0.4 0.00 0.00 1604959415
select count(*) from (mch_info left JOIN auth_area ON auth_area.
area_code=mch_info.area_code) left JOIN mcc_code ON mcc_code.mcc
=mch_info.mcc
37,082 1 37,082.0 0.4 0.00 0.00 1474678425
INSERT into stats$sqltext ( hash_value
, text_subset , piece , sql_text
, address , command_type
, last_snap_id ) select st1.hash_value
, ss.text_subset , st1.piece
34,937 28 1,247.8 0.4 0.00 0.00 4005133339
SELECT min(pan) from mk_card where pan >= :b4 and pan <= :b3
and issu_id = :b2 and mkcrd_flag = 4 and recv_dept <> :b1
25,152 8 3,144.0 0.3 0.00 0.00 922806158
select count(*) from ((((((hist_trans_m left JOIN s_txn_id ON s_
txn_id.txn_id=hist_trans_m.txn_id) left JOIN u_issu_inst ON u_is
^LSQL ordered by Gets for DB: ORCL Instance: orcl Snaps: 11 -12
-> 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
--------------- ------------ -------------- ------ -------- --------- ----------
-------------------------------------------------------------
^LSQL ordered by Reads for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
312,343 28 11,155.1 20.4 0.00 0.00 2566304132
select count(*) from (select stat_mch.pay_date as pay_date,to_ch
ar( min(settle_date) ) || '-' || to_char( max(settle_date) ) as
period, u_issu_inst.issu_id,u_issu_inst.inst_name as inst_name,s
tat_mch.mid,mch_info.cname as cname , sum(cnt) as cnt,sum(txn_am
t) as txn_amt,sum(fee_amt) as fee_amt,sum(sett_amt) as sett_amt
310,650 28 11,094.6 20.3 0.00 0.00 4258184794
select * from (select a.*,rownum row_num from (select stat_mch.p
ay_date as pay_date,to_char( min(settle_date) ) || '-' || to_cha
r( max(settle_date) ) as period, u_issu_inst.issu_id,u_issu_inst
.inst_name as inst_name,stat_mch.mid,mch_info.cname as cname , s
um(cnt) as cnt,sum(txn_amt) as txn_amt,sum(fee_amt) as fee_amt,s
309,632 28 11,058.3 20.2 0.00 0.00 544447472
select sum(cnt) cnt_sum,sum(txn_amt) txn_amt_sum,sum(fee_amt) fe
e_amt_sum,sum(sett_amt) sett_amt_sum from stat_mch left join u
_issu_inst on u_issu_inst.issu_id=stat_mch.issu_id left join mch
_info on stat_mch.mid=mch_info.mid where mch_info.cname LIKE :1
AND stat_mch.pay_date IS NULL
4,281 8 535.1 0.3 0.00 0.00 922806158
select count(*) from ((((((hist_trans_m left JOIN s_txn_id ON s_
txn_id.txn_id=hist_trans_m.txn_id) left JOIN u_issu_inst ON u_is
su_inst.issu_id=hist_trans_m.issu_id) left JOIN u_acq_inst ON u_
acq_inst.acq_id=hist_trans_m.acq_id) left JOIN s_card_type ON s_
card_type.card_type=hist_trans_m.card_type) left JOIN s_sub_type
1,946 6 324.3 0.1 0.00 0.00 2116494957
select * from (select a.*,rownum row_num from (select mch_info.a
cc_name as acc_name,mch_info.area_code as area_code,auth_area.ar
ea_code as t01__area_code,auth_area.area_desc as t01__area_desc,
auth_area.area_name as t01__area_name,auth_area.parent_code as t
01__parent_code,mch_info.br_cname as br_cname,mch_info.bus_type
1,394 4 348.5 0.1 0.00 0.00 128694328
select * from (select a.*,rownum row_num from (select hist_trans
_m.acc_type as acc_type,hist_trans_m.account as account,hist_tra
ns_m.acq_amt as acq_amt,hist_trans_m.acq_dscnt as acq_dscnt,hist
_trans_m.acq_id as acq_id,hist_trans_m.auth_no as auth_no,hist_t
rans_m.author as author,hist_trans_m.bal as bal,hist_trans_m.bal
1,362 1 1,362.0 0.1 0.00 0.00 3376831664
BEGIN statspack.snap; END;
1,162 4 290.5 0.1 0.00 0.00 2052613816
select sum(-s_txn_id.cr_flag*txn_amt) in_amt_sum from hist_trans
_m left join s_txn_id on hist_trans_m.txn_id=s_txn_id.txn_id lef
t join mch_info on mch_info.mid=hist_trans_m.mid where s_txn_id.
cr_flag=-1 and hist_trans_m.tran_status=:1 AND hist_trans_m.mid
=:2 AND hist_trans_m.settle_date>=:3 AND hist_trans_m.settle_d
1,162 4 290.5 0.1 0.00 0.00 2631385599
select sum(s_txn_id.cr_flag*txn_amt) out_amt_sum from hist_trans
5.2 SQL统计信息－物理读
总结：
这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL，即物理I/O。当我们的系统如果存在I/O瓶颈时，需要关注这里I/O操作比较多的语句。
^LSQL ordered by Reads for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
_m left join s_txn_id on hist_trans_m.txn_id=s_txn_id.txn_id lef
t join mch_info on mch_info.mid=hist_trans_m.mid where s_txn_id.
cr_flag=1 and hist_trans_m.tran_status=:1 AND hist_trans_m.mid=
:2 AND hist_trans_m.settle_date>=:3 AND hist_trans_m.settle_da
1,162 4 290.5 0.1 0.00 0.00 3569792259
select sum(-s_txn_id.cr_flag*txn_amt) amt_sum from hist_trans_m
left join s_txn_id on hist_trans_m.txn_id=s_txn_id.txn_id left j
oin mch_info on mch_info.mid=hist_trans_m.mid where hist_trans_m
.tran_status=:1 AND hist_trans_m.mid=:2 AND hist_trans_m.settl
e_date>=:3 AND hist_trans_m.settle_date<=:4 AND hist_trans_m.t
1,162 4 290.5 0.1 0.00 0.00 3775988450
select count(*) cnt,sum(txn_amt) amt_total,sum(txn_fee) fee_amt_
total,sum(txn_fee+txn_amt) txn_amt_total from hist_trans_m left
join mch_info on mch_info.mid=hist_trans_m.mid where hist_trans
_m.tran_status=:1 AND hist_trans_m.mid=:2 AND hist_trans_m.set
tle_date>=:3 AND hist_trans_m.settle_date<=:4
788 24 32.8 0.1 0.00 0.00 1520624711
select count(*) from task_csr where task_csr.appl_card_no=:1 AN
D task_csr.appl_status=:2 AND (task_csr.appl_type=:3 OR task_c
sr.appl_type=:4 )
747 1 747.0 0.0 0.00 0.00 1212505517
select i.obj#, i.flags, u.name, o.name from sys.obj$ o, sys.
user$ u, sys.ind$ i where (bitand(i.flags, 256) = 256 or bit
and(i.flags, 512) = 512) and (not((i.type# = 9) and bi
tand(i.flags,8) = 8)) and o.obj#=i.obj# and o.owner# =
u.user#
632 9 70.2 0.0 0.00 0.00 4236780024
select * from (select a.*,rownum row_num from (select csr.acq_id
as acq_id,csr.audit_org as audit_org,csr.auditor as auditor,csr
.author as author,csr.card_amt as card_amt,card_client.add_date
as t01__add_date,card_client.auditor as t01__auditor,card_client
.cert_no as t01__cert_no,card_client.cli_addr as t01__cli_addr,c
-------------------------------------------------------------
5.3 SQL统计信息－执行次数
总结：
这部分告诉我们在这段时间中执行次数最多的SQL语句。为了隔离某些频繁执行的查询，以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询，这可能是很有用的。
或许一个查询正在一个循环的内部执行，而且它可能在循环的外部执行一次，可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的飞快，任何被执行几百万次的
操作都将开始耗尽大量的时间。
^LSQL ordered by Executions for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Executions Threshold: 100
CPU per Elap per
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
------------ --------------- ---------------- ----------- ---------- ----------
2,385 1,975 0.8 0.00 0.00 94587681
select arg_value into :b0 from sys_arg where arg_name=:b1
1,350 0 0.0 0.00 0.00 2913840444
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
1,156 1,156 1.0 0.00 0.00 438662453
select txn_name ,cr_flag ,msg_type ,ins_trans ,sett_flag ,prof_f
lag ,rev_flag ,txn_type into :b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7 fr
om s_txn_id where txn_id=:b8
1,048 1,048 1.0 0.00 0.00 3947377888
select area_code ,inst_name ,inst_level ,parent_issu_id ,settle_
bank ,settle_accno ,acc_name ,rsv1 ,rsv2 ,rsv3 ,rsv4 ,rsv5 ,stat
us ,local_flag ,msg_id ,quota_flag ,mch_check_tag into :b0,:b1,:
b2,:b3,:b4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b1
6 from u_issu_inst where (issu_id=:b17 and status=0)
1,032 1,032 1.0 0.00 0.00 3902825103
select txn_name into :b0 from s_txn_id where txn_id=:b1
941 941 1.0 0.00 0.00 3230982141
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
939 939 1.0 0.00 0.00 1877781575
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
793 793 1.0 0.00 0.00 1695353531
select resp_code_text into :b0 from u_resp_code where resp_code
=:b1
774 774 1.0 0.00 0.00 893736417
select mch_grp ,cname ,ename ,settle_bank ,settle_accno ,scape_f
lag ,scape_id ,area_code ,bus_type ,mcc into :b0,:b1,:b2,:b3,:b4
,:b5,:b6,:b7,:b8,:b9 from mch_info where (mid=:b10 and status=0
)
689 689 1.0 0.00 0.00 1705880752
select file# from file$ where ts#=:1
689 0 0.0 0.00 0.00 1839874543
select file#,block#,length from uet$ where ts#=:1 and segfile#=:
2 and segblock#=:3 and ext#=:4
689 689 1.0 0.00 0.00 3687396716
insert into uet$ (segfile#,segblock#,ext#,ts#,file#,block#,lengt
h)values (:1, :2, :3, :4, :5, :6, :7)
681 1,067 1.6 0.00 0.00 904892542
select file#,block#,length from fet$ where length>=:1 and
ts#=:2 and file#=:3
669 669 1.0 0.00 0.00 528349613
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 a
^LSQL ordered by Executions for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Executions Threshold: 100
CPU per Elap per
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
------------ --------------- ---------------- ----------- ---------- ----------
nd ext#=:4
636 636 1.0 0.00 0.00 3935516425
update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,
order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:
1
587 554 0.9 0.00 0.00 4116986312
select * from lps_acc where (account=:b0 and issu_id=:b1) order
by acc_type
520 256 0.5 0.00 0.00 3250462428
select trk_m ,cvn2_m ,misc_flag into :b0,:b1,:b2 from s_txn_res
trict where (((issu_id=:b3 and sub_type=:b4) and txn_id=:b5) and
status=0)
519 519 1.0 0.00 0.00 1465481054
select count(*) into :b0 from s_txn_mask where (sub_type=:b1 a
nd txn_id=:b2)
519 357 0.7 0.00 0.00 2260264344
select * into :s1 ,:s2 ,:s3 ,:s4 ,:s5 ,:s6 ,:s7 ,:s8 ,:s9 ,:s10
,:s11 ,:s12 ,:s13 ,:s14 ,:s15 ,:s16 ,:s17 ,:s18 ,:s19 ,:s20 ,:s2
1 ,:s22 ,:s23 ,:s24 ,:s25 ,:s26 ,:s27 ,:s28 ,:s29 ,:s30 ,:s31 ,:
s32 ,:s33 ,:s34 ,:s35 ,:s36 ,:s37 from lps_mst where (pan=:b1
and issu_id=:b2)
519 519 1.0 0.00 0.00 3050780589
select count(*) into :b0 from s_txn_restrict where issu_id=:b1
494 494 1.0 0.00 0.00 2249281901
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), cacheh
int=:15, hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1
and file#=:2 and block#=:3
489 489 1.0 0.00 0.00 543063470
select * into :s1 ,:s2 ,:s3 ,:s4 ,:s5 ,:s6 ,:s7 ,:s8 ,:s9 ,:s10
,:s11 ,:s12 from s_acc_type where acc_type=:b1
489 489 1.0 0.00 0.00 2752590023
select * into :s1 ,:s2 ,:s3 ,:s4 from s_card_type where card_t
ype=:b1
469 0 0.0 0.00 0.00 3459622164
call p_get_seq(:b0,:b1) into :b2
453 452 1.0 0.00 0.00 1412076633
select issu_id ,sub_type into :b0,:b1 from s_card_bin where ((S
UBSTR(:b2,1,LENGTH(card_bin))=card_bin and (card_len=:b3 or card
_len=0)) and status=0)
^LSQL ordered by Executions for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Executions Threshold: 100
CPU per Elap per
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
------------ --------------- ---------------- ----------- ---------- ----------
451 451 1.0 0.00 0.00 2803605287
select card_type into :b0 from s_sub_type where sub_type=:b1
427 258 0.6 0.00 0.00 1442905447
select issu_id ,mch_id ,mng_id ,acq_id ,sett_id ,prof_mode ,sett
_mnr ,status into :b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7 from mch_acq
where ((mch_id=:b8 and issu_id=:b9) and status=0)
411 411 1.0 0.00 0.00 848502162
select * into :s1 ,:s2 ,:s3 ,:s4 ,:s5 ,:s6 ,:s7 ,:s8 ,:s9 ,:s10
,:s11 ,:s12 ,:s13 ,:s14 ,:s15 ,:s16 ,:s17 ,:s18 ,:s19 ,:s20 ,:s2
-------------------------------------------------------------
5.4 SQL统计信息－调用、解析次数
总结：
在这一部分，主要显示PARSE与EXECUTIONS的对比情况。如果PARSE/EXECUTIONS>1，
往往说明这个语句可能存在问题：没有使用绑定变量，共享池设置太小，cursor_sharing被设置为exact，没有设置session_cached_cursors等等问题。
^LSQL ordered by Parse Calls for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Parse Calls Threshold: 1000
% Total
Parse Calls Executions Parses Hash Value
------------ ------------ -------- ----------
1,350 1,350 0.05 2913840444
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
941 941 0.03 3230982141
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
939 939 0.03 1877781575
delete from fet$ where file#=:1 and block#=:2 and ts#=:3
868 1,048 0.03 3947377888
select area_code ,inst_name ,inst_level ,parent_issu_id ,settle_
bank ,settle_accno ,acc_name ,rsv1 ,rsv2 ,rsv3 ,rsv4 ,rsv5 ,stat
us ,local_flag ,msg_id ,quota_flag ,mch_check_tag into :b0,:b1,:
b2,:b3,:b4,:b5,:b6,:b7,:b8,:b9,:b10,:b11,:b12,:b13,:b14,:b15,:b1
6 from u_issu_inst where (issu_id=:b17 and status=0)
858 2,385 0.03 94587681
select arg_value into :b0 from sys_arg where arg_name=:b1
689 689 0.02 1705880752
select file# from file$ where ts#=:1
689 689 0.02 1839874543
select file#,block#,length from uet$ where ts#=:1 and segfile#=:
2 and segblock#=:3 and ext#=:4
689 689 0.02 3687396716
insert into uet$ (segfile#,segblock#,ext#,ts#,file#,block#,lengt
h)values (:1, :2, :3, :4, :5, :6, :7)
681 681 0.02 904892542
select file#,block#,length from fet$ where length>=:1 and
ts#=:2 and file#=:3
669 669 0.02 528349613
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 a
nd ext#=:4
636 636 0.02 3935516425
update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,
order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:
1
533 793 0.02 1695353531
select resp_code_text into :b0 from u_resp_code where resp_code
=:b1
494 494 0.02 2249281901
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), cacheh
int=:15, hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1
and file#=:2 and block#=:3
^LSQL ordered by Parse Calls for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Parse Calls Threshold: 1000
% Total
Parse Calls Executions Parses Hash Value
------------ ------------ -------- ----------
487 519 0.02 2260264344
select * into :s1 ,:s2 ,:s3 ,:s4 ,:s5 ,:s6 ,:s7 ,:s8 ,:s9 ,:s10
,:s11 ,:s12 ,:s13 ,:s14 ,:s15 ,:s16 ,:s17 ,:s18 ,:s19 ,:s20 ,:s2
1 ,:s22 ,:s23 ,:s24 ,:s25 ,:s26 ,:s27 ,:s28 ,:s29 ,:s30 ,:s31 ,:
s32 ,:s33 ,:s34 ,:s35 ,:s36 ,:s37 from lps_mst where (pan=:b1
and issu_id=:b2)
481 519 0.02 1465481054
select count(*) into :b0 from s_txn_mask where (sub_type=:b1 a
nd txn_id=:b2)
481 519 0.02 3050780589
select count(*) into :b0 from s_txn_restrict where issu_id=:b1
481 520 0.02 3250462428
select trk_m ,cvn2_m ,misc_flag into :b0,:b1,:b2 from s_txn_res
trict where (((issu_id=:b3 and sub_type=:b4) and txn_id=:b5) and
status=0)
480 489 0.02 2752590023
select * into :s1 ,:s2 ,:s3 ,:s4 from s_card_type where card_t
ype=:b1
381 411 0.01 848502162
select * into :s1 ,:s2 ,:s3 ,:s4 ,:s5 ,:s6 ,:s7 ,:s8 ,:s9 ,:s10
,:s11 ,:s12 ,:s13 ,:s14 ,:s15 ,:s16 ,:s17 ,:s18 ,:s19 ,:s20 ,:s2
1 ,:s22 ,:s23 ,:s24 ,:s25 ,:s26 from s_sub_type where sub_type
=:b1
363 363 0.01 609682960
select chrg_mnr ,fee_manner ,fee_rate ,srfs ,txn_fee ,fee_min ,f
ee_max ,rsv1 ,rsv2 into :b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7,:b8 fro
m u_cust_fee where ((issu_id=:b9 and sub_type=:b10) and txn_id=:
b11)
363 469 0.01 3459622164
call p_get_seq(:b0,:b1) into :b2
355 587 0.01 4116986312
select * from lps_acc where (account=:b0 and issu_id=:b1) order
by acc_type
345 345 0.01 775311761
select * from auth_org_info where auth_org_info.parent_code=:1
AND auth_org_info.delete_flag=:2
335 335 0.01 1753170949
select RRN.nextval from dual
325 489 0.01 543063470
select * into :s1 ,:s2 ,:s3 ,:s4 ,:s5 ,:s6 ,:s7 ,:s8 ,:s9 ,:s10
,:s11 ,:s12 from s_acc_type where acc_type=:b1
^LSQL ordered by Parse Calls for DB: ORCL Instance: orcl Snaps: 11 -12
-> End Parse Calls Threshold: 1000
% Total
Parse Calls Executions Parses Hash Value
------------ ------------ -------- ----------
299 453 0.01 1412076633
select issu_id ,sub_type into :b0,:b1 from s_card_bin where ((S
UBSTR(:b2,1,LENGTH(card_bin))=card_bin and (card_len=:b3 or card
_len=0)) and status=0)
299 451 0.01 2803605287
select card_type into :b0 from s_sub_type where sub_type=:b1
295 1,156 0.01 438662453
select txn_name ,cr_flag ,msg_type ,ins_trans ,sett_flag ,prof_f
lag ,rev_flag ,txn_type into :b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7 fr
-------------------------------------------------------------
5.5 SQL统计信息－共享内存占用
在这一部分，主要是针对shared memory占用的情况进行排序。
5.6 SQL统计信息－多版本缓存
在这一部分，主要是针对SQL语句的多版本进行排序。相同的SQL文本，但是不同属性，比如对象owner不同，会话优化模式不同、类型不同、
长度不同和绑定变量不同等等的语句，他们是不能共享的，所以再缓存中会存在多个不同的版本。这当然就造成了资源上的更多的消耗。
6、实例的活动信息
总结：
1 这部分数据主要是从V$SYSSTAT表中统计出来的
由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-1530325/(6365125+3402591))= 84.332827
2 脏数据从LRU列表中老化，dirty buffers inspected 139 0.1 0.2
如果这个值大于0，就需要考虑增加DBWRs。
3 free buffer inspected 145 0.1 0.2
值包含dirty，pinned，busy的buffer区域，如果free buffer inspected - dirty buffers inspected - buffer is pinned count=145-139-9,007,973的值还是比较大，
表明不能被重用的内存块比较多，这将导致latch争用，需要增大buffer cache。
4 通过parse count (hard)和parse count (total)，可以计算soft parse率为：
100-100*(parse count (hard)/parse count (total)) =100-100*(1-496/27985)=98.227
5 sort(disk)磁盘排序一般不能超过5％。如果超过5％，需要设置参数PGA_AGGREGATE_TARGET或者 SORT_AREA_SIZE，注意，这里SORT_AREA_SIZE是分配给每个用户的，
PGA_AGGREGATE_TARGET则是针对所有的session的一个总数设置。
6 table fetch by rowid 这是通过索引或者where rowid=语句来取得的行数，当然这个值越大越好
7 table fetch continued row 这是发生行迁移的行。当行迁移的情况比较严重时，需要对这部分进行优化。
8 table scans (long tables) longtables就是表的大小超过buffer buffer* _SMALL_TABLE_THRESHOLD的表。如果一个数据库的大表扫描过多，那么db file scattered read等待事件可能同样非常显著。
如果table scans (long tables)的per Trans值大于0，你可能需要增加适当的索引来优化你的SQL语句。
9 table scans (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参数修改是相当危险的操作。
^LInstance Activity Stats for DB: ORCL Instance: orcl Snaps: 11 -12
Statistic Total per Second per Trans
--------------------------------- ------------------ -------------- ------------
CR blocks created 2,731 2.3 4.2
DBWR buffers scanned 6,055 5.0 9.4
DBWR checkpoint buffers written 964 0.8 1.5
DBWR checkpoints 0 0.0 0.0
DBWR free buffers found 5,159 4.3 8.0
DBWR lru scans 56 0.1 0.1
DBWR make free requests 69 0.1 0.1
DBWR revisited being-written buff 0 0.0 0.0
DBWR summed scan depth 6,055 5.0 9.4
DBWR transaction table writes 5 0.0 0.0
DBWR undo block writes 823 0.7 1.3
SQL*Net roundtrips to/from client 50,950 42.3 78.8
background checkpoints completed 0 0.0 0.0
background checkpoints started 0 0.0 0.0
background timeouts 1,185 1.0 1.8
branch node splits 1 0.0 0.0
buffer is not pinned count 4,473,451 3,709.3 6,914.1
buffer is pinned count 9,007,973 7,469.3 13,922.7
bytes received via SQL*Net from c 16,994,371 14,091.5 26,266.4
bytes sent via SQL*Net to client 30,858,828 25,587.8 47,695.3
calls to get snapshot scn: kcmgss 40,734 33.8 63.0
calls to kcmgas 142,640 118.3 220.5
calls to kcmgcs 776 0.6 1.2
cleanouts and rollbacks - consist 40 0.0 0.1
cleanouts only - consistent read 34 0.0 0.1
cluster key scan block gets 13,744 11.4 21.2
cluster key scans 6,046 5.0 9.3
commit cleanout failures: block l 148 0.1 0.2
commit cleanout failures: buffer 0 0.0 0.0
commit cleanout failures: callbac 12 0.0 0.0
commit cleanout failures: cannot 0 0.0 0.0
commit cleanouts 7,732 6.4 12.0
commit cleanouts successfully com 7,572 6.3 11.7
consistent changes 4,356 3.6 6.7
consistent gets 6,365,125 5,277.9 9,837.9
consistent gets - examination 228,324 189.3 352.9
current blocks converted for CR 0 0.0 0.0
cursor authentications 364 0.3 0.6
data blocks consistent reads - un 2,826 2.3 4.4
db block changes 36,295 30.1 56.1
db block gets 3,402,591 2,821.4 5,259.0
deferred (CURRENT) block cleanout 4,840 4.0 7.5
dirty buffers inspected 139 0.1 0.2
enqueue conversions 0 0.0 0.0
enqueue releases 11,489 9.5 17.8
enqueue requests 11,498 9.5 17.8
enqueue timeouts 0 0.0 0.0
enqueue waits 0 0.0 0.0
execute count 34,157 28.3 52.8
free buffer inspected 145 0.1 0.2
free buffer requested 1,503,032 1,246.3 2,323.1
hot buffers moved to head of LRU 14,494 12.0 22.4
immediate (CR) block cleanout app 74 0.1 0.1
immediate (CURRENT) block cleanou 767 0.6 1.2
index fast full scans (full) 0 0.0 0.0
leaf node splits 159 0.1 0.3
^LInstance Activity Stats for DB: ORCL Instance: orcl Snaps: 11 -12
Statistic Total per Second per Trans
--------------------------------- ------------------ -------------- ------------
logons cumulative 2 0.0 0.0
messages received 3,906 3.2 6.0
messages sent 3,906 3.2 6.0
no buffer to keep pinned count 109,733 91.0 169.6
no work - consistent read gets 4,511,556 3,740.9 6,973.0
opened cursors cumulative 15,238 12.6 23.6
parse count (failures) 0 0.0 0.0
parse count (hard) 496 0.4 0.8
parse count (total) 27,985 23.2 43.3
physical reads 1,530,325 1,268.9 2,365.3
physical reads direct 31,533 26.2 48.7
physical writes 200,463 166.2 309.8
physical writes direct 198,468 164.6 306.8
physical writes non checkpoint 200,386 166.2 309.7
pinned buffers inspected 0 0.0 0.0
prefetched blocks 1,283,280 1,064.1 1,983.4
prefetched blocks aged out before 0 0.0 0.0
recursive calls 111,483 92.4 172.3
redo blocks written 15,816 13.1 24.5
redo buffer allocation retries 5 0.0 0.0
redo entries 18,596 15.4 28.7
redo log space requests 0 0.0 0.0
redo ordering marks 0 0.0 0.0
redo size 7,305,896 6,058.0 11,292.0
redo synch writes 1,431 1.2 2.2
redo wastage 508,268 421.5 785.6
redo writes 2,298 1.9 3.6
rollback changes - undo records a 2 0.0 0.0
rollbacks only - consistent read 2,690 2.2 4.2
rows fetched via callback 42,912 35.6 66.3
session logical reads 9,767,716 8,099.3 15,096.9
session uga memory max 406,588 337.1 628.4
shared hash latch upgrades - no w 21,049 17.5 32.5
shared hash latch upgrades - wait 0 0.0 0.0
sorts (disk) 30 0.0 0.1
sorts (memory) 1,053 0.9 1.6
sorts (rows) 2,083,842 1,727.9 3,220.8
summed dirty queue length 1,069 0.9 1.7
switch current to new buffer 53 0.0 0.1
table fetch by rowid 4,939,430 4,095.7 7,634.4
table fetch continued row 118,525 98.3 183.2
table scan blocks gotten 3,444,700 2,856.3 5,324.1
table scan rows gotten 72,141,486 59,818.8 111,501.5
table scans (long tables) 139 0.1 0.2
table scans (short tables) 1,684,127 1,396.5 2,603.0
transaction rollbacks 2 0.0 0.0
transaction tables consistent rea 1 0.0 0.0
transaction tables consistent rea 1 0.0 0.0
user calls 51,050 42.3 78.9
user commits 598 0.5 0.9
user rollbacks 49 0.0 0.1
write clones created in backgroun 0 0.0 0.0
write clones created in foregroun 0 0.0 0.0
7、I/O统计信息
总结：
在这里主要关注Av Rd(ms)列 (reads per millisecond)的值，一般来说，大部分的磁盘系统的这个值都能调整到14ms以下，oracle认为该值超过20ms都是不必要的。如果该值超过1000ms，基本可以肯定存在I/O的性能瓶颈。如果在这一列上出现######，可能是你的系统存在严重的I/O问题，也可能是格式的显示问题。
当出现上面的问题，我们可以考虑以下的方法：
1）优化操作该表空间或者文件的相关的语句。
2）如果该表空间包含了索引，可以考虑压缩索引，使索引的分布空间减小，从而减小I/O。
3）将该表空间分散在多个逻辑卷中，平衡I/O的负载。
4）我们可以通过设置参数DB_FILE_MULTIBLOCK_READ_COUNT来调整读取的并行度，这将提高全表扫描的效率。但是也会带来一个问题，就是oracle会因此更多的使用全表扫描而放弃某些索引的使用。为解决这个问题，我们需要设置另外一个参数OPTIMIZER_INDEX_COST_ADJ=30（一般建议设置10－50）。
关于OPTIMIZER_INDEX_COST_ADJ＝n：该参数是一个百分比值，缺省值为100，可以理解为FULL SCAN COST/INDEX SCAN COST。当n%* INDEX SCAN COST会选择使用索引。在具体设置的时候，我们可以根据具体的语句来调整该值。如果我们希望某个statement使用索引，而实际它确走全表扫描，
可以对比这两种情况的执行计划不同的COST，从而设置一个更合适的值。
^LTablespace IO Stats for DB: ORCL Instance: orcl Snaps: 11 -12
->ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
APP_DATA
213,556 177 0.1 7.0 650 1 510 0.0
APP_TEMP
20,654 17 0.0 1.5 189,778 157 0 0.0
INDEX14
1,381 1 1.5 1.0 9 0 0 0.0
APP_RBS
1 0 0.0 1.0 833 1 0 0.0
STATSPACK_CHEN
204 0 2.0 1.0 494 0 0 0.0
HIST14
611 1 0.7 1.0 0 0 0 0.0
TEMP
171 0 0.0 5.4 311 0 0 0.0
SYSTEM
341 0 1.1 4.2 24 0 0 0.0
HIST13
17 0 0.0 1.0 0 0 0 0.0
INDEX13
4 0 5.0 1.0 0 0 0 0.0
INDEX10
3 0 3.3 1.0 0 0 0 0.0
INDEX11
3 0 3.3 1.0 0 0 0 0.0
INDEX12
3 0 3.3 1.0 0 0 0 0.0
INDEX09
2 0 0.0 1.0 0 0 0 0.0
INDEX15
1 0 0.0 1.0 0 0 0 0.0
INDEX16
1 0 0.0 1.0 0 0 0 0.0
INDEX17
1 0 0.0 1.0 0 0 0 0.0
INDEX18
1 0 0.0 1.0 0 0 0 0.0
INDEX19
1 0 0.0 1.0 0 0 0 0.0
INDEX20
1 0 0.0 1.0 0 0 0 0.0
-------------------------------------------------------------
^LFile IO Stats for DB: ORCL Instance: orcl Snaps: 11 -12
->ordered by Tablespace, File
Tablespace Filename
------------------------ ----------------------------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
APP_DATA /home/oracle/oradata/orcl/appdata.dbf
213,556 177 0.1 7.0 650 1 510 0.0
APP_RBS /home/oracle/oradata/orcl/apprbs.dbf
1 0 0.0 1.0 833 1 0
APP_TEMP /home/oracle/oradata/orcl/apptemp.dbf
20,654 17 0.0 1.5 189,778 157 0
HIST13 /home/oracle/oradata/orcl/hist13.dbf
17 0 0.0 1.0 0 0 0
HIST14 /home/oracle/oradata/orcl/hist14.dbf
611 1 0.7 1.0 0 0 0
INDEX09 /home/oracle/oradata/orcl/index09.dbf
2 0 0.0 1.0 0 0 0
INDEX10 /home/oracle/oradata/orcl/index10.dbf
3 0 3.3 1.0 0 0 0
INDEX11 /home/oracle/oradata/orcl/index11.dbf
3 0 3.3 1.0 0 0 0
INDEX12 /home/oracle/oradata/orcl/index12.dbf
3 0 3.3 1.0 0 0 0
INDEX13 /home/oracle/oradata/orcl/index13.dbf
4 0 5.0 1.0 0 0 0
INDEX14 /home/oracle/oradata/orcl/index14.dbf
1,381 1 1.5 1.0 9 0 0
INDEX15 /home/oracle/oradata/orcl/index15.dbf
1 0 0.0 1.0 0 0 0
INDEX16 /home/oracle/oradata/orcl/index16.dbf
1 0 0.0 1.0 0 0 0
INDEX17 /home/oracle/oradata/orcl/index17.dbf
1 0 0.0 1.0 0 0 0
INDEX18 /home/oracle/oradata/orcl/index18.dbf
1 0 0.0 1.0 0 0 0
INDEX19 /home/oracle/oradata/orcl/index19.dbf
1 0 0.0 1.0 0 0 0
INDEX20 /home/oracle/oradata/orcl/index20.dbf
1 0 0.0 1.0 0 0 0
STATSPACK_CHEN /home/oracle/oradata/orcl/statspack_chen01.dbf
^LFile IO Stats for DB: ORCL Instance: orcl Snaps: 11 -12
->ordered by Tablespace, File
Tablespace Filename
------------------------ ----------------------------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
204 0 2.0 1.0 494 0 0
SYSTEM /home/oracle/oradata/orcl/oracle1.dbf
341 0 1.1 4.2 24 0 0
TEMP /home/oracle/oradata/orcl/temp01.dbf
171 0 0.0 5.4 311 0 0
8、Buffer Pool统计信息
总结：
这里将buffer poll细分，列举default、keep、recycle三种类型的buffer的详细情况。在这份报告中，我们的系统中只使用Default size的buffer pool。
这里的3个waits统计，其实在前面的等待时间中已经包含，所以可以参考前面的描述。关于命中率也已经在前面讨论。所以，其实这段信息不需要怎么关注。
-------------------------------------------------------------
^LBuffer Pool Statistics for DB: ORCL Instance: orcl Snaps: 11 -12
-> Standard block size Pools D: default, K: keep, R: recycle
-> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
Free Write Buffer
Number of Cache Buffer Physical Physical Buffer Complete Busy
P Buffers Hit % Gets Reads Writes Waits Waits Waits
--- ---------- ----- ----------- ----------- ---------- ------- -------- ------
D 23,604 81.1 7,924,107 1,498,577 1,996 0 0 510
-------------------------------------------------------------
9、实例的恢复情况统计信息
总结：
这部分主要是关于实例的恢复的一些统计信息，也不需要怎么关注。
Instance Recovery Stats for DB: ORCL Instance: orcl Snaps: 11 -12
-> B: Begin snapshot, E: End snapshot
Targt Estd Log File Log Ckpt Log Ckpt
MTTR MTTR Recovery Actual Target Size Timeout Interval
(s) (s) Estd IOs Redo Blks Redo Blks Redo Blks Redo Blks Redo Blks
- ----- ----- ---------- ---------- ---------- ---------- ---------- ----------
B 0 7 0 10554 10000 1843200 29576 10000
E 0 8 0 10716 10000 1843200 26957 10000
-------------------------------------------------------------
10、Buffer Pool调整的Advisory
11、Buffer Pool等待情况统计
总结：
这里的buffer等待往往带来data block的比较大的等待。这部分等待的情况在前面等待事件中已经作过描述。
Buffer wait Statistics for DB: ORCL Instance: orcl Snaps: 11 -12
-> ordered by wait time desc, waits desc
Tot Wait Avg
Class Waits Time (s) Time (ms)
------------------ ----------- ---------- ---------
data block 510 0 0
-------------------------------------------------------------
12、PGA统计信息
13、PGA调整的Advisory
总结：
PGA_AGGREGATE_TARGET参数的调整建议。
我们可以看到，在advisory中，当PGA_AGGREGATE_TARGET达到500M时，再增大PGA_AGGREGATE_TARGET，基本已经起不到提升性能的作用了。
PGA Memory Stats for DB: ORCL Instance: orcl Snaps: 11 -12
-> WorkArea (W/A) memory is used for: sort, bitmap merge, and hash join ops
Statistic Begin (M) End (M) % Diff
----------------------------------- ---------------- ---------------- ----------
maximum PGA allocated 50.776 50.776 .00
-------------------------------------------------------------
14、队列的统计信息
15、回滚段统计信息
总结：
从9i开始，回滚段一般都是自动管理的，一般情况下，这里我们不需要太重点关注。
在这里，主要关注pct waits，如果出现比较多的pct waits，那就需要增加回滚段的数量或者增大回滚段的空间。
另外，观察一下各个回滚段使用的情况，比较理想的是各个回滚段上Avg Active比较均衡。
在oracle 9i之前，回滚段时手工管理的，可以通过指定optimal值来设定一个回滚段收缩的值，如果不设定，
默认也应当为initial+(minextents-1)*next extents ，这个指定的结果，就是限制了回滚段不能无限制的增长，
当超过optimal的设定值后，在适当的时候，oracle会shrinks到optimal大小。但是9i之后，undo一般都设置为auto模式，
在这种模式下，我们无法指定optimal值，好像也没有默认值，所以无法shrinks，回滚段就会无限制的增长，一直到表空间利
用率达到为100％，如果表空间设置为自动扩展的方式，这种情况下，就更糟糕，undo将无限制的增长。在这里，我们也可以看到，
shrinks的值为0，也就是说，从来就没收缩过。
^LRollback Segment Stats for DB: ORCL Instance: orcl Snaps: 11 -12
->A high value for "Pct Waits" suggests more rollback segments may be required
->RBS stats may not be accurate between begin and end snaps when using Auto Undo
managment, as RBS may be dynamically created and dropped as needed
Trans Table Pct Undo Bytes
RBS No Gets Waits Written Wraps Shrinks Extends
------ -------------- ------- --------------- -------- -------- --------
0 5.0 0.00 0 0 0 0
1 2,954.0 0.00 1,517,404 0 0 0
2 2,065.0 0.00 487,874 0 0 0
3 2,004.0 0.00 419,060 0 0 0
-------------------------------------------------------------
^LRollback Segment Storage for DB: ORCL Instance: orcl Snaps: 11 -12
->Optimal Size should be larger than Avg Active
RBS No Segment Size Avg Active Optimal Size Maximum Size
------ --------------- --------------- --------------- ---------------
0 364,544 0 364,544
1 83,881,984 21,255,353 104,857,600 83,881,984
2 94,367,744 19,280,229 104,857,600 94,367,744
3 73,396,224 23,183,321 104,857,600 73,396,224
-------------------------------------------------------------
^LUndo Segment Summary for DB: ORCL Instance: orcl Snaps: 11 -12
-> Undo segment block stats:
-> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed
-> eS - expired Stolen, eR - expired Released, eU - expired reUsed
Undo Undo Num Max Qry Max Tx Snapshot Out of uS/uR/uU/
TS# Blocks Trans Len (s) Concurcy Too Old Space eS/eR/eU
---- -------------- ---------- -------- ---------- -------- ------ -------------
0 0 0 0 0 0 0 0/0/0/0/0/0
-------------------------------------------------------------
Undo Segment Stats for DB: ORCL Instance: orcl Snaps: 11 -12
-> ordered by Time desc
Undo Num Max Qry Max Tx Snap Out of uS/uR/uU/
End Time Blocks Trans Len (s) Concy Too Old Space eS/eR/eU
------------ ------------ -------- ------- -------- ------- ------ -------------
05-Sep 10:12 0 0 0 0 0 0 0/0/0/0/0/0
-------------------------------------------------------------
16、闩锁统计信息
总结：
Latch是一种低级排队机制，用于防止对内存结构的并行访问，保护系统全局区(SGA)共享内存结构。
Latch是一种快速地被获取和释放的内存锁。如果latch不可用，就会记录latch free miss 。
大多数Latch问题都可以归结为以下几种:
没有很好的是用绑定变量(library cache latch和shared pool cache)、重作生成问题(redo allocation latch)、
缓冲存储竞争问题(cache buffers LRU chain)，以及buffer cache中的存在"热点"块(cache buffers chain)。
另外也有一些latch等待与bug有关，应当关注Metalink相关bug的公布及补丁的发布。
当latch miss ratios大于0.5%时，就需要检查latch的等待问题。
^LLatch Activity for DB: ORCL Instance: orcl Snaps: 11 -12
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
-> ordered by Wait Time desc, Avg Slps/Miss, Pct NoWait Miss desc
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
------------------------ -------------- ------ ------ ------ ------------ ------
multiblock read objects 3,650,504 0.0 0.0 0 0
redo allocation 23,291 0.0 0.0 0 0
shared pool 58,710 0.0 0.0 0 0
redo writing 11,270 0.0 0.0 0 0
cache buffers chains 19,527,806 0.0 0.0 0 2,848,400 0.0
hash table column usage 4 0.0 0 1,209 0.0
process allocation 2 0.0 0 2 0.0
row cache objects 72,989 0.0 0 1 0.0
redo copy 0 0 18,590 0.0
FOB s.o list latch 40 0.0 0 0
SQL memory manager worka 67 0.0 0 0
active checkpoint queue 2,054 0.0 0 0
channel handle pool latc 5 0.0 0 0
checkpoint queue latch 294,350 0.0 0 0
dml lock allocation 11,364 0.0 0 0
enqueues 33,214 0.0 0 0
file number translation 553 0.0 0 0
ncodef allocation latch 19 0.0 0 0
messages 13,686 0.0 0 0
longop free list 11 0.0 0 0
loader state object free 68 0.0 0 0
list of block allocation 5,444 0.0 0 0
library cache load lock 190 0.0 0 0
latch wait list 2 0.0 0 0
ktm global data 4 0.0 0 0
event group latch 2 0.0 0 0
user lock 6 0.0 0 0
undo global data 13,130 0.0 0 0
transaction branch alloc 19 0.0 0 0
transaction allocation 7,915 0.0 0 0
sort extent pool 425 0.0 0 0
session switching 19 0.0 0 0
session idle bit 106,190 0.0 0 0
session allocation 19,367 0.0 0 0
sequence cache 1,278 0.0 0 0
process group creation 5 0.0 0 0
post/wait queue latch 2,851 0.0 0 0
enqueue hash chains 22,981 0.0 0 0
child cursor hash table 4,480 0.0 0 0
channel operations paren 399 0.0 0 0
archive control 1 0.0 0 0
cache buffer handles 458 0.0 0 0
library cache 497,614 0.0 0.0 0 6 0.0
cache buffers lru chain 1,686,966 0.0 0.0 0 1,502,986 0.0
-------------------------------------------------------------
^LLatch Sleep breakdown for DB: ORCL Instance: orcl Snaps: 11 -12
-> ordered by misses desc
Get Spin &
Latch Name Requests Misses Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
cache buffers chains 19,527,806 417 5 0/0/0/0/0
cache buffers lru chain 1,686,966 332 5 327/5/0/0/0
library cache 497,614 33 1 32/1/0/0/0
-------------------------------------------------------------
^LLatch Miss Sources for DB: ORCL Instance: orcl Snaps: 11 -12
-> only latches with sleeps are shown
-> ordered by name, sleeps desc
NoWait Waiter
Latch Name Where Misses Sleeps Sleeps
------------------------ -------------------------- ------- ---------- --------
cache buffers chains kcbgtcr: kslbegin 0 4 5
cache buffers chains kcbzib: multi-block read: 0 1 0
library cache kglidp: parent 0 1 0
-------------------------------------------------------------
17、共享池统计信息
总结：
/* 库缓存详细信息，。
Get Requests：get表示一种类型的锁，语法分析锁。这种类型的锁在引用了一个对象的那条SQL语句的语法分析阶段被设置在该对象上。每当一条语句被语法分析一次时 ，Get Requests的值就增加1。
pin requests：pin也表示一种类型的锁，是在执行发生的加锁。每当一条语句执行一次，pin requests的值就增加1。
reloads：reloads列显示一条已执行过的语句因Library Cache使该语句的已语法分析版本过期或作废而需要被重新语法分析的次数。
invalidations：失效发生在一条已告诉缓存的SQL语句即使已经在library cache中，但已被标记为无效并迎词而被迫重新做语法分析的时候。每当已告诉缓存的语句所引用的对象以某种方式被修改时，这些语句就被标记为无效。
pct miss应该不高于1％。
Reloads /pin requests <1％，否则应该考虑增大SHARED_POOL_SIZE。
该部分信息通过v$librarycache视图统计得到：
select namespace,gethitratio,pinhitratio,reloads,invalidations from v$librarycache
where namespace in ('SQL AREA','TABLE/PROCEDURE','BODY','TRIGGER', 'INDEX');
^LDictionary Cache Stats for DB: ORCL Instance: orcl Snaps: 11 -12
->"Pct Misses" should be very low (< 2% in most cases)
->"Cache Usage" is the number of cache entries being used
->"Pct SGA" is the ratio of usage to allocated size for that cache
Get Pct Scan Pct Mod Final Pct
Cache Requests Miss Reqs Miss Reqs Usage SGA
---------------------- ------------ ------ ------ ----- -------- ---------- ----
dc_free_extents 4,682 28.8 689 0.0 3,383 241 75
dc_histogram_defs 955 0.0 0 0 742 100
dc_object_ids 1,281 1.4 0 0 257 100
dc_objects 1,087 4.9 0 0 489 99
dc_profiles 1 0.0 0 0 1 17
dc_rollback_segments 32 0.0 0 0 5 83
dc_segments 2,190 9.0 0 882 424 99
dc_sequences 636 0.0 0 636 9 90
dc_tablespaces 3,012 0.0 0 0 33 97
dc_used_extents 1,358 50.7 0 1,358 213 62
dc_user_grants 4 0.0 0 0 14 25
dc_usernames 42 0.0 0 0 9 43
dc_users 429 0.0 0 0 15 88
-------------------------------------------------------------
Library Cache Activity for DB: ORCL Instance: orcl Snaps: 11 -12
->"Pct Misses" should be very low
Get Pct Pin Pct Invali-
Namespace Requests Miss Requests Miss Reloads dations
--------------- ------------ ------ -------------- ------ ---------- --------
BODY 5 0.0 5 0.0 0 0
SQL AREA 28,116 0.0 111,634 0.5 502 482
TABLE/PROCEDURE 2,647 2.3 6,817 3.4 69 0
-------------------------------------------------------------
18、SGA内存分配
总结：
这部分是关于SGA内存分配的一个描述，我们可以通过show sga等命令也可以查看到这里的内容。
Fixed Size:
oracle 的不同平台和不同版本下可能不一样，但对于确定环境是一个固定的值，里面存储了SGA 各部分组件的信息，可以看作引导建立SGA的区域。
Variable Size:
包含了shared_pool_size、java_pool_size、large_pool_size 等内存设置。
Database Buffers:
指数据缓冲区，在8i 中包含db_block_buffer*db_block_size、buffer_pool_keep、buffer_pool_recycle 三部分内存。在9i 中包含db_cache_size、db_keep_cache_size、db_recycle_cache_size、 db_nk_cache_size。
Redo Buffers:
指日志缓冲区，log_buffer。对于logbuffer，我们会发现在v$parameter、v$sgastat、v$sga的值不一样。v$parameter是我们可以自己设定的值，也可以设定为0，这时候，oracle降会以默认的最小值来设置v$sgastat的值，
同时v$sga也是最小的值。v$sgastat的值是基于参数log_buffer的设定值，再根据一定的计算公式得到的一个值。v$sga的值，则是根据v$sgastat的值，然后选择再加上8k－11k的一个值，得到min(n*4k)的一个值。就是说得
到的结果是4k的整数倍，也就是说v$sga是以4k的单位递增的。
^LSGA Memory Summary for DB: ORCL Instance: orcl Snaps: 11 -12
SGA regions Size in Bytes
------------------------------ ----------------
Database Buffers 100,663,296
Fixed Size 279,740
Redo Buffers 417,792
Variable Size 251,658,240
----------------
sum 353,019,068
-------------------------------------------------------------
SGA breakdown difference for DB: ORCL Instance: orcl Snaps: 11 -12
Pool Name Begin value End value % Diff
------ ------------------------------ ---------------- ---------------- -------
java free memory 33,554,432 33,554,432 0.00
shared 1M buffer 1,049,088 1,049,088 0.00
shared DML lock 196,380 196,380 0.00
shared FileIdentificatonBlock 127,884 127,884 0.00
shared FileOpenBlock 539,056 539,056 0.00
shared KGK heap 1,836 1,836 0.00
shared KGLS heap 2,210,856 2,217,588 0.30
shared KSXR pending messages que 225,836 225,836 0.00
shared KSXR receive buffers 1,058,000 1,058,000 0.00
shared PL/SQL DIANA 838,272 838,272 0.00
shared PL/SQL MPCODE 912,152 912,152 0.00
shared PLS non-lib hp 2,068 2,068 0.00
shared character set object 425,240 425,240 0.00
shared db_handles 186,000 186,000 0.00
shared dictionary cache 970,024 1,000,516 3.14
shared enqueue 311,660 311,660 0.00
shared enqueue resources 135,608 135,608 0.00
shared errors 191,884 191,884 0.00
shared event statistics per sess 2,692,060 2,692,060 0.00
shared fixed allocation callback 380 380 0.00
shared free memory 9,190,728 9,978,700 8.57
shared joxs heap init 4,220 4,220 0.00
shared ksm_file2sga region 148,652 148,652 0.00
shared ktlbk state objects 157,504 157,504 0.00
shared library cache 12,438,944 12,225,476 -1.72
shared long op statistics array 110,000 110,000 0.00
shared message pool freequeue 767,192 767,192 0.00
shared miscellaneous 5,083,364 5,069,528 -0.27
shared parameters 11,844 11,844 0.00
shared partitioning d 60,868 60,868 0.00
shared processes 250,800 250,800 0.00
shared sessions 778,540 778,540 0.00
shared simulator trace entries 786,432 786,432 0.00
shared sql area 108,768,424 108,169,592 -0.55
shared table definiti 2,632 3,572 35.71
shared temporary tabl 5,096 5,096 0.00
shared transaction 355,356 355,356 0.00
shared trigger inform 64 64 0.00
db_block_buffers 100,663,296 100,663,296 0.00
fixed_sga 279,740 279,740 0.00
log_buffer 409,600 409,600 0.00
-------------------------------------------------------------
19、资源限制统计信息
20、初始化统计信息
总结：
这是报表的最后一部分，是关于常用重要的一些系统的初始化参数设置的汇总情况。
^Linit.ora Parameters for DB: ORCL Instance: orcl Snaps: 11 -12
End value
Parameter Name Begin value (if different)
----------------------------- --------------------------------- --------------
compatible 8.1.0
control_files /home/oracle/oradata/orcl/control
db_block_buffers 23604
db_block_size 4096
db_file_multiblock_read_count 8
db_files 80
db_name orcl
global_names TRUE
instance_name orcl
java_pool_size 33554432
large_pool_size 61440000
log_archive_dest_1 location=/DS5020/orcl_archive
log_archive_format orcl_%t_%s.arc
log_archive_start TRUE
log_buffer 409600
log_checkpoint_interval 10000
log_checkpoint_timeout 1800
max_dump_file_size 10240
max_enabled_roles 30
open_cursors 100
parallel_max_servers 5
processes 300
rollback_segments r01, r02, r03
service_names dbname
shared_pool_size 134217728
sort_area_retained_size 262144
sort_area_size 262144
star_transformation_enabled false
-------------------------------------------------------------
End of Report
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29785807/viewspace-1264766/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/29785807/viewspace-1264766/
528
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
