statspack安装使用和report 分析(一)

2014-11-24 12:20:18 · 作者: · 浏览: 0

1. 查看表空间

select tablespace_name,file_name from dba_data_files;

2. 创建statspack表空间

create tablespace perfstat datafile 'd:\oracle\oradata\perfstat.dbf' size 500m

表空间要尽可能的大。

3. 安装statspack.

在oracle_home\rdmbs\admin\目录下运行:

@spcreate.sql

若创建失败则在同一目录下运行:@spdrop.sql

4. 测试:

SQL>execute statspack.snap

PL/SQL procedure successfully completed.

SQL>execute statspack.snap

PL/SQL procedure successfully completed.

SQL>@spreport.sql

使用Statspack:

sqlplus perfstat/perfstat

exec statspack.snap; -- 进行信息收集统计,每次运行都将产生一个快照号

-- 获得快照号,必须要有两个以上的快照,才能生成报表

select SNAP_ID, SNAP_TIME from STATS$SNAPSHOT;

@spreport.sql -- 输入需要查看的开始快照号与结束快照号

其他相关脚本s:

spauto.sql - 利用dbms_job提交一个作业,自动的进行STATPACK的信息收集统计

sppurge.sql - 清除一段范围内的统计信息,需要提供开始快照与结束快照号

sptrunc.sql - 清除(truncate)所有统计信息

statspack report 分析:

1) 调整的先后次序

1. Tune the design. -- Application designers

2. Tune the application. -- Application developers

3. Tune memory.

4. Tune I/O.

5. Tune contention.

6. Tune the operating system.

Statspack分析报告详解:

statspack 输出结果中必须查看的十项内容

  1、负载间档(Load profile)

  2、实例效率点击率(Instance efficiency hit ratios)

  3、首要的5个等待事件(Top 5 wait events)

  4、等待事件(Wait events)

  5、闩锁等待

  6、首要的SQL(Top sql)

  7、实例活动(Instance activity)

  8、文件I/O(File I/O)

  9、内存分配(Memory allocation)

  10、缓冲区等待(Buffer waits

1.报表头信息

数据库实例相关信息,包括数据库名称、ID、版本号及主机等信息。

STATSPACK report for

DB Name DB Id Instance Inst Num Release Cluster Host

BLISSDB 4196236801 blissdb 1 9.2.0.4.0 NO BLISS

Snap Id Snap Time Sessions Curs/Sess Comment

Begin Snap: 4 23-6月-05 17:43:32 10 3.3

End Snap: 5 23-6月-05 18:01:32 12 6.1

Elapsed: 18.00 (mins)

Cache Sizes (end)

Buffer Cache: 24M Std Block Size: 8K

Shared Pool Size: 48M Log Buffer: 512K

2.负载间档

该部分提供每秒和每个事物的统计信息,是监控系统吞吐量和负载变化的重要部分。

Load Profile

~~~~~~~~~~~~

Per Second Per Transaction

Redo size: 431,200.16 18,627,847.04z

Logical reads: 4,150.76 179,312.72

Block changes: 2,252.52 97,309.00

Physical reads: 23.93 1,033.56

Physical writes: 68.08 2,941.04

User calls: 0.96 41.36

Parses: 1.12 48.44

Hard parses: 0.04 1.92

Sorts: 0.77 33.28

Logons: 0.00 0.20

Executes: 2.36 102.12

Transactions: 0.02

Redo size:每秒产生的重做日志大小(单位字节),可标志数据变更频率, 数据库任务的繁重与否。本例中平均每秒产生了430K左右的重做,每个事务品均产生了18M的重做。

Logical reads:平次每秒产生的逻辑读,单位是block。

block changes:每秒block变化数量,数据库事物带来改变的块数量。

Physical reads:平均每秒数据库从磁盘读取的block数。

Logical reads和Physical reads比较:大约有0.55%的逻辑读导致了物理I/O,平均每个事务执行了大约18万个逻辑读,在这个例子中,有一些大的事务被执行,因此很高的读取数目是可以接受的。

Physical writes:平均每秒数据库写磁盘的block数。

User calls:每秒用户call次数。

Parses和Hard parses:每秒大约1.12个解析,其中有4%为硬解析,系统每25秒分析一些SQL,都还不错。对于优化好的系统,运行了好几天后,这一列应该达到0,所有的sql在一段时间后都应该在共享池中。

Sorts:每秒产生的排序次数。

Executes:每秒执行次数。

Transactions:每秒产生的事务数,反映数据库任务繁重与否。

% Blocks changed per Read: 54.27 Recursive Call %: 86.94

Rollback per transaction %: 12.00 Rows per Sort: 32.59

% Blocks changed per Read:说明46%的逻辑读是用于那些只读的而不是可修改的块,该系统只更新54%的块。

Rollback per transaction %:事务回滚的百分比。计算公式为:Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%。本例中每8.33个事务导致一个回滚。如果回滚率过高,可能说明数据库经历了太多的无效操作。过多的回滚可能还会带来Undo Block的竞争。

3.实例命中率

该部分可以提前找出ORACLE潜在将要发生的性能问题,很重要。

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %: 100.00 Redo NoWait %: 100.00

Buffer Hit %: 99.42 In-memory Sort %: 100.00

Library Hit %: 98.1