惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

P
Privacy International News Feed
Hacker News - Newest:
Hacker News - Newest: "LLM"
Application and Cybersecurity Blog
Application and Cybersecurity Blog
N
News and Events Feed by Topic
Hacker News: Ask HN
Hacker News: Ask HN
V2EX - 技术
V2EX - 技术
L
LINUX DO - 最新话题
Google Online Security Blog
Google Online Security Blog
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
Stack Overflow Blog
Stack Overflow Blog
Recent Commits to openclaw:main
Recent Commits to openclaw:main
P
Proofpoint News Feed
A
Arctic Wolf
Forbes - Security
Forbes - Security
Spread Privacy
Spread Privacy
Security Latest
Security Latest
C
CXSECURITY Database RSS Feed - CXSecurity.com
C
CERT Recently Published Vulnerability Notes
Latest news
Latest news
AWS News Blog
AWS News Blog
M
MIT News - Artificial intelligence
GbyAI
GbyAI
V
Visual Studio Blog
T
The Blog of Author Tim Ferriss
有赞技术团队
有赞技术团队
Help Net Security
Help Net Security
博客园 - Franky
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
S
Schneier on Security
S
SegmentFault 最新的问题
Microsoft Security Blog
Microsoft Security Blog
Y
Y Combinator Blog
PCI Perspectives
PCI Perspectives
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
博客园_首页
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
P
Palo Alto Networks Blog
SecWiki News
SecWiki News
TaoSecurity Blog
TaoSecurity Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
K
Kaspersky official blog
G
Google Developers Blog
H
Hacker News: Front Page
T
Tailwind CSS Blog
aimingoo的专栏
aimingoo的专栏
博客园 - 叶小钗
T
Troy Hunt's Blog
F
Full Disclosure
T
Threat Research - Cisco Blogs

博客园 - 小光_520

这个博客18年了.. C#基础概念之延迟加载(转) 把EXCEL文件导入到GridView,GridView根据要求动态的增加列(转) C# ASP.NET CSV文件导入数据库(转) GridView 使用方法总结二(转) GridView 使用方法总结一(转) 单条SQL语句实现复杂逻辑几例(转) Statspack之十四-"log file sync" 等待事件(转贴) Statspack之十三-Enqueue(转贴) Statspack之十二-db file scattered read-DB文件分散读取(转帖) Statspack之十-调整STATSPACK的收集门限(转帖) Statspack之九-其它重要脚本(转帖) Statspack之八-删除历史数据(转帖) Statspack之七-移除定时任务(转贴) Statspack之六-生成分析报告(转贴) Statspack之五-规划自动任务(转贴) Statspack之四-测试安装好的Statspack(转贴) Statspack之三-安装statspack(转贴) Statspack之二-需要更改的系统参数(转贴)
Statspack之十一-Statspack报告各部分简要说明(转帖)
小光_520 · 2011-09-07 · via 博客园 - 小光_520
    • 第一部分

数据库概要信息

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的竞争

该参数计算公式如下:
Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% ……………. user commits 31,910 12.9 0.6 user rollbacks 19,740 8.0 0.4 …………….
对于本例:
Round(19740 / (31910 + 19740),4) = .3822

这一部分的内容还没有写完,在继续进行中...

转自:http://www.eygle.com/statspack/statspack11.htm