June 25, 2004
Statspack之十一-Statspack报告各部分简要说明
作者:eygle
出处:http://blog.eygle.com
- 第一部分
数据库概要信息
|
DB Name DB Id Instance Inst Num Release Cluster Host ---------- ----------- ------------ -------- ----------- ------------ GLOB 188430914 glob 1 9.2.0.4.0 NO b02
|
- 第二部分
数据库采样时段，这一部分记录了数据库采样的时间，以及采样点数，这部分信息对于report来说是十分重要。
任何统计数据都需要通过时间纬度来衡量，离开了时间，任何数据都失去了意义。
我们在论坛上经常看到有人贴出Top 5等待事件寻求分析，我们的回答是:
无法分析，如果没有时间纬度!
|
Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 508 10-Nov-03 15:27:29 76 39.4
End Snap: 511 10-Nov-03 15:57:42 66 35.4
Elapsed: 30.22 (mins)
|
- 第三部分
主要性能指标说明:
- Execute to Parse %执行分析比率
|
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.81 In-memory Sort %: 100.00
Library Hit %: 98.75 Soft Parse %: 97.05
Execute to Parse %: 44.21 Latch Hit %: 94.79
Parse CPU to Parse Elapsd %: 11.74 % Non-Parse CPU: 96.08
|
执行分析比率计算公式如下:
|
100 * (1 - Parses/Executions) = Execute to Parse
|
所以如果系统Parses > Executions,就可能出现该比率小于0的情况.
该参数计算来自以下部分:
|
Instance Activity Stats for DB: ORA9 Instance: ora91 Snaps: 30 -32 Statistic Total per Second per Trans --------------------------------- ------------------ -------------- ------------ exchange deadlocks 481 0.2 0.0 execute count 4,873,158 1,968.2 94.4 …………… parse count (failures) 542 0.2 0.0 parse count (hard) 80,281 32.4 1.6 parse count (total) 2,718,643 1,098.0 52.6 parse time cpu 44,009 17.8 0.9 parse time elapsed 374,902 151.4 7.3 ……………………. |
通过公式及以上两个数值：
|
100 * (1 - Parses/Executions) = Execute to Parse
100 * (1 - 2,718,643/4,873,158) = 0.44211884777797067117462 * 100 = 44.21 |
该值<0通常说明shared pool设置或效率存在问题
造成反复解析，reparse可能较严重,或者可是同snapshot有关
如果该值为负值或者极低,通常说明数据库性能存在问题
- Parse CPU to Parse Elapsd %
来自parse time cpu和parse time elapsed
|
100*（parse time cpu / parse time elapsed）= Parse CPU to Parse Elapsd % 100*（44,009 / 374,902）= 11.7388010733471680599196590% = 11.74%
|
- Rollback per transaction 平均事务回滚率
|
% Blocks changed per Read: 0.37 Recursive Call %: 1.14 Rollback per transaction %: 38.22 Rows per Sort: 11.83 如果回滚率过高，可能说明你的数据库经历了太多的无效操作 过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下: |
这一部分的内容还没有写完,在继续进行中...
:)
Posted by eygle at 10:19 PM | Comments (9)
Oracle中Kill session的研究
作者:eygle
出处:http://blog.eygle.com
itpub link:
http://www.itpub.net/235873.html
我们知道,在Oracle数据库中,可以通过kill session的方式来终止一个进程,其基本语法结构为:
alter system kill session 'sid,serial#' ;
被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程.
我们发现当一个session被kill掉以后，该session的paddr被修改，如果有多个session被kill，那么多个session
的paddr都被更改为相同的进程地址:
|
SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null; SADDR SID SERIAL# PADDR USERNAME STATUS -------- ---------- ---------- -------- ------------------------------ -------- 542E0E6C 11 314 542B70E8 EYGLE INACTIVE 542E5044 18 662 542B6D38 SYS ACTIVE SQL> alter system kill session '11,314'; System altered. SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null; SADDR SID SERIAL# PADDR USERNAME STATUS -------- ---------- ---------- -------- ------------------------------ -------- 542E0E6C 11 314 542D6BD4 EYGLE KILLED 542E5044 18 662 542B6D38 SYS ACTIVE SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null; SADDR SID SERIAL# PADDR USERNAME STATUS -------- ---------- ---------- -------- ------------------------------ -------- 542E0E6C 11 314 542D6BD4 EYGLE KILLED 542E2AA4 14 397 542B7498 EQSP INACTIVE 542E5044 18 662 542B6D38 SYS ACTIVE SQL> alter system kill session '14,397'; System altered. SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null; SADDR SID SERIAL# PADDR USERNAME STATUS -------- ---------- ---------- -------- ------------------------------ -------- 542E0E6C 11 314 542D6BD4 EYGLE KILLED 542E2AA4 14 397 542D6BD4 EQSP KILLED 542E5044 18 662 542B6D38 SYS ACTIVE |
在这种情况下,很多时候，资源是无法释放的,我们需要查询spid，在操作系统级来kill这些进程.
但是由于此时v$session.paddr已经改变，我们无法通过v$session和v$process关联来获得spid
那还可以怎么办呢?
我们来看一下下面的查询:
|
SQL> SELECT s.username,s.status,
2 x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
3 decode(bitand (x.ksuprflg,2),0,null,1)
4 FROM x$ksupr x,v$session s
5 WHERE s.paddr(+)=x.addr
6 and bitand(ksspaflg,1)!=0;
USERNAME STATUS ADDR KSLLAPSC KSLLAPSN KSLLASPO KSLLID1R KS D
------------------------------ -------- -------- ---------- ---------- ------------ ---------- -- -
542B44A8 0 0 0
ACTIVE 542B4858 1 14 24069 0 1
ACTIVE 542B4C08 26 16 15901 0 1
ACTIVE 542B4FB8 7 46 24083 0 1
ACTIVE 542B5368 12 15 24081 0 1
ACTIVE 542B5718 15 46 24083 0 1
ACTIVE 542B5AC8 79 4 15923 0 1
ACTIVE 542B5E78 50 16 24085 0 1
ACTIVE 542B6228 754 15 24081 0 1
ACTIVE 542B65D8 1 14 24069 0 1
ACTIVE 542B6988 2 30 14571 0 1
USERNAME STATUS ADDR KSLLAPSC KSLLAPSN KSLLASPO KSLLID1R KS D
------------------------------ -------- -------- ---------- ---------- ------------ ---------- -- -
SYS ACTIVE 542B6D38 2 8 24071 0
542B70E8 1 15 24081 195 EV
542B7498 1 15 24081 195 EV
SYS INACTIVE 542B7848 0 0 0
SYS INACTIVE 542B7BF8 1 15 24081 195 EV
16 rows selected.
|
我们注意,红字标出的部分就是被Kill掉的进程的进程地址.
简化一点,其实就是如下概念:
SQL> select p.addr from v$process p where pid <> 1 ADDR
|
Ok，现在我们获得了进程地址，就可以在v$process中找到spid，然后可以使用Kill或者orakill在系统级来杀掉这些进程.
实际上,我猜测:
当在Oracle中kill session以后, Oracle只是简单的把相关session的paddr 指向同一个虚拟地址.
此时v$process和v$session失去关联,进程就此中断.
然后Oracle就等待PMON去清除这些Session.所以通常等待一个被标记为Killed的Session退出需要花费很长的时间.
如果此时被Kill的process，重新尝试执行任务，那么马上会收到进程中断的提示，process退出，此时Oracle会立即启动PMON
来清除该session.这被作为一次异常中断处理.
-The End-
Posted by eygle at 3:47 PM | Comments (7)