使用Statspack的幾個(gè)誤區(qū)
2024-07-21 02:08:17
供稿：網(wǎng)友
使用statspack的幾個(gè)誤區(qū)
作者: fenng
statspack 是 oracle 提供的一個(gè)實(shí)例級的tuning工具。很多dba都喜歡用這個(gè)工具來進(jìn)行數(shù)據(jù)庫的優(yōu)化調(diào)
整。不過在交流中發(fā)現(xiàn)很多朋友對這個(gè)工具的的運(yùn)用還有一些 問題。下面就其中比較容易出問題的幾個(gè)方面進(jìn)
行一下簡單的分析。
關(guān)于快照的采樣時(shí)間間隔問題
我們知道，statspack的report實(shí)際上也就是對比兩個(gè)快照 (snapshot，也就是數(shù)據(jù)庫當(dāng)前狀態(tài) ) 得出的結(jié)
果。
一般情況下，專家建議生成statspack報(bào)告的快照時(shí)間間隔為15-30分鐘。
試想，一個(gè)人去醫(yī)院看病，醫(yī)生對其測量體溫，一般也就是5-10分鐘左右就可以了， 為什么是這麼長的時(shí)間？
因?yàn)?-10分鐘這段時(shí)間基本可以近似的得到你的體溫。如 果時(shí)間過短，可能達(dá)不到既定的目的，測到的體溫會
偏低，時(shí)間過長，甚至長達(dá)幾 個(gè)小時(shí)的話(假設(shè)有這種情況)，病人可能都昏迷幾次了 ;) 。
對生成statspack報(bào)告的快照時(shí)間間隔也是這樣，如果兩個(gè)snap time時(shí)間過短，數(shù)據(jù) 庫的一些主要周期性
事務(wù)可能還沒有運(yùn)行，信息收集不完全。如果間隔過長，數(shù)據(jù)一樣會有偏差。
假設(shè)如下的情況：系統(tǒng)一直正常，但是最近幾天有用戶反映，在a時(shí)間段應(yīng)用程序執(zhí)行 很慢。b時(shí)間段正常，而
a時(shí)間段有一個(gè)主要的事務(wù)x運(yùn)行（也是用戶使用到的事務(wù)）。 b時(shí)間段有另外一個(gè)比較消耗資源的事務(wù)y在運(yùn)
行。a和b時(shí)間段的跨度比較大。本來你的 快照如果覆蓋a時(shí)間段內(nèi)就已經(jīng)能夠的收集到比較準(zhǔn)確的數(shù)據(jù)了，但
不巧的是，你的report 所用的兩個(gè)snap id的時(shí)間跨度太長，從而把b時(shí)間段內(nèi)的統(tǒng)計(jì)數(shù)據(jù)也收集了進(jìn)來。
statspack 經(jīng)過比較，“認(rèn)為”事務(wù)y是對系統(tǒng)有主要影響(這也會在report上體現(xiàn)出來)，而你，經(jīng)過分析，認(rèn)
為y才是罪魁禍?zhǔn)祝酉聛?，你不遺余力的對y進(jìn)行了tuning......
問題出現(xiàn)了！調(diào)整了b之后，用戶繼續(xù)報(bào)告，a時(shí)間段內(nèi)系統(tǒng)不但沒有變快，反而變得更慢，甚至不可忍受。這
種情況是很危險(xiǎn) 的，可能會對系統(tǒng)造成不同程序的損害。在比較嚴(yán)格的環(huán)境中，這已經(jīng)構(gòu)成了一次比較嚴(yán)重的
事故。
或許你也要承認(rèn)，statspack的快照的采樣時(shí)間間隔還真需要重視呢......
這是一個(gè)oracle 8.1.7.0.1 版本下的statspack報(bào)告：
snap id snap time sessions
------- ------------------ --------
begin snap: 637 04-aug-03 11:59:33 25
end snap: 646 04-aug-03 16:29:06 25
elapsed: 269.55 (mins)
從中可以看到快照637和快照646之間為269.55 (mins)。這么長的時(shí)間跨度，即使數(shù)據(jù)庫在一定時(shí)間間隔內(nèi)
有問題，在這里的體現(xiàn)也會有偏差?！?br>
下面的這個(gè)statspack 報(bào)告的時(shí)間有點(diǎn)不靠譜了：
snap length
start id end id start time end time (minutes)
-------- -------- -------------------- -------------------- -----------
314 1053 11-dec-03 18:07:13 19-dec-03 10:53:02 11,085.82
11,085.82分鐘? 這么長時(shí)間內(nèi)的數(shù)據(jù)采集分析，怕是絕大部分內(nèi)容都是不能相信的了。
還要注意的是，我們說的時(shí)間間隔，是begin snap和end snap之間的間隔，而不是相鄰兩個(gè)snap 之間的
間隔。對于snap收集的間隔，建議以不要影響性能為準(zhǔn)，收集的太過于頻繁，會對性能和 存儲都造成壓力。
對于所謂的15-30分鐘，不能墨守成規(guī)。具體的環(huán)境下應(yīng)該加以調(diào)整。
以偏概全
statspack從本質(zhì)上說，是對系統(tǒng)的性能統(tǒng)計(jì)數(shù)據(jù)進(jìn)行采樣，然后進(jìn)行分析，采樣，就會有偏差。如何消除偏
差？統(tǒng)計(jì)學(xué)指出"差值隨樣品個(gè)數(shù)的增加而降低"。所以，只憑借一個(gè)report文檔就 斷定數(shù)據(jù)庫的性能問題出
在某處，是比較武斷的做法（個(gè)別情況除外）。還要dba多創(chuàng)建report，對比進(jìn)行分析，會起到很好的效果。
在尋求技術(shù)支持的時(shí)候也最好能夠多提交幾份report，便于 支持人員迅速幫助解決問題。
有關(guān)timed_statistics參數(shù)
雖然這算是一個(gè)低級的錯(cuò)誤，還是很遺憾，常?？吹揭恍┡笥褜@個(gè)參數(shù)的忽略．如果在 timed_statistics的
值設(shè)置為false的時(shí)候進(jìn)行收集，可以說，收集到的東西用處不是很大 (我想你不會只想看一些實(shí)例名字、初始
化參數(shù)之類的信息吧)。甚至可以說，如果該參數(shù)不設(shè)置為true，性能分析無從說起。
相關(guān)信息
《expert one-on-one oracle》 by thomas kyte
《advanced tuning with statspack》 from otn
《statspack使用指南》 by eygle
《performance tuning with statspack》partii from otn
《performance tuning with statspack》parti from otn
原文出處：
<a >http://www.dbanotes.net/oracle/aboutstatspack.htm</a>
