兰色精灵 发表于 2015-1-16 22:30:44

MSSQL教程之利用Statspack的几个误区

这里我们讨论用binlog来实现闪回的方案。
利用Statspack的几个误区

作者:Fenng


Statspack是Oracle供应的一个实例级的Tuning工具。良多DBA都喜好用这个工具来举行数据库的优化调
整。不外在交换中发明良多伴侣对这个工具的的使用另有一些成绩。上面就个中对照简单出成绩的几个方面进
行一下复杂的剖析。


关于快照的采样工夫距离成绩

我们晓得,Statspack的report实践上也就是对照两个快照(Snapshot,也就是数据库以后形态)得出的结
果。

一样平常情形下,专家倡议天生Statspack呈报的快照工夫距离为15-30分钟。

试想,一团体往病院看病,大夫对其丈量体温,一样平常也就是5-10分钟摆布就能够了,为何是这麽长的工夫?
由于5-10分钟这段工夫基础能够近似的失掉你的体温。如果工夫太短,大概达不到既定的目标,测到的体温会
偏低,工夫太长,乃至长达几个小时的话(假定有这类情形),病人大概都昏倒几回了;)。

对天生Statspack呈报的快照工夫距离也是如许,假如两个SnapTime工夫太短,数据库的一些次要周期性
事件大概还没有运转,信息搜集不完整。假如距离太长,数据一样会有偏向。

假定以下的情形:体系一向一般,可是比来几天有效户反应,在A工夫段使用程序实行很慢。B工夫段一般,而
A工夫段有一个次要的事件X运转(也是用户利用到的事件)。B工夫段有别的一个对照损耗资本的事件Y在运
行。A和B工夫段的跨度对照年夜。原本你的快照假如掩盖A工夫段内就已可以的搜集到对照正确的数据了,但
不巧的是,你的Report所用的两个SnapID的工夫跨度太长,从而把B工夫段内的统计数据也搜集了出去。
Statspack经由对照,“以为”事件Y是对体系有次要影响(这也会在Report上表现出来),而你,经由剖析,认
为Y才是祸首罪魁,接上去,你尽心尽力的对Y举行了tuning......

成绩呈现了!调剂了B以后,用户持续呈报,A工夫段内体系不仅没有变快,反而变得更慢,乃至不成忍耐。这
种情形是很伤害的,大概会对体系形成分歧程序的伤害。在对照严厉的情况中,这已组成了一次对照严峻的
变乱。

也许你也要供认,Statspack的快照的采样工夫距离还真必要器重呢......

这是一个Oracle 8.1.7.0.1 版本下的Statspack呈报:





SnapIdSnapTimeSessions
---------------------------------
BeginSnap:63704-Aug-0311:59:3325
EndSnap:64604-Aug-0316:29:0625
Elapsed:269.55(mins)




从中能够看到快照637和快照646之间为269.55(mins)。这么长的工夫跨度,即便数据库在必定工夫距离内
有成绩,在这里的表现也会有偏向。 

上面的这个Statspack呈报的工夫有点不靠谱了:





SnapLength
StartIdEndIdStartTimeEndTime(Minutes)
-------------------------------------------------------------------
314105311-Dec-0318:07:1319-Dec-0310:53:0211,085.82


11,085.82分钟?这么长工夫内的数据收罗剖析,怕是尽年夜部份内容都是不克不及信任的了。

还要注重的是,我们说的工夫距离,是BeginSnap和EndSnap之间的距离,而不是相邻两个Snap之间的
距离。关于Snap搜集的距离,倡议以不要影响功能为准,搜集的太甚于频仍,会对功能和存储都形成压力。
关于所谓的15-30分钟,不克不及抱残守缺。详细的情况下应当加以调剂。

以偏概全

Statspack从实质上说,是对体系的功能统计数据举行采样,然落后行剖析,采样,就会有偏向。怎样打消偏
差?统计学指出"差值随样品个数的增添而下降"。以是,只依附一个Report文档就判定数据库的功能成绩出
在某处,是对照果断的做法(一般情形除外)。还要DBA多创立Report,对照举行剖析,会起到很好的效果。
在追求手艺撑持的时分也最好可以多提交几份Report,便于撑持职员敏捷匡助办理成绩。


有关Timed_statistics参数

固然这算是一个初级的毛病,仍是很遗憾,经常看到一些伴侣对这个参数的疏忽.假如在Timed_statistics的
值设置为False的时分举行搜集,能够说,搜集到的器材用途不是很年夜(我想你不会只想看一些实例名字、初始
化参数之类的信息吧)。乃至能够说,假如该参数不设置为True,功能剖析无从提及。


相干信息

《Expertone-on-oneOracle》byThomasKyte
《AdvancedTuningwithStatspack》 From OTN
《Statspack利用指南》 byeygle
《PerformanceTuningwithStatspack》PartII From OTN
《PerformanceTuningwithStatspack》PartI From OTN



原文出处:
<ahref="http://www.dbanotes.net/Oracle/AboutStatspack.htm">http://www.dbanotes.net/Oracle/AboutStatspack.htm</a>


线上或者测试环境经常出现的误操作总是让DBA同学那么闹心。

莫相离 发表于 2015-1-17 12:01:03

如果我们从集合论(关系代数)的角度来看,一张数据库的表就是一组数据元的关系,而每个SQL语句会改变一种或数种关系,从而产生出新的数据元的关系(即产生新的表)。

灵魂腐蚀 发表于 2015-1-20 18:30:11

可能有的朋友会抱怨集成的orderby,其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率,可以为orderby的字段建立聚集索引,查询计划会忽略orderby操作(因为本来就是排序的嘛)。

海妖 发表于 2015-1-29 14:26:15

也可谈一下你是怎么优化存储过程的?

透明 发表于 2015-2-6 01:55:29

SP4是一个累积性的ServicePack,包含自以前的ServicePack发布以来所有的修补程序(包括MS03-031安全公告)。

愤怒的大鸟 发表于 2015-2-14 21:35:00

代替了原来VB式的错误判断。比Oracle高级不少。

因胸联盟 发表于 2015-3-4 10:43:45

入门没那么困难,精通没那么容易

冷月葬花魂 发表于 2015-3-11 18:24:01

对于数据库来说,查询是数据库的灵魂,那么SQL查询效率究竟效率如何呢?下文将带对SQL查询的相关问题进行讨论,供您参考。

简单生活 发表于 2015-3-11 18:23:57

每天坚持做不一样的是,认真做笔录,定时复习。一个月你就可以有一定的收获。当然如果你想在sql方面有一定的造诣,你少不了需要看很多很多的书籍了。

蒙在股里 发表于 2015-3-19 07:20:09

是否碎片会引发效率问题?这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

再现理想 发表于 2015-3-27 12:29:41

换言之,只有在不断的失败中尝试成功,而关于失败的总结却是很少的
页: [1]
查看完整版本: MSSQL教程之利用Statspack的几个误区