oracle 9i Statspack测试报告.docx
- 文档编号:30037170
- 上传时间:2023-08-04
- 格式:DOCX
- 页数:44
- 大小:37.96KB
oracle 9i Statspack测试报告.docx
《oracle 9i Statspack测试报告.docx》由会员分享,可在线阅读,更多相关《oracle 9i Statspack测试报告.docx(44页珍藏版)》请在冰豆网上搜索。
oracle9iStatspack测试报告
oracle9iStatspack测试报告
测试环境:
OS:
windowXp
DBracle9.2.0.1
一、Statspack的安装
1、从sqlplus登陆数据库
SQL>conn/assysdba
2、创建一个Statspack表空间,要求80M以上或者使用已经存在的表空间,但必须有80M以上的空闲空间
SQL>createtablespacestatspackdatafile'
3、执行安装脚本,在Oracle_Home\dbms\admin下:
SQL>@D:
\oracle\rdbms\admin\spcreate.sql
注:
创建过程中会提示输入perfstat的密码、默认表空间和默认临时表空间。
perfstat密码任意设置,默认表空间为上一步创建的表空间:
staspack,默认临时表空间为temp。
4、检查当前用户是否为perfstat:
SQL>showuser
USER为"perfstat"
注:
如果不是perfstat,则手动用perfstsat登陆。
SQL>connperfstat/****(上一步设置的perfstat的密码)
二、如果安装过程出错,怎么纠正
1、必须先用SYS用户登陆数据库
SQL>conn/assysdba
2、先删除之前创建的对象,然后再重新创建
SQL>@D:
\oracle\rdbms\admin\spdrop.sql
SQL>@D:
\oracle\rdbms\admin\spcreate.sql
三、手工采样生成报告
1、手工抓取快照,必须2次或更过:
SQL>execstatspack.snap;
---间隔一段时间
SQL>execstatspack.snap;
2、生成报告
SQL>@D:
\oracle\rdbms\admin\spreport.sql
输入begin_snap的值:
1
输入end_snap的值:
100
输入report_name的值:
\report.txt
---以上输入内容根据自己的需要输入。
begin_snap开始快照点,end_snap终止快找点,report_name报告名(最好包括目录和文件名,便于以后查看生成报告)
3、根据report_name输入的报告地址,用文本编辑器等打开生成的报告,具体情况具体分析。
四、系统自动采样数据
1、修改spauto.sql内容,定义定时任务,定义采样数据的时间间隔:
bms_job.submit(:
jobno,’statspack.snap;’,trunc(sysdate+1/24,”HH”),’trunc(sysdate+1/24,”HH”),TRUE,:
instno);
一天24小时,1440分钟,则:
每小时一次:
1/24(建议使用)
每30分钟一次:
1/48
每10分钟一次:
1/144
每5分钟一次:
1/288
2、运行自动执行脚本
SQL>@D:
\oracle\rdbms\admin\spauto.sql
3、运行生成报告脚本
SQL>@D:
\oracle\rdbms\admin\spreport.sql
五、删除系统自动采job
1、检查任务中是否有这个任务,并记下该job的ID
SQL>selectjob,intervalfromuser_jobs;;
2、根据查到的job_id删除任务
SQL>connperfstat/oracle
SQL>execdbms_job.remove(job_id);
3、删除历史数据
SQL>deletefromstats$snapshotwheresnap_id
?
?
4、删除全部数据
SQL>@D:
\oracle\rdbms\admin\sptrunc.sql
6、Statspack报告说明
1.数据库总体信息
2.每秒每事务的资源消耗情况
3.实例的各组件的命中率
4.共享池总体情况
5.前5个等待事件
6.DB所有等待事件
7.后台进程等待事件
8.根据BufferGets进行排序的SQL
9.按物理IO进行排序的SQL
10.按执行次数排序的SQL
11.按分析次数排序的SQL
12.实例的当前活动的统计数据
13.tablespaceIO统计数据
14.表空间文件IO统计数据
15.buffer池统计数据
16.实例恢复统计数据
17.Buffer池的参考数据
18.Buffer等待统计数据
19.PGA总体统计数据1
20.PGA总体统计数据2
21.PGA内存参考数据
22.回滚段统计
23.回滚段存储统计
24.undo段总体情况
25.undo段统计
26.锁存器的当前情况
27.锁存器睡眠等待统计
28.锁存器失败情况(对系统影响不大)
29.数据字典cache性能统计(由oracle自己管理,可以忽略)
30.库cache性能统计
31.共享池性能统计(遗漏,没有总结)
32.SGA区总体情况
33.SGA各组件的活动情况
34.系统配置参数
以下是生成报告的各部分信息的解释(只列出了每一部分的头部和描述):
STATSPACKreportfor
---------------------------------------------------------------------
---------------------1.DB的总体信息---------------------------------
---------------------------------------------------------------------
(数据库和实例的名字)
DBNameDBIdInstanceInstNumReleaseClusterHost
----------------------------------------------------------------
MYDB2125240762mydb19.2.0.1.0NOVCS-SERVER1
SnapIdSnapTimeSessionsCurs/SessComment
------------------------------------------------------------
BeginSnap:
109-Aug-0419:
28:
12322.7
EndSnap:
209-Aug-0419:
33:
06323.0
Elapsed:
4.90(mins)(本次报告的间隔时间)
CacheSizes(end)(当前缓冲区主要部件的配置)
~~~~~~~~~~~~~~~~~
BufferCache:
1,536MStdBlockSize:
8K
SharedPoolSize:
112MLogBuffer:
16,000K
---------------------------------------------------------------------
---------------2.每秒每事务的资源消耗情况----------------------------
---------------------------------------------------------------------
LoadProfile(加载配置文件)
------------------PerSecond(每秒)PerTransaction(每事务)-------
Redosize:
38,498.936,733.30–每秒/每事务产生的redo大小
Logicalreads:
593.28103.76–每秒/每事务逻辑读
Blockchanges:
77.6013.57–每秒/每事务修改的块数
Physicalreads:
2.650.46--每秒/每事务物理读
Physicalwrites:
8.171.43—每秒/每事务物理写
Usercalls:
38.326.70
Parses:
6.521.14--SQL分析的次数
Hardparses:
0.050.01–SQL硬分析的次数
Sorts:
0.730.13--
Logons:
0.010.00
Executes:
39.646.93
Transactions:
5.72
%BlockschangedperRead:
13.08RecursiveCall%:
24.84
Rollbackpertransaction%:
0.00RowsperSort:
138.04
说明:
RedoSize——PerSecond:
每秒产生的日志大小(单位字节)可标志数据库任务的繁重与否
RedoSize——PerTransaction:
平均每个事务的日志生成量(单位字节)
LogicalReads——PerSecond(逻辑读):
平均每秒产生的逻辑读,单位是block
LogicalReads——PerTransaction:
平均每个事务产生的逻辑读,单位是block
BlockChanges——PerSecond:
每秒block变化数量,数据库事务带来改变的块数量
BlockChanges——PerTransaction:
平均每个事务所导致的改变的块数
PhysicalReads——PerSecond:
平均每秒数据库从磁盘读取的block数,单位是block
PhysicalReads——PerTransaction:
平均每个事务从磁盘读取的block数,单位是block
PhysicalWrite——PerSecond:
平均每秒写磁盘的block数
PhysicalWrite——PerTransaction:
平均每个事务写磁盘的block数
UserCalls——PerSecond:
每秒用户call次数
UserCalls——PerTransaction:
每事务用户call次数
Parses——PerSecond:
每秒解析次数,近似反应了每秒语句的执行次数
Parses——PerTransaction:
每事务产生的解析次数
HardParses——PerSecond:
每秒产生的硬解析次数
HardParses——PerTransaction:
每事务产生的硬解析次数
Sorts——PerSecond:
每秒产生的排序次数
Sorts——PerTransaction:
#5#每事务产生的排序次数
Transactions——PerSecond:
每秒产生的事务数
Executes——PerSecond:
每秒执行次数
Execute——PerTransaction:
每个事务执行次数
Logons——PerSecond:
每秒钟有多少次logon
硬分析:
就是之前不存在此SQL,是第一次解析。
如果SQL重用度很高,则硬解析应保持很低。
%BlockschangedperRead:
表示逻辑读用于只读而不是修改的块的比例。
发生变化的块数/读次数,即每次Read有百分之多少的block发生了变化。
变化的块
RecursiveCall%:
递归操作占所有操作的比率
Rollbackpertransaction%:
事务的回滚率
RowsperSort:
每次排序所涉及到的行数
---------------------------------------------------------------------
----------------3.实例的各组件的命中率------------------------------
---------------------------------------------------------------------
InstanceEfficiencyPercentages(Target100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BufferNowait%:
100.00RedoNoWait%:
100.00
BufferHit%:
99.55In-memorySort%:
100.00
LibraryHit%:
99.33SoftParse%:
99.16
ExecutetoParse%:
83.56LatchHit%:
99.99
ParseCPUtoParseElapsd%:
%Non-ParseCPU:
说明:
BufferNowait%:
即BufferNowaitRatio,在缓冲区中获取buffer的未等待比率。
RedoNowait:
写日志的不等待比率,太低可调整log_buffer(增加)和_log_io_size(减小,默认为1/3*log_buffer/log_block_size,使得_log_io_size为合适的值,比如128k/log_block_size)。
BufferHit:
即DataBufferHitRatio,数据块在数据缓冲区中的命中率,通常应该在90%以上,否则考虑加大db_block_buffers(9i以上可是db_cache_size)。
In-memorySort%:
即InMemorySortRatio,如果过低说明有大量的排序在临时表空间中进行,可尝试增加sort_area_size,很多时候也需要检查一下是否存在不良SQL。
LibraryHit%:
即LibraryHitRatio,主要代表着sql在共享区的命中率,通常在98%以上
SoftParse%:
即SoftParseRatio,近似当作sql在共享区的命中率,通常高代表使用了绑定变量,太低需要调整应用使用绑定变量,或者参考cursor_sharing=force。
ExecutetoParse%:
是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。
该值越高表示一次解析后被重复执行的次数越多,如果过低可以考虑设置session_cached_cursors>0
LatchHit:
内部结构维护锁命中率,高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多,可参考_spin_count参数设置。
SoftParse%:
软分析:
即在共享池中重复使用的SQL,系统应保持较高的软分析率,否则说明系统的SQL没有绑定变量。
Non-ParseCPU:
查询实际运行时间/(查询实际运行时间+sql解析时间),该值大于95%比较好,太低表示解析消耗时间过长。
ParseCPUtoParseElapsd%:
用于分析每个CPU花费的秒数,应该处于较高比例。
如果=100%,说明CPU没有等待。
---------------------------------------------------------------------
---------------------4.共享池总体情况-------------------------------
---------------------------------------------------------------------
SharedPoolStatisticsBeginEnd
MemoryUsage%:
89.9190.55
%SQLwithexecutions>1:
32.1432.67
%MemoryforSQLw/exec>1:
31.3033.38
说明:
MemoryUsage%:
正在使用的共享池的%,这个值应保持在75%~90%,如果这个值太低浪费内存,如果太高内存不足,会使共享池外部的组件老化,如果SQL语句被再次执行,则就会发生硬分析。
%SQLwithexecutions>1:
共享池中执行次数大于1的sql的比率(若太小可能是没有使用绑定变量)
%MemoryforSQLw/exec>1:
频繁使用的SQL语句消耗内存多少的比例。
即PercentofMemoryforSQlwithExecution,执行次数大于1的sql消耗内存/(所有sql消耗内存)
---------------------------------------------------------------------
------------------------5.前5个等待事件-----------------------------
---------------------------------------------------------------------
Top5TimedEvents
~~~~~~~~~~~~~~~~~~%Total
EventWaitsTime(s)ElaTime
---------------------------------------------------------------------
logfilesync1,682232.30
dbfilesequentialread623346.70
dbfileparallelwrite7,780114,3213.97
dbfilescatteredread8,56070,9452.46
bufferbusywaits12,30340,0581.39
---------------------------------------------------------------------
说明:
logfilesync:
当一个用户的会话提交时,会话的重写信息需要刷新到重做日志文件中,这个用户会话将发送LGWR将日志缓冲写到重做日志文件,当LGWR已经完成写入操作时,它将发送这个用户会话。
当commit发生时,会产生logfilesync.减少commit频率,加快redo的写速度来改善此等待。
另外也需要考察IO子系统的配置是否存在问题,例如可以考虑将redologfile与数据文件分开存放,并将redologfile放到rawdevice上面。
dbfilesequentialread:
和索引扫描有关,查看IO统计,解决IO冲突;加大db_block_buffers;修改应用,减少IO。
dbfilescatteredread:
当ORACLE全表扫描时,一次需读多个数据块,此时使用这一等待事件。
init.ora中的db▁file▁mutiblock▁read▁count定义了多数据块读取时,一次能读取的最大块数。
一般此参数定义为4—16,与数据库大小无关。
但值越大DB▁BLOCK▁SlZE应越小。
如果dbfilescatteredread所占比例较大,必须减少IO的代价(如使用更快的磁盘,均衡IO分布),或减少全表扫描的次数(优化SQL语句)。
(多blocks读;解决方法是修改db_file_multiblock_read_count;让表cache;
用下列语句查找IO过量的session:
SELECTsid,total_waits,time_waited
FROMv$session_event
WHEREevent='dbfilescatteredread'
andtotal_waits>0
ORDERBY3,2;
bufferbusywaits:
有两个原因会引起bufferbusywaits,1.其他的session在将数据读到block中,2.其他的session对block加了锁,与请求的锁不兼容。
如果bufferbusywaits等待的时间过长的话,我们要去查询是哪一部分(查看report.txt中bufferbusywaitsstatistics的统计):
SELECTcount,file#,name
FROMx$kcbfwait,v$datafile
WHEREindx+1=file#
ORDERBYcount;
SELECTp1"File",p2"Block",p3"Reason"
FROMv$session_wait
WHEREevent='bufferbusywaits';
SELECTdistinctowner,segment_name,segment_type
FROMdba_extents
WHEREfile_id=&FILE_ID
and&BLOCK_NUMBERbetweenblock_idandblock_id+blocks-1;
WaitTime:
等待时间包括日志缓冲的写入和发送操作。
Top5TimedEvents
~~~~~~~~~~~~~~~~~~%Total
EventWaitsTime(s)ElaTime
---------------------------------------------------------------------------
globalcachecrrequest147,32469819.66
bufferbusyglobalCR7,43568219.22
globalcachenulltox85,66561317.27
CPUtime57416.17
bufferbusyglobalcache8,0122216.22
从owi方面看起来是符合之前讲的主要issue为bufferbusywaits及RAC相关的wait的。
分析:
目前MLB21上的主要等待事件为bufferbusywait,等待类别为datablock,实际上因datablock而触发的bufferbusywait等待事件下面两类:
1、一种是高并发会话在对相同的对象执行DML,同时db_block_size尺寸较大(因同一个块包含更多的行)
从抓取到的二条TOP合此类型(UPDATE&INSERT),较为合适的方法就是增大PCTFREE。
2、另外就是多个session并发请求相同的数据块,但因该数据块不在b
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- oracle 9i Statspack测试报告 Statspack 测试报告