详细解读 STATSPACK 报告（完结）

秒变学霸的18岁码农

于 2023-04-20 13:32:12 发布

阅读量760

点赞数

文章标签： oracle 数据库

本文链接：https://blog.csdn.net/2301_76957510/article/details/130264419

版权

7、I/O统计信息

下面两个报表是面向I/O的。通常，在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦DBA了解了如何读取和写入这些数据，他们也许能够通过磁盘间更均匀的分配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<FULL SCAN COST时，oracle会选择使用索引。在具体设置的时候，我们可以根据具体的语句来调整该值。如果我们希望某个statement使用索引，而实际它确走全表扫描，可以对比这两种情况的执行计划不同的COST，从而设置一个更合适的值。

5）检查并调整I/O设备的性能。

Tablespace IO Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14

->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)

-------------- ------- ------ ------- ------------ -------- ---------- ------

ICD_DXH_IDX

3,869 5 8.6 1.0 36,701 44 1,180 0.1

ICD_DXH_DAT

2,572 3 9.7 1.0 16,545 20 1,076 0.2

UNDOTBS1

16 0 86.9 1.0 19,084 23 283 0.0

ICD_DXH_HISIDX

689 1 30.8 1.0 14,953 18 108 0.0

ICD_DXH_HISDAT

2,756 3 7.9 7.3 1,082 1 3 0.0

PERFSTAT

215 0 6.0 1.0 193 0 0 0.0

SYSTEM

55 0 11.5 5.0 17 0 717 0.1

INDX

1 0 40.0 1.0 1 0 0 0.0

TOOLS

1 0 40.0 1.0 1 0 0 0.0

USERS

1 0 40.0 1.0 1 0 0 0.0

-------------------------------------------------------------

File IO Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14

->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)

-------------- ------- ------ ------- ------------ -------- ---------- ------

ICD_DXH_DAT /dev/rlv_data001

377 0 9.4 1.0 1,640 2 321 0.2

/dev/rlv_data002

327 0 9.0 1.0 1,630 2 169 0.0

/dev/rlv_data003

313 0 10.0 1.0 1,718 2 87 0.0

/dev/rlv_data004

357 0 9.9 1.0 1,661 2 86 0.0

/dev/rlv_data005

400 0 11.5 1.0 1,627 2 128 0.2

/dev/rlv_data006

389 0 8.5 1.0 6,700 8 126 0.0

/dev/rlv_data007

409 0 9.6 1.0 1,569 2 159 0.7

8、Buffer Pool统计信息

这里将buffer poll细分，列举default、keep、recycle三种类型的buffer的详细情况。在这份报告中，我们的系统中只使用Default size的buffer pool。这里的3个waits统计，其实在前面的等待时间中已经包含，所以可以参考前面的描述。关于命中率也已经在前面讨论。

所以，其实这段信息不需要怎么关注。

Buffer Pool Statistics for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> 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 635,200 99.9 19,556,815 26,990 88,450 0 0 3,368

9、实例的恢复情况统计信息

这部分主要是关于实例的恢复的一些统计信息，也不需要怎么关注。

Instance Recovery Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> 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 300 70 54311 452198 450720 450720 1224858

E 300 69 53127 452947 450720 450720 1472619

10、Buffer Pool调整的Advisory

这是oracle的对buffer pool的大小的调整建议。从advisory的数据看，当然buffer是越大，物理读更小，随着buffer的增大，对物理读的性能改进越来越小。当前buffer 设置为5,120M，物理读因子=1。我们可以看到，buffer pool在3G之前的扩大，对物理读的改善非常明显，之后，这种改善的程度越来越低。

Buffer Pool Advisory for DB: ORA92 Instance: ora92 End Snap: 14

-> Only rows with estimated physical reads >0 are displayed

-> ordered by Block Size, Buffers For Estimate (default block size first)

Size for Size Buffers for Est Physical Estimated

P Estimate (M) Factr Estimate Read Factor Physical Reads

--- ------------ ----- ---------------- ------------- ------------------

D 512 .1 63,520 9.85 245,880,558

D 1,024 .2 127,040 5.41 134,932,093

D 1,536 .3 190,560 3.38 84,471,707

D 2,048 .4 254,080 2.41 60,240,471

D 2,560 .5 317,600 1.86 46,399,611

D 3,072 .6 381,120 1.54 38,365,243

D 3,584 .7 444,640 1.32 33,017,978

D 4,096 .8 508,160 1.18 29,353,901

D 4,608 .9 571,680 1.07 26,763,133

D 5,120 1.0 635,200 1.00 24,962,078

D 5,632 1.1 698,720 0.95 23,661,399

D 6,144 1.2 762,240 0.91 22,672,122

D 6,656 1.3 825,760 0.88 21,902,502

D 7,168 1.4 889,280 0.85 21,277,585

D 7,680 1.5 952,800 0.83 20,755,944

D 8,192 1.6 1,016,320 0.81 20,331,009

D 8,704 1.7 1,079,840 0.80 19,949,127

D 9,216 1.8 1,143,360 0.78 19,563,065

D 9,728 1.9 1,206,880 0.77 19,226,351

D 10,240 2.0 1,270,400 0.76 18,948,622

11、Buffer Pool等待情况统计

这里的buffer等待往往带来data block的比较大的等待。这部分等待的情况在前面等待事件中已经作过描述。

Buffer wait Statistics for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> ordered by wait time desc, waits desc

Tot Wait Avg

Class Waits Time (s) Time (ms)

------------------ ----------- ---------- ---------

data block 3,086 0 0

undo block 196 0 0

undo header 87 0 0

1st level bmb 3 0 0

2nd level bmb 1 0 0

12、PGA统计信息

这一部分主要展现的是PGA使用的情况，我们可以根据具体的情况通过设置参数PGA_AGGREGATE_TARGET来调整PGA的值。

在这里，设置的pga_aggregate_target=500M，并发数大概为270。而且数据库设置为DEDICATED模式，在这种情况下，PGA要求有更大的空间，因为在PGA下需要存放stack space，user serssion data，cursor state信息。

通过下面的两个信息，我们可以看到当前的设置下，PGA Cache Hit达到了100％，所有的操作都是内存中完成的。

PGA Aggr Target Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> B: Begin snap E: End snap (rows dentified with B or E contain data

which is absolute i.e. not diffed over the interval)

-> PGA cache hit % - percentage of W/A (WorkArea) data processed only in-memory

-> 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 Cache Hit % W/A MB Processed Extra W/A MB Read/Written

--------------- ---------------- -------------------------

100.0 2,421 0

%PGA %Auto %Man

PGA Aggr Auto PGA PGA Mem W/A PGA W/A W/A W/A Global Mem

Target(M) Target(M) Alloc(M) Used(M) Mem Mem Mem Bound(K)

- --------- --------- ---------- ---------- ------ ------ ------ ----------

B 500 354 216.3 0.0 .0 .0 .0 25,600

E 500 355 214.4 0.0 .0 .0 .0 25,600

PGA Aggr Target Histogram for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> Optimal Executions are purely in-memory operations

Low High

Optimal Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs

------- ------- -------------- ------------- ------------ ------------

8K 16K 246,058 246,058 0 0

16K 32K 104 104 0 0

32K 64K 1 1 0 0

64K 128K 3 3 0 0

128K 256K 2 2 0 0

256K 512K 2 2 0 0

512K 1024K 1 1 0 0

2M 4M 4 4 0 0

13、PGA调整的Advisory

PGA_AGGREGATE_TARGET参数的调整建议。

我们可以看到，在advisory中，当PGA_AGGREGATE_TARGET达到500M时，再增大PGA_AGGREGATE_TARGET，基本已经起不到提升性能的作用了。

PGA Memory Advisory for DB: ORA92 Instance: ora92 End Snap: 14

-> When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value

where Estd PGA Overalloc Count is 0

Estd Extra Estd PGA Estd PGA

PGA Target Size W/A MB W/A MB Read/ Cache Overalloc

Est (MB) Factr Processed Written to Disk Hit % Count

---------- ------- ---------------- ---------------- -------- ----------

63 0.1 4,398,132.4 17,448.1 100.0 34,943

125 0.3 4,398,132.4 4,267.6 100.0 47

250 0.5 4,398,132.4 435.8 100.0 0

375 0.8 4,398,132.4 382.9 100.0 0

500 1.0 4,398,132.4 0.0 100.0 0

600 1.2 4,398,132.4 0.0 100.0 0

700 1.4 4,398,132.4 0.0 100.0 0

800 1.6 4,398,132.4 0.0 100.0 0

900 1.8 4,398,132.4 0.0 100.0 0

1,000 2.0 4,398,132.4 0.0 100.0 0

1,500 3.0 4,398,132.4 0.0 100.0 0

2,000 4.0 4,398,132.4 0.0 100.0 0

3,000 6.0 4,398,132.4 0.0 100.0 0

4,000 8.0 4,398,132.4 0.0 100.0 0

14、队列的统计信息

关于Enqueue，我们在等待事件里面已经作了比较详尽的描述，这里只是对等待事件的一个展开描述，分项的含义请参考在等待事件的说明。

Enqueue activity for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> Enqueue stats gathered prior to 9i should not be compared with 9i data

-> ordered by Wait Time desc, Waits desc

Avg Wt Wait

Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)

-- ------------ ------------ ----------- ----------- ------------- ------------

TX 81,127 81,263 0 674 134.32 91

SQ 2,032 2,032 0 53 .25 0

HW 107 107 0 1 2.00 0

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，也就是说，从来就没收缩过。

Rollback Segment Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14

->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 4.0 0.00 0 0 0 0

1 67,197.0 0.00 52,642,136 7 0 7

2 16,647.0 0.00 12,321,446 2 0 2

3 9,179.0 0.00 7,032,792 8 0 8

4 8,004.0 0.00 6,735,562 3 0 2

5 7,748.0 0.00 6,428,610 3 0 0

6 7,848.0 0.00 5,847,978 6 0 3

7 7,825.0 0.00 6,115,490 6 0 6

8 7,878.0 0.00 6,782,332 5 0 4

9 8,119.0 0.00 7,708,258 8 0 5

10 7,634.0 0.00 5,493,894 5 0 6

11 7,645.0 0.00 6,633,562 1 0 0

12 7,624.0 0.00 4,911,454 5 0 5

13 7,514.0 0.00 6,006,992 0 0 0

14 7,656.0 0.00 5,171,854 6 0 6

-------------------------------------------------------------

Rollback Segment Storage for DB: ORA92 Instance: ora92 Snaps: 13 -14

->Optimal Size should be larger than Avg Active

RBS No Segment Size Avg Active Optimal Size Maximum Size

------ --------------- --------------- --------------- ---------------

0 385,024 59,380 385,024

1 176,283,648 6,272,394 176,283,648

2 92,397,568 3,103,770 92,397,568

3 54,648,832 1,317,711 116,514,816

4 47,308,800 1,769,136 520,216,576

5 38,920,192 3,437,158 92,397,568

6 34,725,888 3,251,782 93,446,144

7 64,086,016 2,344,243 100,786,176

8 41,017,344 3,139,717 130,146,304

9 41,017,344 1,793,144 113,369,088

10 57,794,560 1,822,037 109,174,784

11 36,823,040 838,860 36,823,040

12 50,454,528 719,518 50,454,528

13 52,551,680 429,400 52,551,680

14 45,211,648 967,324 45,211,648

-------------------------------------------------------------

Undo Segment Summary for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> 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

---- -------------- ---------- -------- ---------- -------- ------ -------------

1 13,853 ########## 56 1 0 0 0/0/0/0/0/0

-------------------------------------------------------------

Undo Segment Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> 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

------------ ------------ -------- ------- -------- ------- ------ -------------

14-Jul 00:28 13,853 ######## 56 1 0 0 0/0/0/0/0/0

16、闩锁统计信息

Latch是一种低级排队机制，用于防止对内存结构的并行访问，保护系统全局区(SGA)共享内存结构。Latch是一种快速地被获取和释放的内存锁。如果latch不可用，就会记录latch free miss 。

有两种类型的Latch:willing to wait和（immediate）not willing to wait。

对于愿意等待类型(willing-to-wait)的latch,如果一个进程在第一次尝试中没有获得latch,那么它会等待并且再尝试一次,如果经过_spin_count次争夺不能获得latch, 然后该进程转入睡眠状态，百分之一秒之后醒来，按顺序重复以前的步骤。在8i/9i中默认值是_spin_count=2000。睡眠的时间会越来越长。

　　对于不愿意等待类型(not-willing-to-wait)的latch，如果该闩不能立即得到的话，那么该进程就不会为获得该闩而等待。它将继续执行另一个操作。

　　大多数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的等待问题。

如果SQL语句不能调整，在8.1.6版本以上，可以通过设置CURSOR_SHARING = force 在服务器端强制绑定变量。设置该参数可能会带来一定的副作用，可能会导致执行计划不优，另外对于Java的程序，有相关的bug，具体应用应该关注Metalink的bug公告。

下面对几个重要类型的latch等待加以说明：

latch free：当‘latch free’在报告的高等待事件中出现时，就表示可能出现了性能问题，就需要在这一部分详细分析出现等待的具体的latch的类型，然后再调整。
cache buffers chain：cbc latch表明热块。为什么这会表示存在热块？为了理解这个问题，先要理解cbc的作用。ORACLE对buffer cache管理是以hash链表的方式来实现的（oracle称为buckets，buckets的数量由_db_block_hash_buckets定义）。cbc latch就是为了保护buffer cache而设置的。当有并发的访问需求时，cbc会将这些访问串行化，当我们获得cbc latch的控制权时，就可以开始访问数据，如果我们所请求的数据正好的某个buckets中，那就直接从内存中读取数据，完成之后释放cbc latch，cbc latch就可以被其他的用户获取了。cbc latch获取和释放是非常快速的，所以这种情况下就一般不会存在等待。但是如果我们请求的数据在内存中不存在，就需要到物理磁盘上读取数据，这相对于latch来说就是一个相当长的时间了，当找到对应的数据块时，如果有其他用户正在访问这个数据块，并且数据块上也没有空闲的ITL槽来接收本次请求，就必须等待。在这过程中，我们因为没有得到请求的数据，就一直占有cbc latch，其他的用户也就无法获取cbc latch，所以就出现了cbc latch等待的情况。所以这种等待归根结底就是由于数据块比较hot的造成的。
解决方法可以参考前面在等待事件中的3) buffer busy wait中关于热块的解决方法。
cache buffers lru chain：该latch用于扫描buffer的LRU链表。三种情况可导致争用：1）buffer cache太小；2）buffer cache的过度使用，或者太多的基于cache的排序操作；3）DBWR不及时。解决方法：查找逻辑读过高的statement，增大buffer cache。
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、设置合适大小的共享池
Redo Copy：这个latch用来从PGA中copy redo records到redo log buffer。latch的初始数量是2*COU_OUNT，可以通过设置参数_LOG_SIMULTANEOUS_COPIES在增加latch的数量，减小争用。
Redo allocation：该latch用于redo log buffer的分配。减小这种类型的争用的方法有3个：
增大redo log buffer
适当使用nologging选项
避免不必要的commit操作
Row cache objects：该latch出现争用，通常表明数据字典存在争用的情况，这往往也预示着过多的依赖于公共同义词的parse。解决方法：1）增大shared pool 2）使用本地管理的表空间，尤其对于索引表空间

Latch事件	建议解决方法
Library cache	使用绑定变量; 调整shared_pool_size.
Shared pool	使用绑定变量; 调整shared_pool_size.
Redo allocation	减小 redo 的产生；避免不必要的commits.
Redo copy	增加 _log_simultaneous_copies.
Row cache objects	增加shared_pool_size
Cache buffers chain	增大 _DB_BLOCK_HASH_BUCKETS ； make it prime.
Cache buffers LRU chain	使用多个缓冲池；调整引起大量逻辑读的查询

注：在这里，提到了不少隐藏参数，也有利用隐藏参数来解决latch的方法描述，但是在实际的操作中，强烈建议尽量不要去更改隐藏参数的默认值。

Latch Activity for DB: ORA92 Instance: ora92 Snaps: 13 -14

->"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

Pct Avg Wait Pct

Get Get Slps Time NoWait NoWait

Latch Requests Miss /Miss (s) Requests Miss

------------------------ -------------- ------ ------ ------ ------------ ------

Consistent RBA 67,061 0.0 0 0

FIB s.o chain latch 4 0.0 0 0

FOB s.o list latch 240 0.0 0 0

SQL memory manager latch 1 0.0 0 281 0.0

SQL memory manager worka 296,916 0.0 0.0 0 0

active checkpoint queue 1,340 0.0 0 0

cache buffer handles 2,980 0.0 0.0 0 0

cache buffers chains 44,382,255 5.4 0.0 0 93,328 0.0

cache buffers lru chain 148,064 0.0 0.0 0 131,731 0.0

channel handle pool latc 30 0.0 0 0

channel operations paren 627 0.0 0 0

checkpoint queue latch 463,732 0.0 0.0 0 85,528 0.0

child cursor hash table 36,633 0.0 0 0

dml lock allocation 450,770 1.0 0.0 0 0

dummy allocation 1,434 1.1 0.0 0 0

enqueue hash chains 638,884 0.3 0.0 0 0

enqueues 233,476 0.2 0.0 0 0

event group latch 14 0.0 0 0

global tx hash mapping 264 0.0 0 0

hash table column usage 5 0.0 0 14 0.0

job workq parent latch 0 0 1,191 8.6

job_queue_processes para 182 0.0 0 0

ktm global data 3 0.0 0 0

kwqit: protect wakeup ti 27 0.0 0 0

lgwr LWN SCN 67,123 0.0 0.0 0 0

library cache 4,755,237 1.1 0.0 0 0

library cache load lock 274 0.0 0 0

library cache pin 3,867,684 0.2 0.0 0 0

library cache pin alloca 470,588 0.3 0.0 0 0

list of block allocation 19,378 0.0 0 0

loader state object free 84 0.0 0 0

longop free list parent 1 0.0 0 0

messages 212,197 0.1 0.0 0 0

mostly latch-free SCN 67,390 0.0 0.0 0 0

multiblock read objects 4,601 0.0 0 0

ncodef allocation latch 14 0.0 0 0

object stats modificatio 25 0.0 0 0

post/wait queue 128,656 0.0 0.0 0 74,194 0.2

process allocation 14 0.0 0 14 0.0

process group creation 30 0.0 0 0

redo allocation 1,477,895 0.2 0.0 0 0

redo copy 0 0 1,344,659 0.1

redo writing 203,129 0.0 0.0 0 0

row cache enqueue latch 21,995 0.1 0.0 0 0

row cache objects 30,913 1.9 0.0 0 0

sequence cache 122,787 0.3 0.0 0 0

session allocation 499,051 0.4 0.0 0 0

session idle bit 901,267 0.0 0.0 0 0

session switching 14 0.0 0 0

session timer 291 0.0 0 0

Latch Activity for DB: ORA92 Instance: ora92 Snaps: 13 -14

->"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

Pct Avg Wait Pct

Get Get Slps Time NoWait NoWait

Latch Requests Miss /Miss (s) Requests Miss

------------------------ -------------- ------ ------ ------ ------------ ------

shared pool 2,819,295 0.1 0.0 0 0

sim partition latch 0 0 252 0.0

simulator hash latch 1,046,772 0.0 0.0 0 0

simulator lru latch 596 0.0 0 15,390 5.7

sort extent pool 17 0.0 0 0

spilled msgs queues list 27 0.0 0 0

transaction allocation 3,207 0.4 0.0 0 0

transaction branch alloc 62 0.0 0 0

undo global data 286,249 0.1 0.0 0 0

user lock 1,432 0.6 0.0 0 0

-------------------------------------------------------------

Latch Sleep breakdown for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> ordered by misses desc

Get Spin &

Latch Name Requests Misses Sleeps Sleeps 1->4

-------------------------- -------------- ----------- ----------- ------------

cache buffers chains 44,382,255 2,408,704 1,302 0/0/0/0/0

library cache 4,755,237 51,183 5 51178/5/0/0/

session allocation 499,051 2,050 1 2049/1/0/0/0

-------------------------------------------------------------

Latch Miss Sources for DB: ORA92 Instance: ora92 Snaps: 13 -14

-> only latches with sleeps are shown

-> ordered by name, sleeps desc

NoWait Waiter

Latch Name Where Misses Sleeps Sleeps

------------------------ -------------------------- ------- ---------- --------

cache buffers chains kcbgtcr: kslbegin excl 0 859 741

cache buffers chains kcbchg: kslbegin: bufs not 0 217 139

cache buffers chains kcbgcur: kslbegin 0 135 130

cache buffers chains kcbrls: kslbegin 0 58 188

cache buffers chains kcbgtcr: fast path 0 11 3

cache buffers chains kcbbic2 0 3 0

cache buffers chains kcbnlc 0 3 3

cache buffers chains kcbget: pin buffer 0 3 1

cache buffers chains kcbget: exchange rls 0 3 2

cache buffers chains kcbchg: kslbegin: call CR 0 3 70

cache buffers chains kcbzwb 0 1 0

library cache kglpnc: child 0 3 2

library cache kglic 0 1 0

library cache kglupc: child 0 1 0

session allocation ksuxds: not user session 0 1 0

17、共享池统计信息

/* 字典缓存统计

Dictionary Cache Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14

->"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

Cache Requests Miss Reqs Miss Reqs Usage

------------------------- ------------ ------ ------- ----- -------- ----------

dc_database_links 528 0.0 0 0 2

dc_histogram_defs 22 86.4 0 0 4,295

dc_object_ids 69 29.0 0 0 403

dc_objects 233 36.1 0 0 895

dc_profiles 705 0.0 0 0 1

dc_rollback_segments 3,911 0.0 0 0 233

dc_segments 187 1.1 0 12 5,778

dc_sequences 1,978 0.0 0 1,978 9

dc_tablespace_quotas 12 0.0 0 12 4

dc_tablespaces 458 0.0 0 0 11

dc_user_grants 120 0.0 0 0 18

dc_usernames 56 0.0 0 0 12

dc_users 3,674 0.0 0 0 20

/* 库缓存详细信息，。

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');

Library Cache Activity for DB: ORA92 Instance: ora92 Snaps: 13 -14

->"Pct Misses" should be very low

Get Pct Pin Pct Invali-

Namespace Requests Miss Requests Miss Reloads dations

--------------- ------------ ------ -------------- ------ ---------- --------

BODY 1,699 0.0 1,699 0.0 0 0

INDEX 54 0.0 54 0.0 0 0

SQL AREA 5,665 0.0 1,497,193 0.4 6,086 0

TABLE/PROCEDURE 92,424 0.1 429,557 0.1 0 0

TRIGGER 1,412 0.0 1,412 0.0 0 0

/* 共享池调整建议。

Shared Pool Advisory for DB: ORA92 Instance: ora92 End Snap: 14

-> 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

Estd

Shared Pool SP Estd Estd Estd Lib LC Time

Size for Size Lib Cache Lib Cache Cache Time Saved Estd Lib Cache

Estim (M) Factr Size (M) Mem Obj Saved (s) Factr Mem Obj Hits

----------- ----- ---------- ------------ ------------ ------- ---------------

224 .5 97 55,129 10,514,328 1.0 807,719,425

272 .7 112 68,387 10,514,329 1.0 807,719,480

320 .8 113 68,787 10,514,329 1.0 807,719,485

368 .9 113 68,787 10,514,329 1.0 807,719,485

416 1.0 113 68,787 10,514,329 1.0 807,719,485

464 1.1 113 68,787 10,514,329 1.0 807,719,485

512 1.2 113 68,787 10,514,329 1.0 807,719,485

560 1.3 113 68,787 10,514,329 1.0 807,719,485

608 1.5 113 68,787 10,514,329 1.0 807,719,485

656 1.6 113 68,787 10,514,329 1.0 807,719,485

704 1.7 113 68,787 10,514,329 1.0 807,719,485

752 1.8 113 68,787 10,514,329 1.0 807,719,485

800 1.9 113 68,787 10,514,329 1.0 807,719,485

848 2.0 113 68,787 10,514,329 1.0 807,719,485

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的单位递增的。

SGA Memory Summary for DB: ORA92 Instance: ora92 Snaps: 13 -14

SGA regions Size in Bytes

------------------------------ ----------------

Database Buffers 5,368,709,120

Fixed Size 754,760

Redo Buffers 2,371,584

Variable Size 3,137,339,392

----------------

sum 8,509,174,856

-------------------------------------------------------------

SGA breakdown difference for DB: ORA92 Instance: ora92 Snaps: 13 -14

Pool Name Begin value End value % Diff

------ ------------------------------ ---------------- ---------------- -------

java free memory 33,554,432 33,554,432 0.00

large free memory 16,777,216 16,777,216 0.00

shared 1M buffer 1,056,768 1,056,768 0.00

……省略部分内容……

19、资源限制统计信息

这部分是关于oracle资源限制的一个描述。只显示当前正在使用或者最大使用率超过80％的资源限制。

Resource Limit Stats for DB: ORA92 Instance: ora92 End Snap: 14

-> only rows with Current or Maximum Utilization > 80% of Limit are shown

-> ordered by resource name

Current Maximum Initial

Resource Name Utilization Utilization Allocation Limit

------------------------------ ------------ ------------ ---------- ----------

parallel_max_servers 0 5 6 6

20、初始化统计信息

这是报表的最后一部分，是关于常用重要的一些系统的初始化参数设置的汇总情况。不再详述。

init.ora Parameters for DB: ORA92 Instance: ora92 Snaps: 13 -14

End value

Parameter Name Begin value (if different)

----------------------------- --------------------------------- --------------

aq_tm_processes 1

background_dump_dest /opt/oracle/app/oracle/admin/ora9

compatible 9.2.0.0.0

control_files /dev/rlv_ctrl1, /dev/rlv_ctrl2, /

core_dump_dest /opt/oracle/app/oracle/admin/ora9

cursor_sharing SIMILAR

db_block_size 8192

db_cache_size 5368709120

db_domain

db_file_multiblock_read_count 8

db_name ora92

……省略部分内容……

-------------------------------------------------------------

End of Report

----END----

秒变学霸的18岁码农

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
详细解读 STATSPACK 报告（完结）

7、I/O统计信息下面两个报表是面向I/O的。通常，在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦DBA了解了如何读取和写入这些数据，他们也许能够通过磁盘间更均匀的分配I/O而得到某些性能提升。在这里主要关注Av Rd(ms)列 (reads per millisecond)的值，一般来说，大部分的磁盘系统的这个值都能调整到14ms以下，oracle认为该值超过20ms都是不必要的。如果该值超过1000ms，基本可以肯定存在I/O的性能瓶颈。如果在这一列上出现#
复制链接

扫一扫